People sometimes ask me about the structure of our internal development team, and to what extent we’re truly “agile”. My response is that we’re actually more “lean”. I happily give examples of some of the key working practices we have. I generally don’t explain the difference between “lean” and “agile”, though.
Sometimes, people use these terms interchangeably. I think this is wrong, but understandable. As a JIRA user, I’m used to it offering a Kanban board to run a scrum sprint. This can be a great choice, but it muddies the waters. Let me take this opportunity to explain my thinking then!
Origins of Lean
Let’s dive into history quickly – at least, the Wikipedia version, which will suffice. Lean manufacturing, the form we recognise it today, was first implemented in the early 20th century. Toyota, the car company, created the Toyota Production System based on the reduction of three types of waste:
- muda – non-value-adding work
- muri – over-work (e.g. bottlenecking)
- mura – variation, or “unevenness”
Reducing these types of waste should improve “flow” in a manufacturing context. This is exactly what Toyota found, and they became the largest car manufacturer in the world – at least partially in credit to the TPS.
As we know, software is eating the world, and this thinking applies to software development. Most famously, the Poppendiecks wrote “Lean Software Development: An Agile Toolkit“, a comprehensive mapping of lean principles.
Now, manufacturing is quite different to software development. Replicating software is not hard; replicating cars is. Some of the waste that Toyota’s system would identify rarely arises in a software context.
Equally, there is a lot more potential waste in most development contexts. Bottlenecking is a huge problem, and non-valuable development (“muda”) is commonplace.
Rise of Agile
The Agile Manifesto, set out in 2001, took a number of lean principles one step further. In particular, they empower people over processes and emphasise response to change. This moves the thinking beyond what was possible in a manufacturing context.
Similarly, the “Decide as Late as Possible” principle in the Poppendieck book was compared to die manufacture in car plants. With software, a decision can be delayed to much later, though. Most software decisions are also reversible, to some degree.
This all makes sense. Software is not manufacturing, and the principles of lean should be applied – trying to mash the TPS into a software shop wouldn’t work. But, for me, agile has become something else.
Constraints and trade-offs
Both agile and lean force you to think about waste. In software, we particularly want to focus on user needs (avoiding muda). However, tactically, there are a number of things you can do in the software world that are different.
One great way of building things people want is to experiment, prototype rapidly, and gain user feedback. This iterative process is at the heart of agile. A lot of these prototypes end up being thrown away, though. Are we creating more waste? Well, in a sense yes – but each prototype tells us something about how to design the next iteration. Iteration generates a lot of small-scale waste, but ensures a design is valuable.
Agile tells us we don’t need a plan; just alignment and a goal. We can iterate and adapt rather than trying to plan and predict. The logical extrapolation of this includes the #NoEstimates crowd (my thoughts on this haven’t changed much).
I like Martin Fowler’s general criticism here:
Most methodologists want their methodologies to be usable by everyone, so they don’t understand nor publicize their boundary conditions. This leads to people using a methodology in the wrong circumstances, such as using a predictable methodology in a unpredictable situation.
– the New Methodology
Lean processes are very much about reducing waste, improving product and iterative improvement – but it’s quite an evolutionary process. The TPS does not anticipate a large amount of change in the product. The design of a new car is similar to annealing: the size of acceptable change must reduce as the end of the project nears.
Agile accepts change, first and foremost, and holds similar principles to lean. The value of the product to the customer is crucial, and indeed they may co-create it. However, lean teams may be large and a lot of their work can be process-driven. An agile team must be quite small, and cannot rely on process to function.
Using agile versus lean
Both systems treat value to the end user as their first priority (fundamentally, so do other methodologies, though – including Waterfall). I tend to differentiate them by second priority: for agile, it’s acceptance of change. For lean, it’s creation of flow.
There is no right or wrong here in the abstract. The type of thinking most applicable in a given situation comes down to what is most useful. For highly experimental products, adaptation to new data is crucial – highly agile techniques are a must. As we try to scale a product, lean thinking should begin to dominate.
There is absolutely a continuum between these positions. Any organisation should adapt these processes to their specific situation. Mixing in regulatory requirements, operational requirements, or other constraints is OK as well, if that’s what is needed.
What is crucial is ensuring an organisation focus on what matters, and prioritising the outcomes of the process that matter most.
