jidoka in software development

Lean manufacturing is based on two pillars: pull and jidoka. And agile software development should be no different. It is one thing to have the customer pull features or user stories from the development team, and for that development team to carry out every task just in time and without building up inventory. But it is quite another to be able to sustain that kind of emergent behaviour over even a few iterations without being beset by problems.

And that’s where jidoka comes in. This is the policy of stopping the production line whenever a fault occurs, and then fixing the fault and the cause of the fault. The time invested in doing this more than repays itself in terms of relentlessly improving quality and decreasing down-time.

This morning I workshopped for an hour or so with an agile team that has come off the rails a little recently. It seems that there are a number of obstacles in the way of them being truly agile, and in the last two weeks these have happened to conspire together, with almost crippling effect. They know what the obstacles are, but they don’t (yet) have a process for eliminating them completely. So the same problems keep on coming back time and again.

So we talked about jidoka and then we sketched out the following process, to be followed whenever a blockage in the team’s flow is identified:

  1. Identify and acknowledge the existence of the blockage.
  2. Remove the immediate blockage as quickly as possible, to get value flowing through the process again. Be sure to find a solution in keeping with the team’s agile principles.
  3. Allocate some slack time to preventing the same class of problem recurring. Begin with a root-cause analysis, using the 5-whys technique if necessary. Discuss ways in which one or more of these root-causes could be eliminated. Then form one or more kaizen pairs as required to implement the process changes. Timebox the fixing activity. And remember that we cannot change anyone but ourselves.

Where possible the changes will be automated (eg. using software tools, tests, forms etc). We’ll find out what happens during the next few iterations…

(The lean manufacturing slant on these ideas is presented very nicely in The Essence of Jidoka by the Society of Manufaturing Engineers.)

One thought on “jidoka in software development

  1. Pingback: people problems vs process problems « silk and spinach

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s