Healing the Design-Agile Rift

I’ve started seeing increasing amounts of concern about Agile coming from the design community. There seems to be a feeling that Agile impedes good design by forcing everything to fit into short cycles. Designers object that not every problem can be understood, let alone solved, within a single sprint. If we have to translate design into delivery every two weeks, they complain, then we can only solve very small, incremental, and relatively unimportant problems.

To some degree, designers’ suspicion of Agile is deserved. As Agile has become integrated into mainstream management systems, it has in many cases lost touch with its purpose as a methodology for steering through uncertainty and unpredictability. Instead, it has become a mechanism for chopping work into smaller and smaller pieces, in the hopes of greater and greater certainty and predictability.

If, however, we return to Agile’s underlying motivation, I believe we can discover a shared purpose between development and design. I think we can also uncover ways that design and Agile can learn from each other. The result will hopefully be a unified approach that reflects the best that both have to offer.

We live in an ever more complex world. We are designing, building, and operating ever more complex systems. What complex systems have in common is their resistance to our attempts to model, predict, or control them using familiar techniques. Interventions in complex systems inevitably generate unintended consequences. Attempts to rid these systems of surprises result in more rather than less severe degradation. Fail-safe doesn’t work in complex systems. What’s needed instead is “safe-to-fail”.

Complexity doesn’t just defeat attempts to build systems that are guaranteed to work as the engineer expected. Regardless of the amount of research, ideation, prototyping, or user testing we engage in, complexity also defeats attempts to design solutions that are guaranteed to function as the designer expected. The only way to know precisely how an intervention will work in the real world is to release it into the real world. “Release” is thus a more poetic term than we might realize. In the process of releasing something, we relinquish control over it. The concept of “done”, whether in the Agile “definition of done” sense, or in the designerly double-diamond sense, becomes empty. Deployment is the beginning, not the end.

The emptiness of doneness points the way to unifying design and Agile. It implies the need to learn before, during, and after building. In some cases, research saves us from building the wrong thing. In other cases, only building and deploying allow us to learn where we should go next. We thus need to do them all together.

For this reason I don’t favor multi-track iterations. From the perspective of continuous learning, “design”, “development”, and “operations” are all part of a single activity. There’s no reason a single cross-functional team shouldn’t be doing some research, building some features, deploying some other features, and monitoring yet other features, all at the same time. The value of having everyone reflect together on the results of all of those activities would seem to be, as they say, priceless.

Nothing says that research has to be finished at the end of a sprint. We should, however, reflect on that research and decide where to go next with it. Would we best be served doing some more, or doing some different research, or building a prototype, or building and releasing a real feature into production? We should repeatedly be asking ourselves, “given where we ended up last, what’s the best way to learn where we should go next?” We need designers and product managers and developers and ops folks asking and answering that question for and with each other.

Much of design’s suspicion of Agile arises from the Scrum dictum that you should deliver working code at the end of every sprint. It’s important to understand that the Agile Manifesto came about in an era where organizations would design and build code for months if not years before delivering anything. It was only at the end that they discovered they built the wrong code in the wrong way. In 2019 the key point is not to deliver working code at the end of every sprint, but to deliver something as continuously as possible that helps you steer through the next increment of uncertainty and change.

The Agile Manifesto expressed itself in terms of a set of relative value statements: we value X over Y. While they’ve often been wildly misunderstood, these value statements were intended to imply “we value Y, but we value X more”. In keeping with that intention, we could add a new value statement that I believe expresses what it is that we need to continuously deliver:

We value learning over delivering features

Sometimes valuing learning over delivering does in fact mean spending more time designing and less time building. Other times it means spending more time monitoring and less time designing or building. Of course, the only way you can monitor something is if you've designed and built it. Ironically, in order to successfully steer through complexity, operations needs to become an input to design.

At some point, learning depends on delivering working code to customers. Affordances are expressions of promises: intentions to facilitate desired outcomes. In a complex environment, the things we release are still hypotheses - intentions that may or may not come to pass. The only way to know for sure how well we’re keeping our promises, or whether they’re the right ones to make, is by releasing and then monitoring them in production.

It is my belief that design needs development and operations as much as development and operations need design. Making the transition from fail-safe to safe-to-fail depends on mutual empathy and collaboration between them all. It is my hope that valuing learning over delivering features, coupled with treating operations as input to design, captures the heart of where we’re all trying to go across contemporary design, product, development, and operations practices.

Jeffrey Sussna