The Incomplete Judo Definition of Done

One of my clear memories from youth is training Judo projections and uncountable number of times. In Judo you won a match in several ways, but the most spectacular one is when you throw your opponent to the floor over your heap. You get a full point, the match ends, you won a medal, the crowd chants your name and everybody is happy but your opponent.

But what if you for misfortune you are forced to use the same technique to protect your life in the street? Throwing somebody to the floor would be enough to neutralize your attacker? Hard to say, but statistics shows that this won't be enough, you need to immobilize your attacker to be really safe. So following this rationale, Judo projections are half done.



Extrapolating this to the Scrum world, Judo projections are like writing code: looks really cool, people love to see it, it attracts attention and respect but is still half cooked. Code that has been coded but not tested is like a furious attacker in the ground, it can counter-attack and really hurt you unless you do something to really control him.

In Judo (and more effectively in Ju-Jitsu) you use punches and locks to really immobilize your attacker. In software development you can use testing-both manual and automated-to assure that the code is good enough. Further, you need to reach consensus about the acceptance criteria and the Definition of Done. Why? Simple, it's a team's activity, without consensus effort would be wasted without favorably impacting in code's quality.