Failure is sometimes seen as a bad word. When you discuss this with people, you discover it carries baggage, often from an identifiable incident where someone of influence criticised their failure. They are right in some ways that failure can be bad, but only when you don’t learn from it.
An essential facet of Agile principles is continually improving, using the inspect and adapt cycle. Scrum has a specific ceremony for it, the Sprint Retrospective. Scrum is an empirical process that continually adapts and modifies for your team and your project to improve the output of results being produced. While the retrospective is the headline act, improvements are not limited to here. Scrum teams benefit from improvements, often through feedback on either individual team members from other team members or the Scrum Master, the team or the product themselves from the Daily Standup through to the Sprint Review.
While Scrum is taking the limelight in the IT world, Scrum didn’t create the concept of continuous improvement. If you’ve been around the block before, you’ll likely have sat in an After Action Review, Root Cause Analysis, Digital Six Sigma or a Lessons Learnt exercise. Where they often didn’t provide value was how often they were done. Scrum does them every sprint, typically twice or more a month. Yet, I can recall sitting in a meeting in a past life where we needed to remember what we could have improved at the beginning of a project that started 18 months before then; sometimes, I struggle to remember what I did two weeks ago, let alone 18 months ago!
Outside of the corporate world, learning from failure happens in many places. I coach my clients that there is no failure, only feedback. In sports, teams watch the recording of the match afterwards to learn and improve.
The Psychologist Carol Dweck, who has focused on learning and education, says, “You can still learn from your mistakes until you deny them.” John Wooden, the basketball coach, says, “You aren’t a failure until you start to blame.”
So how do we learn without blame? In Scrum, we often quote the Prime Directive at the beginning of a retrospective. In essence, we should look to the future and not dwell on the past by focusing on the issues and learning what caused them so that next time we don’t walk the same path.
I once worked with a client where a team thought they didn’t need to do the retrospective as they would ‘just get better on their own’ – clearly not the case, as I’d been brought in to help their improvement activity! You do need to take a step back from the day-to-day work to reflect and learn, as there is no fairy dust you can sprinkle to make this happen.
Culture also comes into play here. In the US, failure is seen as less of an issue. Someone who wants to run their own business is given more credit for having tried before and failed and trying again – they are celebrated for trying. In the UK, people commiserate with you for your failure.
Failures make you stronger when you learn
Learn and adapt, become better, and become the best. In the Lean Startup, Eric Ries says, “a setback, [is] an opportunity for learning how to get where they want to go”. As Albert Einstein says, “Insanity is doing the same thing over and over again and expecting different results.”
Learn from your failures, learn what to do differently, celebrate trying and celebrate the learning from trying.