Leading Lean Software Development: Results are Not the Point (Addison-Wesley Signature) [Paperback]

Anything by Mary and Tom Poppendieck is recommended reading but I'm not quite as impressed this time around. To be sure, there is much we can learn here about the application of lean principles to project management and software development. The discussion of value demand vs. failure demand is particularly good. And I couldn't agree more with their assessment of targets and "goals gone wild." Our systems, as well as our people, are what they are; targets will not change their capabilities. We're more likely to produce distortion and cheating than improvement. And "relative goals can motivate competitors to sabotage each other's performance. Thus ranking performance relative to peers can be damaging...if reward systems are based on this ranking." Performance rewards should be "shared equally among all competitors." A number of themes span multiple frames--a weakness of the "frames" construct--and the authors revisit this one several times.

More lessons from Toyota--the darling of every lean study--are helpful even if quotes such as this one now ring hollow: "One of the fundamental elements of TPS [the Toyota Production System] that management must be fully committed to is the `customer first' philosophy."

Frame 6: Quality by Construction is generally helpful but this is where I first began to notice some incendiary rhetoric and straw-man argumentation against waterfall or "sequential" development. For example: "not trying to find [defects] until the end of development" demonstrates "the distorted logic of the sequential frame of reference." Later, in telling the fascinating story of the Empire State Building's construction: "They did not break down the job into tasks" and the project "was not framed by cost, schedule, and scope." Yet they did break down the job into "small batches" and the project was framed by a number of constraints including "$35 million of capital...and May 1, 1931." And "Let's be honest; customers do not need scope. They need to have business goals accomplished"--the definition of scope. And "I often wonder how companies can expect superior performance...when there is no one whose job it is to uncover the strengths of each person and match the job to the individual."

Some concepts advocated here, such as eliminating defects, change control, and work queues, are debatable and sometimes raise more questions than answers. On quality, for instance, the authors quote Edsger Dijkstra who says "effective programmers...should not waste their time debugging--they should not introduce bugs to start with." Bug-free programming is certainly possible but at what cost, even in a lean environment? And on eliminating work queues: "'But,' you protest, `our customers won't tolerate that!' Or `How will we learn what customers want if we turn down their requests?' Or `How will we keep track of what has been discarded?' Or `Won't customers simply keep their own queue?' Or `What do we do with the list we have now?' These are all good questions, and you should search for good answers." Such conclusions are not quite satisfactory. Nonetheless, this work will certainly force you to think and is, therefore, recommended reading.

Wow! I was blown away by how good it was. I expected it to be "light reading" as I'd read about many of the concepts elsewhere. Somehow the authors managed to present them all in a thought provoking way. Even the introduction had me scribbling in the margins. As a result, I only finished 5 chapters in a 6 hour flight. I promptly finished the remainder the next morning. A real page turner.

Each of the chapters follow the same format: detailed example of company applying concepts, 4 frames and brief portrait of how used. A frame is a point of view - like a camera frame. There were detailed examples throughout. Each chapter ends with questions to think about - these aren't classroom exercises - they really help. The frames really drew me in - each time I started the next one, I felt the mental shift.

I'm not sure what my favorite part of the book was - between the current examples (banking crisis, Captain Sully, Obama's website), historical ones (Empire State Building construction), clear diagrams, etc.

The beginning of the book really grabbed me. It explained why Southwest Airlines is so much more successful than the traditional airlines. The fact that I was on an airplane at the time helped, but the example stood on its own.

The fact that I didn't go more than 5 pages without writing a note or more than 1-2 pages without underlining something really speaks for itself. The book was great!

This book - as expected from Mary and Tom - is good value for money. Although some of the items are common sense and known to the active practitioner there are still enough gems in it for the experienced reader.

Those who have read the Mary's and Tom's other books on Lean Software Development will find new perspectives and ideas. This book is certainly on the list of books I regularly consult.