December 2007

A value stream is composed of processes

Work flows through these processes until it is ready for the customer. People add value to the product, but they are not the value added. People use process to add value to the product. People design, compose, operate and manage processes. How people manage these processes is the subject of work standards and kaizen. Kaizen and work standards are the vehicle for creativity in process design.

A kanban system is a mechanism by which people manage processes. Kanban tokens should therefore be allocated to processes, and not people. Kanban should be allocated to analysis and not analysts, testing and not testers. Kanban should be distributed according to the value that is added by each process. If a process does not add a lot of value, then you should not spend a lot of time on it. This distribution of kanban helps you to judge the relative value of the investments in your processes.

Comments (2)

Print This Post Print This Post

Email This Post Email This Post

Permalink

A simple trick for work standards

If you make it cumbersome to document work standards, then people may resist updating them or even following them. So anything you can do to make standards easier to use is probably worth the effort.

When you draw your heijunka board, leave room at the bottom of the columns to document the standards. If the standards are simple, you can write them directly on the board (part of why whiteboards are so handy for this purpose). If the standards are too detailed to write directly, then try making the columns wide enough to attach a single printed page with tape or magnets, e.g. 9 inches (for U.S. letter) or 22 cm (for A4).

If you go with printed pages, then a wiki can reinforce the message of shared ownership, while also creating an audit trail and facilitating root cause analysis. Not everybody is comfortable with editing wikis, so in that case a simple document will suffice. Even so, versioning is still a nice thing to have. If you go with the low-ceremony whiteboard method, take a photo from time to time.

Comments (2)

Print This Post Print This Post

Email This Post Email This Post

Permalink

Book review: Lean Software Strategies

Note: I read this book a couple of years ago, and I truly meant to review it earlier, but it’s been out on loan to a worthy recipient.

If there are now a couple of camps in the world of lean software development, they might be the “Lean/Agile” interpretation and the “Lean Software Engineering” interpretation. Middleton and Sutton made the first definitive statement of the latter camp, and well, you can guess where my sympathies lie.

I’ll start by saying that reading Lean Software Strategies and writing this review have been frustrating for me, because this is a book that I dreamed of writing. It’s kind of uncanny, really. QFD, TRIZ, DSMs, Design by Contract, static analysis, lean vs. craft, and so on. These are most of my big themes, and they’re all in there.

This outstanding book won a 2007 Shingo Prize for Operational Excellence and most deservedly so. It is the most direct and thorough application of Lean principles to the software development process that I have seen yet.

Cons? There is some crap on the CMM and programming languages that I didn’t find helpful, and I wish they had spent less ink on XP. More about reliability and security engineering would have been welcome (why does security always get short shrift in methodology books?). What the book lacks most is a usable walkthrough of how to set up a lean engineering process. It’s full of descriptions of what would be in such a system, but short on telling you how to get started.

If you are interested in this subject and all you have read is the Poppendiecks, please, please, please read this book. If you are interested in this subject and you have a background in software engineering, this is the book to start with. If you don’t know a lot about either software engineering or Lean, you should probably start off with Womack/Jones and the Poppendiecks, and then….please read this book!

Comments (0)

Print This Post Print This Post

Email This Post Email This Post

Permalink

Tom Gilb’s “evolutionary delivery,” a great improvement over its successors

Why is it that the popularity of Agile processes appears to be in reverse order of their usefulness?

Tom Gilb’s ‘evolutionary delivery’ or Evo, dates back to the 1980′s and is more comprehensive and powerful than most of its imitators. But who uses Evo? Who is talking about it today?

There’s something odd about a software culture that is so obsessed with novelty and technological determinism that it perpetually loses the knowledge of the past in an endless pursuit of the reinvention of the wheel. The race in the 2000′s to “out-agile” each other and distance ourselves as far as possible from any crusty old notions of “software engineering” in the flight from some phantom bogeyman of the “waterfall” has resulted in the neglect of a great deal of hard-fought knowledge and wisdom from the great systems engineers of the 1960′s-1980′s. It’s our loss. We’re forgetting things that are better than what we think we know now.

There seems to be an uneasy feeling amongst parts of the Agile community that they’re running out of steam, that there aren’t enough new ideas. I think that’s true, and that there’s a simple reason for it: they bet on the wrong horse. XP is the weakest of the name-brand Agile processes, and it’s a dead end.

I don’t know if the Kanban idea will prove to be important or not, but I don’t think it is a coincidence that the strongest expression of that practice is coming from the FDD community rather than the Scrum/XP community. FDD is a better process than Scrum/XP, it appeals to a higher caliber of developers, and it never had the luxury of complacency.

But if you really want to take a step up, you should read Tom Gilb. The ideas expressed in Principles of Software Engineering Management aren’t quite fully baked into the ADD-sized nuggets that today’s developers might be used to, but make no mistake, Gilb’s thinking on requirements definition, reliability, design generation, code inspection, and project metrics are beyond most current practice. And I sort of like the quirky presentation, because it forces you to put together the pieces for yourself, which you really ought to learn to do anyway. It’s more of a “patterns and practices of evolutionary delivery” book than a how-to.

Tom and Kai Gilb also have an excellent website over at http://www.gilb.com.

Comments (9)

Print This Post Print This Post

Email This Post Email This Post

Permalink

What is Lean Product Development?

Michael Kennedy did his readers a real service by calling his excellent book Product Development for the Lean Enterprise instead of the more obvious Lean Product Development. In that book, Kennedy describes the set-based principles of the Toyota Development System, and how they may be applied to any product development business. TDS is a fascinating system, equally as innovative and interesting as the Toyota Production System, but also very different in the mechanism of its operation.

On the other hand, my own journey down the road of lean development started with Donald Reinertsen’s Managing the Design Factory. Don’s description of Lean Product Development is more like the application of lean production principles to product development, breaking the work into small pieces, managing capacity, measuring flow, and delivering value incrementally. It is this view of lean that my friend David Anderson expounded upon in his book Agile Management for Software Engineering.

The difference between TDS and TPS creates a lot of confusion in discussions about Lean Product Development. Does LPD mean product development targeted to lean production systems? Or does it mean the principles of lean production applied to product development? These two definitions have very different consequences.

If it wasn’t already clear, I am decidedly in the camp of lean production principles applied to product development workflows. Even though I think TDS is ingenious, and I wholeheartedly endorse set-based thinking, I do not consider TDS to be Lean Product Development. To me, lean development is a means to an end. That end is evolutionary design, and lean production fits that end in a way that set-based development does not. Which is not to say that there is not a strong evolutionary interpretation of SBD, as large-scale open source development is exactly that. But I’m not really speaking to the open source audience here. I expect my readers are largely of the enterprise variety, building products or IT systems to spec and for hire. And evolution with such finite resources means flow.

Observant readers have probably noticed that I don’t talk much about Mary and Tom Poppendieck here. I feel a little bit bad about that, because I think they deserve credit and respect. I think they have done the software profession a tremendous service by popularizing the relevance of lean principles to software development. But they have also done a couple of things that bother me, including blurring the definition between set-based, time-boxed methods like TDS and continuous workflow methods like TPS. The consequence of this is that people can (and do) weasel out of lean principles by hiding behind the weakest interpretation. By conflating these definitions, the Poppendiecks, perhaps unwittingly, encourage their readers to claim to be lean while avoiding actually doing it. One of the greatest offenses I see again and again is the rationalization of “craftsmanship” under the auspices of Lean.

In contrast, Womack and Jones (and Roos) were not at all ambiguous about what is Lean and what is not. Jim Womack, who coined the expression, “lean production,” to describe the principles behind the Toyota Production System, explicitly defined lean production as neither craft production nor mass production. Not craft production is part of the definition of lean, and he dedicates whole chapters in his books to why craft production is inferior:

Our advice to any company practising “craftsmanship” of this sort in any manufacturing activity, automotive or otherwise, is simple and emphatic: Stamp it out.
- The Machine that Changed the World, The Strange Case of the “Craft” Producers

Now, I realize that development is not manufacturing. But using that as an excuse to rationalize craft methods is overwhelmingly contrary to philosophy of lean. I am not saying that you shouldn’t practice craft development if that’s what you want to do. But claiming that it is lean to do so is either ignorant or outrageously dishonest. Standard Work is not an optional practice. Craftsmanship means doing it your way, Standard Work means doing it our way. If you’re not doing Standard Work, you’re not doing Lean. Period.

Comments (3)

Print This Post Print This Post

Email This Post Email This Post

Permalink

Close
E-mail It
Socialized through Gregarious 42