Jidoka is essential


Jidoka is one of the basic elements of the Toyota production System. Jidoka stands for “automation with a human touch” or “autonomation”. The term dates back to the Type-G Toyoda Automatic Loom which automatically stopped when it detected a problem such as thread breakage. That meant that an operator didn’t have to keep watching the machine, but could quickly intervene when one of many looms detected and signalled a problem.

The same principle can be applied to the production line. Whenever a machine or, more likely, an employee detects a problem, they “stop the line” and signal the problem using an “Andon” board. Everybody can see that there’s a problem. The team leader can quickly come and help diagnose the problem and solve it.

The sooner the problem is detected, the easier it is to fix and the smaller the impact.  Thus, one of the important parts of Lean training is to be able to detect problems, raise them quickly, analyse and fix.

Jidoka and software development

Can we apply this production line principle to software development? Of course.

How can we detect problems and defects? One good way is to have a comprehensive suite of unit tests and continuous integration. Whenever we check in, our build server tells us quickly what we’ve broken. The build server serves as our Andon. Patrick Debois has several examples of Andons in his Visu-Wall collection.

Another way is to have a suite of automated functional tests, performance tests, code analysers and other tools that are run by the continuous integration server.

Good testers who are really involved from the start of the project and track the deliverables closely are a great way to implement Jidoka. The really great testers can tell us clearly what goes wrong and how to repeat the problem.

As long as you get fast, high quality feedback that’s something’s wrong, you’re implementing Jidoka.

Jidoka is an attitude

Is that all there is? Of course not. It’s not enough to detect problems, you have to do something about it.

The build broke? I didn’t check anything in, so it’s not my fault.

What do you mean by “It doesn’t work”? It works on my machine!

Who said so? Oh, Bob… He’s so negative, he’ll find fault with everything.

Have you ever heard remarks like that? It’s not enough to detect problems, you have to do something about it. The only correct answer to someone who reports a problem is “Thank you!”. And then your team corrects the problem.

When the problem has been corrected you’ve done half of your job. The other half is asking why your existing Jidoka mechanisms failed to detect that problem in time:

  • Why didn’t any of our developer tests catch the problem in time? How can we improve the tests in that area? Is that a situation that could happen in other parts of our code? Will we detect it there?
  • Why didn’t any of our customer tests catch the problem in time? How can we improve our specifications in that area? Are there other blind spots? How can we improve those specifications?
  • Why wasn’t this case tested? Did we misunderstand what was needed? Didn’t we do what was agreed? Do we risk more of such misunderstandings?

The biggest bottleneck in IT is learning. By reflecting on our problems, we learn to detect issues earlier.

Jidoka requires Transparency, Trust and Collaboration

If Jidoka was just a matter of installing tools and procedures, it would be easy to implement. But it’s surprisingly difficult to implement, because Jidoka requires:

  • To make every problem visible. My pride might be wounded by admitting I made a mistake.
  • To reward people who admit mistakes. Doesn’t that conflict with the Lean idea of “Right First Time”? Shouldn’t we reward only perfect people?
  • To take the time to improve our problem-detecting systems. But there are so many issues to fix and I have so little time!
  • To thank people who make problems visible. Yes, even that curmudgeon who always finds fault with everything. Yes, even that tester who delights in finding “bugs” in my beloved creations.
  • To collaborate as a team to resolve problems quickly and completely. Whoever “caused” or found the problem, our common goal is to create high quality, high value work.

Being really Lean or Agile is hard. Really implementing those Agile Values is hard.

Have you made a problem visible lately?

Have you thanked a tester lately?

Have you improved your Jidoka tools lately?

If not, are you only doing half of your job?


Kaizen in Paris

A lean evening

Yesterday evening I was back in Paris to give a presentation about “Lean and the Toyota Way“. As I walked from the train station to the offices of Zenika, I came across a large billboard announcing “Dorothy et le magicien d’Oz”. It’s reassuring to see that the fairytales are alive and well.

My friends at Zenika had arranged a nice place and provided some fine drinks and snacks. More than 100 people showed up, among them many of the French Agilistas. I chatted for a while with them about agile, lean and the upcoming XP Days France.

And then it was time to start the presentation. The auditorium was almost completely full.

The Toyota Way

The presentation explained the 14 principles of The Toyota Way of Managing and the many parallels with Agile methods. As I go through the principles I illustrate them with stories from projects I’ve worked on. Each time I do this presentation it changes, as I learn more and discover more great ideas in Lean.

There were some great questions and discussions:

  • “What can I do to introduce more Lean and Agile in my organisation?” – Apply the principles and values, set an example. Support and collaborate with others who apply these values.
  • “Are there any incompatibilities between Lean and XP?” – None that I can see.
  • “For Agile and Lean transformations to succeed we need support from management and workers. Often, we only have support from one of them.”
  • “Lean coaches are very direct, not afraid of saying it as it is to management. Is that something they’re taught?” – It does seem so, judging from the documentary Kenji Hiranabe showed at Agile 2008, where a Lean coach almost made a factory manager cry by bluntly pointing out all the flaws in the production line.
  • “Does Lean make you lose weight?” – A Gemba Walk a day helps 🙂

Unfortunately, I couldn’t stay for drinks afterwards because I had to rush to catch the last train back to Brussels. The next day I had another team to coach, another opportunity to “Develop exceptional people and teams”, the tenth principle of the Toyota Way.

I hope to see the participants again soon. See you at the XP Days France or a Zenika training session.

A bientôt!

What others say

Jean-Claude Grosjean summarizes the principles and contrasts them with the 7 principles of Lean Software Development and Agile.

Nicolas Martignole wrote a very extensive report on each of the principles and relates Lean, Scrum and XP.

Claude Aubry thinks “Obeya” is more beautiful than “War Room”. I fully agree. He currently tries to recreate the Obeya experience for an offshore team.

Thank you for the rapid and very detailed feedback!


A Toyota Way evening in Paris

Lean presentation in Paris

On the 21st of January 2009 I’ll be in Paris to present an evening seminar on how to apply the Toyota Way management principles to Agile software development. The seminar is organised by Carl Azoury and Olivier Huber of Zenika.

To me, Agile is the application of Lean principles to software development. So, the presentation contains a lot of parallels between the two. A lot will be very familiar if you already know and practice Agile.

So, what’s left to learn? Some of the Toyota Way management principles aren’t in Agile methods. These principles are useful when we go beyond software development. There comes a moment in any successful Agile enablement when the development team is no longer the bottleneck. Suddenly, we’re faced with a completely different set of issues. Now that Agile gains more and more acceptance, we need to be able to deal with these new challenges or accept that most Agile transformations will either die or bring limited extra business value.

The more I read and learn about Toyota, the more I realise how much I don’t know and how many preconceived ideas I have to abandon. I need to keep learning. The Toyota Product Development System, for example, contains many counter-intuitive ideas like set-based design. Real Options thinking can help us understand why some of these techniques work. We’ve only started to scratch the surface of Lean ideas.

Toyota losing money? Impossible!

In the news, even Toyota is affected by the economic climate. They might even have to post the first loss since the early years. Isn’t Toyota invincible and perfect? Of course not. It will be a real show of faith in the Toyota Way if Toyota continue to keep on their workers, keep training them and keep improving to be ready when sales take off again.

Secretly, top Toyota management must be happy that this crisis happens now. One of their main concerns is complacency. No one should ever think that the work is “done”, now that Toyota is the biggest manufacturer. Hansei and Kaizen should be applied relentlessly, it’s always possible to do better. Nothing better than tough economic times to bring back the sense of urgency.

See you in Paris

The seminar is free, but you must register here. Don’t wait too long because places are limited.

See you there!


Real Options in the Real World

Real Options?

This Friday, Portia and I will present the “Real Options Space Gameat XP Days London. This strategy board game set in space allows players to experiment with Real Options concepts.

Real Options is a tool to optimize decisions: it helps us to consider and manage more possibilities and gives us more time to gather information, so that our decisions are better informed. The basic ideas are taken from financial options, but have been widened to be applicable to real-world management decisions.

There are several types of Real Options. Let’s see if the option metaphor is a useful one. How can we apply Real Options in the real world?

The option to delay a project

In this paper, Aswath Damodaran compares a Net Present Value (NPV) analysis with a Real Options analysis to decide which projects to fund when. Projects with a negative NPV now, might still become valuable later. That’s because the Real Options analysis takes into account the value of getting more information and therefore reducing risk and uncertainty.

We always have the Learning Option. We can always gather more information.

In the article, the delay is examined in a situation where the organisation has (or can buy) a way to get a hold on the market, like with a patent. We can create an option to delay a project even in a competitive market: if we have a shorter cycle time than our competitors we can afford to wait longer to start our projects. This gives us more time to gather market information. In a very volatile market, it can be more valuable to wait, to increase the odds of building the right product at the right time.

For example, if Toyota’s new product development time is 6 months shorter than a competitor, Toyota can afford to start development 6 months later. That’s 6 months in which to gather more information, six months in which they could see major swings in customer demand or in the market. That’s six months in which people can work on other projects.

So, if you decrease your cycle time you create options to

  • Increase your cash flow
  • Be first on the market
  • Delay the project, take the go/no go decision later, when we have more information

By using Lean and Agile methods to decrease cycle time, we create real options. Starting later may be the right thing to do.

There are more fun real options, like the option to abandon a project. What could be the value of abandoning a project?


Pictures from Agile North mini-conference

The Agile North mini-conference on April 26th featured the Real Options presentation and “Space Game” by Portia and me. Pictures and slides are now online.

The handout for the Real Options session is not yet online, but you can download it from our site.