Category Archives: Process

Agile Retrospectives Workshop

Earlier this year at work I led a short workshop on Agile Retrospectives. We already make use of the retrospective format very frequently within the technology department, but other departments are not as familiar, so I put together this workshop to show them how amazingly useful retrospectives can be.

The full presentation is here, and I’ve also replicated a version of it throughout the following post.

Agile Retrospectives Workshop

What is a retrospective?

A retrospective is a team activity, where team members meet to understand their current process, discuss how it can be improved, and generate action items that can be acted on before the next retrospective.

What are they good for?

  • improving your process
  • learning from past mistakes
  • celebrating accomplishments
  • getting your team on the same page
  • improving your work environment
  • making good teams great

Who can run them?

Anyone!

  • retros do not have to be run by managers!
  • in fact, it’s usually better if they are not

A retrospective is not…

a time to blame people

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
— The Retrospective “Prime Directive”

a forum for fixing everything

  • retro often, and make small, incremental changes each time

Outline of a Retrospective

  • Set the stage
    • Make sure people feel comfortable
    • Check the safety level
  • Gather Data
  • Generate insights
  • Plan of action
  • Close
    • Want to leave on a positive note!
    • Review accomplishments and action items

Outline of a Retrospective: Example

Set the stage

  • Team gathers in conference room
  • Retro moderator gauges the “safety level”
    • team has been through lots of retros, comfortable giving feedback
    • things have been pretty “normal” since last retro
    • => high level of safety
  • Moderator introduces the format (see picture below)
    • Divide the board into four sections: Things we’re happy about, things we’re not happy about, Ideas, Appreciations
    • Write notes on stickies and put them on the board, followed by team discussion

Generate insights

  • Team members write down points on stickies and put them up on the board
  • Moderator takes a few min to “aggregate” the issues and mentally sort through them

Plan of action

  • Team discusses the stickies
  • Comes up with action items, if needed
  • (don’t have to have an action item for every point–sometimes the discussion is enough)

Close

  • Moderator reviews action items

Tips for Moderators

the format of a retro is very fluid, and facilitating is the art of choosing the correct format for the situation
that said, you can greatly improve your retrospectives with a little planning and empathy

Planning a Retrospective

  • Take some time before each retro to figure out the best format for the participants
    • What is the expected safety level?
    • How experienced are they in giving feedback?
    • What sort of issues do you expect to hear about?
    • Do they need to dig deep into an obvious issue, or do they need to brainstorm and mix things up?
    • Is an outside facilitator more appropriate?
  • Talk to some of the participants beforehand if you need to

Empathy is important!

  • The best facilitators are able to monitor the emotions of the participants, and adjust the format appropriately
  • You want to create an atmosphere where people can open up and get to the root cause of their issues
Teaching empathy is difficult, so if you are interested in learning more, I highly recommend reading An Anatomy of a Retrospective

Exercise: create your own retro

  • We’ll split up into groups, and each group will get a scenario
  • Consider the scenario, and choose which format would be appropriate (we’ll go over some examples in a moment), or create your own

Each group should answer the following questions for their scenario:

  • What is the expected safety level?
  • How experienced is the team in giving feedback?
  • What sort of issues do you expect to hear about?
  • Do they need to dig deep into an obvious issue, or do they need to brainstorm and mix things up?
  • Who would be the most appropriate facilitator?
  • How much time is needed?

Scenarios

Scenario 1

You work on a small, cross-functional team (3 developers, 1 QA, 1 BA) in the technology department. Your team has weekly sprints and bi-weekly retrospectives. The team is fairly mature, everyone is familiar with one another and this process has been going on for about six months at this point.
You recently started developing software for a new platform: Android. You’ve done 3 releases now, so things are pretty stable, but you want to see if you can do things better next time.

Scenario 2

You work in sales, and your team has spent the last six months working on replacing a legacy phone system with a shiny, new one. There were some bumps along the way, but the new system is now out the door and working fine.
This project involved a wide range of people from your department, technology, building management, etc. Some people worked on the project for its full length, others only worked on the project for a few weeks, but they’re all here now.
Some people in the room have done retrospectives, but not all. In fact, lots of people are skeptical that this will even be a good use of their time.

Scenario 3

You work in the Customer Service department. Your team has retrospectives regularly, but it seems like lately the same problems keep coming up every time. You’ve had action items in the past, but it doesn’t seem like that is working, since the problems still exist.
People are getting frustrated and are stuck when trying to think of fresh solutions. Every idea you come up with seems to either a) not work in practice, or b) require help from the Technology department, which is too busy with other projects.

Scenario 4

You are a member of the Senior Management Team. It’s the beginning of a new quarter, which is always a great time to step back and take a look at the big picture.
Most of you have done a retrospective before. There are a lot of strong-willed people in the room. Everyone is very busy, and doesn’t have any more than the hour that they’ve set aside for this retrospective.

Further Reading: A List of Retrospective Formats Of Which I Am Quite Fond

Timeline retrospective

An excellent format for a team retro at the end of a project

Appreciation Retrospective

Pair with the Timeline Retro above, for the end of a particularly difficult project

Complexity retro/root cause analysis

Another retro that is good for a small team (stream team) after the end of a project

Starfish

Good ol’ Starfish, a team standby

Learning Matrix

Actions Centered

These are very similar to pluses/deltas format, but with a little extra to mix things up and get people thinking creatively again

Top 5

Gather stickies just like +/deltas, but then only discuss the top five. Sometimes good to split up into five teams to discuss if it is a larger group. Good to use if it seems like retrospectives are too broad and don’t go deep into any particular topic

Circles and Soup

Allows the team to recognize which factors are within their control, so they can be constructive when making future plans
Good to use when team is feeling frustrated with issues/politics outside their control, or to preface a future-planning session

Sails and Anchors

Sometimes you need to step back and look at the big picture–what is pushing us forward? what is holding us back?

Force Field Analysis

Pick a goal, figure out what is pushing you towards that/holding you back. Sails and anchors format can also be used for the same purpose

Values-driven retro

Useful if you want to ensure all team members are on the same page about values

How-Now-Wow

Helps the team think of creative solutions to problems

And finally…
Retrospective Surgery

A retrospective for your retrospectives =)