Why agile can be good for user experience

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.

So…
I know that it’s possible for UX and agile to work well together. But you need the right conditions:

• UX specialists are part of the agile team
• The team has a clear product vision rooted in a real understanding of the customer
• UX specialists create stories and interface sketches in collaboration with other team members
• It’s not ‘done’ till you’ve tried it out with real users

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?

Further reading

• Blog: (Fr)agile

13/02/13 Rob Gillham said:

Agreed on all fronts John, particularly the shared vision part. Whilst Agile is superficially sympathetic to the practice of iterative 'testwith users & refine', the reality is that Agile was not designed with UX in mind, but to mitigate the risks of software development. The way in which functionality is ruthlessly culled to keep scope manageable and deliverable is bewildering and upsetting to many first-timers from the UX world. Having a shared vision for the customer experience that informs what to cut - and how - is important to ensure whatever remains still remains true to that vision.

14/02/13 Leslie Fountain said:

My experience with agile development is similar and it's good to see how we have moved from a developer led agile methodology to multidisciplinary scrum teams. With customer behaviour and technology evolving at a faster pace, agile also means that the final product is no longer out of date as in the days of waterfall.

21/02/13 Craig Sullivan said:

John - couldn't agree more. We did work with you guys when I was at Belron that encapsulated all of what you suggest here (ask Elsa!). The one team, rapid iteration of hypotheses, remote and lab testing - often supported by great tools and insight - was the lifeblood of the project work. What we were doing was a sort of blend of Kanban, Agile, Lean with analytics and split testing thrown in. We should certainly take a look at what I found out when we tried this stuff - and why the outcomes are so good. Would be great to do an article with you folks on this sometime. Leslie also hits a very good point here - not knowing what the product will finally be is part of the process. My analogy here is that with Waterfall, you set off in a tanker - the winds and tides push you away from the direction of an island (which moves too - the market). When you arrrive 150 miles away, you stop and then recalibrate and then do it all over again. It takes you 65 times to dock at the port. You might reach the island of Lovely UX and happy Business owner but you'll spend ages finally arriving - successively taking leaps but mainly not getting signfiicantly closer to your goal with *velocity*. It feels like movement but it's not in the right direction. WIth agile (and lean techniques) involved, you are continually flowing and adjusting the product towards that island. When you do arrive, you're there before everyone else arrivesand hit the sweet spot first time to market. It's a better way to live and work and teams love the continuous improvement and feedback this generates.

21/02/13 Jason Hanley said:

> It’s not ‘done’ till you’ve tried it out with real users This is really important advice. Too many times I've seen people argue about features and UX changes based on their own personal experience without actually testing it "in the wild."

25/02/13 John said:

Thanks for the comments guys. Absolutely Rob, I've seen too many agile projects fail because the final product is just the incoherent bag of features that made it into a sprint before the time and budget ran out. If you have no vision, how do you know what to keep and what to cut. Jason, shortcutting those debates is definitely the reason for the renewed focus on 'getting out of the building' and testing both your assumptions and your evolving product as often as possible. Craig, loved the tanker analogy. Too many people think that agile is about speed, when it is about adapting to uncertain and rapidly evolving requirements. You get their first, not because you travelled faster, but because you steered the best course and reached the best destination. Leslie, have a look at balancedteam.org and their emphasis on "multi-disciplinary collaboration and iterative delivery focused on customer value as a source for innovation."