Practice makes perfect

In an experiment a ceramics teacher split the students into two groups. One group was told to make the single best pot, the other one was told to make as MANY pots as possible. Which group created the best quality pottery?

Answer? The second group. The group who focused more on the ‘doing’ and less on the perfect deliverable created the best pottery.

Why is this interesting? Because every now and then I see this phenomenon in software development. Before a release or before accepting a feature, a sneaking feeling of dread can be felt among stakeholders or team members. I will come back to that in a moment, but first let’s look a little closer on the ceramics class.

In the ceramic class the group that focused on making one perfect pot were limited by their relationship to failure. They were fully focusing on their performance, and was afraid of failing. The second group got the benefit of iterative learning. They focused more on the process and implicitly they were constantly learning, one pot at the time. This focus on learning and on the technique, without worrying too much on delivering a perfect result, was the better way.

The aversion of failure is often getting in the way of delivering with the quality that should be expected. This limitation can, if it is not mitigated, kill any software development project.

In order to get the best quality, it is essential to instil a culture that sees failure for what it really is: A learning opportunity. If you find yourself in a team where releases are often postponed, where features are not regularly shipped or where “gold plating” of features are encouraged, stop!

You should take a break, and reflect on what is going on together with your team. The reason is that you are way better off with failing small and often, then failing big or more importantly, never at all.

Get together with your team and discuss the following

• Are there technical or architectural reasons behind us being afraid to release?
• Does anyone feel that releases are scary?
• If we fail, meaning that we deliver something that doesn’t work, how fast can we normally fix it? Can we optimise this?
• How can we ensure that we get enough practice? How can we do the things we are afraid of more often, and in smaller bits?

As an end note the complexity in software development can of course not be directly compared to making pottery. But the effect when not taking advantage of failure is the same. Although the technical complexity will challenge us, there are always techniques and patterns that we can use in order to get less complexity, improved craftsmanship, better learning and more fun!