Monday, April 20, 2009

What are your wastes?

The Toyota production system starts with a conversation between Norman Bodex and Taiichi Ohno. Mr Bodex asks Mr Ohno where Toyota is today, by now they must have reduced all work-in-process inventory - enabling them to chip away at all the problems. "What is Toyota doing now?" he asked. Taiichi Ohno's reply is simple but brilliant. "All we are doing is looking at the time line, from the moment the customer gives us an order to the point when we collect the cash. And we are reducing that time line by removing the non-value-added wastes."
For the sake of this post I would translate this picture to the world of software by replacing order with "Feature Conceived". Although I think you could make compelling arguments to expand the time line to a earlier point in time such as "customer demand".

Fundamentally the Toyota production system is based on the elimination of waste, and In my experience the most productive teams I have been on followed this practice of constantly removing waste. Becoming such a team is not a destination but a constant journey, as Kent Beck says in xp explained; "Perfect is a verb, not a adjective". A helpful tool to enable this continuous improvement is the 5 why's, for example:

Why did the server go down?
The wrong privileges were set when the application was deployed.
Why were the wrong privileges set?
The wrong account was used to push to production.
Why was the wrong account used?
Bob was sick so Fred pushed the deploy.
Why does Bob's account have to push the build?
He has always done the deployments.
Why has Bob always done the deployments?
No one ever took the time to automate the deploy to production.

The five why's are by no means perfect, Wikipedia provides a list of good criticisms of the methodology. I have seen many of the anti-pattern's they describe occur, I have also seen a team apply techniques like the five why's to a point where we got our release cycle down from two-four weeks to one day. Retrospectives can also be helpful in identifying and eliminating waste, however again it is important to stress there are no silver bullets and you should not limit your improvements to scheduled meetings. Keep in mind: "It is said that improvement is eternal and infinite." - Taiichi Ohno

There are issues in drawing parallels between software and manufacturing; one is a far more creative process then the other, however the advantages that result from eliminating wastes can be realized for both. One should bear in mind that Just-in-time was far more heavily influenced by American supermarkets then Automotive manufactures. That being said as software and manufacturing are analogous, so the sources of/kinds of waste may differ between the two. What would you identify as the wastes in your organization? There are some common places you can look; Do you rely on manual testing? Are there manual steps in your deployment? Do you spend a lot of time merging code branches? Do you develop large feature sets to find they are unused? How long does your code sit in source control before it goes out to production? Do you have fat requirement documents that quickly go out of date?

Think you have no wastes? Think you can't get working software into the hands of your users any faster? If so let me leave you with this quote:

"No one has more trouble than one who says that he has no trouble." -Taiichi Ohno


Jason Yip said...

Re: one is a far more creative process then the other

I'd suggest Matthew May's The Elegant Solution. Manufacturing work becomes significantly more creative when continuous improvement is a fundamental part of every job.

Nolan Evans said...

Thanks for the book recommendation Jason I will add it to my list.

When I toured the Toyota NUMMI plant in Fremont CA I didn't get a sense of creativity in the work, however as I have never worked in a Toyota manufacturing plant I could of course be wrong.

I feel that as a software developer I am far more of a polymath or Renaissance Man than a assembly line worker. I agree with Paul Graham that great programmers can be orders of magnitude more productive than a ordinary one. I don't think the same is true for a manufacturing line.