When the software first appeared, it was all delivered in boxes. Such software had a finite state. 20 years after that, it already seemed ridiculous. Today we're building systems that can be perfected endlessly. This begs the question: "When does the work end?" - and that question is difficult to answer. We are looking for an answer to this question because it will help us answer other, even more important questions. Will the team receive its award or will it be reprimanded? Will the team do something new? Will the stakeholder benefit from it?
Development teams that use Scrum (or any other variation of the Agile methodology) have a clear idea of when their development ends. This often means 'a set of minimum criteria that a product/service must have in order to meet business needs'. As a result, it all comes down to a list of functions that are approved by the stakeholder (or product owner) and must be fully implemented at the time the project is completed. Developers call it "working as intended".
But "works as intended" means only that the software does what it is expected to do. Unfortunately, sometimes this is not enough. In fact, this is just the beginning of a conversation that we have with our users and clients continuously. It is continuous improvement of our systems to provide better experience that gives them real value.
So, how can we define "completion" for the team? When does the team start a new project? No ROI is a good place to start, but how do we know there is no payback? The answer will be given to us by the clients. We look at their behavior. We listen to their needs, assess whether our systems meet those needs and think about what we can do to meet those ever-changing needs. We call these metrics results.
And these results are impossible to predict how one can't predict human behavior. Good results require team members to actively interact with clients to understand changes in their behaviour, why they are occurring and how they can better meet clients' needs in the future. The good news is that your company probably already employs people who are particularly good in these aspects - designers. Although there are designers present in almost every company today, most of them do not hold high enough positions to influence big decisions. In fact, many of them are left out of the Agile development processes, sharpened for programmers and product managers.
Integration of designers into the Agile development process is a constant challenge for many organizations.
With many years of experience designing, managing and consulting product teams, we at 8allocate have highlighted the following 5 rules that a team must follow if they want to ensure that user experience (UX) development is successfully integrated into their Agile process:
1. Separate designer for each team
There can be no compromises. Without your "own" designer in the Scrum team, you simply have a development team that, without a designer, cannot provide the right level of user experience.
2. Team hours with clients
We learned this rule from Jared Spool who conducted research proving that teams spending at least 2 man-hours every 6 weeks communicate with customers (e.g. receiving customer service calls, talking to users, watching people, etc.), develop more successful products.
3. Designer's work - the first item in the backlog
Briefly: Keep a single backlog. Development, quality control, design, research work - all this should be in one backlog, prioritized by the whole team that is doing the job. Once the work is divided into two backlogs, the team will choose one of them and decide to treat it as the "main" and the second one will simply be put aside in a long box.
4. Results as prioritization filters for backlog
The only thing we would like to note is that each backlog entry must pass the team's endpoint filter. Ask yourself the question, "Will this work help in achieving the goal? If the answer is no, then discard this item.
5. Cross-functional training
User experience and design have many interesting things to learn. Such events may be conducted by designers (or analysts), but they should be practiced and attended by the whole team. The more the team can learn together, the less time is spent sharing the knowledge gained and the more time is spent deciding where to apply it (which is a more productive subject for the team).
Scrum's iterative, retrospective nature is well suited to UX and design activities. The integration of client insides into the workflow comes directly from Agile Manifesto (work with clients, etc.). UX and design bring us closer to Agile's goal of customer focus and better customer satisfaction. Follow these 5 rules to combine design and Agile development.