Why Designers Don’t Think About Agile

I get that people want to fit product (UX) design within Agile, and there are conditions that make that combination less painful…

But why in the world are people trying to fit service design (and even systemic service design) within Agile?

— Corneliux (@corneliux) March 23, 2022

Designers don’t think about Agile.

Not because designers are ignorant, but because they’re honest.

Not because Agile is opaque, unfamiliar or new, but because it’s obvious, familiar and nothing new.

To designers, it simply doesn’t make sense to think about Agile separately.

Agile is Nothing New to Design

The core principle of Agile is inherent in design practices. Not only are designers familiar with it, they also take it for granted. They don’t specifically talk about it because it’s kind of like “duh.”

If we’re to believe Dave Thomas, one of the Agile Manifesto founders, on his interpretation, then agility via iteration is inherent in all design practices.

In his fascinating article, Agile is Dead (Long Live Agility), Dave lays out the simple principle behind Agile:

— Find out where you are

— Take a small step towards your goal

— Adjust your understanding based on what you learned

— Repeat

Agile is Dead (Long Live Agility)

And —

When faced with two or more alternatives that deliver roughly the same value, take the path that makes future change easier.

Agile is Dead (Long Live Agility)

While those might have been very controversial in the traditional IT world where people did things linearly (“waterfall”), they are nothing new in the design practices.

Agile is what designers intuitively do.

Designing is Always Iterating

In many design situations, the generation of possible solutions and their gradual improvement is the only way forward.

Lawson, Bryan; Dorst, Kees. Design Expertise (Kindle Locations 384-386). Taylor and Francis. Kindle Edition.

The act of designing is inevitably solution-oriented, not in the sense that designers jump to solutions without thinking about problems, but in the sense that designers approach problems in two types of iterations:

• Iterations of approach: designers approach a problem in many different ways by exploring potential solutions in many different ways. They know that in addressing many real world problems, a single, fixed approach is often not enough, especially in a world where many problems are becoming more open, complex, dynamic and interconnected. So they tweak, refine, pivot and disrupt their approach with a keen focus on getting to viable solutions.
• Iterations of problem-solution pair: designers know that how a problem is framed is often just as (if not more) important than how solution is formed. And they know that the understanding of the problem evolves together with that of its solution. Along the way of designing, they dance back and forth between problem and solution, and evolve both to find a most viable problem-solution pair, where a problem is framed in a way that leads to the best possible and probable solution.

The Agile practice common in software development is merely a subset of a designer’s iterations.

Agile Fetish Hurts Design

There’s no agility in rigid process. There’s only dogma and tyranny.

When a team is misled to enforcing rigid process in learning to adopt the Agile practice, they stray away from the fundamental principle of it — agility.

Extended Agile frameworks like SCRUM are not as much about Agile practice than about organizing practice.

What’s really incompatible with the design practices is the commercialized, fetishized and power-ridden extension of Agile.

A Long Dark Shadow Hinders Both Agile and Design

It’s totally weird to talk about “fitting” any kind of design within Agile, or vice versa.

While specialized practices of design like graphic design and UX design are often practiced to make tactical contributions to developing products, many of them also have a strategic element that cuts across social sciences.

Management’s resistance to the strategic element of both Agile and design, combined with their general lack of respect for expertise, is why the relationship between Agile and design becomes a topic — both require changes in the way expertise is embedded in existing power structures (to some organizations, it’s the difference between an expertise-based accountability system and an authority-based one), and both are largely practiced in a way where their strategic element is suppressed. Without the strategic element, both find it difficult to make decisions and take risks. And when the actions become a total mess of operationally ambiguous power structure and managerially shallow collaboration, both begin to wonder why we can’t work together very well (if at all).

The chasm between Agile and design is not natural. It’s artificially created by the management. That chasm casts a long dark shadow in fifty shades of grey to both expertises.

{END}