The last few weeks have seen some heated debate over the advantages and disadvantages of agile and lean practices for creating great user experiences.
My perspective in these discussions comes from managing a number of software products and software development groups through the transition from waterfall to agile approaches. In these roles I created and owned the product concept and was responsible for its realisation in the delivered product. I found this much easier to do in agile rather than waterfall projects.
Earlier integration and test helps create better user experiences
I have seen several large waterfall projects crash and burn because components were integrated and tested far too late. By the time serious problems were found the release deadline was looming, most of the budget had already been spent and the people needed to resolve the problem had moved to other projects or even left the company.
The imperative on agile projects to “deliver working software frequently” should drive them towards frequent (continuous?) integration and test. Access to this early working software gives the UX specialists on the team the chance to inject some ‘undercover’ or ‘guerrilla‘ user testing. This will expose usability and usefulness issues before they grow too big and while there is still the time and resource to do something about them.
Lean development practices make this even more explicit by focusing on creating and rapidly testing a minimum viable product (MVP).
I also found this early integration really valuable in creating a consistent interaction style and visual style across a large product, as components produced in early iterations could act as exemplars for later components.
To really drive this home UX specialists in agile teams should push to get basic user testing included in their team’s ‘definition of done’ and push to get the most challenging user journeys built in early iterations.
Self-contained teams produce better products faster
For me, the second great benefit of an agile approach is having a self-contained team with all the skills needed to create the product and the authority to make its own decisions. This saves so much time and avoids so much frustration.
Many years ago I worked in an organisation that had separate teams of testers, developers, architects, product managers, analysts, writers, etc., with all the delays, back-biting and brick-throwing that you might expect. Bringing all these people together into agile teams has been painful, but ultimately incredibly rewarding. And bringing UX people into the mix is painful, but can bring the same rewards.
So UX specialists should join multi-disciplinary teams centred on products rather than try to stay on the outside.
The product roadmap provides the big picture
Common complaints about agile are the poor quality of the incoming stories or use cases, and the lack of a clear vision to tie them all together. In most of my jobs I was lucky enough to be able to maintain a longer-term roadmap for my products. And I saw the benefits this had for projects.
The product roadmap set out a clear vision for each new product or release. What it would provide to the business and to our customers, what it would contain, what design principles would guide it, etc. So when it came to building a new feature, while there was still detailed design work to do, the purpose of the feature was clear and its place in the big picture was clear.
The roadmap also helped to drive through broad improvements to usability, performance, reliability, etc. If all you have is a backlog of functionality-focussed stories, important but longer-term work too often gets squeezed out.
Lean development practices can also help as they put a clear product vision at the heart of the process. They also encourage teams to tease out the assumptions that support the product vision and construct tests that prove or disprove those assumptions.
So UX specialists should push their way into the product planning process, or push to create one if none exists. This is where you get to do your customer research and concept design, and where you get to create the big picture that carries through the project.
Agile does not mean ‘no documentation’
The Agile Manifesto states that “we have come to value … Working software over comprehensive documentation.” I heartily agree with this. When you are creating a software product or system, documentation is a means to an end. And working software is that end.
But somehow, for some teams, this has been warped into no documentation, no specifications, just code. As well as leading to the lack of a big picture that I described earlier, this also cuts the legs out from under the UX people on the team. As Hannah Donovan said, our superpower is visual storytelling. If we can’t draw concepts, personas, storyboards, etc., then how do we ‘talk’ to the rest of the team?
UX specialists should not expect the rest of the team to wait while they create a complete and comprehensive specification of every aspect of the design. But they can and should work with other members of the team to produce simple stories and sketches that communicate both the big picture for the product and the more detailed design of specific components.
A good way to think about this is the transition from always using a language like UML to create a complete specification of a software product before building anything, to using UML as a sketching language to help team-members communicate their design ideas, while they are building a product.
Understanding the UML as Sketch idea is a good way to understand and explain how UX outputs can fit into an agile project, and how UX specialists can make them into bite-sized chunks.
I know that it’s possible for UX and agile to work well together. But you need the right conditions:
While this is a personal take on agile and UX rooted in my own experience rather than any research, conversations with Johanna Kollmann and others from Agile UX Meetup suggest that I’m not completely wrong.
What do you think?
I guess the easiest way to explain my working life is as a journey in designing and making things. From my first Meccano and Lego sets and the labs and workshops at techn...