When I was just starting my career, the software came in boxes. If this sounds strange to you, know that when I was a child, my father brought home punched cards on which programs were recorded in the 1970s. Such software had an end state. After 20 years from that moment, it already seemed ridiculous. Today we are creating systems that can be improved endlessly. This begs the question: “When does work end?” – and this question is difficult to answer. We are looking for the answer to this question, because it will help us answer other, even more important questions. Will the team receive their prize or will they report it? Will the team do something new? Will the stakeholder benefit?
Development teams that use Scrum (or any other variation of the Agile methodology) have a clear idea of when development ends. Often this means “a set of minimum criteria that a product / service must have to meet the needs of the business.” As a result, it comes down to a list of functions, which is approved by the stakeholder (or product owner’s) and at the time of completion of the project should be fully implemented. The developers call it “works as intended.”
But “working as intended” means only that the software does what they want from it. Unfortunately, sometimes this is not enough. In fact, this is only the beginning of a conversation that we conduct continuously with our users and customers. It is the continuous improvement of our systems to provide a better experience that gives them real value.
So, how can we define “shutdown” for a team? When does a team start a new project? Lack of ROI is a good place to start, but how do we know if there is no payback? The answer will be given to us by customers. We look at their behavior. We listen to their needs, evaluate whether our systems meet these needs and think what we can do to meet these ever-changing needs. We call these metrics the results.
And these results cannot be predicted, just as it is impossible to predict human behavior. Good results require team members to actively engage with customers in order to catch changes in their behavior, the reasons for their occurrence and opportunities to better meet customer needs in the future. The good news is that your company most likely already employs people who are especially good at these aspects – designers. Despite the fact that today designers are present in almost every company, most of them do not occupy high enough positions to influence the adoption of large decisions. In fact, many of them are left out of the reach of Agile development processes tailored for programmers and product managers.
The integration of designers in the Agile development process is an ongoing challenge for many organizations. Thanks to almost 20 years of experience in designing, managing and consulting product teams, I have identified the following 5 rules that a team must follow if it wants to make sure that user experience (UX) is successfully integrated into their Agile process:
1. A separate designer for each team
There can be no compromise. Without the “own” designer in the Scrum-team, you simply have a development team, which without a designer cannot provide the appropriate level of quality of user experience.
2. Team hours of work with clients
I learned this rule from Jared spoolwho conducted a study proving that teams spending at least 2 man-hours every 6 weeks communicate with customers (for example, receiving support calls, talking to users, watching people, etc.) are developing more successful products.
3. The work of the designer – the first point of backlog
In short: keep a single backlog. Development, quality control, design, research work – all this should lie in one backlog, prioritized by the entire team that performs this work. As soon as the work is divided into two backlogs, the team will choose one of them and decide to treat it as the “main” one, and the second will simply put it in the back box.
4. Results as prioritization filters for backlog
I AM a lot of wrote about the results (and Josh Seyden wrote about this whole a book), but the only thing I want to note in the context of today’s topic is that each backlog item must pass a filter of the team’s final goals. Ask yourself: “Will this work help achieve the goal?” If the answer is no, then discard this item.
5. Cross-functional training
User experience and design carry a lot of interesting things that are worth exploring. Such events can be conducted by designers (or analysts), but they must be practiced and attended by the whole team. The more a team can learn together, the less time it takes to share the knowledge gained, and more to decide where to apply it (which is a more productive subject of conversation for the team).
The iterative retrospective nature of Scrum is well suited to UX and design activities. The integration of customer insights into the work process comes directly from Agile Manifesto (work with clients, etc.). UX and design bring us closer to the Agile goal of customer focus and better customer satisfaction. Follow these 5 rules to combine design and agile development.