The Blurring Between Design Thinking and Agile

A recent internal email chain at IDEO discussed the question of Design Thinking vs. Agile at IDEO.

The question: how does IDEO differentiate the Design Thinking process from Agile?

Below is my response, which I’m publishing here for future reference and with the hope that it might be useful for others.(The following is copy/pasted from our email thread, with a few images and links added to emphasise point).

Hi Greg,

It’s worth digging into the origin stories for Design Thinking and Agile as, although they are both converging on the same challenges today, they come from quite different places:

Design Thinking

Design Thinking is the decoupling of Design from any specific toolset (Industrial Design, Architecture, Graphic Design) and recognising that the process can be applied to any problem space.

Design Thinking has also become synonymous with Human Centred Design; this link is largely due to the work of people inside Stanford and IDEO in the late 80s / early 90s. Design in this context is the cyclical process of defining a future state and then working backwards to connect to the current state (hence why terms like ‘reverse engineering’ and ‘post rationalisation’ are so common in design).

This jumping forwards and backwards between what’s possible, what’s wanted, and what makes money is the essence of design. I use the word ‘jumping’ here deliberately as no matter how many three-way venn diagrams, squiggly lines or metaphors we use it’s essentially a foggy process, where consensus and confidence only emerges by jumping forward (prototyping, brainstorming, sketching) and then jumping backward (synthesis, storytelling, reporting).

Agile

Agile is a methodology for developing software, and its properties are borne of software itself. To many it’s the antidote to Waterfall development (or Engineering as it’s otherwise known). The Waterfall / Engineering process is entirely appropriate for the production of hardware — but it turns out to be almost entirely wrong for software.

With hardware, the cost of making changes becomes increasingly expensive as a you move closer towards production; with software, or specifically object oriented software (basically all software since the 1970s) the implication of changing elements is less costly. This is further magnified by ‘always-on’ internet connectivity which means that updates to software can now be pushed to users as often as the software developer desires.

The Agile Manifesto embraces this notion of perpetual beta and that software should be developed with a continuous loop of customer needs going in and ‘good enough’ software coming out.

This state of continuous refinement is ultimately the same as design’s process of jumping backward and forward. The only difference is that with design we stay in this state for the duration of the project, whereas in Agile we stay in this state for the lifetime of the software.

Lean

Its also worth talking about Lean and Lean Startup (which are different things).

Lean builds on Agile.

Where Agile promotes autonomy of teams and continuous process, Lean further emphasises efficiency along the way (less waste, move quickly, have awareness of the bigger picture). These are again familiar concepts for design teams which leads to blurring between Lean and Design Thinking.

Lean Startup takes the methodology and applies it to building companies. It’s where the infamous Build/Measure/Learn loop comes from and it essentially borrows software paradigms and uses them in the world of business. It works so well because:

1. All new businesses are software businesses 
   (see Software Is Eating The World)
2. Software tools are increasingly democratised. Naturally this means that designers have access to the tools previous only accessible to software engineers — which is means that software people, design people and business people are all using the same tools.

(So, to answer the original question: how does IDEO differentiate the Design Thinking process from Agile?)

Similarities (between Design Thinking and Agile)

1. Both process seek input from beyond the team doing the work. For designers this is user research, business needs and technology possibilities. For software development this looks more like a backlogs, user stories and success metrics.
2. Both processes also embrace iteration and ongoing refinement. I personally feel that design is more about jumping backwards and forwards where software is the continuous loop of development —but both talk to the same notion of ongoing refinement.
3. Less obvious, but equally important, is the strong call for a healthy culture of empathy and empowerment in the team. It’s striking how similar the Agile Manifesto’s values are to IDEO’s values:

Agile ‘Individuals and interactions over processes and tools’
IDEO ‘Take ownership’

Agile ‘Working software over comprehensive documentation’
IDEO ‘Talk Less, do more’

Agile ‘Customer collaboration over contract negotiation’
IDEO ‘Collaborate’

Agile ‘Responding to change over following a plan’
IDEO ‘Embrace Ambiguity / Learn from Failure’

Differences (between Design Thinking and Agile)

1. Software development in general doesn’t have a ‘synthesis’ stage. Often the learnings from the last iteration are the direct input for the next iteration. It’s common for requirements to be collected and then, at best, prioritised before work commences. Design Thinking is better at taking learnings and then spotting patterns to make an informed leap to something new. This mysterious process of synthesis is possibly more unique to IDEO than we realise.
2. The legacy of Design means that we still often think in terms of projects with a beginning, middle and end. Agile definitely has these stage gates of deployment (alpha, beta, launch) but the design process perhaps needs these points to force a coherent output, where software development is possibly better at being able to deploy a solution at any point in time.
3. Perhaps the most interesting difference is design’s separation from software. While we use software in our day-to-day activities we have a much broader range of tools to get the job done. From simple things (like pens and paper) to more complex tools (like the Business Model Canvas), I’d like to think we have a bigger tool-belt than software teams.

Blurring (between Design Thinking and Agile)

1. As per my previous point, perhaps the biggest cause of blurring is the use of software in all stages of both Agile and Design Thinking. Not only do we sit at the same laptops and use the same software, it’s increasingly easy for non-technical people to carry out software engineering tasks. Much like Desktop Publishing Software made it possible for anyone to do the job of a graphic designer, software frameworks means that designers today can develop very advanced software. Equally design patterns and libraries like Google’s Material Design makes it easier for developers to produce advanced visual interfaces. The difference between a high resolution prototype and production ready code is, in some cases, now zero. If I build with scaleable cloud based tools like AWS there’s nothing stopping the scale from 10 users to 10,000. (Apart from my bank balance ? ).
2. Another factor at play is more and more diverse teams. At IDEO we obvious value this highly, but with more and more design founded companies (such as Airbnb) it’s common to find design teams with software engineers and software teams with ethnographers. When diverse teams bring their processes together blurring is inevitable.
3. Finally, The sheer speed of the points above makes everything look a little blurry. Amazon currently deploys code roughly every 10 seconds. Which means 60 times since you started reading this. Imagine if Ford updated a car 60 times in 10 minutes. (In fact, Tesla is already doing this — so imagine them instead). When this is a fundamental characteristic of the material we’re working with things will get blurry.”

Epilogue

The end of my original email asked that if anyone made it to the end, to let me know. So I’ll ask the same again, if you made it through this rather lengthy diatribe, please let me know.

This article was originally published on Matt's Medium page.