Believe it or not, an incremental software development methodology, a grandparent of today’s agile, dates to as early as the 1950s. It then took an evolutionary and adaptive form in the early 1970s, and finally in 2001 the agile as we now know it was born in the Manifesto for Agile Software Development (1).
For something that’s been hot for so long it is still misunderstood by many. Wikipedia’s short and sweet definition describes it as a “set of principles under which requirements and solutions evolve through the collaborative effort of self-organising cross-functional teams. Agile advocates adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change” (2).
One may say it is a rather wide term. Indeed, it is very crowded under the agile umbrella and apart from the popular Lean, Scrum or Kanban (honestly, these names) there are many more methods, plus all kinds of mixed approaches. In fact, in real life it seems like not just every team has its own way of agile working, but also nearly every project.
The challengeAlthough agile preaches to welcome changing requirements, even late in development, it also promises to satisfy the customer, through early and continuous delivery, which makes agile’s marriage with user research not always blissful and sometimes in need of counselling.
It may all be nice and easy if you are working on one digital product and you can delight your users with incremental changes, improving their experience from sprint to sprint, while new improvements are being researched and tested simultaneously. The reality is usually somewhat different and most of us face the challenge of fitting research into projects where time and budgets are limited (as they usually are).
There is no doubt that to build products that meet user needs, we do need to include user research in the process, research that at times can be perceived as slow and not always compatible with rapid iterations which characterise agile. There is a danger that if time is limited, UX research will get sacrificed and not produce the best results.
Working together for the common goal
Perhaps the key to success is to understand that the goal of agile is not speed but quality. Having that in mind we realise that we all – stakeholders, user experience professionals, designers and developers – are on the same page. It is not about lingering for a long time in the discovery phase of the project, but delivering a product which will meet the needs of the client and users, and provide the biggest impact. The up-front research is vital, but if requirements or goals change with time, additional research should also be considered iteratively and included in the backlog as with any other piece of work.
Doing it rightI guess everybody agrees on the importance of validating complex designs, and without user-centered activities and testing, even the best ideas are only assumptions. These can be overcome if we stick to a few simple rules:
- Research activities must be well planned, just as any other delivery activities
- All user research activities should occur either before the development stream or at least one step ahead of the sprint. Tackling the problems ahead of the rest of the team prevents deadlocks
- Research should be done with appropriate time efficient methods and tools, which include:
- Online tools that allow un-moderated usability testing, card sorting and tree testing studies (validating information architecture), online surveys etc.
- Simplified user testing on a small number of participants, click testing and contextual inquiry etc.
- Uncomplicated UX prototypes that demonstrate a single path or user journey through the system
- Heuristic evaluation (inspection against established usability guidelines)
- Research findings should be easy to consume: instead of heavy documentation the results should be delivered to the team and stakeholders in an easily digestible form, in sessions that accommodate discussion and dialog.
Agile methodologies support transparency and dialog. Including a user-centered approach to this dialog, adds to the value of agile.