The difference between agile and UX is not about quantity vs. quality
It’s between building and dwelling.
I have worked with some people who bill themselves as both developers and designers at once, united in the same person. Most are either developers who dabble in design or designers who dabble in development, so I can perfectly understand the skepticism that greets me when I myself claim to be that semi-mythical creature: a designer/developer, the “unicorn” of the world of digital product creation. We consider it common sense that generalization must come at the expense of specialization. I don’t agree, but I can certainly understand why that’s taken as a given — and I acknowledge there do seem to be more examples in its favor than not.
I make this contentious claim for myself to provide some context. Existing in both circles at once has convinced me that the worst thing in the world of development is the worst thing in the world of design: the illusion that we’re doing different work. I understand why my designer and developer colleagues alike look at me like I’ve suddenly sprung a second head when I say that. It’s so obviously different work, how could I possibly think it’s not? I’d like to focus today on just one part of this supposed division to illustrate what I mean, though it is probably the one that causes the most rancor between us: agility.
The Worst Game of Telephone
In “The Age of Agile Must End,” Michael Burnett claims that agility is premised on three fundamental flaws:
- Humans are not machinery.
- Design is not inventory.
- Product can’t be defined by what can be accomplished by an arbitrary number of people of arbitrary skill and experience in a two-week sprint.
Michael is by no means alone in his opinion of agility. UX professionals who think and write about our craft have made a bit of a genre out of the anti-agility screed. Dave Malouf opens the DesignOps Handbook with the story of his own terrible experiences with the agile regime. He recounts the problems he observed in this “culture optimized for engineers,” and diagnoses the root of the problem with this:
I discovered that the metrics of success for our partners in development and product management differed from those of design, leading to the shipment of subpar products. And therein was the problem: developers and product managers measured success by whether a product shipped on time, and not whether the design satisfied user needs.
The emphasis placed on that last sentence is from Dave himself, and I mostly agree with this point — though there is one critical detail that he’s missed with this assessment.
The best handling I’ve seen of agility in UX has come from Jared M. Spool (though I am, admittedly, more than a bit of a Spool stan) in his Agile UX training. Even here, though, I was deeply frustrated when Jared claimed that agility is all about getting work out the door more quickly, and that agility therefore fundamentally lacks any concept of quality. Jared argues that this is where UX is needed, to direct agility’s obsession with shipping towards products that are worth shipping in the first place.
Before the agility coaches and Scrum Masters scoff at such sentiments, understand that these are very reasonable responses to the way that agility is actually implemented in very nearly every case. The tragedy is that UX professionals know agility only from what is actually implemented at the companies they work with — from what we as Scrum Masters and agile coaches show them. They largely don’t know what agility is supposed to be. Why would they? It’s a “culture optimized for engineers,” not for them. They’re usually not invited to join Scrum Master trainings. Why would they waste time reading the Manifesto for Agile Software Development — and if they do, why would they read it any less contemptuously, informed by their actual experience with “agile teams,” than Michael did in his article above?
The tragedy, of course, is that the solution to this mockery of agility is actual agility — but with no examples of agility except the cargo cults that Scrum tends to create, what right do we have to be surprised that they end up reinventing agility over and over again?
I find it remarkable that the three fundamental flaws that Michael says lie at the heart of agility are each addressed by one of the four values of the Manifesto for Agile Software Development, the very origin point of the entire agile movement:
- “Humans are not machinery” expresses the same point as “Individuals and interactions over processes and tools.”
- “Design is not inventory” is an excellent example of “Customer collaboration over contract negotiation.”
- “Product can’t be defined by what can be accomplished by an arbitrary number of people of arbitrary skill and experience in a two-week sprint” is an excellent example of “Responding to change over following a plan.”
According to Michael, one of the reasons why Scrum “is the way it is” is that “[i]t has to be timeboxed into a Sprint to make sure software can be released into the market in an ‘iterative’ cycle.” It is true that Scrum asks us to cut our work down into smaller pieces so that it can be released into the market iteratively, but that’s a strategy, not a reason. The reason is given by the Manifesto’s first principle:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
There is a focus on delivery and shipping a working product in regular increments, not for its own sake, but as the means by which a high-quality product is created. Agility assumes that we’re working on complex problems, meaning that we’re not necessarily certain what we need to do to solve the problem, nor are we entirely certain on how to do it. With problems like these, we have to put something incomplete and imperfect into the world sooner rather than later, start getting feedback on it, and iterate towards a real solution.
The “Age of Agile” has seen very few companies that actually follow this idea, though the Scrum cargo cult has become almost ubiquitous. These teams call themselves “Scrum teams,” but they usually cut out critical parts of the process defined in the Scrum Guide, like forming cross-functional teams and letting those teams manage themselves.
Did you know, my esteemed UX colleague, that when the Scrum Guide refers to “developers,” it means you, too? The Scrum Guide defines “developers” as “the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.” “Developer” is used here to mean “people who develop a product,” not just programmers. UX researchers and designers are developers in Scrum every bit as much as software engineers. A Scrum team is supposed to be cross-functional, “meaning the members have all the skills necessary to create value each Sprint.” UX research and design are some of the skills necessary to create value each sprint, so if you’re not a part of the team, then it’s not actually a Scrum team.
And yet, “dual-track agile” (and even “triple-tracked agile”) is far more common than what is explicitly defined as a Scrum team by the Scrum Guide. The problem here goes back to the point of disagreement I had with Dave Malouf’s bolded statement above. He wrote:
“…developers and product managers measured success by whether a product shipped on time, and not whether the design satisfied user needs.”
But let’s be clear: developers do measure success by whether or not the product satisfies user needs. That’s the first principle of the Manifesto for Agile Software Development. The goal is not to ship the product on time, but to ship regularly as the means by which we can ensure that we satisfy the customer. Product managers have a triad by which they measure success: feasibility (is the product something that we can actually make), usability (will users like the product), and viability (will the product make a profit). It’s not the developers or product managers who measure success by whether a product ships on time, but our mutual superiors higher up in the organization. The promise of shipping more software faster is the most common reason that businesses undergo an agile transformation, but it is not the point of agility. As Allen Holub puts it:
I can certainly understand why, from the point of view of UX professionals who are excluded from all of this, bludgeoned into “dual-track agile” schemes and worse, it can certainly seem like agility only cares about quantity, but this isn’t a problem with agility — it’s a problem with the pale shadow of agility that’s left after its heart has been ripped out.
At the end of his article, Michael presents what he considers a far superior procedure for creating products. The first three points in his process are:
- Determine what needs to be built.
- Determine how best to build it for scalability and future-proofing.
- Then build it, however long it takes. (It’s not going to take two years but neither is it going to take two weeks. Releases can be sliced and diced, so long as the product gets built to spec.)
Having been on many projects that were run on precisely this model early in my career that did take two years or even longer, I’m not sure that I believe this parenthetical assertion, but I want to focus on the perspective underlying this and how it contrasts to the one that underlies agility. Step one is to determine what needs to be built. This rests on an unspoken assumption that it’s possible to know what needs to be built before anyone starts building anything — as opposed to the assumption that agility makes, that the problems we face are complex and fluid.
The Problem with Dead Drops
The meme above was posted by a graphic designer on LinkedIn. It’s a great expression of the frustration that designers often feel towards developers. After spending hours creating beautiful high-fidelity mockups of delightful interfaces, the actual product that comes out is often a crushing disappointment that seems far removed from what was designed.
As hard as it may be to believe in those moments, though, the developers probably weren’t trying to sabotage your design. It’s probably not that they’re incompetent, either. They probably don’t know nearly as much as you do about composition or balance or visual hierarchy, but they might know some things that you don’t about technical limitations and how things are rendered on the screen. It’s very likely the case that at least some of those problems arose from exactly that sort of situation. Placing a line right here is the easiest thing in the world in Figma, but could be something that takes a full day to achieve in the actual product. It is frequently surprising and unintuitive which problems in programming are trivial and which are nearly impossible, and even developers don’t always know the difference until they’re deep into the problem.
To designers, which parts of a mockup are important and which ones are clearly artifacts from earlier drafts or simply incidental might seem clear, but all programmers have to go by is the mockup itself, so they can’t always tell. It’s generally the case that developers did their best to bring your vision to life, but you probably weren’t there to help. After all, you’re not part of the Scrum team. You were probably busy getting the next batch of mockups ready for the sprint to come. Without your guidance, the developers did the best they could — to everyone’s disappointment.
Usually, our goal as designers is to facilitate what Dan Mall likens to a “dead drop.” He and Brad Frost have had quite a bit to say over the years about how we can rethink the relationship between designers and developers by eliminating handoffs and instead collaborating more closely with one another. Shamsi Brinn wrote recently about the ways in which this handoff culture is disastrous for designers and developers alike, writing:
Handoff leads to a false antagonism between design and development teams. Designers fight to “be in the room”, but design handoff is a door we can’t walk through. While for developers, front-loading design means they are always building solutions they had no say in and are left holding the product hot potato.
Closer collaboration sounds very nice, of course, but a hard-headed pragmatist might ask if it’s really true. The two diamonds of the double diamond are often summarized as:
- Design the right thing.
- Design things right.
If those steps are done correctly, what does it matter if designers collaborate with developers, or if developers feel like they’re not included? Have we considered the possibility that they’re not included because they don’t have anything useful to add? We may need to make sure that the artifacts we hand off are better documented — or maybe we just need developers to learn how to read a mockup properly — but if we designed the right thing, and we then designed the thing right, then surely the only step remaining is for developers to do their jobs, right?
Doing Everything Right, and It Still Goes Wrong
There is an abiding faith in UX that we can ensure product success from the outset — that we can figure out the right thing to design, and then design it the right way, so that further iteration is unnecessary. And to be clear, UX offers some amazing tools that absolutely do catch a lot of problems before users do. A problem that you catch in a paper prototype is far easier to fix than one you catch in a live product. But as valuable as UX is, it isn’t foolproof. You can do everything right and there’s still a chance that things can go wrong.
Angus Morrison gives us a detailed post-mortem of such a case. Angus did everything right with regards to the tools and processes of UX, but he ended up with a solution that made users 20% less likely to sign up. He caught the problem in an A/B test, but it still needed to be implemented and put in front of a large number of users before the problem could be identified and solved.
Even when we’re rigorous in our participant selection and research methods, the truth of the matter is that users don’t always behave with a prototype the exact same way they will with a live, finished product. There are factors at play that only exist when a product is actually released. Often the differences are small enough to be ignored, but they can be critical — and there’s no way to know which ones you might encounter until there’s something out there in the world.
Wicked Problems
In “On Design Thinking,” Maggie Gram presents the history of design in the 20th century as a tug-of-war between two powerful ideas that have arisen again and again over the decades, in slightly different forms.
In the United States, design first emerged as a profession in its own right in the 1930s. When those designers went off to war, they worked alongside scientists, engineers, mathematicians and others, who thus became familiar with “the idea of the designer as an all-capable architect of clever solutions across domains.” This contact not only garnered greater respect for designers, but also, in many cases, motivated designers to apply their craft to much larger problems. Figures like C. West Churchman, Christopher Alexander, John Chris Jones, L. Bruce Archer, and Herbert Simon all contributed to the idea that “the design process could be fully cataloged, described, and rationalized.”
Enter Horst Rittel. Like Churchman, Alexander, and Simon, his thoughts on design were deeply influenced by his wartime experience, but he’d experienced the conflict from the other side. Horst was born in Berlin in 1930. He was part of the Flakhelfer generation. By the time he was 10 in 1940, Germany was at war and membership in the Hitler Youth was mandatory. When he was 15, he was conscripted to serve as cannon fodder in the doomed defense of Berlin. Like other “Forty-Fivers” like Jürgen Habermas, this experience left Rittel with a deep appreciation for democracy and freedom in all of its messy vitality, and a deep-seated skepticism of any totalizing ideology that came cloaked in rationality and rigorous scientific precision.
Rittel is best known for introducing the concept of “wicked problems.” In the version of the Stacey matrix often used by Scrum trainers, the class of “complex problems” has a great deal in common with “wicked problems,” including no definitive formulation, no stopping rule, no immediate or ultimate test of the solution, and unavoidable ties to other problems.
Gram writes:
For Rittel, design problems’ wickedness meant that they could never be subject to a single process of resolution. There could be no one “method.” Textbooks tended to break down, say, engineering work into “phases”: “gather information,” “synthesize information and wait for the creative leap,” et cetera. But for wicked problems, Rittel wrote, “this type of scheme does not work.” Understanding the problem required understanding its context. It wasn’t possible to gather full information before starting to formulate solutions. Nothing was linear or consistent; designers didn’t, couldn’t, think that way. If there was any describing the design process, it was as an argument. Design was a multiplicity of critical voices batting a problem around unknown terrain until it formed itself, or not, into some kind of resolution.
This methodlessness, Rittel believed, was a wonderful thing. It entailed, he wrote later, an “awesome epistemic freedom” (the italics are his), without algorithmic guardrails or rules of validity. “It is not easy to live with epistemic freedom,” he wrote, and so designers often sought out sachzwang — practical constraint, inherent necessity, “a device to ‘derive ought from fact.’” But they shouldn’t. Without methodological constraint, design had room for heterogeneity. It had the capacity to surprise. “Nothing has to be or to remain as it is,” Rittel wrote, “or as it appears to be.”
Design artifacts are the side-effects of a singular process that’s content with dead drop handoffs because it has faith that a singular process can reliably reach the correct answer. If you believe that, then the central concept of agility is unnecessary. We don’t need to release iterations of our product to find out if it’s viable, usable, and feasible. We have a process that can determine that. We just need to follow that process, and we can make sure it’s right on the first release. There’s no reason why a waterfall approach wouldn’t work.
But what if we remove that article of faith, and entertain the same doubts that Rittel did? What if we recognize that design is an argument? Rittel’s wicked problems were problems we have only one chance to address, where the designer has no right to be wrong. “One cannot build a freeway to see how it works, and then easily correct it after unsatisfactory performance,” he and Melvin Webber wrote in their seminal paper from 1973 introducing the concept. That makes most of our work in digital product design decidedly not wicked. While they might otherwise share the complexity of those problems, we are conspicuously empowered to try something, learn from it, and then correct it. How foolish would Rittel consider us, to see us bestowed with such bounty, and fail to take advantage of it?
Designing & Dwelling
When we think about the creative process, we often imagine someone who has the vision to imagine something novel and the skill to make that vision real in the world. This doesn’t line up with how artists typically describe their processes, though. Michelangelo famously said:
The sculpture is already complete within the marble block, before I start my work. It is already there, I just have to chisel away the superfluous material.
Most of us who’ve made art can relate to this. We’re not merely shaping material to match our vision; the material is also shaping our vision at the same time. The result is not the artist’s vision made manifest, but what remains from a sort of argument between the artist and the material — an argument that is had by working.
In The Perception of the Environment: Essays on Livelihood, Dwelling and Skill, Tim Ingold discusses what he calls “the dwelling perspective,” and contrasts it with “the building perspective.” The building perspective is, for most of you reading this, the conventional way of seeing the world. This is the perspective of the artist who imposes his vision on the material to create art. It’s a dualistic perspective, in which thought precedes action, planning precedes doing, and discovery and definition precede development and delivery. The double diamond is an expression of the building perspective.
For Ingold, it was developmental biology, ecological psychology, and phenomenological philosophy that led to a different perspective, what he calls the dwelling perspective.
Life, in this perspective, is not the revelation of pre-existent form but the very process wherein form is generated and held in place. …it is through being inhabited, rather than through its assimilation to a formal design specification, that the world becomes a meaningful environment for people.
This seems much closer to the perspective we’ve been circling around this entire time, the perspective of the Manifesto for Agile Software Development, Horst Rittel, and Michelangelo.
I feel I need to (finally?) exercise some restraint here and avoid digging into Walter Ong’s Orality and Literacy and how the dwelling perspective seems to emerge from orality, and the building perspective seems to arise from the cognitive distortions created by literacy. Ingold explores the myriad ways in which these perspectives have shaped history, the modern world, and the broader human experience in his book, so we’ll focus here on what it means for the very narrow interest of creating digital products.
The divide between UX and agility is not that UX cares about quality and agility is concerned only with delivery. It’s a much deeper philosophical division about the world and, by extension, how one brings something of high quality into the world.
Working within old waterfall environments, it is entirely understandable that UX designers would follow the building perspective and the processes suggested by it, following the work of Churchman, Alexander, Simon and others. Within the confines of the roles they were given, this perspective offered them the best chance to create a great experience for users. The problem is that the building perspective is wrong. The processes built on it routinely fail to create great experiences not because of the failures of our colleagues downstream, but because the entire process was built on a faulty assumption.
Working downstream, closer to delivery, it makes sense that the movement towards the dwelling perspective would begin with programming, but that doesn’t make it something that is uniquely suited to programming alone. When the Scrum Guide refers to “developers,” it quite explicitly means programmers and designers — and everyone else who’s involved in developing the product.
Agility is completely right on this question. Horst Rittel was trying to tell designers this thirty years before the famous meeting in Snowbird. If we’d had the courage to embrace the awesome epistemic freedom he talked about, it would have been designers teaching this lesson to programmers instead of vice versa.
But just like planting a tree, the second best time to change is today. And the fact of the matter is that agile development desperately needs UX. Early agile practices often involved having the customer in the room with the programmers as they developed the software. This worked really well for specialized software used by a few dozen highly specialized professionals, but no one customer could ever speak for the millions of users who will use a popular, public application. That calls for a UX researcher in the room. Wisely selected UX metrics can give agile teams a far better targets to optimize for than velocity and story points. Teresa Torres has pioneered the practice of continuous discovery, an approach to UX and product research that embraces the dwelling perspective and Rittel’s idea of design as argument and can be an incredible complement to continuous delivery.
UX professionals have, for a long time, argued that UX cannot be viewed as a stage in a process, but as something that is involved in every stage. This is just as unambiguously correct as agility’s insistence on the dwelling perspective — but then, why do we continue to rely on models like the double diamond, or working in dual- or triple-track parodies of Scrum in which we hand off design artifacts instead of getting involved in the work directly? What are our colleagues supposed to think when we say we’re not a stage in the process, but still divide our work into the stages that we’re involved in and the stages that we aren’t?
Rittel was correct: it’s not easy to live with epistemic freedom. It can be terrifying. The Scrum Guide calls out courage as one of its values for a very good reason. It takes courage to live with that epistemic freedom. Design is not a field for cowards. If we can look beyond that fear, all the wide-open frontiers that Rittel dreamed of are still there. What can design become, when we root it in the dwelling perspective? What new ways of design can we pioneer when we embrace the fact that we learn by doing? What new ways of working together might we discover? What wonderful new things might we create together?
Nothing has to be or to remain as it is, or as it appears to be.
