It is good to have a overall concept of lean development.
However, what is presented here is absolutely not rigorous enough.
For instance, the author lists 7 lean principles in manufacturing and adopts them for software development.
Let me ask a couple of questions here:
Are these 7 principles complete? meaning have you identified all the lean principles? If yes, can you prove it?
If no, then these 7 principles are arbitrary? Who cannot BS some randomly chosen principles anyways?
Your first - First Book on Agile Development
This book is a great first read for you if you are ready to learn about "NEW" tools for developing a product that your customers are expecting in the expected time frame and with a no-surprise budget.
I was introduced to LEAN tools from a manufacturing perspective and could not make a coherent connection between those tools and development tools. This book was a great start in making that connection.
I've been able to apply many of the tools from the text and examples with positive results within my team, with my customers and with contracted teams.
Excellent read
This is a great introduction to Lean software development principles. It makes a logical connection from lean product development and manufacturing systems to software development systems. It was so good that I also started reading the 2nd version.
Comes complete with instructions and a warranty
Shortly after leading my first Six Sigma process improvement project, which involved my constructing of software to automate client business processes, I came across this book by the Poppendiecks. At the time, the integration of Lean and Six Sigma seemed to be picking up steam, and rather than reading a general text on Lean, getting a better understanding of how to apply Lean to software development seemed to make sense. In reading through this book, although Lean and Six Sigma (now often called Lean Six Sigma) share some commonalities, it became quickly apparent that Lean shares much in common with practices set into motion by the agile software development movement. The introduction to this text lists seven Lean principles as applied to software development: eliminating waste, amplifying learning, deciding as late as possible, delivering as fast as possible, empowering the team, building integrity in, and seeing the whole. In addition, it is also indicated that the Lean principles, respectively, do not mean throwing away all documentation, continuously changing one's mind, procrastinating, rushing and delivering sloppy work, abandoning leadership, performing big upfront design, or ignoring the details. It is interesting that the authors wait until the last chapter to disclose what the authors deem as instructions and a warranty card. The authors caution the reader that "one team's prescription is another team's poison", one should "not arbitrarily adopt practices that work in other organizations", and "the right amount of features analysis and traceability depends on the nature of the system and the probability of change" just as "the right amount of user interaction design depends on the users of the system, their background, and how they might use the system". These cautionary notes present a reminder of what the Lean principles applied to software development are all about. The authors also briefly discuss such areas as "special work environments" like the government, where skeptics to agile methods are common. I would like to see the Poppendiecks (or someone else) write an entire book on special work environments. En route to the closing chapter, the authors present 22 tools to help customize the right agile practices for any particular environment. Much of the material will probably already be familiar to agile practitioners, but a substantial amount of the discussion is on Lean. Most of the diagrams presented are well done, although some are a bit amateurish and do not aid the associated discussions. Small case studies that are provided throughout the text are beneficial (although sometimes minimally so) in helping the reader understand the problem space as well as apply the tools. The first few chapters are well suited for an introduction to Lean, and the book in general is recommended for those interested in exploring how Lean might be incorporated into software development.
The Best Introduction I've Read
It's pretty much all been said by previous reviewers but this one is worth another accolade. As a CIO with over 20 years in software engineering, I've just about read it all, seen it all, tried it all. As a result I'm a big believer in Lean/Agile, and this is the best introduction I've come across. It's a nice, practical mix of principles and practices and touches on all the right themes.
A previous reviewer laments the authors' distaste for CMMI and PMI. For instance:
"Between PMI and CMM certification programs, a heavy emphasis on process definition and detailed, front-end planning seemed to dominate everyone's perception of best practices...spending a lot of time and getting the requirements right upfront was the way to do things `right the first time'...CMM, in its eagerness to standardize process, leaves out the heart of discovery and innovation..." Spot on.
As a PMP with CMMI experience, I couldn't agree more with the Poppendiecks' observations and concerns. They go on to say, "This is not to say that CMM and PMI are bad, but only that for anyone who has lived through the lean revolution, they tend to give the wrong flavor to a software development program." That "wrong flavor" is called "waterfall."
Of course there are Level 5 Agile shops out there, and the author's recognize that "CMM is not supposed to dictate approach, but only assess..." But here's the problem: "CMM programs...may standardize on less than ideal practices...they may be better implemented separate from--and after--process improvements."
This book is a must read for software development managers and other business execs pursuing the promise of an Agile company (vs. IT shop). I'll definitely be passing out a few copies!
