Design in Process

We've often talked about how lean manufacturing can be applied to other industries and activities, including software development.  Those of us that have managed software development teams in the past understand how frustrating it often is... and those of us in the lean world now realize it didn't have to be that painful.

A hat tip to the Silk and Spinach blog for letting us know about this post on the Kallokain blog discussing "design in process" as analogous to the "work in process" of manufacturing. 

What is Design-In-Process? It is partially finished work. Most software development projects have too much of it. The manufacturing industry learned decades ago that too much inventory was a bad thing. In the software development business, the inventory is Design-In-Process. We still haven't learned the lesson. The problem with DIP, is that it is risky. If a requirement changes before it has entered the development process, for example if it is in a Scrum backlog, the change costs very little money. 

Henrik Martensson goes on to describe the various forms that risk can take, such as requirement changes occuring before, during, and after the development process.  And as with manufacturing, the impact can be very significant.

Most project managers don't even know how much DIP there is in their projects, have absolutely no idea what it is worth, and consequently do not know what changes to the DIP costs. This, I am afraid, is probably true of most agile developers and managers too.

Regular readers know of my love for white boards as a substitute for overly complex software-based task management systems, and Henrik goes after my heart by suggesting similar visual controls.

An easy, and highly visible, way to measure DIP, is to make a Project Control Board. Use a whiteboard, or a large mylar sheet on a wall. Make a table with one column for each hand-off in your development process. […] At the start of each iteration, write sticky notes for each story (use case, feature description, or whatever you use). […] Whenever a developer begins to work on a new story, the developer moves the story from the stack of sticky notes to the first column in the table. The developer is then responsible for moving the story to a new column each time the story goes into a new phase of development. […] The sticky notes in the table are your DIP. Track it closely. If you have a process problem, you will soon see how sticky notes pile up at one of your process stages.

Identify it, measure it, track it... simply.  Whether it's WIP, DIP, or anything else "in process."