Doing Scrum Properly

By

Agile Retrospectives Online Image

Do you know what my favorite animal is? The octopus. As a kid I was fascinated by anything that lived at the bottom of the sea, and anything that lived at the bottom of the sea and had eight arms was always going to command my attention.

I’m sure you’ve seen the many videos of Octopi doing incredible things? (cough cough) Using coconut shells as protective armor, changing color to blend into the scenery, working their way through man-made assault courses, opening jars to get to the contents and picking the winner of the world cup, their intelligence is clearly unmatched in the underwater kingdom.

What’s amazing, though, is that for an octopus, reproduction is fatal. Most male octopi live only a couple of months after mating and the mother octopi die soon after their eggs hatch. What this means is that each octopus learns everything for itself. An octopus was not taught how to open a jar, or use a coconut shell as armor or how to pick the winner of the world cup; every generation of octopi has had to learn these tricks for themselves.

This is great for mankind – if each generation of octopi could teach the next generation we would probably be answering to our octopi overlords right now, but, clearly, it sucks for the octopi; doomed to blend in with their ocean surroundings for eternity…

When I started practicing Scrum my teams were very much like the octopus; each sprint they would make the same mistakes and apparently have to learn everything again, from scratch, with no guiding hand or residual generational intelligence. Sure, we know that doing retrospectives was the right thing to do, but clearly we weren’t doing them properly:

  1. They were unselective; those with the loudest voices tended to be heard the most.
  2. They were uncomfortable. Often the blame would be applied to individuals.
  3. They were shallow. We could identify the surface areas but the underpinning elements were left untouched.
  4. They were broad; we were trying to fix everything immediately.
  5. They were expensive; especially so, as they weren’t working

Does any of this resonate? If so, the first thing to know is that it’s okay. You can’t fix the problem if you’re ignoring it, so congrats on facing up to the problem. The second thing to know is that it’s time to change.

  1. Ensure your retrospectives are democratic. People cannot contribute equally if they cannot contribute as equals. Set the stage in a way that allows everyone to contribute – for example, “Say what you most respect about the person to your left.”
  2. Read and recite the Retrospective Prime Directive – “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” (Go here for more.)
  3. Gather data. Get deep. Thoroughly catalogue what happened before you go deep into why things occurred…
  4. …and don’t boil the ocean. Prioritize the important items and spend your time digging right into what’s important. Don’t scrape the surface, use a technique like “The 5 Why’s” to get to the root of the issue.
  5. A retrospective is the planning stage for a change. If you’re not seeking to improve, what are you doing? Change comes from within, after all.

Who goes to work to just be busy for 8 hours a day? Drive your value, satisfy your customers and use your retrospectives to accelerate your success. Truth and purpose, please.

Truth and purpose, please.

Andrew Burrows is a Scrum Master currently working with IBM. Prior to this, he worked in video game development for over 12 years.

Interested in learning more? Check out GA’s Programming for Non-Programmers online video series, and upcoming web development classes taking place at a GA campus near you.