Behind the Scenes at Global-Roam

I was first introduced to Tom and Mary Poppendieck at a software conference (ASWEC) earlier this year. Lean Software Development is a continuation of the themes that they touched on at that conference. With their familiar analogies from other product development disciplines, Tom and Mary provide thought provoking ideas and practical exercises to help increase the value of software.

Lean Software Development is based on 7 principles, with a chapter for each principle. They are:

1. Eliminate waste
2. Amplify learning
3. Decide as late as possible
4. Deliver as fast as possible
5. Empower the team
6. Build integrity in
7. See the whole

Included with each principle are a couple of “tools” to help you action the principle in your own environment. And, of course, there are plenty of stories from Toyota and 3M to help make things a bit easier to understand and keep the book interesting.

To me, the ideas in the book really make sense. The book promotes a no-nonsense approach to product development and zeros in on what really matters: generating business value. Away with hand-me-down guesswork documentation, planning when a plan will be planned, huge fault-riddled development cycles, dissatisfied customers and bloated, unmaintainable software.

With the book still fresh in my mind and ideas still to be digested I will attempt to present my ideal product development methodology as a result of reading the book. First things first, get rid of the bullshit. The only thing that matters is knocking the socks off the customer and making a few bucks in the process. What’s required? Customer, computer, me.

Customer and me get together. I ask Customer what would really make them happy. I write Customer’s ideas down as tests and prioritise the tests according to what Customer thinks is important. I divide the tests into small workloads and get started.

I begin on the first batch of tests. Each day I pick a few tests and complete the code required to run the tests from start to finish. Each night the tests run automatically to check that what I have done satisfies the tests and has not broken something else. Each morning I check the results: daily feedback.

When I have completed the first batch of tests I present a variety of product options to Customer. Customer lets me know when I have hit the nail on the head and when I have hit my thumb. It’s OK when I miss, or Customer has changed her mind. I didn’t really expect to get it right the first time: I can’t predict the future and I’m not a mind reader. I haven’t done all that much work and I have left my options open while doing the work. Change is welcome. Risk is low. There will be no 6-month rewrite of long-forgotten features or, at worst, a totally useless product.

Write new tests. Prioritise. Divide. Complete a set of tests every day. Run the tests every night. Present to Customer. Repeat.

That is the method. Check this space for the results. And be sure to check out the book, Lean Software Development by Tom and Mary Poppendieck.

This entry was posted on Friday, June 26th, 2009 at 4:03 pm and is filed under Book Review, Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.