Lean Software

I recently finished a short, insightful book called The Art of Lean Software Development.  It connects the principles of lean manufacturing with those of agile software development.  It's a fascinating path: lean manufacturing started with Toyota decades ago, and focused on obsessively ridding systems of "seven deadly wastes:"

• Defects
• Overproduction
• Transportation
• Waiting
• Inventory
• Motion
• (Over)Processing

(These can be abbreviated to "DOTWIMP" if you're ever quizzed on them.)  Most of them are self-explanatory if you consider the additional costs they could bring to the car manufacturing process.  "Motion" refers to the idea of people or machines moving around -- if you can find a way to avoid it, you're better off.  "(Over)Processing" means doing anything that's not required by the customer.

It's interesting to apply these to software, as the book does, and find corollaries:

• Defects => Bugs
• Overproduction => Extra Features
• Transportation => Handoffs
• Waiting => Delays
• Inventory => Partially Completed Work
• Motion => Task Switching
• (Over)Processing => Unneeded Processes

As with a lot of discussions about process, it's easy to write all this off as common sense.  And yet we can all get mired in processes and miss the forest for the trees.  It's always insightful to step back and use a list like this to get a fresh perspective on what's working and what needs fixing.

I find a lot of people (including myself) trying to apply software development processes without always thinking about the overall idea: they have daily standups, planning meetings, workflow charts, etc.  It's easy to think that just going through the motions of these steps will help you.  And in some cases, it does.  But it's important to constantly challenge your assumptions.  Holding yourself accountable to eliminating these "deadly wastes" seems like a great way to do that.