-
Notifications
You must be signed in to change notification settings - Fork 5
Retro
Driving Change with Retrospectives
Engage the team in improving their process in direct response to problems that they face.
“Without retrospectives you will find that the team keeps making the same mistakes over and over again.” -Henrik Kniberg
- Determine what is working well
- Prioritize what needs improvement
- Identify one change to make in the next two weeks
Alternating Fridays at 16:00 (EDT -04:00)
Discord
Focus conversations on learning and improvements.
An iteration retrospective should help the team explore the following:
- What insights do they have from the last iteration?
- What areas do they want to focus on improving?
- What ideas can they act on in the next iteration?
Consider the retrospective as a bridge between the past iteration and future iterations.
Buy-in from the team is needed for changes to stick. Build support for improvements by starting the retrospective with a review of what was learned in the last iteration—to get the story out.
Each person on the team has a different experience of past events. To understand what actually happened, the team needs to share their individual stories and integrate them. Take time to hear what everyone has to say.
Consider creating a timeline using sticky notes. Piece together a picture of events that happened. Notice how actions were influenced by other things that were going on at the time. As events are added to the timeline, remember other events and fill in the gaps. The timeline is a temporary artifact to encourage conversation. You don’t need to preserve it after the meeting.
Now we need to draw out insights from the experience gained last iteration. Start by surveying the timeline to try to spot where to dig. Try digging down to underlying causes. Ask for examples to illustrate the problem so the team understands the point being made.
After you’ve walked the timeline, choose the most important topics to focus on. Whittle this list down to the team’s top two or three topics.
Once you have extracted the topics to focus on, shift into looking forward for process improvements the team can make in the next iteration.
This is when the team works out what they’d like to change about their process. But you’ll need more than agreement that changes are necessary; the team must work out actions to implement the changes.
Before starting to create new actions in the retrospective, take the time to review what happened on the actions from the last retrospective. If those actions have not been completed, then the team needs to understand why before piling on more actions.
The smaller these action steps are, the more likely it is that they can get done. Which each suggested action step, check whether anything else needs to happen before they can get started.
Actions are not always about fixing a problem. You need to understand a problem before you can fix it, so the team may need to start with actions to explore the problem and gather data. When you have more data, you can work out actions that directly address the problem. You may also need actions to see whether the changes have resolved the problem. Also, after you’ve found a solution that works well, you may want to let other teams know about it and create actions around sharing lessons learned.
To create actions that will stick, it’s not enough to identify what needs to happen; agree on how the changes will be implemented.
Here’s the basic process:
- Ask each team member to work on their own to write a list of actions that they would like to team to take.
- Next the team works in pairs to combine their lists into a consolidated shortlist.
- Then the pairs join up with other pairs to further reduce their lists.
- Eventually the team has a shortlist of action that have been refined by the whole group.
Once you have a set of actions that the whole team is happy with, you can wrap the meeting. Don’t forget that, after the retrospective, there actions need to be considered when planning the next iteration. Post the actions on the team board so they aren’t forgotten during the next iteration.
You’ll need to do some basic preparation, such as scheduling the meeting and making sure you have a place to collaborate. The hardest bit is usually working out the agenda.
You can suggest different activities to the team to help them:
- Reveal insights
- Agree on a focus for process improvement
- Enable creative problem solving
Decide how long you will need for the retrospective based on iteration length and how many people are on the team.
Here’s an example of how to break down the time:
- Review the goal of the meeting, and remind the team of the ground rules (5 minutes).
- Create a timeline (15 minutes).
- Mine the timeline for insights (15 minutes).
- Select the topics to focus on (10 minutes).
- Review the progress on previous actions (5 minutes).
- Generate ideas for improvements (15 minutes).
- Action planning (15 minutes).
There is one special ground rule that underpins all retrospectives called the prime directive. This states that, “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew about time, their skills and abilities, the resources available, and the situation at hand.”
Make it safe to explore what went wrong because it points us at the situational causes of action and absolves the people in the situation from blame.
Retrospectives are not the best place to discuss individual performance issues. Following this directive, steer the conversation away from the blame and destructive criticism that can damage teamwork. Retrospectives should focus instead on how to improve team process.
Post the prime directive on the wall and explain it to the team.
This is usually caused by not splitting the actions down into tasks that can be achieved in a single iteration.
Encourage input with writing activities. Experiment with round-robin discussion, inviting an opinion from each team member in turn.
Do not allow the session to become overly focused on complaining rather than constructive discussion. Get back into learning mode by asking, “If this situation happens again, how should we react to it?”
Share you own impressions about past events and get involved in brainstorming actions. Be careful not to be seen as, “taking sides,” “playing favorites,” or abusing your position as meeting facilitator to get more airtime for you own personal topics.
- Start the retrospective by looking back to understand what happened and why. Allow enough time for the team to tell the full story.
- Spend the second half of the retrospective looking forward and deciding on a plan of action.
- Watch out for retrospective “smells” that are stopping you team’s retrospectives from being effective. If the retrospectives are not driving process improvement, think about how you could run them better.
- Find out what problems the team wants to fix most. Use dot voting to focus on what the team has energy to work on.
- Don’t commit to more actions that can be completed before the next retrospective. Even two or three actions completed every iteration can have significant impact over several months.
- If the actions from last retrospective weren’t done, find out why before adding any more.