I've always been uncomfortable with the comparison made between lean manufacturing and software development.
If you're mass-producing Toyotas, then you know exactly what steps you need to go through to build the car. Okay, some will be different colours, have different features, etc, but the variation is constrained. The customer gets a set of choices, and has to tick a box. 'Which colour?', 'Which stereo?', etc. Go to your local Toyota dealer and ask for a spec not on the option list and see what he says. The whole idea is to do a relatively small set of predictive tasks as efficiently as possible, anything which does not contribute to the end result is waste.
Software, on the other hand, is a non-predictive, learning activity. If you do something which turns out to be useless in the end software, well that might have been a critical part of how you learnt about the domain and worked out the best solution; it's waste from a manufacturing perspective, but not from a design perspective.
The problem is we're applying lean MANUFACTURING principles to software DESIGN, and the metaphor just doesn't work. However, try applying lean manufacturing principles to what your software does, rather than how you develop it, and it’s a different story.
Let's use retailers as an example. They have to move stock around, and each warehouse/store needs to know what stock is expected in that day, but sometimes unexpected stock just turns up. Someone in the business says that 'some stock movements are just not advised', and we have to cope with it. And since we're IT people and do what the business say, we find a way to cope with it. But what would a lean car factory do in this situation? I think they would stop the production like, work out why stuff is turning up un-advised, and fix that problem, not find a work around to cope with unreliable inputs.
Lean manufacturing gives us insight into how we can structure our predictive, repeatable business processes so they are as efficient as possible, it just happens that if you work in an information industry most of this business processing is done by application servers, not people and robots in factories.
Posted by timv at November 23, 2004 2:22 PMI think where Lean Manufacturing approach applies to software is its focus on waste. There is a lot of waste in the typical development process and Lean helps us identify waste (e.g. using value stream maps to identify when work is sitting in inventory).
Posted by: Chris Matts at November 23, 2004 2:29 PMHi Tim,
Nice first post! Love the blog name too!
I kinda agree with you and kinda don't. Many lean principles do move across to product development fine.
For instance, working in small batches in manufacturing translates into work in small increments in software.
Small batches in manufacturing allows you to (a) spot quality problems much earlier because the quality problems aren't hidden amongst piles of wip, and (b) make changes to your products much easier and cheaper because it takes so much less time for the wip to flow through the system and be sold before you can introduce you changes.
Small batches in software development allows you to (a) spot quality problems much quicker because the quality problems aren't hidden until the end (amongst the wip), and (b) make changes much easier and cheaper because many changes are free (since they haven't been started yet).
Keep writing ... I like what you've done so far.
Posted by: Clarke Ching at November 23, 2004 4:25 PM