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.

But is failure embraced?

Continuing with my earlier coaching example, I remember not that long ago I was talking to a group of our Scrum Masters at my employer . If you don’t know about Scrum, the Scrum Master is the primary coach and guide and agile leadership voice within the agile scrum team. They’re also responsible for maintaining core agile values within the team and for the team’s overall performance. What I mean by that is—guiding the teams improved performance over time. Continually asking questions like: Is the team improving in their overall performance? Is their velocity improving? Is their work quality improving? Are their teamwork and collaboration improving? And, is their focus on delivered customer value improving?

So my point to the Scrum Masters was I felt we hadn’t failed in quite a while. I defined failure in this case as a sprint failure or a stop-the-line incident where a team basically ran into a challenge and needed to re-plan or re-align their sprint.

They all agreed with me that things had been going smoothly. And I received more than a few questioning stares as to why that was a problem. I tried to be careful in my reply, but my concern was that we might be playing it too safe. That we were becoming complacent in our agile practices and that we weren’t stretching ourselves enough. We weren’t taking chances or risks.

I explained that these traits are fundamental to the growth and advancement of agile teams. And the fact that we weren’t seeing failures indicated that we’ve leveled off in our growth and performance. I felt this was a problem…and I asked if they could drive more failures from the teams.

Can you imagine the remainder of this discussion?

Here I am, the Director of R&D at a successful company talking to my team of Scrum Masters and asking them to drive more failure—to influence their teams towards more risk-taking and inspire more stretch goals. The point I’m trying to make is that I truly embrace failure. That I’ve learned to view it as a critical success criterion and that its absence is a problem for me. I wonder how many organizations and leaders have the same view.

The notion of “Failing Forward”

One of my favorite authors is . He’s relatively well known as a leadership coach and he’s quite a prolific author—having written more than 50 books on various leadership topics. He’s got a strong Christian background to his life and writing, so if you’re not so inclined, don��t let that put you off. He’s truly mastered the art of leadership.

A few years ago he published a book entitled . In it he emphasizes failure as a truly transformative factor in our personal, professional, and team-based lives. However, he carefully frames failure with a leaning forward posture. That is, instead of viewing failure as a negative end-state and feeling sorry for ourselves, we should embrace it as a positive learning experience. That you should be “leaning forward” in your failure, leveraging the lessons learned towards improvement and trying new approaches.

I don’t think Maxwell is simply blowing positive smoke in our direction here. History is clearly littered with examples of successes that were inspired, forged, and hardened in the fire of failure; Thomas Edison being a famous example as he persevered to invent the light bulb.

In my agile coaching I consistently use the terminology “fail forward” when I discuss team-based failures. Yes, I want a team to be honest with themselves and acknowledge they failed. But I also want them to embrace their mistakes instead of getting defensive, blaming others or denying it entirely. And I want their posture to be leaning forward, eager to try something new that will drive different results—certainly never, ever being afraid of failure.

I find that using this terminology helps teams to ‘get’ the nature of failure and to behave appropriately. Beyond terminology, however, project and functional leadership need to fully support the idea too—meaning the entire leadership team needs to be supportive of failure. There…I said it. They need to create, foster, and support a culture that embraces failures…as well as success.

Wrapping up—But, I’m a bit strange…

All of that being said, I wonder if I’ve got a strange and largely minority view towards failure. I wonder if the right response is to indeed be fearful of it; to deny its existence; to spend countless hours trying to predict it; and to never mention it in public.

Are those and similar actions the right responses? Anyway, I hope I’ve at least made you think about success vs. failure and perhaps inspired you to occasionally fail. Now I wonder if this blog series was a failure 🙂

Stay agile my friends,

Bob.