Mary Poppendieck – Lean Software Development – What's not in the book

Posted on November 7, 2007


… was the title of a talk a had the pleasure to attend organized by the Agile Philly user group and hosted by my current employer Siemens Medical Solutions in Malvern, PA.
Mary Poppendieck (together with her husband Tom) wrote the books “Lean Software Development” and “Implementing Lean Software Development”. As far as I learned Lean Software Development is a real world example including the necessary tools for implementing an agile eXtremeProgramming Software Development process. In her talk Mary reminded of some essential issues in implementing an agile (software development) process. This is a short summarization and a good starting point if you’re having the though your neat and agile processes don’t quite feel that way.

  • Do you have a stop-the-line-culture?
    Sakichi Toyoda who is often regarded as the father of the Japanese industrial revolution invented a lot of kinds of weaving machines. He is also referred to as the inventor of Jidoka. He was the first one to invent a weaving machine that was able to detect errors and stop to work right away, avoiding to produce any waste. He also applied this idea to the car production meaning that the line would be stopped if any error occured at anytime. After the reason for the error was fixed the line could continue. In the beginning this policy resulted in a very low productivity but after two years of practice it led to a factory with a constantly high productivity and the best quality known at that time.
    For software development this means that no error in the system should be tolerated at any moment. If an error occurs it has to be fixed before anything else can be done. Furthermore it is the aim to find an error as early as possible limiting the time frame within which the error was produced. If you know your tests ran through in the morning and they don’t in the evening the problem has to have been generated that day. One actual implementation of the rule could be the policy not to allow any checkins as long as any test doesn’t run through.
  • Timebox don’t Scopebox
    What this means is basically the idea not to define the work that has to be done (scope) and then just set an amount time the team will have. The idea is to switch the view on this from a PUSH to a PULL type. There is a constant amount/stream of work. This should be in or be split into estimatable chunks of work. But this work is not pushed into the TODOs of the team, no. The team estimates the amount of time they will have and then pulls a task from the stack.
  • No partial credit
    A project counts as done if it is by 100%. If there is only one thing missing the whole project is not done. This especially means that no one in the team gets a “well done” until everything is settled.
  • Kaizen – relentless improvement
    Another big part of really implementing an agile process is to design it adaptable and to make sure it stays that way. Kaizen means a small improvement every day.
  • Don’t produce waste
    How can you make sure you don’t develop something that isn’t required in the end? The process of checking the developed software against the requirements should be implemented to happen as early as possible or even automatically. The final tests are to show mistakes in the implementation not in understanding what the customer wants. One way to achieve this is to consequently rely on test driven development. If its possible to bring the requirements to a human-and-computer-readable format you could gain that. One approach is described in “Fit for Developing Software: Framework for Integrated Tests” by Rick Mugridge and Ward Cunningham.
Tagged: ,
Posted in: Uncategorized