Insights

3 Ways I Was a Massive Failure: Scrum Edition

April 11, 2017 | Kate Gordon-Bloomfield

Kate Gordon-Bloomfield

We fail. Hard. And the mistakes of our lives repeat on endless memory loops while we stare at our friends’ picturesque, photoshopped vacation pictures on Facebook and Instagram.

My colleagues have recently shared some marketing and design failures. This week, allow me to take you on a painful, embarrassing journey through three massive, personal failures—so you too can learn to take a Failure Bow.

FAIL 1: Planning for Perfection is Planning for Failure

Storytime:
Many years ago, my client’s web application had a security hole. Salting the wound, the site had been advertised on the back of millions of cereal boxes. Clever people had found said hole, exploiting it like a zero-day Windows vulnerability at Black Hat, enabling them to put their own user ID at the top of the high scores list for all of the Flash-based games on the site.

Cue the emails from concerned parents, frustrated that someone had somehow gotten a total score of 1 on an 18-hole mini-golf game.

Cue the internal monologue of arrogance and dismissal. It’s only a gaming site. They’re just kids.

The technical reasons for the failure were foremost on my mind at the time. This lead to many sleepless nights, fatigue, and higher bug rates. The stress mounted until my team and I were much less effective.

But in those heady dot-com bubble days, such technical mistakes happened: we corrected them and moved on. We use processes like peer programming, coding reviews, Quality Assurance (QA), User Acceptance Testing (UAT), and penetration tests, building on our experience.

This is all well and good, but, your client doesn’t get a second first impression.

Lessons Learned:

  • Make room for mistakes. We must do our lower-risk failing before the “cannot fail” moments come along.

    FAIL 2: Process Over People

  • Storytime:
    My client had hired me to lead an international team developing a web application for a travel sector client. The code base was a mess: over-dependence on a small number of all-stars, poor hiring, and the added pressures of a shrinking industry hadn’t helped matters either.

    I thought, however, that my job was to sort out the project through correcting the process. I was, after all, hired for my experience in agile software development.

    In my zeal, we made some radical progress. Technical debt was getting paid down. Velocity was increasing with each sprint. The team was finally able to structure some improvements in a reasonable way. Success!

    In that fervor of team improvement, however, I failed to look up. The project manager associated with project kept updating his Gantt charts and making promises for delivery that I failed to sufficiently challenge.

    The inevitable train wreck arrived. It came in the form of a protracted argument over bugs and how to handle them. Which resulted in a surprised and disappointed client whose expectations weren’t met.

    Lessons Learned:

  • Like Janus, a ScrumMaster must look both in and out, macro as well as micro.
  • Process isn’t anything special; people are.
  • The only Right Way is humanistic.

    FAIL 3: Trust Without Verification

  • Storytime:
    I was leading multiple, interdisciplinary teams for my client, but we had a shortage in QA, leading to a bottleneck. So, we brought in an additional QA specialist. We’ll call him Steve.

    Soon after, I heard complaints. Steve didn’t know or understand how we did things. He couldn’t grasp the software.

    The team QA manager came to me with her manager in tow, advocating for Steve to go. As a contractor, dismissal from the project was relatively straightforward. We contacted his line manager, discussed the issue, and that was that. Steve’s last day would be 30 days hence.

    I believed the story about Steve’s shortcomings because it was easy. And by the time counter-indications came through conversations with other team members, it was nearly Steve’s last day.

    Despite the simple story that Steve didn’t get the software, it turns out that the team QA manager had given Steve only the most cursory explanation of the application, hadn’t explained the bug handling process, hadn’t created clear expectations, or assisted him to meet team needs.

    I wrote emails to Steve’s line managers, apologizing for getting this spectacularly wrong. He had been asking for additional help. He had been brushed off by his team QA manager. He hadn’t done anything wrong, and was instead a victim of some terrible management—some of it my own.

    When Steve and I spoke, the fact he had another role in place did little to make the conversation easier.

    Lessons Learned:

  • Don’t believe the message just because it’s convenient.
  • There are two sides to every story.
  • Do the Right Thing, even if it’s extremely painful.

    Take a Failure Bow

    Clearly, we all make mistakes. Recognizing this and expecting it fosters compassion for others. But when we screw up, we can defend against the endless loops of mistakes by taking a Failure Bow.

    You know your guilty look—the lowered head, raised shoulders, the cringe on your face as your body tries to say “sorry.” The Failure Bow is the opposite of that. You raise your arms way above your head and yawp “Whoo-hoo! I failed!”

    We aren’t celebrating failure, necessarily. Consider it a body hack—we are letting go of the endless loops of mistakes that replay in our heads in order to enable growth and learning.

    If your environment is staid, do it in the bathroom. Better yet, cajole a co-worker into Failure Bowing with you right in the moment. Blunt the arrows, be kind to yourself, and being the person you want to be will get easier.


  • Related articles:

  • Two Ways I Was a Massive Failure: Marketing
  • How to Apply Scrum Principles IRL
  • Four Ways I Was a Massive Failure: Design

    Are you enjoying our Failure series? We want to hear more of your fails. Reach out on Twitter @pluscitizen and let us know your favorites.

  • Author:
    Kate Gordon-Bloomfield