Mini XP Day Benelux 2009

The dangers of success

XP Days Benelux 2008 was a success, as evidenced by all the smiling people in the conference pictures and the positive feedback about the conference and the sessions.


  • Many people couldn’t participate because the conference was sold out. We cap the number of participants to (on average) 30 per track, so that the sessions can be interactive with participation from all attendees.
  • Many participants were frustrated because choosing one session meant not being able to attend a session in the four other tracks.
  • Good sessions improve when they’re run again as the presenters incorporate feedback. We do have a collaborative session proposal refinement system, but after the XP Days it’s done.
  • How can we reach more people? If we grow the conference and allow more people we will either dilute the experience (more participants per track) or need to add more tracks. With more participants, the organisation becomes more complex. There is a greater risk that the participants will split in groups of people with similar interests and backgrounds so that there’s less exchange of ideas.
  • The organisation of XP Days is done by volunteers. We all have a limited amount of time we can invest.

How can we solve these problems and make the XP Days even better?

Mini XP Day – XP Days greatest hits

Mini XP Day is a one day event where we rerun eight of the most liked sessions of the previous year. It’s a second chance to participate in these sessions.

There are only two tracks, so participation is limited to 60. Such a small event requires less effort and time than a full XP Day conference. For example, there’s no session improvement and selection process to go through.

The preliminary program (two sessions have not yet been confirmed) is now online.

So, here’s you chance to go to four great XP Days sessions.

Don’t wait too long to take it.

Pictures by Xavier Quesada


XP Day Switzerland

Another XP Day!

XP Days branches out: our French-speaking Swiss friends organise the first XP Day Switzerland in Geneva on Monday March 30th, 2009.

The conference is a good opportunity for me to return to Geneva and see some of the local Agilists again. I’ve got great memories of the conference center, where I presented the Toyota Way and the participants discussed Toyota, Lean and Agile into the night. I’m looking forward to go for a run along the lake.

The conference program has been published at http://www.xpday.ch. The detailed descriptions aren’t available yet, but judging from the subjects and the speakers, this looks to be another fun and interesting XP Day.

Another new session!

One of the proposals Portia and I sent in got accepted. For the occasion, we’ve developed a new session: “Les Cinq premiers pas pour devenir vraiment agile”. In this interactive presentation, the audience gets to try out 5 “tools” we use when coaching teams that are new to agile. They can immediately put these tools into practice during the conference day.

I’m really looking forward to this session. If it all works out, this will be both fun and useful. The session is scheduled at the start of the conference because it also serves as an ice-breaker. We might be able to reuse parts of this session for other occasions. Like the one that will be announced soon…

More XP Days news

Watch this space for more exciting XP Day news soon…


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.


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?


Agile in Paris

Comment appliquer les méthodes agiles dans son équipe

Vous aimeriez appliquer les méthodes agiles. Quelles en sont les éléments fondamentaux ? Comment les appliquer dans votre équipe, sur votre projet ? Comment faire la transition vers les méthodes agiles? Cette formation répond à toutes ces questions. A travers des exercices, des jeux et des simulations vous expérimenterez les techniques agiles. Vous saurez comment, pourquoi et quand les appliquer afin d’améliorer la qualité du résultat et du travail de votre équipe.

Après la soirée Lean à Paris du mois passé, encore une collaboration avec Zenika. En février, avril, juin, septembre et décembre vous pouvez assister à deux jours de cours pour mettre l’agilité en pratique.

Ce cours est basé sur les jeux et sessions que Portia, Vera et moi ont développé et que nous utilisons dans nos missions de coach Agile.

Zenika est un des sponsors des XP Days France, 25-26 Mai à Paris.

A bientôt à Paris, j’espère.

Short English translation

Join me in the Paris training sessions to put Agile into practice. The sessions are based on the games and sessions that Portia, Vera and I have developed and use daily in our Agile coaching work.

Zenika sponsors the XP Days France in Paris on May 25-26. See you there or at one of the training sessions!