If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!

Lean project delivery and agile software development are sidling up to one another. Quite a number of the readers of this weblog are from the agile software/extreme programming/scrum development community, or should I say 'communities'. I can't tell yet. I am clear all three camps share a great dissatisfaction with the status quo and conventional wisdom. (Maybe when I'm able to pay closer attention, I'll be able to see the ground they've carved out for themselves.)

Two authors have caught my attention. Mary and Tom Poppendiek are well along to publishing a book on a lean approach for software development. They have posted a working manuscript of the book Lean Development: A Toolkit for Software Development Managers looking for comments from the community. I've been reading the manuscript for the last few days. The book is planned for publication in April 2003. They ask that folks not quote from their working copy, so I'll paraphrase some of their opening comments. (Please note that I take full responsibility for my interpretation.)

What if there were tools and practices that allowed for quick changeover…so there'd be no penalty for customers to change their mind?

Mary and Tom claim we have our mental models to blame for the current state of software development. The prevailing view is software is difficult and expensive to change, so we must take the extra time upfront to lock down the requirements to avoid those changes. I sse the same sort of thing outside the software community. People make similar statements about mechanical engineering, architecture, and construction. In all these disciplines the approach is get the client to say what their requirements are then don't let them change those requirements without penalty to the schedule and increased costs.

But what if you put the conventional wisdom aside…what if software was no longer difficult to change? What if there were tools and practices that allowed for the quick changeover of code just as Toyota has done with the quick changeover of production machinery? What might be possible? But you say, "Why invest in changing software quickly? It'll never pay off. We don't let our clients change their minds." Right. But what if your competitiors learned how to do it? Where would you be?

Both Toyota and Honda are in their second generation of production hybrid automobiles. Detorit doesn't have the first commercially viable vehicle. By the time they come around Toyota and Honda will be on the third or fourth generation. Those firms have taken the lessons of quick changeover from the factory floor to product development: design, marketing, tooling, supply, and process design. It is just this opportunity that Mary and Tom are writing about for software. There's a revolution underway. Many of you are a party to that revolution. The rest of you watch out. There's a hybrid in your review-view mirrow bearing down on you.

Read about scrum at Jeff Sutherland's SCRUM Log from the person there at the beginning.