Facilitating retrospectives

In the last blog post, I introduced you to retrospectives and listed the different types of retrospectives. This time we will focus on the contents of a retrospective. The theories I present will be best suited for iteration/milestone, release and project retrospectives. Sprint retrospectives as well as Kanban kata have their own routines. A retrospective consists of five phases, which are:

Set the stage
Gather data
Generate insights
Decide what to do
Close the retrospective

Continous improvement

Picture based on Agile Retrospectives: Making Good Teams Great (Esther Derby & Diana Larsen).

I will cover each of the steps in detail below. Each steps consist of a set of different activities. I list some example activities in this blog post, but I recommend that you check the books and website I am referencing to at the end of the blog post. Nothing prevents you from thinking of own activities either as long as it helps getting results. Be sure to reserve time for each of the presented steps and do not skip any of them. Each step has its purpose to help getting the most out of a retrospective.

One final thing before we begin. I want to introduce you to Kerth’s Prime Directive. It is of utter importance that everyone understands this regardless of retrospective:

Regardless of what we discover, we must understand and truly believe that everyone did 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.

Set the stage

Setting the stage helps set the focus on the retrospective and it is good to reiterate the goal of the retrospective. Ask everyone in the room to speak, e.g. by asking their expectations or goals of the retrospective. Studies show that there is a bigger chance that a person will stay silent for the rest of the session if they have not spoken in the beginning. We want to include everyone in the retrospective. Next, outline the approach for the session and agree on common working agreements. You can re-use and possibly update the working agreements in future retrospectives. Ensure that everyone respects and follows the working agreements during the retrospective.

Check-In

Used to set the stage and activate everyone.

Ask one question that each person can answer with one word of short phrase. What is happening for you right now? What are your hopes for the retrospective? What is one thing that is on your mind?

Focus on/Focus Off

Used to establish a mind-set for productive/unproductive communication patterns.

Form small groups if needed. Think of pairs of words that, and describe them. Example word pairs/sentences: Inquiry rather than advocacy, Dialogue rather than debate, Understanding rather than defending.

Working agreements

Establish a set of behaviour that will help the team in having a productive retrospective.

Form small groups if needed. Develop 3-5 working agreements in each group. If followed, it will help the team have productive discussions. Narrow down the agreements to a total of 3-7 items if there are several groups.

Gather data

In order to make sound decisions during the retrospective you need hard data: events, metrics, features or stories completed and so on. Events can include meetings, decisions, changes in team structure, milestones, celebrations, technology adaptations etc. Ask team members to bring with the data to the retrospective that they might find useful. It can be either physical items or data in digital format. It is a good practice to visualize the events/history on a timeline for periods longer than 2 weeks. It helps people grasp patterns and make connections. Hard facts is one part of the equation. It is also important to address how people have felt during the iteration and map that on the timeline (highs and lows).

Timeline

Stimulate memories by visually building a timeline of the iteration events.

Fill in a timeline to create a fuller picture of this iteration/release/project. Divide into small groups if needed. Hand out marker cards and stickies’ and ask everyone to think back over the iteration to place events on the timeline. They can be personally important or significant for the project. After a while summarize the timeline and walk through it with the team.

Team Radar

Help the team gauge how well they are doing on a variety of measures.

Track individual and group ratings for specific factors that you have chosen in the team. Factors can be e.g. communication, feedback, simplicity, quality, technical debt. Grade each factor (0=no performance, 10=full performance) either as a team or individually and by calculating the average. Write down the results in a radar diagram. Re-use these factors in consecutive retrospectives to track progress.

Note! Team radar is a subjective measure that should generate discussion and thus can be useful in case the team has no common definition or criteria to measure against.

Generate insights

The next step in the retrospective is to ask “Why?” and start thinking about what to do differently. Be cautious that you do not directly jump into conclusions. We want to consider additional possibilities and understand the full picture before thinking of any action points.

Brainstorming

Generate a large number of ideas that you later filter against a set of criteria to get a more refined list of ideas.

Most are familiar with brainstorming so here’s a couple of methods that can be used:

Free-for-all. People call out ideas at random.
Round-robin. Pass a “talking-token” around the circle. Only the person with the token can to talk.
Silent/individual brainstorming. Afterwards continue with method 1 or 2.

Five Whys

Find the root cause of an issue.

Choose an issue to analyse and ask why it happened. When you come up with an answer, make a follow-up question of why that happened. Continue asking why until it makes no sense to ask why any more times. Usually this is somewhere around the fifth why.

Fishbone

Another method to look past symptoms in order to identify root causes.

Draw a fishbone diagram and label the “bones” with categories e.g.

What, where, who, why, when
Methods, machines, materials, staffing
Place, procedure, people, policies
Surroundigs, suppliers, systems, skills

Pick categories that makes sense for you. They can also be specific for software development. Brainstorm factors within each category in order to identify causes. Stop when the causes are outside the team’s control or influence. Look for recurring causes. Discuss where the team can make a difference.

Patterns and Shifts

Use with a visual data-gathering activity to generate insights.

Look for links and patterns in activities. Focus on one section at a time. Write notes on what the team observes. Look for connections, patterns and where do shifts occur.

Prioritize with Dots

Use both when generating insights and when deciding what to do.

Prioritize top issues by giving dots to items. Each person gets e.g. 10 dots to use. Give 4 dots to the highest priority item and 1 dot to the lowest priority item. Calculate the total number of dots after each person has placed their dots.

Get variation by phrasing a question differently:

Which is the most important thing to work on?
Which will have the greatest impact?
Which do you want to work on most?”

Decide what to do

Now the team should have a list of potential experiments and improvements and it is time to prioritize the actions and pick the top items to address. Make sure that you only one or two actions for the next iteration. Something that the team can commit to and that will have a positive effect. Preferably, you create backlog items of the action points so that they end up on the same work plan as the rest of the work in your iteration. Finally ensure that individual people commit and sign up for the task(s). Assuming that “the team” will do it is a usually means that no one does it.

The Do-Nothing retrospective

It is easy to identify improvement targets that are seemingly out of the teams reach or someone else’s responsibility. Remember thought, that the most powerful place to start a change is within the team! Change happens in the course of normal work. Many teams fail to improve due to the reason that the retrospective items are separate from the backlog and consider it as “extra work”.

Retrospective Planning Game

Brainstorm and develop detailed plans for selected items.

Split the experiment/improvement item into tasks. Do this either individually or in pairs. After a while group together and compare/merge the results. Order the tasks by which task(s) to start with. Identify tasks to do simultaneously. Assign the tasks or alternatively add them to the team’s backlog to the normal workflow.

SMART goals

Translate ideas into priorities and action plans.

SMART goals are Specific, Measurable, Attainable, Relevant and Timely. Everything else needs to fizzle. Think of goals that to achieve that relate to the prioritised work items. Do this in smaller groups if needed. Report and summarise what the goals are.

Close the retrospective

End the retrospective decisively. Summarize the retrospective, decide how to document it as well as agree on follow-up. Before you end, take a few minutes to take a retrospective of the retrospectives. Discuss what worked well and what you want to do differently next time. Maybe it is time to mix up some of the activities done during the retrospective.

+/Delta

Identify strengths and changes for the next retrospective.

Make up a list of items to keep, and to change, for the next retrospective. Gather items by allowing anyone to report a keep/change item. Compare the results with previous feedback to look for patterns.

Appreciations

Allow team members to notice and Appreciate each other.

Start by selecting one person who says a sentence in the following format: “I appreciate you for …”. The person who received an appreciation now passes on a new appreciation to another person. This goes on until at least everyone has received one appreciation.

Return on Time Invested (ROTI)

Gather feedback whether the team spent their time well.

Use the following scale:

0 points – Lost Principle: No benefit received for time invested.
2 points – Break-even: Received benefit equal to time invested.
4 points – High return: Received benefit greater than the time invested.

Ask each person to reflect his or her feeling on the retrospective. Record has marks on a flip chart. Ask those who rated 2 or higher what benefit they received. Then ask those who rated 0 or 1 what they wanted but did not get. Discuss what to keep and what to change for the next retrospective, even if you received high scores.

Conclusion

This has been a very brief overview of facilitating retrospectives. Remember Kerth’s Prime Directive, rely on data and commit to the actions. Everyone can make a change! Do not hesitate to contact me in case you want to discuss the topic more or need mentoring. I will be happy to help you out or even come and facilitate a retrospective for your team!