How Agile leaves design out, and what we can do about it.
You might not guess it from the title of this article, but I love Agile. I work in UX, I lead web projects, and I never want to go back to the time before Agile.
Why the headline, then? Because, in addition to being wonderful for software and web development, Agile as commonly practiced leaves design and discovery out in the cold.
In Agile, discovery is assumed. At a minimum, you need a rough spec and some goals to get started. But is the spec validated against business goals or user needs? Is this the best solution? If so, when does that discovery work happen? Not during Agile development.
Filling the void
There are a few patterns that have emerged to fill this void:
Design Sprints are a compressed two-week (or so) period where all of the complex work of discovery is intended to take place, with an artifact handoff at the end. While I love the ambition, it is essentially a modified waterfall process, just shorter.
Sprint 0 is similar to a design sprint, but more overtly “agile-ish”. A single sprint is set aside to figure out what the heck you are doing! But a single sprint is not nearly enough time, and it does not involve the whole team (I’ve written a bit more about this here).
XP offers a pattern that improves on the design sprint and sprint 0 by integrating design into iterative cycles. Designers are integrated into the team, working on small deliverables as they are being built. What is still missing is integrated discovery and validation. In particular, there is no space for UX research because the focus is on incremental deliverables.
A pattern I really appreciate is Dual Track Agile, where design and development interact in a sprint-paced pax-de-deux, with design and discovery leading one sprint ahead. I feel this pattern is close, but the thing Dual Track lacks is a shared language, wasting time on the throwaway artifacts that designers usually rely on to communicate with development. They are not quite one team, just two teams working together well.
A different pattern
The pattern I have stumbled into using — that I refer to as No Handoff — is dual-track plus. In addition to the tight coupling of the design and discovery track with the development and deployment track, I rely on functional prototypes from day one. (For a great review of prototyping from a true master, take a look at The Pretotyping Effect by Alberto Savoia)
The prototype is the final product, just going through incremental improvements. It is a shared language that all stakeholders understand, from users to developers to executives. With a functional prototype we are not asking anyone to make an imaginative leap, we are showing them the functionality in a language they already understand.
“If you fail fast, you can recover easily, make a few changes and re-test your assumptions–or move on to the next idea”
— Alberto Savoia
It can be validated through testing, too, at every step. By contributing to a functional prototype from the beginning, accessibility concerns can be caught and addressed at the ground level. User testing can begin at a really early stage, and you get more useful feedback than with static wireframes. A design team with some basic front end capabilities can quickly pull together functional wireframes and show developers what the goal is, eliminating guesswork and frustration.
The other benefit to MVP prototypes is that it allows the visual manifestations of the design to be layered on in strategic increments. Starting with a polished design, like waterfall does, invites scrutiny of design elements before they have meaning. It is distracting. (ie: you might want feedback on speed and functionality, but keep hearing “I don’t like that color.”) On the other hand, layering in the polished design incrementally — and after functional buy-in is achieved — helps us get the right user feedback at the right time.
“We find our identities in the artifacts of the culture that we keep around us.”
— Kyle Chayka
It is also good change management practice. Visual changes are psychologically disruptive. As Kyle Chayka wrote recently regarding a Twitter style update: “We find our identities in the artifacts of the culture that we keep around us.” And when those artifacts change “…it’s hard to feel that the things we publish and collect in our digital spaces really belong to us.” Introducing change incrementally helps users and other stakeholders adjust and adapt, providing time for feedback, and carrying everyone forward together on a shared journey.
Conclusion
If you are a designer frustrated with your limited role and the lack of UX in standard Agile, or a developer who wants more validation and direction so you can stop guessing a spec into existence, consider a new Agile pattern. No Handoff respects the interdependent relationship of design and discovery with development and deployment. Harnessing the power of continuous discovery and validation within Agile development helps us incorporate design and discovery and build more successful projects.
Resources
Sohaib, Osama & Solanki, Hiralkumari & Dhaliwa, Navkiran & Hussain, Walayat & Asif, Muhammad. (2019). Integrating design thinking into extreme programming. Journal of Ambient Intelligence and Humanized Computing. 10. 10.1007/s12652–018–0932-y.
“Are Agile Methods Good for Design? | ACM Interactions.” ACM Interactions, https://interactions.acm.org/archive/view/january-february-2004/are-agile-methods-good-for-design1.
Chayka, Kyle. “Why Twitter’s New Interface Makes Us Mad | The New Yorker.” The New Yorker, The New Yorker, 19 Aug. 2021, https://www.newyorker.com/culture/infinite-scroll/how-social-media-redesigns-manipulate-us.
“Dual Track Development is not Duel Track.” Jeff Patton and Associates, https://www.jpattonassociates.com/dual-track-development/, May 10, 2017
“The No-Handoff Manifesto.” No Handoff — Stop Throwing Your Work over the Fence!, https://nohandoff.org/the-no-handoff-manifesto/.