Cost Effective Approaches to Iteration in Agile UX

by Jared M. Spool

The whole point of Agile was that you discover more about what you need to do as you go. If you’re not doing that, you may have a more disciplined development process, however you won’t get the full benefit of going to an Agile approach.

That’s what InContext’s Hugh Beyer told me as we were discussing how teams are making the transition to Agile development methods. I thought that Agile would make things easier for UX professionals, since Agile has, at its core, a philosophy of iteration. We’ve known for a while that experience design thrives when you can iterate over a design.

According to Hugh, Agile sprints—time-boxed development cycles that are often two to four weeks in length—are not the same as iterating on a design.

One of the things I enjoy doing when I’m talking to a group of Agile practitioners is to ask, ‘How many of you get to iterate a particular piece of functionality through three sprints until you get it right?’ No one raises their hands. ‘Two sprints?’ No one raises their hands. ‘One sprint?’ Now I get some hands. The idea that you’re going to go back and re-work functionality is hard—organizationally hard, emotionally hard, and practically hard—because then your schedule slips. So yeah, we like the idea of iteration. The actuality of iteration, not so much.

(Listen to our conversation or read the interview transcript.)

Agile teams are trying to iterate in multi-week sprints and their costs are too high. A six-person team working on a three-week sprint is investing 90 person-days of effort. If they get to the end of that sprint and discover they’ve built something the users can’t use, they’ve wasted a lot of effort for that discovery.

Hugh says this leads to people falling back into their old waterfall habits, even while they are claiming they are using Agile.

You work out your functionality ahead of time, like in a PRD, just the way you always did. Then, using some vague idea of velocity, you plan that functionality into your sprints, and then you go. It’s just like traditional development except that you’ve got a base level at every sprint. This mentality leads to the idea that if I don’t get all of my functionality implemented in this sprint that was planned and pushes into the next sprint, I have slipped. I am bad.

The thing is, it doesn’t have to be this way. It is possible, in fact, highly desirable, to get low-cost iterations into an Agile development process. The trick is to have iterations that are shorter than a sprint, by looking at techniques for bringing the costs of iterations down significantly.

Reducing Iteration Costs With Paper Prototypes and Design Studios

One approach that brings the cost of iterations down is creating paper prototypes. In a few hours, a team of six can build a working prototype, made completely from paper, of practically any design. Our most complicated prototype took two days, but we kept “trying it out” and revising the design. Those two days involved a dozen major iterations on the design and what we ended up with was very different and substantially improved from our first design.

While paper prototypes let you quickly refine a design idea, finding the best ideas in the first place is where a design studio comes in. In a design studio, the team of six starts sketching a ton of design ideas as fast as possible. Using a series of short sketch periods, followed by critique and discussion, then more sketching and more critiquing, the team generates dozens of ideas to explore the design space.

Both of these techniques are fast because they remove the heavy lifting that happens when you’re coding up the ideas. Because the team makes serious progress in a couple of days, it pays off very quickly and still fits within the framework of an Agile method.

Deconstructing the Iteration

Each iteration, when done well, has four steps: planning, implementing, measuring, and learning. In the planning step, the team is deciding what they want to get out of this iteration. During the implementing step, they create the artifact (whether it’s a prototype or a programmed version of the design). In the measuring step, the team collects information about how well the design is achieving the goals they’ve set for it. And in the learning stage, the team extracts the lessons of this iteration to use going forward. (Read more about The Anatomy of An Iteration)

These four steps seem simple, but we’re surprised at how many folks leave some of them out. Most teams have no trouble with the implementing step—after all, that’s the heart of the iteration. However, the measuring and learning steps get less attention than they should, while the planning step is often ignored completely.

Focus on Measuring Quickly

In Agile, measuring an iteration means asking the question Did this iteration get us closer to something our users need and want? At the end of a sprint, a ‘no’ answer gets us into trouble. But if we’ve only spent a small time, say a few hours (or even just minutes), then a ‘no’ answer is ok, especially if we can then follow up with ‘Why not?” From there we can iterate again, this time with something hopefully closer (or equally educational).

When using a design studio, we plan the initial iterations to answer the question What are different ways we can make things better for our users? These iterations are successful when we’ve produced several alternatives and we’ve had a chance to explore their success. (This is easiest when we’ve done research by meeting real users and watching them work, since this will inform how we judge what ‘better’ means.) In subsequent iterations, we can start to look at how to refine the ideas, again bouncing the designs off of each other.

With a technique like paper prototypes, we can create something useful enough to try out with real users. Here we build an interactive model of what we think is our best design and, with one of the team members playing the computer, we ask users to complete real tasks with the design. From this, we’re measuring how we answer the question, Where does the design work well and where does it miss the mark? for these tasks.

We’ve found the most successful teams are those that spend as much time in each iteration measuring their designs as they do implementing it. Because these techniques are fast, they can be done early in the design process. And because they are cheap, they can allow the team the necessary failures to explore the design space adequately, without wasting expensive coding resources.

Design Is a Team Sport

It’s tempting to let those UX-focused design team members do this early work while the rest of the team goes off and does other activities. However, the biggest value from these early iterations comes from the discussions and insights that emerge. The most successful teams involve everyone who will influence the eventual design—including developers and stakeholders—in their design studios and paper prototyping activities.

From the iterations comes a shared understanding of what the team is trying to do. When things get intense in the later stages of the project, this shared understanding will prevent debates and speed decision making, resulting in a better design, faster. After all, creating great designs quickly was why we’ve made the shift to Agile in the first place, right?

Published here on March 21, 2012.