When my colleague Patrick Goffin wrote his recent (Fr)agile blog post, it sparked some lively discussions here. What was particularly interesting was how our different backgrounds influenced our view of the advantages and disadvantages of agile processes for creating great user experiences.

My perspective 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. And 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. So they can catch problems before they grow too big and while they still have the time and resource to do something about them. This also requires some leadership within the agile team to prevent difficult tasks being continually pushed into later iterations.

I 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. And it is now giving UXers the chance to inject some 'undercover' or 'guerilla' user testing to expose usability and usefulness issues, and get them resolved earlier.

To really drive this home UXers should push to get basic user testing included in their team's 'definition of done' and push to get the 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, whingeing 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.

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 overall 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, these vital efforts too often get squeezed out.

So UXers 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 design 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 UXers on the team. As Hannah Donovan has said, "Your super power is that you can visualise things in your head and you can draw them." If we can't draw concepts, service blueprints, storyboards, wireframes, illustrations of design principles, etc., then how do we 'talk' to the rest of the team. Do we just wave our hands? Or try to explain everything in a tweet-sized story?

So while UXers should not expect the rest of the team to wait while they create a complete and comprehensive specification of every aspect of the design, UXers can and should produce drawings to 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 UXers can make them in bite-sized chunks.

So …

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?