The Agile Coach on Failure

They say the best way to learn is sometimes through failure. I couldn’t agree more.

Now you may be thinking, “Yeah, that sounds nice, but my boss doesn’t like failure. And I don’t like getting called on the carpet. The culture in my company doesn’t encourage risk taking. In fact, we get penalized for failing via negative performance reviews.”

Welcome to the culture of command and control; management by fear.

Now don’t get me wrong. I agree that we should try to mitigate risk. But on the other hand, we might not come up with that new groundbreaking technology if we never take a chance, step outside our comfort zone every now and then.

Funny thing; agile both mitigates and encourages risk at the same time.

It mitigates by employing short, 2-week timeboxes; by allowing the customer to see what we’ve built for them at the end of those timeboxes; by having team retrospectives, identifying what we do well and where we can improve; and by practicing agile technical practices.

An agile culture encourages risk taking by making clear that we will never win in the long-term by sticking to the status quo. We must take calculated risks and invest in them. R&D isn’t the only place that spends money on crazy ideas. The IT divisions are becoming increasingly important to a company’s success or failure.

As an Agile Coach, I find one of the hardest things to learn is to let the team fail. Watching and waiting is not an easy thing to do. That said, as a Coach, I’m not going to allow them to make an epic failure that would cost the company millions of dollars. But I do want the team to feel comfortable taking chances and using failures as an opportunity to learn.

If you’re overly protective of your team’s failures, they will recover from failure more slowly, learn less, and become weaker as a team. And, as you might expect, the opposite holds true.

And an epic failure at the end of a long cycle (6, 9, 12 months) is frowned upon even more, as it should be. Accordingly, this is the dig on the waterfall approach to developing software. At the end of the 12-month project, we may think we got it all right. We may have even worked double-time at the end to get there. But when the day comes to go live, we discover that what we created doesn’t work like it should, isn’t quite what the customer asked for 12 months ago, or the market has changed — and this thing we spent so much time creating is no longer valuable.

It’s not uncommon to end up only using 20% of the original requirements list. That’s a pretty large failure risk, if you ask me. Over my 10 years of managing waterfall projects, I’ve had more than a few projects fail in this way. Of course, as the Project Manager, the fingers were usually pointed at me. I loved my job. NOT!

Enter agile development. I made the transition from Project Manager to ScrumMaster very naturally. For some PMs, it’s not a good fit. Hard to shake that command-and-control mentality. But I liked this new and refreshingly realistic way of working and getting stuff done. If we failed in agile, we failed at the 2-week mark, not at 12 months. Simple. Brilliant. The finger pointing ceased. We succeeded or failed as a team. And if we did fail, we got better the next time, or we pivoted and went a different direction. ‘Why hadn’t we all been doing this the past 4 decades,’ I thought to myself. But that’s another blog topic.

Bill Cosby once said, “The desire to succeed must be greater than the fear of failure.” Ruminate on that.

Is your energy focused on succeeding or failing?

This entry was posted in Agile Adoption, Agile Benefits, Agile Coaching, Agile Management, Agile Teams. Bookmark the permalink.

9 Responses to The Agile Coach on Failure

  1. Ewan O'Leary says:

    Mike, you’ve raised a really important topic here, one I’ve been thinking and working on a lot lately, in my coaching. So many organizations exist with control structures that operate on fear and blame, which invalidates any kind of risk-taking behavior, so important for innovation. As a coach, I try to create space for teams (especially new ones) and their leadership to learn from small failures, rather than experience large painful ones. Much of the blame inherent in organizations is the residual damage from the failures of large, opaque projects run in a waterfall fashion. As agile practitioners, I think we should be mindful of how these ‘ghosts of projects past’ can regulate organizational cultures, and actively seek ways to shake them out of the system. Small transparent failures with demonstrated learning clearly communicated with key players in the organizational hierarchy can help.

    • Mike McLaughlin says:

      Ewan, you’re spot on identifying the ‘fear and blame’ structure that exists in many organizations. How we deal with these ‘ghosts of projects past’ is crucial to moving to a more empirical and agile culture.

  2. Allison says:

    You’re right–it’s hard to watch teams fail! I find it helpful to ask myself if the team is going to feel some pain or if the team is going to get injured; pain encourages learning, but an injury can be a big setback. It puts their ‘failures’ in perspective for me as a coach.

    • Mike McLaughlin says:

      Tell me about it… I have an 8 year old son, and I’m fighting this idea of ‘allowing him to learn by making mistakes’. It’s tough. Of course, the same applies to Agile Teams. Small failures in the short term, early on, often lead to long term success as we learn and grow.

  3. Pat Smithson says:

    Well said Mike, this holds true in other industries than IT. People are afraid to fail. Risk is a scary thing for most of us. My guess is that most of the big IT successes we all experienced came out of taking big risks and having good communication. Look at all the applications that are out there in the world and how many updates get sent out for those programs. If companies relied on creating one product and thought it would be good for forever, we’d have thrown them out the door. They don’t say they’ve failed they’re just using Agile on an ongoing basis as customer needs change.

  4. Satish Thatte says:

    Fail fast, fail cheap and fail early, so it doesn’t cost a fortune, and you learn quickly. Human beings don’t learn much from other’s mistakes, but at best learn from their own mistakes.
    Good blog, Mike.

  5. Mike McLaughlin says:

    So true, Pat. A little company called Apple comes to mind…

  6. Gunjan Choudhary says:

    Lessons learnt from ones own mistakes and blunders are likely to stay with them longer. Also, the willingness to work towards the goal of not repeating a mistake is more than the willingness to do some thing just because some told them to do so. I could nt agree with this article more.

  7. Pingback: Who Really Needs Agile Training? | Items on the Left

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>