QualityDev.net

Tom and Mary Poppendieck are two leading evangelists of Lean software development who share their experiences at conferences on a regular basis. Their first book was an excellent introduction to lean principles and tools, and this book continues the theme by explaining the concepts in the real world, and how to implement them.

Firstly, let me say that, in my opinion at least, this is a book for managers who want to find out more about lean processes, rather than being aimed at software engineers or architects. And in this context, it does very well. The theories and concepts described are well laid out in individual chapters that cover: Principles, Value, Waste, People, Knowledge, Quality and Partners. The book quickly gets you thinking about how to start implementing these ideas in your own organization.

For a book that is less than 250 pages, I was surprised by how long it took me to read. This was mainly due to the large number of very good and equally intriguing references and examples that compelled me to investigate further.

My favorite chapter is “Waste,” including the description of the “Seven Deadly Wastes.” Sound advice is concisely provided in the form of often-missed principles that lead to waste, for example:

If there isn’t a clear and present economic need for the feature, it should not be developed!

Other, less obvious examples are also given such as:
Rotating/replacing staff – handoffs are a good example of losing tacit knowledge (waste)
Map a Value Stream - although not necessarily accurate, does identify waste from the customers’ perspective.

Waste is one of those concepts that is somewhat subjective, and in one part of the book there is an example of an organization that ran multiple projects to develop different versions of the same system against a hard deadline (absolute minimal functionality but guaranteed, more functionality but not guaranteed, ideal system but very unlikely to be completed by the deadline).

This can appear contradictory to a key agile principle: to develop only what you need (and indeed to a key Lean tenet, which is to reduce costs). The authors justify this by stating that one system will be implemented by the defined deadline and then something much better will be built in time for the next iteration. However in my experience, organizations tend not to have the resource available to perform simultaneous development of the same system. It is more usual to deliver to the customer as much functionality as is available by the deadline (remember that it will be working through smaller iterations) and then to implement any improvements over time depending on priority against other parts of the system.

The chapter on quality begins with a discussion of the Polaris Submarine project and moves onto a description of iterative development. Then follows details of what I would refer to as implementing quality gates, code reviews, test driven development, standards and continuous integration. More detail and an example of the benefits of CI would greatly enhance this chapter.

I would like to have seen more examples from the software industry to explain the many well laid out concepts. But some of the brief examples used from other industries hit the mark well, for example: Deadlines! Daily Newspapers and Concerts/Theatrical Productions hit deadlines constantly and consistently unlike the software industry.

I believe the best example in the book is the Rally Software Case Study, where they explain that it took 14 months to eliminate technical debt using a Strangler approach. Some of the concepts in the book read as if these are quick fixes to implement that will see a fast return. This example highlights the fact that process management change does take time to take effect.

Overall, I consider this to be a great book for laying out the principles and how to begin to implement them, especially for managers wanting to find out more about lean software development. It covers the concepts well and provides excellent further reading resources.

The Poppendiecks’ companion site provides an interview about the book. Other useful resources for anyone who wants to learn more about Lean are the Yahoo groups leanprogramming. and leandevelopment.

When investigating Lean for the first time, books and articles that give an overview of the principles and tenets of Lean can appear to be contradictory. For example many managers may question how Cease Inspections can be advocated where a basic principle of Lean is to Create Knowledge. Surely one of the fundamental reasons of Inspections such as Code Reviews is to help more Junior Developers adhere to company standards and learn better, more efficient ways to code?

I discussed this further with Bob Martin (Uncle Bob) and Jean Tabaka and they gave some good insight into what this phrase ‘Cease Inspections’ really means, even with Jean’s radical conclusion of Firing your QA department

When your manager says: “We expect you to write good quality code,” many people, especially junior developers, will freeze, thinking about code structure, performance, best practices, company coding standards, patterns… the list goes on and on.

At SD West, I recalled David Bernstein’s advice when writing a class. He said to ask yourself the question: “How would I test this class?” If the answer is too long or complicated, then you need to refactor the class. That seems like a good starting point for someone who is not sure where to start.

That led me to think that a good topic for Enerjy.tv would be to ask our panel of experts what one piece of advice they would give to developers when thinking about quality issues. So that’s what I did.