Wednesday, 14 September 2011 14:38

The Agile Project Manager—Fail NOW as a Strategy

Written by

bob1

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 basing it 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 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 just want to share some thoughts and to 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.

bob2

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 their teams away from failure. He brings up the 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 the 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, what practices they need to amplify and do “more of” so as to achieve greater and greater results.

These conversations are clearly easier.

But what about the failure lens? 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. But certainly not in a malicious or heavy-handed manner. I think if you’re effectively coaching a team you must explore their errors & mistakes with equal passion and energy to how you handle their successes.

And I don’t think you do this quietly, hiding behind 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 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 & failure results from a team. 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 teams review.

In Scrum, it’s the Product Owners 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.  I think 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, I think 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 commit to 10 user stories, but who had an extra 3 days at the end of their sprint of idle time, fail their sprint. Sure, they delivered to their commitment, but their commitment was flawed. They sandbagged 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.

If also seen teams that commit to 10 stories, but deliver 7 have a very successful sprint. In it they work hard against complexity and adversity. They’re incredibly transparent and engage 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 Owners intent.

Both of these cases should be discussed in the teams’ retrospective and ways to improve discussed. Not small ways and not ignoring the first teams’ behavioral problems. No. All of it—the good, the bad (mistakes & failures), and significant improvement ideas will be discussed in order for the team to decide what points are worthy of their improvement focus in the very next sprint.

bob3

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 “day job” iContact. If you don’t know about Scrum, the Scrum Master is the primary coach & 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 teams’ overall performance. What I mean by that is—guiding the teams improved performance over time. Continually asking questions like—is their team improving in their overall performance? Is their velocity improving? Is their work quality improving? Is 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 an impediment 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. And we weren’t taking 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 plateaued 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 John C. Maxwell. 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 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. But 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 would be “leaning forward” in your failure—leveraging the lessons learned to improve.

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. Not afraid of failure.

I find that using this terminology helps teams to ‘get’ the nature of failure and to behave appropriately. But beyond terminology, 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.

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.  To never mention it in public. Are those and similar actions the right responses?

To that end, I’m closing this post with a request of all readers. I’ve put together a small, focused survey that I’d like you to take. I know, I know, you’re busy. But I really think your insights will be helpful here.  The survey is focused on gathering a view towards organizational, group/team, and individual acceptance of failure and risk. I’m trying to get to a root understanding of acceptance and also the root cause for those views. While I’m particularly interested in agile teams, don’t let your lack of agile experience prevent you from responding.

Enter Survey Here…

I also request that readers weigh-in with your blog comments too. What I’ll do is collect comments and survey responses, consolidate them, and share them in a future blog post.

I wonder if the survey will be a failure?

Don't forget to leave your comments below.

Read 11936 times
Robert Galen

Robert 'Bob' Galen is the President and Principal Consultant of RGCG, L.L.C. a Cary, NC based agile methods coaching & training consultancy. He is a deeply experienced agile coach who is active in the agile community and regularly writes & teaches on all topics related to the agile methods. Bob wrote the book Scrum Product Ownership, which is focused on that role and driving value in team delivery. Bob can be reached at bob@rgalen.com and networked with via his LinkedIn profile.

© ProjectTimes.com 2017

macgregor logo white web