Retrospectives: Getting from Good to Great

How success can start with failure…

Opportunities for failure lurk everywhere. In projects, in code roll-outs, in team member interactions. We’re going to try a lot of new things. Some will work. Some won’t.  We don’t set out to fail, but when we do, how will we handle it?

When a mistake stares us in the face, will we:

  • Deny it (nah, that didn’t really happen, or maybe it doesn’t really matter…)
  • Defend it (well, it happened, but it wasn’t my fault, the problem’s in the legacy code…)
  • Explain it (yeah, well, it happened, and it was my fault, but…)
  • Understand it (I see what happened there…)
  • Learn from it and change

We often find “failure” so upsetting that we miss out on the primary benefit of failing (yes, benefit): a chance to get over our egos, learn from the experience, and come back with a stronger, smarter approach.

This openness to looking for benefits in failure has produced many insights. Many of the things we do as standard practice weren’t always in place “since the beginning” – instead they came from looking at things through the lens of “how do we learn from this and iterate?”

In fact, the idea of retrospectives themselves emerged from “things not going right.” Back in the early days of Scrum there wasn’t a formal sprint retrospective at all. The prevailing wisdom at the time was that a good Scrum team should be always on the lookout for opportunities to improve; they should not defer opportunities to discuss improvements until the end of a sprint. That argument was a fairly good one. Good enough that the community was strongly opposed to making retrospectives a generally accepted Scrum practice – what Mike Cohn likes to call: a GASP. (Cohn’s definition of a GASP is not something every Scrum team “needs to do,” it’s just something every Scrum team needs to be aware of. They may reject doing it – hopefully for a good reason – but should not be ignorant of it.)

However, people observed that in-spite of what “should” be happening, what actually occurred on most Scrum teams was that day-to-day urgencies took precedence and opportunities to improve (i.e., failure.) often went either unnoticed or un-acted upon. So most teams eventually realized they should really set aside a dedicated time each sprint for doing so – and thus the retrospective became a standard part of Scrum practice.

An approach to retrospectives

What is a retrospective?

  • A forum to inspect, tinker, and adapt
  • A safe, collaborative, reflective and forward thinking event
  • An opportunity to catalyze continuous improvement
  • A team activity, done on regular intervals
  • A means to facilitate autonomous, self-motivated, and continuously improving teams

How we organize retrospectives

The general format of a retrospective can vary a bit based on team preferences, but usually we do it something like this:

  • We allocate 0.5 to 1.5 hours depending on how much discussion is anticipated. (Time-box is determined before we start.)
  • Participants: The full cross functional team: product owner, developers, operations, customer service, design, marketing, etc.
  • Grab a meeting room, a cozy alcove. (We have yet to take advantage of the outside patio on a good  weather day – we do have mobile white boards… hmmm.)
  • Somebody grabs dry erase markers, someone else writes things up in our internal wiki.
  • We look at the planned vs. actual story point velocity of the sprint. Did we hit our sprint forecast? Was the sprint a success? (This is a binary. We’re not playing horseshoes where “getting close counts.”)
  • We do “the columns” (see below).
  • The team brainstorms up candidates for change.
  • The team decides which candidates for change to put into place with the next sprint.
    • Typically a short list (1-3) of agreements are chosen to be implemented during the next sprint.
    • If there are many candidates for change, the team might use “dot voting” to determine which improvements to focus on during next sprint. In dot voting, each team member is given 3 “votes” to place on whatever improvements they would like the team to prioritize during next sprint. Each team member can distribute their votes as they like, even placing all three on a single candidate for change. The idea with the most votes wins.
    • The agreements get written up as “cards” and those cards go into the backlog for the team’s next sprint. And at the next retrospective we inspect if those items made it to “Done.”

The underlying theme is always the same though: “what can we do better next sprint?”

The columns (at least three… sometimes five maybe six…)

  • Continue: If we could redo the same sprint again, we would do these things the same way. The team likes and thinks these have been and will continue to be successful.
  • Stop: What slowed the team down? Where were the impediments? What did the team tolerate that it shouldn’t have. If we could redo the same sprint again, we would try to not do these again.
  • Examine: Candidates for change. Things the group is not doing, but think they should be. Ideas to address new situations or factors that may not have existed at the beginning of the sprint but emerged. Things the team might try to fix some of the stops.
  • Start: Concrete ideas about how we could improve “next time”; “To Do’s” that address the Stop’s or Examine’s. (Start doing these.)
  • Whoa: Complete surprises (optional): things that came out of the blue, things that were hidden under the carpet…
  • Kudos: Props, brilliant moments in the sprint. Gotta celebrate those…

The Continue and Stop columns look into the past, while the Examine and Start columns look into the future. And the Kudo’s – well, they are just plain nice to hear…

Teams can approach the columns in a variety of ways:

  1. Individuals get a chance to say, without being interrupted, what they thought was good (continue), what wasn’t good or what they think could have been better (stop);
  2. Individuals say one thing (stop or continue), and then the next person speaks, and the team continues going round until nobody has any additional continues or stops;
  3. Everyone writes down their notes (individually in silence or in quiet pairs), and then we share.

Variations on a theme….

It makes sense to explore a number of different retrospective exercises. Why? A couple of reasons:

  • Teams differ from each other so an approach that resonates with one team, might not work so well with another.
  • The things that each team deals with can be different in each iteration.
  • Teams might just get bored when they are always doing retrospectives the same way sprint after sprint.

The key here is that individuals must feel comfortable enough to share their problems, opinions and concerns and suggest different ways to approach the problem. So various means of doing so (group, individual, spoken, written) are often needed.

The following are some exercises we are currently or soon will be using to mix things up (I’ll post more details soon for your retro toolbox…)

  • What Worked Well / Do Differently Next Time (aka WWWDD)
  • Keep / Drop / Add
  • Stop Doing / Start Doing / Keep Doing (aka StoStaKee)
  • Start / Stop / Stay
  • Start  Stop / Less / More / Keep (Starfish or Sand Dollar)
  • Glads / Sads
  • Prouds / Sorries
  • Smiley / Frowny / Light Bulb
  • Plus / Refactor / Integrate
  • Right / Wrong / Fix
  • More of / Less of
  • Liked, Learned, Lacked, and Longed For (4L’s)
  • Eliminate, Reduce, Raise, Create
  • Sailboat

For more details on many of these variation, see Retrospective Exercises

Spreading lessons learned

A sprint retrospective is not only about how a single sprint team can do a better job during their next sprint, it has wider implications than that. Perhaps other product teams are having the same or similar issues. Our strategy for handling that is very simple. Not only is each team responsible for publishing a sprint retrospective report – we recently started synchronizing our sprint planning sessions, so at the outset each team gives brief “last sprint we learned” presentation.

Project close retrospectives

Just as we “kick off” a project, we like to bookend things with a “close out,”  especially when we are developing a feature that will span more than a couple of sprints. We distribute a survey to all those involved with the project – stakeholders, product owner, design/ux and the dev/ops team. (We have a template in SurveyGizmo that we use as a starting point, and frequently iterate on it based on – you guessed it – retrospective feedback…)

The output of that survey provides background and often drives a great deal of the discussion during the close out retrospective meeting itself. We’ve been following the start/stop/continue approach, and just recently used (with great results) the 4L’s approach for a newly formed team. (Future post on that in the works…)

Our aim is to consider the overall project from a higher level than we do during a sprint retrospective:

  • How did our Product Owner do?
  • How did our Team do?
  • How were our Engineering practices?
  • How did our Organization do?

Some specific lines of inquiry we explore at the close-out retrospective:

  • Team Work – How did things go in terms of respect, cooperation, accountability, passion, commitment?
  • Design / UX – Feedback on the design of the application, what did we learn during beta?
  • Execution / Focus / Schedule – How well did we execute overall in getting this to done?
  • Personal Achievement – Did people learn something during this project?
  • MVP Accuracy – How closely did what was produced match the initial goal for the project?
  • Escaped Defects – How many bugs made it out into the wild?
  • Technical Debt – Did we leave things better than we found them?
  • Did we build a cathedral – when a dog house would do?
  • What were the project high/low points?
  • Knowing what we know now, how would we have planned the project differently, more efficiently?

Blameless postmortems

Postmortems are a special kind of retrospective – scheduled within 24 hours of an “incident.” The prime directive of our postmortems is:

“Regardless of what we discover, we must understand and truly believe that everyone does the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.” –Norm Kerth, Project Retrospectives: A Handbook for Team Reviews

Failure happens. This is a foregone conclusion when working with complex systems. We want to view failures with a perspective of learning. By investigating things in a way that focuses on the situational mechanisms, instrumentation, and the decision-making processes, we come out safer, stronger, and more resilient. At a postmortem, team members who were part of the incident give an account of:

  • Timeline of events as they occurred
  • What assumptions they made
  • What actions they took
  • What effects they observed

… and all this happens without fear of punishment or retribution.  After all, the actions made sense to the person at the time they took it, because if it hadn’t made sense at the time, they wouldn’t have taken them in the first place.

We strive to remove any fear regarding “coming clean.” Nobody has reason to hide their mistakes or avoid talking about them. This creates an openness and the opportunity to learn from one another.

Or in the words of Henry Ford “Failure is only the opportunity to begin again, more intelligently.”

Wrapping up

I recently discovered “Getting Value of of Agile Retrospectives” from Luis Gonçalves and Ben Linders and they sum things up nicely:

“In retrospectives you look for improvement actions within the agile team that team members do themselves. Teams are self-organizing which means that they have the power to change the way they work (their process). If they want to try a different way of working, it’s up to them to give feedback to each other, to discuss what happened, to learn, and to decide what to do…

In the retrospective, the team defines the actions that they want to perform in the next iteration to overcome issues that they ran into during their last iteration, to work more efficiently and effectively, and to deliver more business value to their customers. Nobody can effectively change a self-organizing team but the team itself!

Retrospectives empower the team to control their own destiny.”

Resources for more:

One comment

  1. Thanks Andy for mentioning our book! As you mentioned, retrospectives are a great way for teams to learn and improve. We hope and expect that the exercises described in our book will help teams all around the world to get more value out of agile retrospectives.

    @BenLinders

Leave a Reply

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

Back to Top