Hope you had a good Christmas and Happy New Year!

This post is for an idea I have for a retrospective. It is not something I have tried yet. Hoping to do so at some point.

Here is the gist of it.

At the end of the previous retrospective, outline the goals for the next sprint for the next retrospective. The goal is… to fail.

I know, insane, but I am insane, so lets move on and let me explain myself.

Each time something does something wrong during the sprint, record the following.

• The failure.
• What caused the failure
• What can be done to fix the failure

Points are awarded based on the the following.

For the failure – 1 point.

For What caused the failure, for immediate cause, 1 point. For root cause 3 points.

For What can be done to fix the failure, 1 point for a work around. 1 point for a manual process. 2 points for an automated process or documenting a way to remove it permanently . 3 points for making the failure never happen again. Now, for everyone involved in the solution, they all get the points. Not just the person who came up with the solution, nor the person who failed in the first place. This is to try to promote co-operation in solving problems.

Here is the kicker, everyone must have at least one failure. The way we do that is that everyone must fail at least once on purpose. That is right, I want everyone to have one failure on purpose. The more exotic the better. (For a really good one, award 2 points for the failure). Hopefully killing the system isn’t their on purpose failure.

Points can be placed on a board so that throughout the sprint, everyone knows the tally, the scrum master awards points and their say is final.

So, why do this?

Well, firstly, as I mentioned previously, I’m insane. So again, accept that and move on.

Secondly, I work in a place where failure has a stigma against it. There is finger pointing within the team. By making failure as part of the game, hopefully this removes the finger pointing. The focus then goes onto solving the problem rather than finger pointing.

Thirdly, by making failure open, you get to see where your weaknesses are, and ways to solve those weaknesses. This is the opposite of current culture where successes are focused on and celebrated, failures are hidden so you never know when problems occur.

Finally, by making failure a requirement, it removes the fear of failure. Hopefully you get to the point where people fight to take ownership of a failure.

Now, at the end of the sprint, during the retrospective. Go through the results.  For those results that have workarounds, or manual processes, try to improve them. Tease out what lessons have been learned during the sprint from failing. Any permanent solutions documented, decide whether to add them to the backlog.

Now, for the person who gets the most points, award them with a token prize. For example a block of chocolate. For second and/or third, a chocolate bar.

Finally, see if the team enjoyed this method of Retrospective, if it was valuable and if they want to do it at another point in time.

Please let me know in the comments if you tried this and how it worked. If I ever get a chance to try this out, I’ll be creating a new post.