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.