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.
Scrum is getting a real bashing at the moment as you can see here and here and I think it could do with some defending.
I was on a team that adopted Scrum and it really empowered us. After a while, pair programming, TDD and refactoring became common-place because we learnt through the iterative process that they helped us write better software. People saw the positivity in the team and the productivity improvements and it lead to a fundamental shift in the department’s culture. Now all our teams are doing some form of iterative development, BDUF has gone out of the window and practices such as TDD and pair programming are actively encouraged by the management! People at all levels can see the difference it’s made to our productivity and the reputation of our department.
So Scrum can be very successful. It would never have got this far if people weren’t doing Scrum and getting positive results, in fact agile would not have become so big if it wasn’t for the success of Scrum so we’ve got a lot to thank it for.
However, here is where I think some of the criticism sticks:
Three people on the team above (including myself) went on the Certified Scrum Master course ran by Mike Cohn who is an excellent teacher, but I’ve since been on a “Scrum Estimating and Planning” course which seemed more geared towards telling people what they wanted to hear rather than any fundamentals of agile and the problems it’s trying to solve. As James Shore suggests in his article, the quality of the teachers on the CSM courses has a huge impact.
As company’s will always prefer to send people on a course rather than create a learning culture within (especially if they’re very small, which is more forgivable) the 2 day Certified Scrum Master course will be with us for a while yet and most significantly, will continue to be the main entry point to the agile world. People will continue to adopt Scrum because they’re failing with whatever they’re currently doing and continue to fail because the Scrum trainer will teach them how to write a story or run a stand up but not address the root problems, partly because you could never go into such detail in such a small amount of time and partly because that’s not the point of the course.
“Certified Scrum Master” suggests that you’re some kind of guru (it certainly sounds a lot more impressive then my BA(h) in Business and Quality Management which took me 4 years to get a mediocre grade in). Perhaps a name change would make it more credible. If organisations were not led to believe this 2 day course is going to solve all their problems then they wouldn’t be in the situation they’re in.
Edit: Since writing this article (a few hours ago) I’ve had a significant change of heart and feel I’ve incorrectly laid blame at the foot of the Scrum Alliance. It’s not their fault that their Certified Scrum Master training (which is designed to teach people how to become Scrum Masters, not solve all their problems) has become so popular. However, it is a bit unfortunate that the name could so easily be misinterpreted to mean more that it is and it’s also unfortunate that organisations hook on to the most simple looking solution to their problems (and no, I haven’t been threatened by Scrum mafiosa or bottled out I’ve just changed my mind).
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
