Combining Agile, Lean, and Design Thinking — a layered approach
By: Raj Nagappan
Tags: Product Management, Software Development, Design Thinking, Agile, Lean Startup

The Recap

Previously, I wrote about the similarities and differences between Agile, Lean and Design Thinking. The definitions that I gave for the focus of each was:

Design Thinking focuses on value discovery. That is, deciphering what people actually want.

Lean focuses on value validation. That is, determining if there is a market for your idea.

Agile focuses on value delivery. That is, building a working product that customers can use and gain benefit from immediately.

(A few definitions are required here. By “Lean”, I mean The Lean Startup, not the Lean manufacturing model. When I say “Design Thinking”, you could equally apply either Design Thinking itself, i.e. the five stage model, or the similar and equally valid Double Diamond approach to design.)

I observed that these three methods all follow a common, looping pattern of identifying and exploring a problem, then attempting to solve it, then evaluating and analyzing the solution’s success, and finally repeating the cycle until we’re confident and satisfied. All three methods tend to ask similar questions about understanding a customer’s need, and whether or not our solution adequately fulfills that need.

I also observed that the method you tend to prefer often has a lot to do with your own experience and tools at your disposal. Agilists tend to prefer software-based solutions, Design Thinkers tend to prefer design-based solutions, and Lean aficionados tend to prefer business-oriented solutions. Thus the model that we prefer has a lot to do with problem solving modes that we’re already comfortable with and confident using.

The Debate

This is where the story continues. Patrizia Bertini very kindly reshared a quote from my article above, and then attached an image of the Gartner Model that combines all three models. A lively debate ensued.

Whilst my previous article compared and contrasted the three models, and talked about mixing their use, it stopped short of defining a formal way to combine them into a larger unified model; this is what the Gartner model sought to do. I’ve never seen a unified process model that I am happy with, so I thought, why not just invent my own? How hard could it be? 😊

The Gartner Model

Figure 1: the Gartner Model — not my idea of a process to follow! Source

My opinion of the Gartner model is that it is flawed. The Gartner model implies that Design Thinking, Lean and Agile operate as sequential stages: first you use Design Thinking to identify a customer problem, then you use Lean to identify the solution, and finally you use Agile to build and deliver the solution. Make sense? Absolutely not!

To begin, consider that all three models actually have both problem identification and solution development stages. It makes no sense to solve a problem in the Design Thinking model, only to then redefine the problem all over again when progressing to the Lean model!

Let’s say that you identify and solve a customer problem using Design Thinking and then retest it for business viability using Lean. What do you do if the solution from Design Thinking is not viable? Do you discard the ideas from Design Thinking and start over in Lean? Or do you return to the Design Thinking model all over again, appearing to go backwards according the model? If you do go backwards, doesn’t that create a lot of both waste and time pressure? We not only have to repeat the design process all over again, but we have to retest it again using Lean — even though Design Thinking has its own test stage — with the added risk that the Lean test might fail yet again, forcing us to repeat the whole cycle! It just doesn’t make sense.

Now let’s imagine that we got past that first hurdle, and indeed we got past the second hurdle of the Lean loop too; we’ve actually made it into the Agile cycle. Let’s say that we develop a product increment and demonstrate it at the Sprint review, as per the diagram. The stakeholders take a look at our newly implemented solution and say “now that I see it working, it’s not quite what I need — it does X but now I realize that I need it to do Y instead.”

The necessity to pivot based on feedback from a working demo is not a far fetched idea — it’s what Agile was designed to do. So according the Gartner diagram, what do we do now? Do we go back to the Design Thinking process and pause development? Or do we reply “sorry, we can’t materially alter the purpose of the feature or how it’s designed, that stage has already passed.” In fact, this latter reply happens a lot. It’s one of the many ways that a product development team drifts into being a feature factory. It’s disheartening to realize that the Gartner model helps to promote this drift.

To temper my criticisms above, I will acknowledge the view that you don’t necessarily have to take the Gartner diagram quite as literally as I have here. You could interpret it to mean to three phases in your overall journey of product discovery and delivery, like different roads that you can follow at different times, joining to form a meandering overall journey for your whole team. Still, I find this view difficult to implement: if your engineers are doing Scrum as per the Agile cycle, then do they abandon their Sprints to shift gears and go into the Lean Startup cycle for a while? I think it’s confusing.

I could go on, but I think you get the idea. The Gartner model both reinforces a linear factory model of work, and fails to take into account the similarities and overlap of the three models. Several people on Patrizia’s post commented that it reminds them of a Waterfall model, and I have to concur. Suffice to say, I don’t recommend it.

A Layered Spiral Model, a.k.a. A Swiss Roll!

Agile, Lean and Design Thinking all have a lot in common. They all favor an experimental approach. They all promote fast feedback. And they all work in iterations or loops. I prefer to think that the three models should operate in layers (i.e. concurrently) rather than in stages (i.e. sequentially).

Where they differ is in their primary focus, as discussed above. We might say:

Design Thinking focuses more on on putting delight and benefit into customers’ hands, i.e. desirability.

Lean focuses more on maximizing market fit and winning a portion of the market, i.e. viability.

Agile focuses more on guaranteeing product actualization and minimizing the risk of non-delivery or operational failure, i.e. feasibility.

You might have heard of the triad of “desirable, viable and feasible” as the three lenses of innovation. Sure, there will be overlap — none of the models focus exclusively on only one lens, but rather they all possess elements of all three. For the moment it suits our purpose to consider a primary lens as being synonymous with each of the three models. (We will return to the overlap later.)

This leads me to think that a unified model might actually behave like a virtuous spiral. Let’s say that from an initial germ of an idea we have three arms spiralling outwards that represent desirable, viable and feasible, each being answered by continuous work in the models of Design Thinking, Lean and Agile, and each overseen by designers, product managers, and software engineers respectively. Conceptually, it might look like this:

Figure 2: A spiral model to combine Agile, Lean and Design Thinking.

To me, this looks like a Swiss roll cake — just like the photo at the top of this article! The spiral illustrates two concepts particularly well. First, that Design Thinking, Lean and Agile all operate in a similar iterative, looping style. And second, that all three are continually present and influence each other regularly with their primary concerns.

Unwinding the Roll

Now, let’s go deeper; let’s unwind the spiral and consider it further. The next figure shows what our spiral might look like if we lay it out flat (just like the jam, cream and cake layers in that Swiss roll!)

Figure 3: the Spiral model “unwound” and flattened out to show the layers. The bottom layer tends to taper Design Thinking into Agile, but at the top layer Lean always has something to test.

Let’s consider the bottom layer first. Design Thinking is the predominant model at the start of the process, because it is concerned with figuring out what problem we’re trying to solve for the customer. Agile still has a small say, because the engineers need to understand the problem too, and can in fact come up with some fantastic ideas because they know what is possible to build. As mentioned in “Inspired” (2018) by Marty Cagan, “often the key to innovation is the engineers… this means including them from the very beginning, and not just at the end.” (p316)

At the tail end of the spiral, it’s mostly Agile work done by the engineers to build out the solution. The roles are reversed here; designers get involved in finessing the final look and feel, ironing out any UX glitches that become apparent during the build, and so on. The main thing about these two layers is that they are tapered. There’s no sudden handover; both the engineers and the designers are involved all the time, just to differing capacities according to how mature the problem discovery and solution delivery is.

In parallel to this, we have the Lean layer. The Lean layer is involved from start to finish. It is always testing the business viability of something. At first that will be the problem: is the problem common enough that solving it will be worthwhile? Next it’s the design mockups: if I presented you with this hypothetical solution to your problem, would you pay for it? How much? Later it’s the working prototype: now that you see this working, are you willing to place a pre-order for the final product? And last, it’s the actual uptake of the released feature: what do customer comments and usage metrics say? There is always something to test in regards to viability. Many solvable problems have failed because they don’t make good business sense — just ask Juicero!

As I said, Figure 3 is a flattened spiral. You can imagine each rotation of the the spiral as being one iteration of each model: build, measure, learn; build, measure, learn; and so on. On the flattened diagram, you could indicate each iteration as a segment, as shown below in Figure 4. If you’re using Scrum, this makes it easy to see how your Sprints map onto the overall process. Likely you noticed the undulations in the Lean layer, and Figure 4 shows why: each time we produce a new artifact such as a new design or product increment that gives the Lean layer something new to test for viability. So the Lean layer tends to be out of phase with the lower layer.

Figure 4: the same layered view from above with iteration boundaries added. Each time the lower layer produces an artifact such as a new design or product increment, Lean needs to test that for viability, so the Lean layer tends to be out of phase with the lower layer.

Examining the Criticisms

Let’s revisit my criticisms of the Gartner model, and see how the spiral model (a.k.a. Swiss roll) model stacks up.

First, the spiral model allows each discipline (product management, design and engineering) to move through the entire problem and solution lifecycle, using their tool of choice, in parallel to the others. For example, engineers don’t have to worry about being handed a specification that cannot be built, because their “problem” phase will uncover that early and feed back into the spiral. Product managers don’t have to worry that an expensive Design Thinking exercise might produce an nonviable solution, because they can assess its viability early and in parallel. The key here is that each discipline needs to work in parallel to the others performing small tests by incorporating rough initial data from the other disciplines, and then redistributing their findings back into a common pot of knowledge.

Second, let’s imagine that you make it all the way to a demonstrable product at a Sprint review, as per the Agile cycle. Let’s imagine that stakeholders’ feedback is negative: “now that I see it working, it’s not quite what I need — it does X but now I realize that I need it to do Y instead.” Under the Gartner model this poses a problem because we need to go backwards and start over, but under the spiral model it’s easy to take that feedback and work into the next iteration of the Lean or Design Thinking layer with the added insight of an already demonstrated product (the Agile delivery work would taper down during this time). More importantly, in this parallel, layered approach the Agile cycle will produce something that works far earlier than using the Gartner model… which is the purpose of Agile after all!

Finally, let’s consider the need to pivot. In the Gartner model it’s too late to pivot by the time we reach the Agile engineering stage; the design is “done” and the business case is “done” too. If the delivery of the actual working product fails to meet customer expectations, then it’s often too late to pivot — “there’s not enough time!” In contrast, in the spiral model, because we had been delivering a working product early and in parallel to both design and business case refinement, we would identify that same problem far earlier than if we had left the Agile delivery until the end of the sequence. Thus, if we need to pivot we have plenty more time to do so.

Let Go of Waterfall-style Approvals

If you’re thinking “hang on — how can the development team build a working product when we haven’t fully finalized and signed off the design yet?” then you’re asking the right question. You’re just looking in the wrong place for an answer. The flaw is the assumption that you need to fully finalize the design before development begins, and it’s counter to Agile’s purpose to build early and pivot often. You’re perpetuating Waterfall thinking! Instead, try to break that assumption. Ask “what is a small chunk or use case that we can realize and demonstrate early, with the goal of folding that feedback into our future iterations?” This is a Lean thinking mindset!

Yes — the layered model will result in some engineering work that is discarded, but this is the essential nature of Agile and Lean improvement, and it is what differentiates them from Waterfall. In order to succeed with an Agile mindset you must embrace the idea that some work will be discarded along the way. It is not waste though, because it leads to greater understanding. The trick is to work out the cheapest or fastest thing that we could construct to get that same learning — which sometimes will be UI mockups, but other times will require shipping actual code. This is the Lean Startup ethos.

You will need to let go of the notion that we can sequentially approve the completed design, then the completed business case, and then finally engineering in three neat, distinct stages. That is Waterfall thinking.

The essence of all three models — Design Thinking, Lean, and Agile — is that you define a bit, test a bit, and repeat. “Is the design finished yet?” is the wrong question to ask. The right question is “do we understand an opportunity combination— design, business case and engineering — such that we can progress to the next iteration of all three?” It’s a little bit of all three, mixed in together, rather than one after the other — layers, not stages! (Don’t underestimate this new question: it’s a massive paradigm shift.)

Passing the Information Baton

Earlier I mentioned a common pot of knowledge. Let’s dig into that a little further; let’s think about an athletics relay team for a moment. The team works together to advance the baton from the start line to the finish line during a relay race. The baton is representative of our knowledge, insight, and deliverable solution — it’s our intellectual property. Any specialization could be advancing the baton at any given point, be it design, product management, or engineering.

But here’s the thing: in a relay race, each runner gets a warm start. Before the baton is handed over, they start running! When the next runner sees the previous runner approaching, they start jogging and gradually increase their speed. By the time the baton is handed across, the next runner is almost at full speed and ready to rocket through the next segment of the race.

Our overlapping concerns are just like this, both in lens (or focus) and in time. Yes, the engineers are primarily concerned with building something feasible, but they are also secondarily concerned about whether it’s both desirable and viable. And they’re not sitting idle waiting for the designs to be formally “handed over”. Rather they are getting warmed up on what the preliminary designs look like in order to understand the lay of the land, whilst the designers are still reviewing their work and making finishing touches.

This overlap in both time and focus cannot be overstated. If you want your teams to be nimble and quick-footed, then they need to treat handing over work just like a warm-start passing of the baton, rather than blindly throwing it over a wall and hoping that someone will catch it on the other side.

Cross-Functional Teams Are an Advantage

All of this information baton passing and layered, overlapping work requires frequent communication and coordination. This becomes a lot easier if your team is cross-functional and all the people involved regularly collaborate with each other. Did you hear about the relay race where each team member ran their leg of the race on a different track, fenced off from each other, and management had to approve every baton pass before it commenced? Neither did I, because it just wouldn’t work.

I understand that many organizations have separate departments for product management, design, and engineering. And that each department — and therefore each specialization — has separate reporting lines. But if your goal is to combine Lean, Design Thinking and Agile so that the people using each one can collaborate more effectively, then your invisible departmental walls will just get in the way. Sorry, but that’s life! Even the Scrum Guide (2020) says “Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.”

I realize that the average enterprise is not going to just reorganize its whole structure based on an article that you read on the Internet. And to be truthful that is part of the appeal of the Gartner model — the stages make it look easy to just cleave off the work into three separate sections and give one to each department. It’s easy to apply. But as we’ve seen above it’s far from optimal. My opinion that this arrangement is ultimately siloed in nature and you’re just perpetuating whatever problems you already had.

A Lumpy Business

In reality, the spiral model is often messier to implement than the Gartner one. That’s important, because it reflects reality. Combining Lean, Agile and Design Thinking is a messy business. If it were not, then there would have been a clear, foolproof unification of them years ago. In practice you’ll find that sometimes you need to pause or dampen the Agile cycle whilst you revisit the design, or other similar convolutions. This makes your Swiss roll cake a bit “lumpy” — in some parts one layer is thicker (i.e. more involved) than the others, and in other parts it’s thinner (i.e. less involved). This is OK; lumpy cakes can still be tasty! As I mentioned earlier, this lumpiness will be much easier to cope with if your team is cross-functional and can navigate the lumps and bumps internally.

Conclusion

In this article I revisited Agile, Lean Startup and Design Thinking and thought about a way to combine them. I started out by critiquing the Gartner model of combining them, which I felt was unsuitable and reinforced Waterfall style thinking.

I presented an alternative way of combining the three — a spiral model or “Swiss roll cake”. It emphasizes that the three models operate concurrently in layers, and pass information and learning back and forth between them continuously just like relay runners passing a baton using “warm starts”.

Most importantly, I identified that approving and signing off each model in a sequence — design, business case, and engineering — just isn’t going to work in a system where all three continuously inform each other with their outputs, and where all three keep evolving over time. Approvals for sequential artifacts are a relic from a Waterfall era; what we need instead is to embrace “holistic” approvals of all three at the same time, in several successively refined versions. Patrizia Bertini describes this as adopting a systemic approach that recognizes the importance of keeping all three goals — desirability, viability and feasibility — unified, balanced and aligned at all times.

Finally, we identified that a cross-functional team which solves the whole problem from start to finish (as per the Agile 2 principle) would be an effective way to empower this to happen.

I hope this article has given you some thoughts to consider when combining Agile, Lean and Design Thinking. At the end of the day, it matters less which process (or combination thereof) that you employ, but more that you focus on generating effective products and outcomes for your customers.