Failure Quota Framework

User Rating: 0 / 5

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

In a previous article I talked about the Failure Quota.

I proposed carving out a specific amount of time per builder to give them near-carte-blanche in solving the particularly tough (or maybe not-so tough) challenges their project was giving them. The purpose of this ‘safe haven’ was to combat burnout while at the same time encouraging them to fail, but do so usefully. That article has sparked no small amount of chatter and I’ve been asked for my thoughts on a framework for the Failure Quota.

Before we dive into the who’s, when’s, and how’s I would like to point out that the Failure Quota is preliminary thought work. My current position features several very small teams of extremely happy and satisfied builders (thankfully!!) who would derive little benefit from such an exercise. My intention is to follow up on this concept in future writings with better data.

Now, one of the first questions we’ll come to is the WHEN of the thing. A Failure Quota should only be implemented when you are dealing with creative builders who are showing the first signs of settling into a rut. Of course you’re probably thinking that I’m talking about the whole team, but let’s be honest… by the time the whole team is into a rut you’ve got major problems. I would recommend that you consider utilizing this tool at the first signs. Make sure the ‘rut’ isn’t just a worker assigned to the wrong team or some other similar issue specific to that builder. Once you are certain that this team is getting into a rut or burning out, then proceed.

Actually, that paragraph covered the WHO and the WHEN as well! Efficiency for the win!

Let’s move on to HOW. Since Scrum’s framework specifies activity duration based on how long your sprint is, I say we use the same method here. But there’s a complication. Since the Quota is not a required part of your Scrum, and since many exec’s could look at it as ‘lost time’ then we need to take into account the executive team’s appetite for this behavior. I give three examples; one each where the E-team is Neutral, then Hostile and finally Friendly to the concept. Consider a neutral E-team‘s Quota duration to be 2 hours per two week sprint (2 hours/2 weeks). In other words if your leadership is OK, but just OK with the idea then give each builder 2 hours for a 2 week sprint to spend in Failure Quota mode. If that’s true then half less for a hostile E-team (1 hour/2 weeks) and half more for the friendly execs (3 hours/2 weeks). If your sprints are shorter or longer than the 2 week norm, adjust accordingly. For the neutral scenario this means your Failure Quota time is right at 2.5% of each builder’s sprint time, which is pretty reasonable.

Great, we’ve decided to implement a Quota and we’ve figured out the appropriate duration. In one of your grooming sessions prior to the sprint where you’ll be activating the quota, take a few minutes and talk the team through the exercise. Make sure you communicate that this time is for them to use to creatively solve problems. Talk about the limits that we discussed last time (creative problems and not procedural) and tell them that they each get X amount of time in the upcoming sprint to work their Failure Quota.

A few days later when the team is sitting in the Planning session make sure that there is a Failure Quota story in the backlog and that each builder has a task in that story for however many hours you’ve determined. Then have each one of them declare outright what they are going to work to solve. And here’s the kicker… no problem is too trivial, silly or mundane. These hours are theirs to stretch their mental legs and run around a bit. Let them. During the upcoming sprint they can allocate these hours whenever they see fit. But make sure they actually do! It can be too easy to look at these hours as spare hours to be used to complete other tasks, don’t let that happen!

Now comes the fun part, the Failure Workshop. For the next Retro skip the usual Retro dog and pony and instead have the team report on what they did, what worked, what didn’t, all of it. Give each of them a certain amount of time to talk through it and encourage other team members to comment where appropriate. Also make sure that someone records the lessons learned, just make sure they are anonymous!

In the right circumstance the Failure Quota can be enough of a shot in the arm to rejuvinate your team and re-engage their brains. Even the best workers can get tired and worn out, and everyone enjoys a change of pace. If these things sound like the cure for what’s ailing your team, then give it a go!

Author Bio:
Lee Allison
Author: Lee AllisonWebsite:
Agile Coach
Lee is an experienced Agilist and IT professional who loves the people-centric nature of Agile practices. He and his awesome family live in Austin, TX where they watch the Cowboys, brew beer, laugh and wish the weather weren't so damn hot!