What fascinates me the most in the Lean software development approach is the quality of the people that support it. The Poppendieck are not an exception to this rule. Their book achieves the seemingly contradictory goals of being very insightful but still easy and captivating to read. It might be however easier to have the right flow when you are a Lean adept ;o)
The book starts with a chapter on systems thinking that takes also examples outside the software development world like Southwest Airlines. The next chapter on technical excellence is dedicated to a panorama of the software development approaches. Chapter 3 is kind of my favorite part of the book, extracting process management knowledge from the history of the construction of the Empire State Building, a project that took only one year to be completed. Chapter four presents the tools for improvement. Finally, the last part of the book is dedicated the people and leadership aspects of Lean.
The structure of the book makes it very pleasant to read, mixing the presentation of lean concepts with case studies and short personal stories. It is definitively a book that I will recommend to every software developer and manager…. and wish that every software developer and manager had read. Even if you think that Lean is not for you or you are a Toyota owner, this book provides a mind-opening text about what the values of software development and organizations should be.
Reference: “Leading Lean Software Development – Results are not the Point”, Mary and Tom Poppendieck, Addison-Wesley, 278 pages, IBSN 978-0-321-62070-5
[…] I started a conversation with the question that had been bothering me: “How do you reconcile the lean view that tests are waste with the need for tests in software development?” Mary’s immediate response: “Unit tests are what let you stop the line.” (quoted from the Foreword by Dottie Acton)
In our experience, the most common causes of policy-driven waste in software development are:
2. Economies of scale
3. Separating decision making from work
4. Wishful thinking
5. Technical debt
The strategy of designing the effort to fit the constraints, rather than computing the constraints form the design, is absolutely the most effective way to achieve reliable delivery.