Opinion: Relentless reduction of waste yields process improvements.

Like model years in Detroit, it seems as if the new year for book publishers starts in the fall. I just received a new book with a copyright date of 2007, "Implementing Lean Software Development: From Concept to Cash," by Mary and Tom Poppendieck (Addison-Wesley Professional).

Wonderful, I thought. I've only just finished teaching my editors that developers use "agile" (short for "agile methods") as a noun. I'll bet that "lean" is next. Whether or not the term catches on, the book is usefully concise and densely packed with convincing stories about good practices that have transformed projects—often despite initial skepticism from developer teams.

About a quarter of the way into the book, I ran across something rare: a list of basic principles of productive software development I actually had never seen before. Even better, this looked like a list that might be effective in shaking up people's ideas of (what may not be) necessary evils.

Guru Jakob Nielsen offers advice on designing applications for usability. Click here to watch the video.

Shigeo Shingo's original list of "The Seven Wastes of Manufacturing" is well-known, the Poppendiecks say, among those who use "lean" (I told you it was the new noun) in manufacturing. Since it's a widely held goal that software development should become more of a process of production and less of a guildsman's craft, it's logical to seek to improve development using manufacturing disciplines—and they've modified Shingo's list to that end.

In manufacturing, we've heard for years that it's vital to shrink in-process inventories from both ends—to deliver input just in time and to build to order rather than keeping finished goods expensively stored as their market value falls. The Poppendiecks redefine this for developers as the problem of "partially done work." They apply that label to change requests that wait for years to get attention, to code that's done but has not been tested, and to code that's tested and ready to go but that sits undeployed.

I'd therefore urge that users get prompt and honest feedback about when (if ever) their requests will be fulfilled; that code be tested as close as possible to the time and place of development; and that useful functionality should be delivered—for example, through a service interface—immediately upon completion of work.

Manufacturing gurus who espouse lean call overproduction the worst of the Seven Wastes. The analogous fault in software development, the Poppendiecks say, is the design and coding of features that no customer task actually requires. I'll add my own spin on "requires" in an economic sense—I don't mean a feature that no customer wants; I mean one that no customer would request if that customer knew upfront what it would cost in terms of delivery delay, performance handicap and reliability reduction of the code.

In a previous career, when I got the chance to ask a paying customer, "Would you want that feature if it took more than X seconds to work or if it required more than Y additional hardware?" I found that desire rarely turned into requirement.

Another of the Seven Wastes I had not considered before is the one the Poppendiecks label "handoffs," which they compare to Shingo's "waste" of transportation in manufacturing. "When work is handed off to colleagues," the Poppendiecks observe, "a vast amount of tacit knowledge is left behind in the mind of the originator."

If we fail to convey as much as half of our relevant knowledge when we hand off a task—a conservative estimate, the authors assert and I agree—then by the third such handoff, the person now stuck with some part of the original task is trying to do it with one-eighth the knowledge originally available for the job. Cross-functional design-and-build teams, improved communications (almost anything is better than written documents) and plenty of feedback loops to call prompt attention to misunderstandings are among the practices that "Implementing Lean Software Development" recommends.

I'm implementing leanness myself by not going into all seven elements of the list. You don't need to be told again, for example, that defects are wasteful and worth killing upfront. The things I've mentioned here are enough of an agenda to keep most teams busy for now.

Peter Coffee can be reached at peter_coffee@ziffdavis.com.

Click here for an archive of Peter Coffee's columns.

This article was originally published on eWEEK.com.

Discuss What It Means to Be Lean   >>> Be the FIRST to comment on this article!

>>> More ASP and .Net Coding Techniques Articles          >>> More By Peter Coffee