Now we’ve all heard the mantra “fail fast, learn fast” and it sounds quite logical – the more you try, the more you learn, and people can certainly learn from both success and failure. In fact, if you learn from failure such that you don’t repeat it, it doesn’t really feel like a “failure” anymore. At least not in the embarrassing gut-punched way we’ve been conditioned to traditionally feel about failure. Still, to many people, that mantra seems like a simple platitude that they can never put into practice. If they fail, they’re sure someone is going to punish them for it.
Most Agile teams start out using the Scrum process. And Scrum gets teams working on fixed-length sprints, typically set between 2 and 4 weeks. Usually, when people learn about sprints, they have a problem believing that can break down their work into meaningful deliverables that can be delivered in such a short time. So we’ll do some exercises to show you how it can be done, and people will start to believe it’s possible. In one of my recent Agile coaching engagements, we went beyond simply breaking work down into chunks and got to the incredible “ah-ha” moment people have when they realize that “fail fast, learn fast” can become reality.
I don’t get to follow-up and coach everyone who attends my training classes. It’s unfortunate because when I get to spend time coaching teams, and they’re confronted with jumping in and really trying this, there’s often a moment of hesitation. It’s one thing to be bold in a training class. It’s another thing to put your professional reputation on the line back at the office when you’re trying something radically different. And in that moment, people are able to truly understand the value of the following:
It’s only 2 weeks. And then you can try again.
Boom. You can try anything. And if it doesn’t work as expected, we’ll look at what happened, discuss it, and we’ll do better the next 2 weeks. Sure, not everyone uses 2 week sprints – I’m just using that as an example. But whatever your sprint length, this is something we’ll do every sprint. There are non-Agile teams that will easily burn 2 weeks just planning to try something new. And then they won’t do it because they couldn’t get to 99.99999% confidence that it will work. An Agile team will just do it. In 2 weeks they’ll know more and have more experience no matter the outcome. Isn’t that cool?
Another nice thing about getting to coach teams: I get to spend some time with the managers above the Agile team. And it’s not hard to have a short and meaningful conversation that will set their expectations appropriately for what’s about to happen. In short, they’re going to see some people try something new, and things will get messy for a while and then start getting better at a rapid rate. Why is this so important? Well, obviously, it’s nice if upper-management doesn’t overreact to “failure” and wind up demoralizing or paralyzing the team. What’s less obvious is that it’s also very important that management lets failure happen early-on in Agile adoption.
Why? Because failing early-on will give a team opportunities to self-identify problems, figure out how to solve them and improve without relying on outside help such as management intervention. And the sooner teams get comfortable making mistakes, acknowledging them, and analyzing them, then the sooner they can start making rapid improvements.
Conversely, I would be really worried about any Agile team that doesn’t experience any problems or “failure” early-on. Such a team won’t develop the try-inspect-adapt skills necessary to truly become a high-performing team. So when teams truly adopt Agile, failing fast and learning fast isn’t just possible, it becomes essential.
Does that sound like the environment you work in? Or does it sound like some far-off dream? Take my Agile Marketing Boot Camp class and learn how to make it a reality.