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.

  • I’d also love to hear from people who’ve effectively put this into practice as UXers, especially anyone delivering it within an agency model (as opposed to in-house).

    The ‘low fidelity version of whole experience’ is in my mind much closer to how agile is really meant to work. The idea of just breaking down the work into sprints, but nonetheless working on it sequentially to a high level of fidelity each time, is really not much different from traditional project approaches. As someone (possibly David Bland at Lean Day London?) said: “you’re not iterating if you only do it once”.

    Alastair Cockburn advocates a similar approach from a development perspective when he talks about building the ‘walking skeleton’: “a tiny implementation of the system that performs an end-to-end function” He has several more posts on that whole approach you might want to check out.

    The essence of agile is to build a version of a thing, then make it better, then make it better again. Somewhere in all the ‘working software’ and ‘definitions of done’, the idea that it’s OK if the ‘working software’ is still a bit rough round the edges or lacking in features has been lost.

    I think also, as designers of any stripe, we get very easily sucked into designing and building to a high level of fidelity, rather than creating low-fidelity/low-quality versions of the fuller system. Agencies in particular are conditioned to think of deliverables as needing to be high-quality and high-fidelity. There’s a discomfort at the idea of delivering something low-fidelity or sketchy that we – and our clients, of course – need to get over.

  • I think what you are getting at is what I’ve heard called a design sprint(s). It happens in some instances before sprint 0. I was chatting with someone on an agile team at IBM recently and I liked their approach which is to define the requirements or MVP up front then have the designers split off for some sprints to work on UX, wireframing, etc… while the developers work on building services that don’t affect the UI at this point. Both teams should NOT work in a silo but they can still work in parallel in agile sprints. Once these design sprints are complete, you start the actual sprint 1, functional story sprints. I’ve actually written a post about this very recently that goes over the process I’ve carved out at my own job over the last 1.5 years:

  • Lots of folk do it this way ;-) It’s how agile processes have recommended folk build stuff for years. Here’s Jeff Patton talking about exactly those issues back in 2007/8 ;-)

  • Dan Winterberg

    Agile should be a tool in the toolbox, not a forced methodology. Hammers are great for nails, but you’re going to make a mess if you try to use one on a screw.

    For more iterative work, agile is pretty great. For designs/problems that require more holistic thinking, it often wastes more time than it’s trying to save. Better to give yourself a little space to solve those complex problems outside the agile cadence, then fold it back in to sprints once you’ve got it better figured out. At least that’s how I’ve seen it work best.

  • lightrocker

    If your doing it this way, your doing it wrong. Sprints should be “focused on a set of user goals and tasks” not a “set of content or functionality”. That way you can complete a sprint with a minimal viable product.

  • Tyler B

    I think you could really break things down into a hybrid of the two agile models you’ve presented.

    The fidelity build model can work great for working through and solving different UX challenges, presenting concepts and overarching ideas to clients, and working out a basic site architecture. These could be set up as a sprint for low fidelity design ideas, translated to a fully mocked up, designed, and mapped out infrastructure.

    Once it comes down to development and the actual build stages, I think it can take on a hybrid “design and development” sprint based approach. This can be a great time to look back, rethink and revisit some of the initial design challenges and work with developers to get their feedback to readjust and tweak designs, and solve small problems that arise.

    Again, this depends on the scope and scale of a project, but I have worked using a similar hybrid methodology in the past, with good results.

  • Gab Scali

    Agile has nothing to say about design. It was born as an implementation strategy and it always tacitly assumed the holistic elements of design were known, and design sprints could deal with the rest.

    So if you are using using incrementally more detailed prototypes, paper, lofi etc, before writing any code, you are not in the domain of agile yet. There is no such thing as a sprint on paper. Sprints are a code thing.
    You are still waterfallishly designing upfront, until you can move to code.

    If instead you start with a seminal system and you keep adding both design and code to it, in circles, you are in the domain of Lean.

    Lean is in turn largely a rehash of something those of us who studied software engineering in the 80s always knew very well as Evolutionary Prototyping. And normally used before it was given a more marketable name, simplified for the new web crowds, and, crucially trademarked.
    (We all know how the business of selling books, emperors, their wardrobes, “branding” and Internet celebrity, all wickedly mix up these days).

    So, yes, provided the system is not too complex (no you can’t build operating systems like this), it would certainly work.
    Better than that, it *has* worked for decades ;)

  • Anders Dahlberg

    What you describe is a traditional waterfall project. I dont like this approach because it limits learning during the project.

    Instead I find it effectiv to first do a strategy/design/UX sprint on a high generalist level and then break the project down into three week sprints delivering working units where each sprint learns from the previios ones and strategy/design/UX is rewritten after every sprint delivery.

  • Jordan Julien

    Kinda feels like your suggesting a waterfall methodology instead of an agile one. A big part of agile software development involves working on chunks of functionality. (I often use a modified version of Xtreme Programming process that treats these chunks of functionality as user stories & epic stories.) I have worked on projects where we performed usability testing at the end of each sprint asking users to interact with the prototyped components required to satisfy the user stories assigned to the sprint.

    But as you point out, a waterfall methodology where we sketch out the UI, then move into a wireframe, then prototype is a waterfall process. Sprints are intended to produce final working prototypes by the end of each sprint; waterfall methodologies produce lower fidelity pieces of ‘documentation’ that get higher-and-higher in fidelity until an entire product is produced.

  • Jason Civjan

    Hi, Paul. I just came across this post and it is something my group has thought a lot about recently. After a bit of a rocky patch of trying to align Agile and UX, we took a break to redesign our processes. You hit on one of the major takeaways for us: that we needed to iterate by fidelity, rather than by additive functionality to reach MVP. I absolutely disagree with those stating that this isn’t Agile. It might not be true Scrum (at least how it is traditionally implemented), but it most certainty aligns with Agile Development(

    We have been using this Iterative Fidelity model for almost a year now –across a variety of projects– and have found that it not only supports holistic UXD thinking across a project, but provides the entire team (UXD, Engineering, QA, PM, stakeholders,…) with clarity in vision and confidence in the work being produced (at both a code- and ux- level).

    Anyway, I have just started posting about our experience on our blog (I plan to have part 3 of 3 posted next week). A definite example of what you were pondering in action:

    Thanks for sharing– I’m glad to have come across this post and the blog!

  • Good stuff.

    The prototyping phase in Design Thinking would use this approach and increase fidelity or refine prototypes’ design iteration after iteration.

    Also the Pretotyping approach would start in very low res (you can search for it, no typo in “Pretotyping”)

  • Martinnovation

    Interesting post and especially the comment section is gold. I think it illustrates very nicely the fact that agile is great for incrementally and iteratively implement code, but there is still some ways to go before the defining of the system is also part of the same openess in the process. I work with both UX design and setting requirements as a PO. In both cases changing the assumption underneath the agile implementation process by changing requirements or the design is never a welcome event. But it is in line with the values and perspective overall in agile. But still – it always creates havoc in teams when you do it. Lets call it a challenge