The Agile Project Manager - Fail NOW as a Strategy

You are here:


I was at a conference not long ago speaking on and sharing various agile topics. After one of my presentations, a young man stopped me to ask a few questions. We struck up a nice conversation that eventually discussing sprint dynamics within Scrum teams. I mentioned that I usually coach teams toward declaring their sprints a success…or (pause for meaningful effect) …a failure.

I 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 they (he worked 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 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 post, I want to discuss failure from a few perspectives. The discussion isn’t intended to be exhaustive. Instead, I 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 toward your risk handling as well, because I believe the two are inextricably linked.


Coaching to avoid failure


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

However, in non-life threatening cases I disagree with Giora. I wholeheartedly believe that failure can 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 mis-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. 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. 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 quickly toward delivering improved results.


Agile exposure


In agile teams, there are two key ceremonies focused toward success and failure results. In Scrum, they are 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.

Fail-NOW-as-a-StrategyFor example, I think something around the team delivering a set number of user stories or other indicators of by-rote execution, is a poor sprint goal. 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. In another example, I’ve seen a team who committed to ten user stories, but had an extra three days of idle time at the end of its sprint, fail that sprint. Sure, the team delivered to their commitment, but that 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 ten stories, but delivered seven, 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 toward the very next sprint.

Continuing with my earlier coaching example, I remember talking to a group of our Scrum Masters at an old 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.

In other words, 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?

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.


Does your project manager favor quality or quantity?

Watch this short video to find out why quality should matter most in agile organizations.

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 we might have been playing it too safe. We were becoming complacent in our agile practices and 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. The fact that we weren’t seeing failures indicated that we had 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?


There I was, 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 to inspire more stretch goals. The point I’m making is I truly embrace failure. I’ve learned to view it as a critical success criterion and 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 John C. Maxwell.¹ He’s relatively well-known as a leadership coach and a prolific author having written more than fifty books on various leadership topics. He’s truly mastered the art of leadership.


A few years ago he published a book entitled Failing Forward: Turning Mistakes Into Stepping Stones to Success.² 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 toward improvement and trying new approaches.

I don’t think Maxwell is simply blowing positive smoke in our direction. 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 team members 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 and to certainly never, ever be afraid of failure.

I find that using this terminology helps teams ‘get’ the nature of failure and to behave appropriately. Beyond terminology, however, project and functional leadership need to fully support the idea also, 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 said, I wonder if I have a strange and minority view toward 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 then never mention it in public. Are those and similar actions the right responses? Please contribute your thoughts in the comments section below.

Stay agile my friends!



Up Next: