Taking One for the Team: the Refactoring of Failure

Recently I've been coaching a large organization through an agile transition. I've introduced Scrum, Kanban and Scrumban ways of working to about a dozen teams so far. I like to keep my "finger on the pulse" of all of them, and as part of this I try to attend as many stand-ups, reviews, retrospectives, and planning sessions as I can. And so it was that yesterday I sat down with one particular team while they did their Sprint Planning. It soon became clear that not all was well.

The planning session started off okay. The team had done some backlog grooming beforehand, and enough of the User Stories were in shape to be admitted to the Sprint Backlog. The team knew their prior velocity and how many story points they could budget for the upcoming Sprint. Allowing for a bank holiday and foreseeable absences, the budget they could allow themselves came to around 42 points.

Now, I'd coached the Scrum Master to remove impediments from the team. In furtherance of this duty he would represent them at meetings so everyone else could get on with their jobs. The problem was, it became clear in the planning session that during those meetings he had gone ahead and made certain commitments on the team's behalf. In short, he'd allowed himself to be brow-beaten by stakeholders, and he'd agreed to the delivery of significant pieces of work by the end of the next Sprint. This was work that the team hadn't been properly appraised of, and which they certainly hadn't estimated yet or accepted. If it was added to the Sprint Backlog for this iteration then their total commitment would come to 65 points.

Ouch.

The team pushed back. I'd coached them to only accept work that they were prepared to commit to, and I was pleased to see that they were standing their ground. They said there was no way that they could take on work that they felt they weren't able to commit to, and which would clearly not be achievable according to any sensible interpretation of objective metrics.

Of course, this put the Scrum Master in a bit of a spot. He was the one who made those ex parte commitments, and so he announced that he would work overtime himself to do the work. He declared that he would come in at 5am every day and work whatever ungodly hours were needed to get things done. Of course, it was obvious that even this effort could never be enough to deliver 23 points, so he was clearly going to have to plan on a miracle as well. He seemed to accept this with philosophical resignation. He had made the commitment, so he would take this one for the team.

I could see them start to crumble when they heard this. One of them, effectively the spokesperson for the team, shored things up a bit. "We're being made to feel that by keeping to our forecast we aren't pulling our weight, and that by not taking on the 65 points we're letting you down. But we know what we can commit to and we made our estimates for a reason."

They needed my own input now. "That's right", I said. "You should keep to your forecast and what you believe you can commit to. The metrics are clear, and you've made your estimates and you know what you can achieve. Don't set yourselves up to fail. If your Scrum Master plans to set himself up to fail, then that's a separate deal. There's no sense in cutting yourselves in and making it a team fail". I left them to mull this over for a few minutes. I knew that I hadn't really given them a solution. Sure, the Scrum Master could work himself into the ground, and fail personally as his mea culpa, but that's nothing more than the refactoring of failure.

Now, there is a special agile term for this. No, it isn't called "taking one for the team" or even "the refactoring of failure". It's just called lying. If someone makes a commitment to deliver something by the end of a timebox, and if they know perfectly well that they can't hope to deliver without a miracle, then that person is being dishonest. It doesn't matter how noble their intentions are, they are feeding stakeholders a lie. Hoping for a miracle doesn't sanctify any of this. A human plan that secretly relies on miracles is no plan at all. It's nothing more than an exercise in deceit.

I ran through the corridors in search of influencers who might be able to resolve things at the root cause. Perhaps those deadlines could change, or other resources could be brought to bear. Within 15 minutes I had three senior managers assembled and I quickly gave them the low-down on the situation. They were able to suggest bringing in sufficient help from other teams, competent and qualified people, who could make up the shortfall. I squared this with the teams themselves so they were fully in the loop and could revise their plans accordingly. Satisfied, I went back to the team with the news. Nobody would have to fail. I advised them to keep the extra work off the Sprint Backlog until the agreed resource was provided. Then yes, they could bring it forward and action it.

This morning I attended the stand-up, and I was pleased to find an even happier team. They had taken it upon themselves to resolve one of the core issues and to begin the sprint with a team reconfiguration. The Scrum Master had agreed to become a proxy Product Owner, and a new Scrum Master...as it happened, the lady who had spoken for the group during planning...had been elected from the ranks. So despite the problems that they had encountered, they came through it as a team. Everyone - the team themselves, the new Scrum Master, and the new Proxy Product Owner - seem to be relieved and keen to get on.

Of course, perhaps they are a bit too close to events to see this as a genuine success rather than the mere avoidance of failure. However, I know that I have seen a team pull through a crisis by committing to transparency, inspection and adaptation, and I know that they have moved just that little bit closer towards the agile transformation they crave.