The Agile Project Manager - Fail NOW as a Strategy

• Coaching to Avoid Failure
• Agile Exposure
• The Notion of ‘Failing Forward’
• Wrapping Up – But, I’m a Bit Strange…

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.

For 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.