Permission to Fail
We’ve all heard it before, but what does it mean, “Permission to Fail?” How about its cousins, “Fail Fast” or “Failure IS an Option?”
The idea isn’t to promote failure. Nobody, from team members to stakeholders, wants that. The idea is to create an environment open to change.
An Agile team should have enough power to try things that won’t necessarily work. This is not to say every Agile team is a prototype lab. In fact, the majority of what a mature Agile team tries will likely result in more value delivered to the client. Even a relatively new Agile team should see more successes than failures. These “things” the Agile team is trying can range from specifics of how to implement a feature for a user story to a new bonus structure more befitting of the team.
There are two basic types of failure that we consider when we think of these phrases. One is a failure of delivery. The new component didn’t work with the rest of the application. The other is a failure of process. Adding a mid-iteration PO demo resulted in too much confusion.
Delivery failures are the most visible. They directly affect the delivery of completed items to the product owner. Something happened and it prevented stories from meeting the definition of done by the end of the iteration. It could come from an attempt at using an unfamiliar back-end platform for new functionality. Perhaps a new type of interface is being introduced to user. Preventing these problems is important, but so is allowing them.
One method of preventing delivery failures is the concept of the spike. Basically, instead of trying a new thing out on a promised user story and hoping for the best an extra task is created. It usually runs at least an iteration before the relevant user story. While it will have no deliverable to the product owner it may result in a demo to the product owner. It is used as a proof of concept for something that will be used in addressing later stories. The permission to fail is that the spike might result in an answer of “this just didn’t work.” As a product owner it is important to realize that while this may not be a deliverable result it is still a valuable result.
A failure of process is both easier and harder to deal with. A high performing Agile team will eventually want to do something that doesn’t conform to the rules of whatever process they started with. For instance, they may want to eliminate the daily stand-up after implementing Scrum to start their Agile journey. The idea and reasoning should come up in the retrospective. This is a move that Scrum will not allow, but Agile will. It needs to be a time-boxed experiment that runs for a bit and then is reviewed. While many examples exist of this being a bad move for Agile teams, it has also worked for some.
Process changes need management buy-in. To prevent failures here the team needs to own the process with management supporting it. The team will find ways to improve their work. Management needs to allow changes where possible and valid explanations of why not when they cannot. If the team understand why a process change cannot happen they will be more likely to find another way to address the problem then if they just get a no.
In trying to be Agile we need to be open to change. Inspecting and adapting often. When change happens we never know 100% what the outcome will be. The classic risk-averse approach to project management often stymies change efforts in new Agile teams. All we are saying by providing permission to fail is that more risk is acceptable than previously thought. Without accepting that risk the rewards of positive change cannot be realized. If attempts at positive change are not allowed we are not Agile.
