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.

Glitch Watch is a bit abbreviated this week by virtue of the fact that I am on the road which severely limits the amount of time I have available to sort through the mail bag. However, one story did catch my eye this week. Irish airline Aer Lingus inadvertently advertised €5 (about $8) business class seats from Ireland to Boston. The normal business class seat price is apparently €1,775 (about $2,765) each way.

Between 7:30 am and 9:00 am when the “glitch” was discovered, about 700 tickets were sold, including some to Aer Lingus employees themselves, and the airline now has the problem of what to do with them. Initially, they canceled the tickets, on the basis that it was clearly a mistake. But in the PR firestorm that ensued, the airline backpedaled and offered the customers economy class tickets. Still not a bad deal!

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

Stillwater, MN: the Stillwater Lift Bridge got stuck in the open position for more than two hours this week after its controlling computer got “confused”. According to Minnesota Department of Transportation spokeswoman Mary McFarland-Brooks, the computer “said that the bridge was both open to boat traffic and available to motorists at the same time, which obviously couldn’t be the case.” Although strong winds were thought to have played a part in the incident, a reboot of the computer fixed the problem and had motorists on their way again.

Meanwhile, in Japan last week, Hitachi announced that they had discovered a programming fault in software used to measure the impact of earthquakes on pipes at atomic power stations. The fault allowed the software to underestimate the impact of earthquakes on steel pipes in eight nuclear reactors. Good job it wasn’t anything important. The software has been in place and monitoring the pipes since 1980. Test results using corrected software indicated that there were no problems with the pipes.

Problems with a new $3m automated trip reservation system caused difficulties last week for disabled users of Chicago’s paratransit system. Apparently, computerizing the dispatch system was supposed to make things better for the roughly 6,000 disabled people who use the system each day. But according to Pace Executive Director T.J. Ross, “it has created more problems to date than it has solved.”

Back to London’s Heathrow Airport again this week, where problems with the new Terminal 5 baggage handling system just won’t go away. The new terminal has been plagued with problems since it opened at the end of March, and on Saturday the baggage system failed, causing handlers to have to sort bags by hand.

But our favorite story of the week comes from Lee County, FL where, if you are using a TomTom to find your way around, you may end up going around in circles. It seems that there is a specific area of road that has the device confused. According to a Tom Tom spokesperson, “There is a segment of road between I-95 and the first road that crosses the route that causes an anomaly due to the manner in which TomTom’s software application processes the location of Ft Myers.” Apparently the problem has been found and fixed, and an update is available from TomTom’s web site.

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.

Wednesday last week in Lake Placid, FL, residents were warned to boil water after a computer glitch caused the town’s water storage tanks, which together hold some 300,000 gallons, to run dry. By Friday, the water was back on, and certified drinkable.

Meanwhile, at Heathrow Airport in London, England, Terri Patsalides had a long wait for her baggage. So long, in fact, that she stopped by the Giraffe Juice Bar for a coffee, and had time for four cappuccinos. However, when she got the check, she was a bit surprised to find that she had consumed £360,000 worth of coffee (roughly $720,000). Patsalides said “When I got the print-out I told the waitress that although they were very nice, I thought £90,000 a cup was a bit over the top.” According to the Giraffe Juice Bar it was “just a glitch on the computer system.”

Finally, to Portage, WI, where problems with the Wisconsin Department of Natural Resources computer system caused delays for turkey hunters trying to get their permits last week. According to Doug Williams, the owner of DW Sports Center, issuing the tags was taking one to two hours instead of five to ten minutes. “Thankfully, they’re not blaming me,” he said. Good job too. If you’re going to upset a bunch of customers, it’s probably best not to pick the ones with shotguns.

 After three months of beta testing Enerjy, it’s April 1st and that’s the date we always said we would go live with the commercial version of the product.  So, as of today, we’re switching from the free beta version to a 30-day trial model.  If, 30 days after you download and install Enerjy, you decide to keep it, you’ll need to buy a license at $195.

We have discussed the variables at length.  The sub-$200 level feels right to us, in terms of the value that the product brings.  Software pricing is a tricky subject and it’s amazing how almost everyone has an opinion on it.  Feel free to comment if that includes you.  We’ve also discussed the relative merits of a 30-day trial versus having a “free” and a “professional” version of the product.  The problem with the latter approach is that different people will pay for different features, so it becomes hard to draw the line between the “free” and the “paid for” feature sets.  So, in the end, we decided to go with a pretty traditional model, a $195 perpetual license with a 30-day trial.

During the beta period, we had about 1,200 people download and try out the product.  We have also been pretty pleased with the level of engagement on the forum.  In fact, we decided to give free licenses to anyone who posted on the forum during the beta period.  Just our way of saying thanks for participating.  Also, students and other academic uses should be free, we think.  If that includes you, drop us a line.

So, to everyone who participated in the beta, we thank you.  If you have thoughts or suggestions about the commercial model, please send them our way.  We’re all ears.