One of the most difficult lessons that many organizations learn is that of failure. Mostly it means that we put whatever failed on the trash-heap of bad ideas and “never do that again”. And we ostracize and demean the people who were involved in the failure. But is that really the best way?
A lot of agile and lean relies on people trying new things, experimenting, and – yes – failing. But if we’re not allowed to fail we can’t make the leaps that help us exceed our wildest expectations. Apple’s products were not the result of small changes – they revolutionized marketplaces. And they had an evangelist who helped push them. But can we imagine a world without iPads now? Or computers that make phone calls (also called “smartphones”, but let’s be honest – they’re computers that make phone calls).
How do we get our organizations to allow for failure?
Failure Is Life
I was talking to my teen daughter a few years ago about failing. She was asking because I had just had a team completely “biff it” with a sprint. They totally failed to deliver anything they committed to and blamed everything and everyone but themselves. The conversation, though, dealt with something more important to her – swimming.
She swims semi-competitively on a local summer team. And she isn’t one of the best swimmers on the team. She’s very middle-of-the-pack, but swimming is both an individual and a team sport. We talked about the importance of introspection/retrospection. Examining what happened and finding ways to make improvements.
I asked her “if you won every meet, every heat, would you really try to improve?”
“No,” was her answer. “I would already be the best.”
“Exactly. So it’s through failure – through not achieving our goals – that we can find the most opportunities for improvement.” She nodded but I still don’t think she fully gets it. After all, she IS still a teenager. But she’s a smart cookie and I know she’ll figure it out. Hopefully sooner than I did.
It is through failure that we find the most motivation and opportunity to improve. If we succeed every time we are not highly motivated to make changes. And we possess all the skills and understanding necessary to succeed. If we fail, however, we obviously missed something. With my daughter’s swimming, it could be flip turns or dives or a better kick. Some people – especially high-performing athletes – always look at ways to improve their performance, even if they have a dozen gold medals. But most people – and especially organizations – don’t have that drive.
How Organizations Deal With Failure
I think organizations suffer from the belief that they can succeed every time and that those who fail should be punished. But it’s oftentimes through failure that we find our greatest successes. In science, especially, the phrase “well, THAT’S not what I expected” is the precursor to a number of dramatic advances. If everything goes as we expect, we should win every meet every time. But we don’t. We should plan on failure and find ways to improve our performance.
Some companies I’ve heard of (who shall remain nameless to protect the guilty) have policies that force teams to force rank all of their employees. At least one of those employees will get a rank of “needs improvement” or, worse, they take Jack Welch’s advice and fire 10% of their workforce every year. This is the equivalent of getting rid of 10% of your body every year because you think it’s underperforming. Even if you have a team of rock stars, you’re going to let one of them go. Every year. Think about how (de-)motivating that is!
Now some of those companies decide to get rid of whole teams that fail to deliver. Again, this is like cutting off your leg because you didn’t win the marathon. We should be identifying what went wrong. Did we miss the market’s needs? Did we overestimate the market’s desire for the product? Was the timing wrong? There could be a raft of problems that caused the product or project to fail that have nothing to do with the team. They built what was requested. We just missed the mark. Whoops. It happens. That’s life. Don’t punish people for doing their jobs.
The image to the left is an example of a product that was ahead of its time. And it was pushed by the “evil empire” of Microsoft. It wasn’t the wrong product. It was the right product at the wrong time. And with the wrong messenger. It took someone like Steve Jobs to introduce the iPad eight years later to change how we work. Partly the product, partly the message, and, I’d argue, a lot of it was the messenger. But change it did.
Learning By Failing
Depending on your role in an organization, you have the potential to make failure acceptable. And I don’t mean we should “celebrate failure” – we celebrate learning. Failure just gives us a lot more opportunities to learn. Jurgen Appelo shared his ideas around experimentation and learning at Mile High Agile 2017. The image is to the right (and more information about celebration grids can be found here).
The different sections represent our opportunities to learn. Things that we expect to succeed and do are normally “best practices”. Things that fail that we expect to fail are “things to avoid”. But there are times when “best practices” go badly. And things we thought might fail succeed. But if we think it’s going to fail, why would we do it? Instead, we want to focus our attention on the middle section where we don’t know if things will succeed or fail. That is our best opportunity to learn.
For an organization, we need to encourage experimentation. Whether we’re trying to create a Lean Startup model or we’re using Lean Change Management techniques to improve our time-to-market and better meet customer needs, we need to be able to experiment, fail, learn, and make changes. Safely. Without fear of retribution or being cast out as pariahs. It should be encouraged by the organization, not looked at askance. So how do we deal with that?
Changing Organizational Failure Paradigms
The first thing we need to do is recognize that we have a problem. If your organization punishes those who fail or there are strong avoidance behaviors, you have a cultural problem to address. If your management team just doesn’t like missing numbers or dates, that’s a slightly different issue. Let’s tackle them separately.
I’ve worked in a few companies where the company said they were accepting of failure but reviews would often be negatively impacted if you were on a team that did. So “in name only”. What has to happen in these risk-averse environments is actually allow a team to fail – with no consequences. No “tiger teams” to address the failings of the product. Just a recognition that we missed the mark and what we’re going to do to improve next time. It’s a hard, hard thing to do. We want to hold responsible those who fail for their failings. In this case, though, we need to take the high road. Sean Connery’s character in Rising Sun said:
The Japanese have a saying: “Fix the problem, not the blame.” Find out what’s [messed] up and fix it. Nobody gets blamed. We’re always after who [messed] up.
There is a lot of wisdom in that. The first step, though, is not blaming people for the failure. Bob didn’t break the build – the build broke. This is something Diana Larsen and Esther Derby discuss in their book Agile Retrospectives. I’ll be the first to admit there are a lot of problems with that movie (Rising Sun), but that quote is not one of them.
Allow a team space to experiment and fail. And then make it okay. What did they learn? By demonstrating that it’s okay to fail, others will begin to believe that it is okay to fail. Not that we want to fail – but failing is okay provided that we’re making progress and learning.
Date and Scope Problems
If you have an organization that is fixated on dates and scope, then first – congratulations on considering agile. It will likely help address your challenges in many, many ways. But if you’re using agile and date and scope are the reasons failure is unacceptable, you may need to get everyone on the same page. I’ve heard people say that agile doesn’t work with fixed date projects. “Horse-hockey”, as Colonel Potter (left) would say. It works just fine with them. You just can’t fix the date and the scope. You get your choice – “fix the date and float the scope” or “fix the scope and float the date”. Organizations that try to fix both are still mired in traditional project management thinking.
Agile tries to find the best product through the solution space (see this post for more information). At each step of the way (each iteration/sprint) we find the best way forward for right now. It is probably not what we thought it would be when the project started, but it is now. Refocusing your management and business teams on what agile is and how we deliver value should help with this particular problem. Then make sure bring in celebration grids or something similar to encourage experimentation. You can even tell them about that great book you read (and give them a copy) about how to be a more effective business.
We encourage our teams to focus on delivering the best product to our customers every time. We know that we can’t have the perfect solution from the beginning. Some of our clients aren’t so easily convinced, but as they see their product take shape and see how much influence they have on future development, their minds quickly change. We also have occasional hackathons to help explore new technologies and push our technical acumen. It can sometimes be a balancing act between client expectations and learning, but with good coaching and good solutions management, we often walk that line.
Failure is a critical component of learning in any scenario – work or life. Failing gives us the best motivation to improve, to make changes. And when we feel like it’s safe to fail we are more likely to try riskier experiments. And sometimes those riskier experiments have huge payoffs. We’ll never know if we don’t try. So get out there, experiment, fail, and learn. And hopefully, you’ll soon get to shout “Eureka!”.
Feliz entrenamiento, mis amigos! (Happy coaching, my friends!)