Lean vs Agile

I’m currently lucky enough to be on the road delivering Lean presentations to industry in a number of our key cities (Hong Kong, Beijing, London, Manchester, New York, Chicago, San Francisco - details on the ThoughtWorks website). I’ll write more about the presentations and the people I’m meeting soon - I want to talk about something that I’ve noticed along the way in this blog…

There seems to be a perception in the IT community that Lean and Agile are two mutually exclusive processes for delivering software. I wanted to talk about it because I hadn’t even thought of Lean as a delivery process at all and I think my view of Lean and how it can be used in IT is diverging with some of the IT community. I’m worried that we may be missing the point.

First of all I think it will be useful to talk about Agile. I’ve spent a lot of time talking about this recently because I think it is important. The Agile Manifesto was signed in 2001 by the key individuals involved in the development of the Agile Software movement and if you read it I think that it’s very clear that it belongs at a philosophical level, rather than a practical one. It’s non prescriptive and that’s important. The original signatories recognised that there is no ‘one right way’ to build software and this is reflected in the manifesto. It simply outlines principles that we all agree with, at least in the Agile community.

Lean also belongs at a philosophical level. Deming’s and Ohno’s work teaches us how to get the best from people and how to build business processes to get the best from them by aligning their futures with that of the organisation. Toyota recognised that there was no ‘one right way’ to build cars and equipped their workforce with tools that supported them in continually improving how the cars were built.

Why do we like Lean as members of the Agile community? Well, at a philosophical level Lean and Agile are incredibly well aligned. They are both about empowering people to get the best results. They are people centric and they teach us how to adapt and improve processes to get the best results from the people we have to solve the problem that we are confronted with.

With this in mind I don’t fully understand how it is possible to follow a Lean software development process. We can only have processes that are more or less efficient than each other in a particular context. There is no ‘one right way’.

What do I mean by that? Well, let me see if I can explain. There are 4 situations where I call on my Lean knowledge heavily. Let’s take them in order…

(1) Lean as a metaphor for Agile.

One of the challenges that I feel we have had historically within the Agile community is explaining Agile to executives in a way that they can digest and understand. Due to the close parity between Lean and Agile we can use Toyota and others to explain how and why the concepts that we apply in the Agile community work.

(2) Improving the efficiency of the software delivery life-cycle.

Through it’s processes and problem solving tools, Lean provides us with a great tool kit for improving the efficiency of a process. This is where most of the Lean concepts are being applied in IT today. Let me hear you say value-stream maps and waste elimination.

(3) Improving the efficiency of the business processes our IT systems support.

If we improve the efficiency of the software delivery life-cycle we can now deliver IT solutions that support poor business processes at speeds previously thought unimaginable! Lean is putting good process engineering tools in the hands of the IT community. We are now better equipped to work with our business partners to ensure we are building the right solutions and delivering the most value.

(4) Introducing large scale change to organisations.

This is where my focus is today. Toyota, through it’s consulting division, have been transforming other organisations for many years. They’ve been at it much longer than we have in the Agile community and they have learned many lessons along the way. If we look at what they have learned we can apply the same thinking when we are tasked with transforming an IT division to an Agile model. This is all about people, values and encouraging the right behaviours. The process and problem solving tools come much later.

So, I like Agile because the processes that we have developed are more efficient than traditional ones; I can prove this in most contexts with value-stream maps. I like Lean because it helps me to explain these processes, introduce them on both a small and large scale, and most importantly it helps me to continuously improve them over time as we learn. The process that we start with may not be the one that we end with. We learn new things and improve along the way.

I look at Agile and Lean as complimentary. If we study Lean we can become more pragmatic about how we introduce our processes, where they are adding value and where they are just causing issues. Lean also ensures that we focus on people rather than tools, although I worry that in IT we are becoming a little obsessed with the tools (VSM and waste elimination in particular). The Lean Ops movement went through a similar ‘tool age’ before they returned to the people philosophies at the core of Lean.

I really hope the Lean and Agile communities don’t diverge. I feel as an Agile community we have a lot to learn from Lean but I don’t think that it makes sense to refer to Lean as something we apply instead. I argue that there’s no such thing as Agile projects and Lean projects, just projects… and some have more efficient processes than others.