Steve Freeman Rotating Header Image

Lean and Agile: should cousins marry?

Dave West has written a cautionary posting (Lean and Agile: Marriage Made in Heaven or Oxymoron?) on the dangers of taking a simplistic view of Lean and Agile. He’s right that a naive reading of a Lean approach to software will just trap us in another metaphor, manufacturing, that’s as inappropriate (or appropriate) as we once thought building construction was. And yes, there will be teams that adopt the techniques without understanding the meaning behind them, just as we’ve seen with all the Agile methodologies. I particularly like his reminder to show the bigger picture by making visible the current product backlog, with all its inconsistencies and misunderstandings.

I think there is a place for the production features of Lean in software practice, such as the idea that when I get something working, it really works and it stays working. I think there’s value within development on staying focussed on the task at hand and getting in “Done, done”. For some teams, just getting their system to a state where they can safely make and deploy changes is a huge advance. As Martin Fowler points out, there are quite a few “Agile” teams that can’t achieve that. Working in a reliable code base where all the mechanical stuff just works is so much more productive than the alternative, which counts, I think, as removing waste.

David Anderson claims that nowadays the most significant waste is usually around development rather than within it. It’s in the weakness of the organisation’s communication and prioritisation, the stuff that Dave has pointed out we need to support; teams waste effort when they don’t communicate and understand.

Once I started exploring deeper into the Lean material, I discovered the Toyota Product Development System which some think is even more important than their Production system. From a Production point of view, it looks very wasteful because they work on multiple possible solutions but choose only one, which allows them always to deliver on time. From a Product point of view it’s worth the cost because slipping the date is too expensive, and it’s not totally waste because they record what they’ve learned from the failures and use it the next generation of products. I think this is where much of the activity that Dave wants to remind us about belongs, and many software teams just don’t spend enough on exploring the range of features and technical issues available to them.

To mangle Dave’s metaphor, I don’t think we should expect wedding bells because the couple is already too closely related. There will be mistakes of interpretation in the field, such as dismissing retrospectives as waste, but, properly understood, the underlying values share too much DNA.


  1. rob bowley says:

    Spot on Steve, exactly what I recently tried to say (but much more eloquent) in an article I wrote about why Lean projects will fail for the same reason Scrum projects do (here) – an absence of understanding of underlying principles.

    You comments are also pertinent to the ongoing “Agile War” Jeff & Joel started, they’re simply missing the point.

  2. As I mention in my own response to Dave’s article, I work for a company that does product development. We aim to do product development the same way (as far as possible) as we do software development. Neither is especially Lean. Successful, though.

  3. Hi Steve,

    Perhaps I was too quick to agree with you on InfoQ. Now I think about it, I have had some exposure to the TPDS, although I wouldn’t describe it as a primary source, and I wasn’t impressed. Here is why:

    1. Toyota are known for a quick time to market for new products, but they aren’t well known for good product design. For example, the Italians have a better reputation for esthetic design, and the Germans have a better reputation for innovation, introducing things like ABS, air bags etc. In the area of design the japanese have a reputation for mimicking others rather than being leaders.

    2. New product development at Toyota exists in a completely diferent context then new product development for most software development organisations. In fact only organisations like Microsoft can be said to share a similar context. The reason? Volume. In terms of their total expenditure new product development is only a small fraction of the operating costs of Toyota when compared to software development. The bulk of their costs is in production: tooling, materials and the like, which is why the organisational focus seems to be more on the TPS where Toyota is a world leader, rather than in the TPDS, where they can be considered an also run, in terms of the desirability of the output.

    3. Conccurent development is an affordable option when you can recoupe the cost from a large customer base. We just don’t have that option to the same degree in software.

    Which brings me back to my main point. Applying principles and practices out of context is a very dangerous thing indeed. We know that we share the same values and the same philosophy, but we do not know how relevent Lean principles and practices are to us. Although we can see parallels.

    Toyota didn’t copy anyone else, they spent three decades discovering what worked for them, in their context. I don’t think Lean will turn out to be a free lunch. I think we still need to do the hard work to discover which Lean ideas works for us in our context just as Toyota did. Lets hope it doesn’t take three decades :) In the meanwhile we already have home grown approaches that have a proven track record of success.

  4. @Paul … and they’re rubbish at Formula 1, too. That’s not really the point. It’s not about copying their processes directly, after all we don’t recommend that design teams have to move into dormitories near the office. It’s about taking the core ideas that make so much sense and finding out what it means to apply them to software.

    Remember that Ohno got some of his supply chain ideas from visiting US supermarkets.

  5. allan kelly says:

    The Agile and Lean relationship has been on my mind recently and I was blogging about it only last week

    (Steve, you were there, you should remember Dan Jones comments too.)

    Developing Software is like, well, Developing Software. We can learn from production and we can learn from product development. The industry has been plagued before with people wanting us to adopt production line techniques so it would be wrong to swap one production line metaphor for another (even if it is the lean one).

    Still, we can learn from lean manufacturing and we can learn even more from lean style product development – or Knowledge Based Product Development as its better called.

    As to the business, I’ve come to the conclusion that fixing development it actually the easy bit. We know how to do that, it requires a will to do it, and some cash helps. Its fixing what the business wants, the business strategy and how it communicates and develops it all that is the hard bit.

  6. Hi Steve,
    I agree we don’t want to copy blindly, but there is evidence of this happening. I now work on a team where the coach says we will only have retrospectives when we need them, because they get in the way of flow and are waste.

    We also have a PDCA board for retrospectives. Now I did PDCA in 1996. It didn’t work then for software, and I’m pretty sure it still doesn’t work now.

    Keiths point is correct. We have native approaches that have been tried and tested in a software context for over 20 years (or however long Ward Cunningham, Beck and others have been doing this stuff). Why throw out the baby?

    (PS. I know this isn’t what you are suggestion, but from my experience it does seem to be what is happening).

  7. Just one last point.

    >> Remember that Ohno got some of his supply chain ideas from visiting US supermarkets

    Yes, and he then spent a decade perfecting Kanban and production leveling within Toyota before spreading these practices to the rest of the supply chain.

    I am not seeing anyone in the Software industry doing this degree of hard work. I do see a lot of blind copying though.

  8. John Cook says:

    Smart is what smart does. And it is good to be lost sometimes. That is the only way to find something. Just remember what you did and keep going. AND the more mistakes you make, the more sucesses you have, too.


    John Cook
    Agile + everything else

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>