“We don’t have enough failed sprints,” my boss said during his staff meeting. The comment was said completely out of the blue as the meeting was winding down and I have to admit it threw me for a loop. Surely not failing a sprint was a good thing right?
Our group was pretty new to scrum at the time, and I didn’t really know what he expected me to do. The comment wasn’t related to any of his managers, just a general observation. It was his way of saying that he didn’t think our teams were pushing the envelope hard enough.
Some years, and bosses, later I was sitting in on a planning meeting. The team would calculate available hours by adding up the man days for the sprint and multiplying by four (the number of available hours per day). They’d then compare that to the sum of the task estimates to get an idea as to whether a backlog item was achievable in a sprint.
The thing was I thought the 50% availability was a bit conservative. And, I could tell that the task estimates were padded too. So to my mind the team was running at a capacity of about 25%. OK, that’s probably unfair to the team, but you get my point. I bit my tongue at the time because an in progress planning meeting is not the place to tweak process.
But it reminded me of my old boss’s remark, and to his credit I couldn’t recall the last time that any of my team’s sprints had failed. It was pretty clear that the team was scared of failure, and that was translating into very conservative estimates, and excessive time padding. They’d lost that gung-ho frontier attitude.
The fact is, that to get the most out of a team they need to be encouraged to push themselves and be aggressive about what they can pull off the backlog. But that will mean failure at some point. And if that failure has consequences they may not push as hard next time.
And remember, even thought you may not practice executive censure for failure, if they are a group of high achieving individuals -as these guys were- then just the fact that they’ve failed, and that their peers know it, is probably as bad as anything you can dish out.
So what do you do?
The official scrum process is that the team should be conservative in what they commit to, but if they have time left over then they should work with the product owner to possibly pick up some additional backlog items. To me this seems like a good litmus test of an engaged enthusiastic team. Make sure your scrum master is checking for this.
Looking back I struggle to identify the source of their fear of failure. It certainly wasn’t punishment on my part. We’d been through numerous management changes and had a new fire breathing VP, so that could have been it. In hind sight I should have encouraged a more aggressive approach to counter that cultural pressure.
And that’s the thing with self managing teams. While you inspect and measure their output and they optimise themselves appropriately, they are also subject to other pressures from the organisation. If you’re not diligent about inspecting all the results of the team they could easily be optimising themselves in a direction you don’t expect.
And the fact that they fail, or don’t, is another output that should be inspected as well. And never failing could actually be the less desirable result.