Copyright: 2007

Publisher: Addison-Wesley

ISBN: 0-321-43738-1

Sub-titled "From Concept to Cash" this book from the Poppendiecks explores in detail what it takes for software development teams to take a concept and turn it into a working solution for the customer in an Agile manner.  They start with a brief history of Lean production concepts and then delve into the Principles of Lean as applied to software development.  The core of the book digs deep into very practical methods of converting a more "traditional" approach to software development into a "lean" software development process.  While the bulk of this book will be familiar ground for anyone working in an Agile development shop as I do, the book is well worth reading regardless of your experience with Agile. 

History

Predictably, the history chapter gives a high level overview of the Toyota Production System and the roots of lean manufacturing.  Early on though the Poppendiecks show their intention of translating the principles of lean production to principles of lean development.  They offer this chart of similarities between the two systems:

For the reader familiar with lean production principles, this sort of mapping is invaluable to begin applying these principles to the information centered "production" of software. 

Principles and Practices

This chapter is must read material for anyone who is considering Lean Software Development.  Many of your questions will be answered and a general outline of the principles that make up the whole is presented with great clarity.  There are a number of opinions about what Lean Software means but the Poppendiecks have clearly extracted the principles of Lean Production and translated them to the Software World.

They identify 7 Principles:

1. Eliminate Waste
2. Build Quality in
3. Create Knowledge
4. Defer Commitment
5. Deliver Fast
6. Respect People
7. Optimize the whole

Waste is defined as "anything that interferes with giving customers what they value at the time and place where it will provide the most value."  This is one of the best definitions of waste I have read and it truly embodies the principles stated by Shigeo Shingo and Taiichi Ohno in their writings. 

Interestingly as I read this chapter I had the following thoughts. More traditional methods of manufacturing and software development focus on reducing risk rather than reducing waste.  In reality, focusing on reducing waste WILL reduce risk however focusing on risk will often lead to waste (leading to greater risk!)

Value

Creating value is the key to a successful business.  One of the interesting parts of the chapters deals with "Delighted Customers".  The idea here is that it is not enough to just satisfy customer but you must instead delight them.  In order to satisfy customers you must either "1) increase performance by adding features or 2) discover needs that the customers aren't even aware of and delight them by meeting these needs."  It is obvious that the goal should be to do both of these things and yet most companies feel they are doing well if they just accomplish number 1.

 Towards the end of the chapter on Value the authors focus on IT-Business Collaboration with regard to internal projects.  They advocate treating internal software development projects as products that are being sold to the internal customer.  One result of this is that IT departments will feel responsible for the success of the business unit rather than shoving that responsibiltiy off on the end user.  This will create greater energy and dedication to quality in the development process.

Waste and Task Switching

One of the keys to achieving good feature development flow is to limit the amount of task switching that goes on.  Teams should be allowed to work on a feature until it is done without having to switch back and forth between other features that other customers have been promised.  Doing one feature all the way through will eliminate spin-up time as the team members come back to working on that feature. 

I have recently argued that the principle of "pair switching" in eXtreme Programming violates this idea.  The stated reasons for not switching tasks is to eliminate the distraction of having to stop thinking about one problem and start thinking about another.  It seems intuitive to me that includes switching from one story to another as you swith from one pair to the next.  Others have argued that "task switching" is only applicable to "sticking with one story through to completion" on the team level and not the individual level.  I tend to think that it is a very rare team that can engage in that kind of "team think" to where there is little or no lost effort in the distraction of switching from one pair to the next. 

That said, I don't think that pair switching is ALWAYS a bad thing.  The benefits of shared code knowledge and fresh perspectives on difficult problems are definitely not to be overlooked.  I think the dogmatic practice of "you must switch pairs and switch often in order to be XP" has missed the vital concept of minimizing task switching.

Speed

One of the seven principles outlined early in the book is "Deliver Fast".  As the authors state, most software development shops have more work than they can possibly get done.  The reason is that there are always a great number of requests for features that come in alongside the work that is already in progress.  It becomes necessary to minimize both the number and size of things that are in process. 

What do you do about customer requests that you don't have time for?  Traditionally they get placed in a queue somewhere and often are never looked at again... but they are "on the list".  But as the authors point out, from the customers perspective, once they place the request, that order is placed and the response time clock begins.  Since "Deliver Fast" is a relative term and one that is highly subjective, the best way to manage that speed for these customer requests is to manage the customers perception.  It is arguably better to tell the customer "that's an excellent idea and we wish we could implement that but right now we cannot fit that into the plan" than to have the customer think that you are working on their idea when in reality you have forgotten it completely. 

Later in the book in the chapter dealing with Knowledge, the Poppendiecks explore a case study in problem solving.  They deal with this very issue only with regard to bug fixes.  After some analysis the team in question found that the great majority of bug reports and requests that had been in the queue for more than 16 weeks (not an uncommon thing I am sure!) were no longer desired.  This led them to simply chop off all of those old requests and formulate a plan to keep requests from getting that old again. 

Part of the solution lay in categorizing requests.  Low priority requests were contacted by customer support who usually found alternative solutions to the problem and were able to satisfy the problem without adding it to the queue.  In some cases the amount of effort required for the request was relayed to the customer and they admitted that the request did not justify that amount of effort. 

Higher priority requests then were put into the regular work-flow and eventually the team was able to resolve requests coming in at relatively the same rate as they were requested.  With a small (four week) buffer, the team was able to keep from feeling fluctuations in their regular work flow as a result of the extra requests and at the same time they were able to keep the queue from growing longer and longer.

I did not see any mention of takt time in either of these sections of the book but I believe that you could easily relate the lean production concept of takt time to this method of handling requests.  The idea is that you produce things along the line as fast... and only as fast... as the orders come in.  This eliminates queues and backlogs in production and can be used the same way in handling software requests.  I believe the real key to managing fast delivery of software is managing the ordering process as well as the production process.

Sharing Knowledge 

There wasn't a lot of practical advice regarding the building, sharing and keeping of knowledge in an organization however there is quite a good discussion of the concepts.  One of the sidebars I found interesting dealt with the 3M notebooks.  Mary Poppendieck worked for 3M and they gave each scientist a lab book.  In this book they kept detailed notes of experiments, data, conclusions and all sorts of knowledge that they gathered on a daily basis.  When the book was full it was checked into the library and another one was started.  The knowledge was extracted, summarized and made available to others in the organization. 

It would be interesting to come up with a virtual "notebook" that would be useful in a software development lab.  We have wiki's and other useful tools but they aren't terribly good at organizing data.  Perhaps an easy to use wiki with a great search engine attached would be a plausible solution here but I have yet to see any concrete examples of how to retain the knowledge that is generated during software development. 

Conclusion

I approached this book hoping to come away with a greater understanding of just what Lean Software Development was all about and the book delivered on this promise.  It is an excellent mixture of practical advice, anecdotal evidence and solid theory.  I would strongly recommend this book to anyone seeking a better grasp on the concepts of Lean.