The UX problem with Agile

Without a doubt Agile is a great way of working, but it can be challenging from a user experience perspective. Fortunately there might be a way to make things better.

I have become a big fan of many elements of agile. I like the way teams operate in agile, the focus on user needs and the lightweight, iterative approach. But, there has always been one thing that I have found a challenge — working through functionality in a series of sprints.

Typically we split projects into a series of sprints with each sprint focusing on a set of content or functionality. 

At face value this makes a lot of sense, but from a user experience perspective it can be challenging. The problem is that it never allows for looking holistically at the entire picture. Decisions made in early sprints may need changing when we see their impact on functionality in later sprints.

It also makes usability testing tricky, because you don’t yet have a minimal viable product to test with. For example, how can you test information architecture without all content areas in place?

Sophia Voychehovski proposes a solution in her talk ‘The Simplicity Imperative’. She suggests that instead of structuring sprints around functionality, we structure them around fidelity.

In other words, sprint 1 might be a paper mockup of the entire minimal viable product. Sprint 2 might be a high fidelity wireframe and sprint 3 the final build.

It might not be necessary to run a whole project like this. But beginning in this way would help the UX designer see the bigger picture and result in something tangible to test much faster.

This isn’t an approach I have put into practice. But it does seem to address many of the misgivings I have about Agile from a design perspective. What do you think? Have you tried this approach? Do you think it could work? I would love the perspective of others before giving it ago myself.