Is Focusing on Agile or Lean Damaging the Practice of UX? Part 2

The Importance of the Discovery Sprint

“This is such a timely question for me,” responds Warren. “I’ve now been through transitions to agile in two companies over my career—one quite recently. The thing is: agile is an engineering methodology, and it works really well for organizing development work. But I have yet to be in a situation where agile has worked really well for the design process. Agile works best for design when there is a Sprint 0—essentially a discovery sprint, during which UX professionals can do preliminary work to understand the design problem and experiment a bit. You must do big-picture design work in advance, or you’ll be building the plane while you’re flying it. While this can be exhilarating, the plane would probably crash.”

Agile: An Opportunity to Guide Product Direction

Adrian offers the following guidance: “Short answer: No. Long answer: Still no.

“I’m old and grumpy and have been involved in delivering software products and doing work that now sits under User Experience or user research for more than thirty years. I started doing UX work long before teams adopted agile and Lean practices in any major way.

“And the work is so much easier now than it used to be. These days, I work with teams whose feedback loops take minutes, hours, or days—not weeks, months, or years. This means the cadence of agile lets me slot in generative and evaluative user research that can actually steer the product direction. This is better than having a one-off user research phase, after which various layers of the organization slowly translate my findings into an opaque set of requirements that don’t actually meet the user’s needs. Or later doing a one-off usability-testing phase, during which we get to tell the development team that the product is awful when there’s no opportunity to fix it—for which they quite rightly hate us.

“Now I’m working with teams that are happy dealing with artifacts such as user-story maps. These help teams discuss prioritization within the context of actual customer journeys—instead of creating half a dozen two-inch binders full of contracts and requirements.

“Now I’m working with teams that are working with tools that blur the lines between interaction design, user-interface design, and development, making it vastly easier to experiment at different levels of fidelity—rather than arguing over static wireframes and hardcopy style guides.

“Now I’m working with teams who understand concepts such as assumptions and hypotheses, and acceptance of the need for UX research has been socialized across the whole organization because of the popularity of the ideas coming out of The Lean Startup. This means I can frame design and research work in ways that the rest of the organization can understand—rather than having to spend precious time and resources educating people about these concepts.

“Now I’m working with teams that are building in product analytics from the very start, so we can understand how our customers are using the product in real time. We have continual delivery and feature flags, so we can test options and help validate design decisions. We can spot interesting bits of customer behavior using the real product, then use our learnings to drive our research and design practice elsewhere. This is way better than sending off boxed software on a floppy disk or CD and never knowing in any way at all what the vast majority of our users actually do with it—if anything. I could go on. It’s so, so much better.

“Does this mean that everything is awesome?” asks Adrian. “Hell, no. There are still development teams that are dismissive of UX work. There are still organizations that don’t value research—where the CEO’s bad hunches drive the creation of unusable products and run the organization into the ground. There are still people whose entire focus is on adding more features rather than on designing better features. Obviously, all of this sucks.

“But these are not new problems. Organizations and teams had these problems long before agile came along. The community of practice that became agile never had creating these problems in mind. There is, as they say, no silver bullet. But agile practices give me many, many more levers for helping organizations to do better UX design and research than I’d ever had in the pre-agile days.”