I’ve been really curious about lean manufacturing (which basically means the way Toyota does things) for a couple of months now. I was aware that people had made some analogies between it and agile software development, but my interest got more concrete when I started reading Silk and Spinach: that’s a blog that spends a lot of time talking about that analogy, using various Japanese terms to talk about high quality, continuous improvement, and other things that sound productive to me when developing software. From there, I learned about Evolving Excellence, a blog about lean manufacturing itself, which I also quite like.
I just finished reading Toyota Production System, the key original source book on the subject. Which wasn’t at all what I expected: I didn’t see any references to the specific Japanese words that I was curious about, and in general there wasn’t the explicit laser focus on high quality. (Though I can see how it developed: more below.) Instead, there was the term kanban, which are cards used for resource/production management whose use I’m only starting to understand, and a laser focus on eliminating waste.
Which they think about in quite interesting, and I think quite productive ways. As far as I can tell, Toyota’s ideal would be that, when a customer walks into a car dealership and buys a car (or maybe takes it for a test drive), a car would magically be created instantly on the spot, while nothing would be invested on building the car until that very moment. This is referred to as a “pull model” of production, as opposed to a “push model”, where forecasts drive production. And anything that doesn’t help with this goal is considered waste.
This is, obviously, impossible in real life, but it does give you a rather different way of looking at waste. We can all recognize that people standing around doing nothing is wasteful; what is less obvious is that focusing on having people work full time can also cover up waste. This is the waste of overproduction: the easiest way to have people work full-time is for them to produce products that aren’t immediately needed. And there are second-order effects, too: to enable those people to work full-time, the easist thing to do is to make sure that they always have an abundant supply of their necessary raw materials (e.g. the components they’re assembling) at hand, which leads to overproduction in the earlier stages, products that aren’t immediately needed.
And this is bad for (at least) the following reasons:
- That excess inventory needs to be stored somewhere, incurring warehouse costs.
- If demand for the excess inventory never materializes, the effort spent producing it was wasted: the people creating the excess inventory could potentially have been working on something valuable, or not been hired in the first place.
Analogies have problems, and in particular it’s not clear to me exactly what lesson the first point has for software development, but certainly the other point is relevant. So now I’m wandering around work trying to figure out where I’m committing the sin of overproduction, where there’s waste that I hadn’t been seeing.
To get back to our story, the lean solution to this problem is to manufacture everything “just in time”. They still want to keep their pipeline flowing as smoothly as possible: they just try to use buffering as little as possible while accomplishing that. This is the (or at least one) source of the lean focus on quality: if you have a defective part, you don’t have extra parts that you can use to replace it, so it stalls your entire pipeline. So you’d better work hard to not have defective parts in the first place!
Next in the reading list is Lean Software Development. Its authors have experience both in manufacturing and software development, and are quite aware that the two are very different things. Their thesis is that software development is more like product development than manufacturing; fortunately, Toyota has something to say here, too. But I am planning to read more books about lean manufacturing itself; it seems quite interesting, totally aside from its potential applications to software development.
Toyota has a few videos on the subject available from their web site. I enjoyed them, though I’m not sure I would have gotten much out of them if I hadn’t already been reading about the topic.
Post Revisions:
There are no revisions for this post.
inventory in software development
One of the central tenets of lean is that inventory is not an asset, but is waste. In particular, carrying inventory incurs storage costs. What is the analogue to this in software development?
5/6/2006 @ 8:30 am
Time is “inventory” in project-based work. As in – submit the request and in six months someone will decide whether to schedule it. Also known as “Why didn’t you start sooner?”
6/20/2006 @ 12:44 pm
Good post. Toyota is the father of lean and has countless examples of success.
However, it is critical for anyone implementing lean to learn the tools of the discipline.
As one small example, inventory is definitely waste. But if setup time and lead time cost more than the carrying costs of the inventory (a whole bunch of items such as floor space, damage, interest, obsolescence, opportunity), then these costs and lead times must be reduced first.
This is one fundamental mistake many companies first implementing lean make. Get the best lean manufacturing training first and it enables continuous learning.
11/28/2007 @ 5:47 pm