Last night I finally received my copy of Lean Software Development: An Agile Toolkit for Software Development Managers by Mary and Tom Poppendieck. I’ve actually had quite a few books on order and as they’ve been coming I’ve hoped that they were this one. Finally it got here.

I started getting really interested in “Lean Concepts” after reading The Goal by Eliyahu M. Goldratt and Jeff Cox, a very well written “parable” illustrating the application of lean principles and the Theory of Constraints to the manufacturing process. This was the first book in a long time that I was completely drawn into – so much so that I actually dreamed about the content after I had finished reading the book. Thanks to John Goodsen for recommending this book to me, among others, while attending a recent training.

This posting is not a book review of the Lean Software Development: An Agile Toolkit for Software Development Managers book – that will come later. However I did want to point out that rarely have I been sucked into a book as quickly as I have been with this one. I think that this is because what I’ve read so far maps so closely with the content of The Goal that it jarred me a bit.

Chapter One starts with the first principle of Lean Development. Identifying and eliminating waste. The authors define waste as “something that does not directly add value as perceived by the customer”. They also assert that “If there is a way to do without it, it is waste”.

Here’s the strongest piece of this argument, taken directly from the book:

In 1970, Winston Royce wrote that the fundamental steps of all software development are analysis and coding. “[While] many additional development steps are required, none contribute as directly to the final product as analysis and coding, and all drive up the development costs”. With our definition of waste, we can interpret Royce’s comment to indicate that every step in the waterfall process except analysis and coding is waste.

The argument that the authors are making really make sense to me. What pieces of accepted software development practices are adding “direct value as perceived by the customer”? Does the customer appreciate the long requirements and design processes that wind up feeding into a process in which documentation then has to be generated to change the design of the system after requirements have been frozen? Do they appreciate the fact that we have a “process” to document each change that we make, even though, when push comes to shove, the documentation is rarely looked at as often as the code is? Is the long, drawn out process we IT people use to try to keep our world under control adding immediate perceived value to our customers lives?

“Perceived value to the customer” is another reason why I have always been confused to see development teams put more value on being involved in “projects” than maintaining current systems, whether it be fixing reported defects or adding requested functionality to an application. In my mind, these smaller changes and fixing of defects found BY customers are the things that make the customers life easier and that they will get value from almost instantaneously upon deployment (not to mention that more times than not, they are “chunked” properly). Larger scale “projects”, mostly perceived by teams as “sexier” work, are essentially (in many cases) just a guess from the busines as to what might create value.

I can see from just the first part of this book that this is going to be a really interesting and valueable read. I think it will definitely get my brain working again – and I know there will probably be quite a few rambling posts like this one about thoughts I have as I go through it. This is an area of thought that completely excites me, mainly because there is so much waste in our industry (IT) as a whole. Its kind of nice to read books every now and again that confirm that many of the thought processes you go through in your professional life are not as crazy as they seem sometimes.