Another review of the Toyota Way in Paris

François Wauquier describes the Toyota Way presentation I gave in Paris in Janruary.

Merci François!

Portia and I will present an updated version of this presentation at the Integrating Agile conference on June 18th in Amsterdam. See you there.


The Toyota Way at Integrating Agile Conference

Portia and I present “The Toyota Way” at the Integrating Agile Conference in Amsterdam, organised by the Agile Consortium Benelux and Agile Holland.


New Agile Coach site online

Do you want to play?

Portia, Vera and I have published a new version of the Agile Coach website. There you’ll find coaching tools we use like games, tutorials and presentations. Topics range from introductions to Agile (the XP Game, the Business Value Game, XP Loops, First Five Steps to Become Really Agile), Theory of Constraints, Real Options, Toyota Way, Interviewing techniques to Agile Fairytales.

Creative Commons licenseMore materials and translations will be added. All of these games are licensed “Creative Commons“, so that you can use and reuse them. If you want to help translate or improve the games, let us know.

We run retrospectives after each session so that we can improve. You can read the results of the retrospectives on the Past Events page. This transparency allows you to verify if we really take the feedback into account.

Come and play at XP Days

If you want to play the “Business Value Game” or “Mirror, Mirror on the Wall… Why Me?” come and see us at the Mini XP Day Benelux in Mechelen, Belgium (May 11th) or XP Days France in Paris, France (May 25-26th). Or invite us to come and play in your company or usergroup. Or better yet, download the games and play them yourself.

XP Days France


Kaizen in Paris – another reaction

Another reaction to the Zenika Kaizen presentation

Last January I presented an overview of the Toyota Way at a Zenika seminar in Paris.

Claire has written a summary of the session (in French).


Beyond Jidoka – Poka-Yoke

Do you want to improve your productivity?

There’s a very simple way to improve productivity.

How much time do you spend on “bugs”? Finding them, analysing them, fixing them and making sure they don’t reappear. Not to forget the time spent writing the bug.

Imagine how much time you could save if you stopped writing bugs.

How do you write bug-free software? It’s simple.

Jidoka is not enough

Great, you’ve implemented Jidoka. Your systems and people find issues quickly. Your team responds quickly to resolve any issue raised. You even improve your tests whenever another issue slips through.

You’re well on your way to deliver quality quickly. But there’s something missing.


Poka Yoke is the practice of “mistake-proofing” work. It’s another principle from the Toyota Production System. Poka-Yoke mechanisms ensure that the user or operator can’t make a mistake. For example a plug that can only be inserted correctly (like the 3 pin UK plug) or can be inserted in two ways that are both correct (like a 2 pin plug).

Poka Yoke is not Baka-Yoke or “fool-proofing”. The goal is not to prevent idiots from doing the wrong thing, but to make intelligent people do the right thing.

Poka-Yoke software

We can Poka-Yoke software if we really think about it.

In one case, a web application didn’t work because of an incorrect configuration parameter. Two tools each required a configuration setting. The two settings had to correspond. One configuration, created by the developers, contained ‘G004’. The other configuration, maintained by the sysadmin, contained ‘GOO4’. Can you spot the mistake?

Once we found it, the issue was easy to fix. How could we avoid it? Some thinking and experimenting showed that there was a way we could reduce the configuration to one setting, even with the existing tools. This type of error couldn’t happen again.

Thank you for reporting this error. Finding and resolving issues is a great trigger to add some Poka-Yoke.

It doesn’t have to stop here. Why wasn’t the mistake found sooner? Because this feature was only fully tested in the acceptance environment and the configuration error happened only in the production environment. Why wasn’t it tested in production? Because testing that part of the application could show confidential customer information. Next time, we’ll get someone who’s allowed to see the confidential information to test that part of the application in production. Poka-Yoke the software is the first step. Poka-Yoke the software process is the next step.

I had finished implementing this class. I just needed to add a comment to explain how to use the class. First, you had to call the methods A, B or C. Then, you could call methods X, Y or Z.

This class was very error-prone. Why not write a class with methods A, B and C? These methods return an object of a class that implements X, Y and Z. You can’t call the methods in the wrong order.

If I feel the urge to document, I stop and think. Isn’t there a way I could simplify? Isn’t there a way to change the system so that errors are impossible? The pay-off is clear: less time to document, more time to code.

Poka-Yoke is an ongoing process. It isn’t done until the system is so easy to use it doesn’t require a manual or training. It isn’t done until all testers have become specifiers instead of verifiers.

Doesn’t this take a lot of time?

Yes it does.

But imagine you only had half the issues you have now. How much time would you save? Now invest that time in finding root causes and making your work Poka-Yoke.

It’s simple. But not easy.