One of the keynotes at XPDay 2008 was from Dan Jones, the author of the books The Machine That Changed the World and Lean Thinking and one of the team of people who came up with the term “Lean Production”. It was quite humbling to be in the same room as the living person who has probably been more influential than anyone else to modern business processes in every industry and all over the world.

One of the most interesting things he said was that when they were coming up with the name for what they were trying to promote they considered “agile”, but thought it would be too difficult to sell and so decided on Lean instead. Also, he didn’t have much understanding of modern software development, but at a glance saw very little difference between what we called Agile and he called Lean.

So when we talk about Lean Software Development being an Agile methodology we’ve got it the wrong way around. Agile is Lean, Scrum is Lean, XP is Lean. You were already doing Lean Software Development, you just didn’t know it!

In my mind it’s time to drop the titles (which all carry too much stigma) and simply start referring to it as professional software development.

Recently, whilst building a very complex work flow system for my organisation we joked how it would be much less expensive and more appropriate if we just gave them a few whiteboards and a stack of coloured index cards instead. It was working really well for us so why couldn’t it work for them?

I’ve just finished reading a few articles from my current favourite blog Evolving Excellence on the phenomenon that companies seem obsessed with trying to automate every possible process and are happy to spend gazzillions doing so, when a simple kanban would be far more effective and a darn sight cheaper.

Quote: “‘Excellence through simplicity.’ To me that quote from Lao Tzu has always epitomized one of the fundamental tenets of real lean.  Don’t proceduralize complexity, and don’t make something more complex than it needs to be.”

http://www.evolvingexcellence.com/blog/2006/06/forget_sap_run_.html

http://www.evolvingexcellence.com/blog/2006/04/keep_one_eye_on.html

The workflow system we delivered is barely used by the customer (who asked for it) because it’s too rigid and every possible scenario is not accounted for. They’re very keen to make improvements (which will cost money), so maybe I really will suggest a kanban board instead this time.

It’s startling to see how much momentum has been gathering around Lean Software Development and I don’t think it’s a coincidence that at the same time many people seem to be falling out of love with Scrum.

At last year’s XPDay there were no sessions on Lean methodologies, this year there are three (the one I’m doing with Matt Wynne, Karl Scotland’s on Kanban, Flow and Cadence and a keynote from the Lean Enterprise Academy).

There’s something about this that makes me feel slightly uneasy. What’s so wrong with Scrum? Well, I’d be the first to stand up and say that Scrum has it’s failings - they’re the same reasons it’s become so popular. The simplicity, clear definition and business-friendliness of Scrum make it easy to sell (arguably, unlike XP) and waterfall or traditional development dynamics (project manager, use-case, Gantt chart, meeting) can be easily translated into Scrum’s characteristics (scrum master, story, burn down, stand up). Unfortunately all too often this is what happens resulting in what’s become know as Cargo Cult Agile, or WAgile, the underlying concepts and belief systems being mostly ignored. When I did Mike Cohn’s Certified Scum Master Course his principle lesson was “Inspect and Adapt” which he repeated endlessly throughout the course, but when I look on the Wikipedia entry for Scrum this doesn’t even get a mention so it’s easy to see how this happens.

So what’s so different about Lean? Well for a start there aren’t any clearly defined rules, but instead principles such as Eliminate Waste and Build Integrity In. However it strikes me that there’s just as much room for abuse with concepts such as Kanban, Minimally Marketable Features, Cumulative Flow Diagrams and so on. Consider this exert from The Toyota Way (which I’ve shamelessly stolen from James Shore’s article on Kanban Systems - I am actually reading this book as we speak, but haven’t got very far yet):

“…TPS experts get very impatient and even irritated when they hear people rave and focus on kanban as if it is the Toyota Production System. Kanban is a fascinating concept and it is fun to watch… When is the kanban triggered? How are the quantities calculated? What do you do if a kanban gets lost? But that is not the point… The challenge is to develop a learning organization that will find ways to reduce the number of and thereby reduce and finally eliminate the inventory buffer… So kanban is something you strive to get rid of, not to be proud of.”

Many of the reasons people aren’t being as succesful as they’d like with Scrum are exactly the same reasons they won’t be any more successful with any other methodology. People tend to focus on tools because it’s a lot easier than trying to tackle the often very difficult, challenging and more fundamental problems they grew from. Real change is hard and takes time, a very long time in some cases.

If you’re failing with Scrum don’t think lean, kanban, extreme programming or any other colour of agile will save you. Essentially if you’re failing it’s because you’re doing it wrong. However if you’ve found Scrum is working really well for you and has brought enormous benefits maybe you should come to the talk Matt and I are doing at XPDay and see how we evolved to a more lean process.


Update: since writing this James Shore has written a frighteningly similar post on The Decline and Fall of Agile, but I guess great minds think alike huh? ;-P