Fail early, Fail often, Fail better

I am a strong believer of not being afraid to fail. When you give appropriate time for analysis, failure teaches you a lot - it really drives home the message so you don't make the same mistakes over and over; and also helps you develop a thick skin. So, I love Agile / Scrum attitude of - fail early, fail often, fail better. Let's talk about it.

Fail Early:

Failing early on in the cycle is important because it gives you time to recover. Compare the cost of failing early to failing late in the game. 

Failing early teaches you important lessons early on. In this context some example of failure are - not meeting your sprint commitments, not having a demonstrable output at the end of the sprint, not having working software at the end of a sprint etc. 

As a Scrum Master, I consider it is my primary responsibility to let the team fail, especially early on. Along with allowing the team to fail, it is extremely important to keep notes about what the team did. I drive retrospective conversations with the team on the basis of these notes. In my Scrum Master capacity, I consider it important to work with the team to help them find the root cause of the failure. 5 Whys is a great way to get the the root cause. Rather than giving your team the answer, ask them the right questions, so they get to the answer on their own. This also helps build trust between you and the team (and may also give them the illusion that you know what you are doing!)

I loved the advice my mentor had given me. When coaching your child you want to let them make the small mistakes, but avoid the big ones. For example, you may want to let your child touch a hot stove so they never do it again, but you definitely want to stop them from running around on a road where they can have serious injury.

Fail Often:

As a child and even as an adult, I love playing computer games. One of the first games I played was - Dangerous Dave and Prince of Persia. When I think back, I don't remember the number of times I was killed in the game, but I remember when I finally beat the game. No matter how many times I failed, I never lost the commitment to beat the game. 

The way I think about it, failing often means trying often and not giving up. Think of the thing you are failing at as a game. If you are analyzing your failures often, it can help you get to success quicker. Trying out various strategies to 'beat the game' is the best way of finding success quickly. 

I remember one of the first projects that I led as a Scrum Master. In the release retrospective there was a comment made saying - each sprint was a cascading set of failures. The team was quick to point out however, that each time we failed, we learned valuable lessons and were better equipped for the next sprint. We started out by over-committing and under delivering; we had issues where we did not produce any working software for multiple sprints. However, in the end, we had a product that worked reasonably well, and was eventually deployed to millions of smartphones around the world. 

Fail Better:

I think there are at least 2 aspects of failing better. The first is to not only learn from your mistakes, but also from others' mistakes. The second is to not only learn from failures, but also learn from successes.

Failure does come at some cost, so it is important to you don't make each and every small mistake. It is important to keep an eye out for what other teams are doing to solve a problem and what they are experimenting on. I encourage other Scrum Masters to listen in on retrospectives of a few other teams - see what they tried, and whether something similar can be applied to your team. You can also see what they failed at, and try to analyze the reason for their failure. Don't wait to make each and every mistake. Read books / guides which helps you avoid some common mistakes. All of this should help you fail a little bit better at your next attempt.

If your team meets all its commitments, produces working software at the end of a sprint, completes a good demo - don't miss the lessons from that retrospective. Ask the team to analyze why they succeeded this particular time. If you and your team can articulate the reasons for your success, you can repeat it. If the success is accidental, you probably will not be able to repeat it. 

My recommendation to all Scrum Masters and teams is to not be afraid of failure. Take chances, experiment in whatever way you can, learn from your mistakes. In the face of failure, I encourage Scrum Masters not to hide it; not to provide justification to your team. Instead, ask the team to analyze the reason for the failure (or success) and learn from the experience. 

Rate this post!

☆

☆

☆

☆

☆