I was at a conference not that long ago speaking and sharing on various agile topics. As often happens, a young man stopped me to ask a few questions after one of my presentations. We struck up a nice conversation that eventually slipped out into the hotel corridors.

We started talking about sprint dynamics within Scrum teams and I happened to mention that I usually coach teams towards declaring their sprints a success…or (pause for meaningful effect) …a failure. That we do this as part of the teams’ Sprint Review, with the Product Owner being the final determinant based on whether the team achieved their Sprint Goal(s).

He was visibly upset with my view. He said that they (he was working at a well-known Atlanta company) had never failed a sprint. Never! They could not nor would not use that WORD in their culture. I asked him point-blank – have you ever failed a sprint? He said of course they had. Many times. But instead of using the term fail, they used the term ‘challenged’. That way, stakeholders wouldn’t get the wrong idea and question the skills or motives of the team.

We went round-and-round for another 10-15 minutes in our discussion, but we never really settled our differences. We simply agreed to disagree. Although it wasn’t a terribly wide chasm between us, I distinctly remember walking back to my room shaking my head. I simply didn’t understand the big deal about failure. About using the word. About a team saying…we failed. In my coaching practice and in my “day jobs”, I’ve been able to steer and evolve our views so that failure is not a bad word, i.e., failure is good, failure is ok, failure leads to improvement, failure is a natural part of life.

So in this article, I want to discuss failure from a few perspectives. The discussion isn’t intended to be exhaustive. Instead, I just want to share some thoughts and get you thinking about failure…how you view it in your organization, what is your tolerance for it, and re-considering your normal reactions to it. I also think this leads you towards your risk handling as well, because I think the two are inextricably linked.

Coaching to avoid failure

In his blog post from June 20, 2011, entitled , Giora Morein makes the case that agile coaches should be leading or guiding their teams away from failure. He brings up an analogy of a Sherpa guiding mountaineers. And yes, in the mountain climbing example I will have to agree that failure is probably not the result we want.

However, in non-life threatening cases I think I disagree with Giora. I wholeheartedly believe that failure can actually be good for a team. I also think the role of the coach is to help a team look at their performance through two lenses. The easier of the two is the success-lens. This is the lens where you give the team positive feedback; where you tell them that they need to repeat those practices that work for them. Indeed, those practices they need to amplify and do “more of” so as to achieve greater and greater results.

These conversations are clearly easier.

What about the failure-lens though? As a coach, do you provide constructive criticism? Do you show a team where they miss-stepped—both individually and as a team? I think so; certainly not in a malicious or heavy-handed manner, but as a fair and accurate observer. I think if you’re effectively coaching a team, you must explore their errors and mistakes with equal passion and energy as you handle their successes.

And I don’t think you do this quietly, hiding behind closed doors and not externally acknowledging their challenges. No. I think you approach it in a completely transparent and matter-of-fact manner. Laying the groundwork that failure is appreciated and welcome. That from it, your teams need to look for improvement possibilities and move forward quickly towards delivering improved results.

Agile exposure

In agile teams, there are two key ceremonies that are focused towards success and failure results.  In Scrum, that is the Sprint Review (demo) and the Sprint Retrospective (lessons learned). Typically, the sprint review is exposed to the world, so you might want to be careful in how you couch your failures – so that stakeholders don��t misconstrue the impact or the effort the team is putting forth. Nonetheless, I believe you should declare sprints either a success or failure as part of the introduction to the team’s review.

In Scrum, it’s the Product Owner’s role to determine this—and it’s relative to the goal(s) the team committed to at the outset of the sprint. Hopefully those goals were flexible enough to allow the team to adjust their work focus to creatively attain it.

For example, I think a very poor sprint goal is something around the team delivering a set number of user stories—or other indicators of by-rote execution.  This leads to potential sand-bagging on the part of the team to hit a numeric goal rather than thinking of the true problem they’re trying to solve. Instead, better goals revolve around achieving some sort of demonstrated behavior that solves a specific set of customer problems.  So success is measured against how well the team met the spirit of the goal and how well they applied the agile principles in their execution.

For example, I’ve seen teams that committed to 10 user stories, but had an extra three days of idle time at the end of their sprint, fail their sprint. Sure, they delivered to their commitment, but their commitment was flawed. They sand-bagged and over-estimated. They also didn’t make their additional capacity available to their Product Owner and ask for more work within their sprint time-box. Instead they planned ahead or gold-plated their deliverables.

I’ve also seen teams that committed to 10 stories, but delivered 7, have a very successful sprint. In it they worked hard against complexity and adversity. They were incredibly transparent and engaged their Product Owner in making daily adjustments on priority vs. their new understanding of capacity. And as a team, while they didn’t deliver the originally perceived quantity, what they did deliver aligned with their goals and met the spirit of the Product Owner’s intent.

Both of these cases should be discussed in the team’s retrospective, exploring ways to improve their results. Not trivial ways and not ignoring the first team’s behavioral problems. No. All of it—the good, the bad (mistakes and failures), and significant improvement ideas should be explored. And the resulting actions should be focused towards the very next sprint.

We’ll continue this in the next post. Between then and now, I want you to be thinking about your “tolerance for” and “reactions to” failure.

Stay agile my friends,

Bob.