PEARL XXIII : Retrospectives are widely regarded as the most indispensable of people-focused agile techniques. Inspection and adaptation lie at the very heart of agility, and retrospectives focus on inspecting and adapting the most valuable asset in a software organization, the team itself. Without pursuing improvement as retrospectives require, true agility is simply not achievable. This section deals with guidelines for Successful and effective Retrospectives.
Performance can be neither improved nor maintained without exercise. Simply conducting a meeting isn’t enough to be successful, however. Attention must be paid to ensuring teams plan improvements. If a plan to improve is not part of the outcome, it wasn’t actually a Sprint Retrospective.
When done well, retrospectives are often the most beneficial ceremony a team practices. When done poorly, retrospectives can be wasteful and grueling to attend.
- Inspect how the last Sprint went with regards to people, relationships, process, and tools;
- Identify and order the major items that went well and potential improvements; and,
- Create a plan for implementing improvements to the way the Scrum Team does its work.Sprint Retrospectives are used by teams to deliberately improve. Effective Sprint Retrospectives are an important ingredient in helping good teams become great and great teams sustain themselves.
Why Retrospectives Matter
Retrospectives are widely regarded as the most indispensable of people-focused agile techniques. Inspection and adaptation lie at the very heart of agility, and retrospectives focus on inspecting and adapting the most valuable asset in a software organization, the team itself. Without pursuing improvement as retrospectives require, true agility is simply not achievable.
Anatomy of a Healthy Sprint Retrospective
Scrum says little about the internal structure of Sprint Retrospectives. Rather than prescribing how the Sprint Retrospective is conducted, Scrum specifies the output of the Sprint Retrospective: improvements the Scrum Team will enact for the next Sprint.
- The entire team is engaged
- Discussion focuses on the team rather than individuals
- The team’s Definition of Done is visited and hopefully expanded
- A list of actionable commitments is created
- The results of the previous Sprint Retrospective are visited
- The discussion is relevant for all attendees
The entire Scrum Team attends each Sprint Retrospective. Usually, this means the Product Owner and Development Team attend as participants while the Scrum Master facilitates the meeting. In some cases, Scrum Teams invite other participants to the meeting. This can be especially helpful when working closely with customers or other stakeholders. Regardless of who attends, the environment for Sprint Retrospectives must be safe for all participants. This means attendees must be honest and transparent while treating others with respect. Passions can ignite in retrospectives as issues of performance and improvement are discussed; skilled facilitators ensure discussions stay positive and professional, focusing on improvement of the team as a whole. This is not an opportunity for personal criticism or attack. Increasing the Definition of Done Development Teams in Scrum use a Definition of Done to note what must be true about their work before it is considered complete. For example, a Development Team may decide that each feature it implements must have at least one passing automated acceptance test. Or the team’s Definition of Done may state that all code must be peer reviewed.
- Focus on the entire Scrum Team
- Focus on the Development Team
Making Actionable Commitments
Although discussion may diverge and converge during the meeting, no Sprint Retrospective is successful if it doesn’t result in commitments by the team. It is not enough to simply reflect on what happened during the Sprint. The Scrum Team makes actionable commitments for what it will:
- Keep doing
- Start doing
- Stop doing
The word “actionable” is significant. Actionable commitments have clear steps to completion and acceptance criteria, just like a good requirement. An actionable commitment is clearly articulated and understood by the team. When teams first start performing retrospectives, they often find it easier to identify problems than plan what to do about them. Accordingly, the commitments published by the team may look like these:
- Work in smaller batches
- Make requirements easier to read
- Write more unit tests
- Be more accurate when estimating
These are not commitments; they are either goals or perhaps thinly veiled complaints. These are certainly issues that teams may wish to discuss during the Sprint Retrospective, but a list of actionable commitments looks more like this:
- Check in code at least twice per day: before lunch and before going home
- Express new Product Backlog items as User Stories and include acceptance criteria
- Create a failing automated test that proves a defect exists before fixing it
- Use Planning Poker during Product Backlog grooming sessions
Commitments made in the previous Sprint Retrospective are visited in each new Sprint Retrospective. This is necessary for retrospectives to retain their meaning and value. Few things are as frustrating as being on a team that continually commits to improving itself without making tangible progress toward doing so. For the Sprint Retrospective to be valuable team members must be more than present, they must be invested. Collaborating to create actionable commitments engages attendees and invests them in the success of the team.
Keeping it Relevant
Sprint Retrospectives are fundamentally a technique used to reveal the practices and behaviors of the Scrum Team to itself. When a self-organizing system becomes self-aware, it self-corrects and deliberately improves when given the tools to do so.
Varying the Techniques
There are numerous techniques for conducting retrospectives. Trying different constructions of the Sprint Retrospective meeting keeps things fresh and interesting. As the primary facilitators for the Scrum Teams, Scrum Masters should at least be familiar with some of the more popular techniques.
There are books about retrospectives and blog articles aplenty to help people get the most from their practice. Some of the most popular are briefly described here.
In the most basic of Sprint Retrospective’s a facilitator simply asks basic questions of the team and facilitates discussion. The facilitator or Scrum Master may use various brainstorming techniques to get the team to answer:
- What went well in this Sprint?
- What happened in this Sprint that could use improvement?
- What will we commit to doing in the Sprint?
One simple technique to derive these answers has each team member write 2-3 answers to these questions on sticky notes during a 3-5 minute period of silence. Once created, the suggestions are grouped on a wall for all to see before being voted upon. A list of actionable commitments can thereby be derived from the collective wisdom of the team. Most other Sprint Retrospective techniques are variations on this theme and may focus on only one question or stage of this process. In any case, the outcomes are most important and any good technique supports this basic model.
Reviewing Previous Commitments
In addition to looking ahead to the next Sprint, each Sprint Retrospective should include a review of commitments made in the previous Sprint and a discussion about the team’s success in meeting those commitments. If this discussion isn’t part of each Sprint Retrospective, attendees soon learn their commitments don’t matter, and they’ll stop meeting them.
Further, the right place to review Sprint Retrospective commitments is throughout the Sprint, not just at the end. Once commitments for improvement are made, posting them publicly can help ensure they are considered on a daily basis. Some teams value posting commitments made during Sprint Retrospectives on the wall in a public area as a reminder to everyone what they should be focusing on improving each day.
There are many other techniques for conducting parts or the whole of the Sprint Retrospective. The names of many techniques are listed below and each is worthy of detailed discussion. All of the following are well documented online and in various publications.
Techniques for Sprint Retrospectives
A fishbowl conversation is a form of dialog that can be used when discussing topics within large groups. Fishbowl conversations are usually used in participatory events like Open Space Technology and Unconferences. The advantage of Fishbowl is that it allows the entire group to participate in a conversation. Several people can join the discussion.Four to five chairs are arranged in an inner circle. This is the fishbowl. The remaining chairs are arranged in concentric circles outside the fishbowl. A few participants are selected to fill the fishbowl, while the rest of the group sit on the chairs outside the fishbowl. In an open fishbowl, one chair is left empty. In a closed fishbowl, all chairs are filled. The moderator introduces the topic and the participants start discussing the topic. The audience outside the fishbowl listen in on the discussion.In an open fishbowl, any member of the audience can, at any time, occupy the empty chair and join the fishbowl. When this happens, an existing member of the fishbowl must voluntarily leave the fishbowl and free a chair. The discussion continues with participants frequently entering and leaving the fishbowl.
Depending on how large your audience is you can have many audience members spend some time in the fishbowl and take part in the discussion. When time runs out, the fishbowl is closed and the moderator summarizes the discussion.An immediate variation of this is to have only two chairs in the central group. When someone in the audience wants to join the two-way conversation, they come forward and tap the shoulder of the person they want to replace, at some point when they are not talking. The tapped speaker must then return to the outer circles, being replaced by the new speaker, who carries on the conversation in their place.In a closed fishbowl, the initial participants speak for some time. When time runs out, they leave the fishbowl and a new group from the audience enters the fishbowl. This continues until many audience members have spent some time in the fishbowl. Once the final group has concluded, the moderator closes the fishbowl and summarizes the discussion
Mad Sad Glad
- Divide the board into three areas labelled:
- Mad – frustrations, things that have annoyed the team and/or have wasted a lot of time
- Sad – disappointments, things that have not worked out as well as was hoped
- Glad – pleasures, things that have made the team happy
- Explain the meanings of the headings to the team and encourage them to place stickies with their ideas for each of them under each heading
- Wait until everyone has posted all of their ideas
- Have the team group similar ideas together
- Discuss each grouping as a team identifying any corrective actions
- Draw a large circle on a whiteboard and divide it into five equal segments
- Label each segment ‘Start’, ‘Stop’, ‘Keep Doing’, ‘More Of’, ‘Less Of’
- For each segment pose the following questions to the team:
- What can we start doing that will speed the team’s progress?
- What can we stop doing that hinders the team’s progress?
- What can we keep doing to do that is currently helping the team’s progress?
- What is currently aiding the team’s progress and we can do more of?
- What is currently impeding the team’s progress and we can do less of?
- Encourage the team to place stickies with ideas in each segment until everyone has posted all of their ideas
- Erase the wheel and have the team group similar ideas together. Note that the same idea may have been expressed in opposite segments but these should still be grouped together
- Discuss each grouping as a team including any corrective actions
A great technique to solve some of these is to use a problem solving tree. What you need is some post it notes, markers and a large wall or whiteboard.
- Start with an problem you need to solve, that you’ve identified in the retrospective.
- Write this on a sticky note, and stick it at the top of the tree.
- Now ask what participants what you can do to solve the problem.
- For each different idea put a sticky note below the first, at the same level.
- For each of these nodes do the same and build up a tree structure similar to an organisation chart.
- For each idea you put up, ask if it can be done in a single sprint, and if everyone understands what they need to do. If the answer is no, break it down smaller and make another level in the problem solving tree.
- Once you have some lower levels that are well understood and easy to implement in a single sprint, dot vote to see which to tackle in the next sprint. Try to only pick one and get it done, rather than lots that go nowhere.
- Draw a boat on a white board. Include the following details:
- Sails or engines – these represent the things that are pushing the team forward towards their goals
- Anchors – these represent the things that are impeding the team from reaching their goals
- Explain the metaphors to the team and encourage them to place stickies with their ideas for each of them on appropriate area of the drawing
- Wait until everyone has posted all of their ideas
- Have the team group similar ideas together
- Discuss each grouping as a team including any corrective actions going forward
Expose the most pressing issues in an initially anonymous manner and determine the most effective actions to resolve them.
Length of time:
Approximately 45 minutes depending on the size of the team.
The facilitator asks participants to bring along their top five issues which are then grouped and in pairs the participants create actions to resolve them them before voting on the top actions which are taken away.
Whiteboard or flipchart paper & pens.
- Before the retrospective provide participants with a simple Word document template and ask them to identify their top 5 issues (one per template) and for each issue suggest as many solutions as possible. The template is to ensure participants can be as anonymous as possible.
- Collect all the print-outs, spread them on the table and ask the team to group relevant issues.
- Ask for a title for each group, create a column for each one on a whiteboard (or flip chart sheets stuck to the wall) and place the associated print outs on the floor below.
- Get participants to form pairs (preferably with someone they don’t normally work too closely with) and give them three minutes with each column to come up with as many actions as they can and to write them in the column. Pairs are able to refer to the print outs and previous pairs’ actions for inspiration.
- After three minutes pairs move on to another column until all are exhausted.
- Go through all the actions so all participants are aware of them all.
- Give each participant three votes and ask them to choose their favourite actions (can use votes however they wish e.g. 3 on one action).
- Identify the most popular actions and ask for volunteers to own them. Make it clear it will be their responsibility to ensure they get completed before the next retrospective (tip: don’t choose too many actions and definitely no more than one action per participant).
- As with all retrospective output Agilists find the best way to ensure they get actioned is to stick them up on the wall somewhere everyone can see.
- Journey Lines
- 6 Thinking Hats
- Appreciative Retrospective
- Top 5
- Plan of action
- Race Car
- The Abyss
- The Perfection Game
- The Improvement Game
- Force Field Analysis
- Four L’s
- World Café
- Emotional Seismograph
Two particularly rich resources for facilitators looking to expand their retrospective toolboxes are:
- The website http://agileretrospectivewiki.org.
- The book Agile Retrospectives: Making Good Teams Great by Ester Derby and Diana Larson.
Sprint Retrospectives aren’t the Scrum Master’s playground. Newly minted Scrum Masters are sometimes tempted to vary the techniques wildly from Sprint to Sprint. While variety in retrospectives prevents teams falling into a rut, tempering this with some consistency will yield the best results. Teams focusing on actionable outcomes will see the most value from their retrospectives.
Why Retrospectives Dont Work
- Considering the retrospective a “post-mortem” or “after-action” report rather than an opportunity to plan for improvement
- Unengaged attendees
- Critiquing a single person’s performance
- No resulting actionable commitments
- Having no “what we did well” answers; teams need to understand and appreciate their positive as well as negative behaviors and practices
In all of the above situations, it is often easy to trace the root cause of the negativity to a lack of trust and commitment on the part of one or more team members. While there is no silver bullet to address this, Scrum specifically charges the Scrum Master with working toward addressing situations like these.
Although Sprint Retrospectives are powerful and valuable events, they are a commonly discarded element of Scrum. Scrum Teams with recent and regular success tend to rationalize away the need to conduct Sprint Retrospectives. This is rather like a fit person deciding to stop exercising.
Scrum Teams reaching that most tenuous state of high performance are rare, beautiful, and fragile. Meaningful retrospectives are a significant ingredient in keeping those teams functioning at such high levels. Reflecting upon itself allows the team to self-adjust and achieve even higher levels of performance and product quality. This is the very essence of Kaizen, and core to any real program of improvement.
When retrospectives work, the results are palpable. There is an excitement in the team to try new things. When retrospectives work, these things will inevitable be true:
- The team achieves measurably higher and higher levels of quality over time
- Individuals understand their role within the context of the team
- Actionable commitments are known by all team members
Finally, when Sprint Retrospectives work well, the team grows more focused, productive, and valuable to the organization. Excellent software development teams do not simply appear. They emerge over time and then only by deliberate attention to improvement. Sprint Retrospectives are a key ingredient in that emergence.
- A retrospective is intended to reveal facts or feelings which have measurable effects on the team’s performance, and to construct ideas for improvement based on these observations. It will not be useful if it devolves into a verbal joust, or a whining session.
- On the other hand, an effective retrospective requires that each participant feel comfortable speaking up. The facilitator is responsible for creating the conditions of mutual trust; this may require taking into accounts such factors as hierarchical relationships, the presence of a manager for instance may inhibit discussion of performance issues.
- Being an all-hands meeting, a retrospective comes at a significant cost in person-hours. Poor execution, either from the usual causes of bad meetings (lack of preparation, tardiness, inattention) or from causes specific to this format (lack of trust and safety, taboo topics), will result in the practice being discredited, even though a vast majority of the Agile community views it as valuable.
- An effective retrospective will normally result in decisions, leading to action items; it’s a mistake to have too few (there is always room for improvement) or too many (it would be impractical to address “all” issues in the next iteration). One or two improvement ideas per iteration retrospective may well be enough.
- Identical issues coming up at each retrospective, without measurable improvement over time, may signal that the retrospective has become an empty ritual.
Once a project has been underway for some time, or at the end of the project (in that case, especially when the team is likely to work together again), all of the team’s permanent members (not just the developers) invests from one to three days in a detailed analysis of the project’s significant events.