Sprint Retrospective Techniques Roundup

Over the last three years I have written a number of posts detailing various Sprint Retrospective techniques. Each technique’s writeup describes what it is good for, the steps to run it and includes pictures of real sessions. This post represents a roundup of all of the techniques I have written about with links to the original posts.

 

• The Wheel/Starfish
• Sailboat
• Mad Sad Glad
• The Cool Wall
• Lean Coffee
• Questions Retrospective
• 4Ls
• Satisfaction Histograms
• Circles
• Quartering
• Managing Retrospective Actions

Enjoy.

Sprint Retrospective Techniques 3

This post presents three more sprint retrospective techniques to add to the six I have already detailed in my previous posts Sprint Retrospective Techniques 1 and Sprint Retrospectives 2. Why present three more techniques? Surely six is enough to drive continuous improvement in any team? First of all I have found these techniques to be useful additions to my arsenal for reasons I outline below. Secondly variation is one of the keys to maintaining the effectiveness of a team’s retrospectives and more techniques makes for more variety.

Technique 1 – 4Ls

The 4Ls is shorthand for the following:

• What was Liked? What were the things that the team really appreciated about the sprint?
• What was Learned? What were things that the team learned that they did not know before the sprint?
• What Lacked? What were the things that the team think could have done better in the sprint?
• What was Longed For? What were the things the team desired or wished for but were not present during the sprint?

A 4Ls retrospective can be run by following these steps:

• Create a poster for each of the Ls and stick them up on the wall (easel paper is good for this purpose but drawing sections on a whiteboard is a good alternative).
• Explain the meaning of each of the Ls to the team.

Click to Enlarge

• Hand out sticky notes and markers to the team.
• Encourage the team to place stickies with ideas onto each relevant poster and wait until everyone has posted all of their ideas.

Click to Enlarge

• Have the team group similar ideas together on each poster.

Click to Enlarge

• Discuss each grouping as a team and note any corrective actions.

Click to Enlarge

The reason I like using the 4Ls is that it has the potential to cover a wide range of topics in a compact session. It addresses both the positive and negative aspects of the sprint (Liked and Lacked) but also specifically calls out the teams growing experience (Learned) and problematic gaps that can filled (Longed For).

Technique 2 – Satisfaction Histograms

There are many variations of the Satisfaction Histogram. I came across the version outlined here when a team member on a project I was a Scrum Master on offered to run a couple of retrospective sessions. This is how he ran one of the sessions and it turned out to be very effective.

• As preparation pick around four topics that you want to gauge the teams satisfaction of. These can be practices, behaviors or anything else you can think of.
• For example: Testing practices, Keeping a clean build, Standup effectiveness, Accuracy of estimates, etc.
• Draw a satisfaction histogram for each of the topics on a whiteboard. Label the x-axis 1-5 for each and add the topic name as a heading.

Click to Enlarge

• Explain the meaning behind each of the topics  to the team.
• Explain the meanings of the 1-5 scale to the team. For example, for “Our Team Communication is…”
  • 1 – “…disastrous, is actively impeding the team”
  • 2 – “…bad, not being done effectively”
  • 3 – “…satisfactory, requires improvement”
  • 4 – “…mostly very good, could still be improved further in small ways”
  • 5 – “…awesome, little or no room for improvement”
• Distribute sticky notes to the team, one per topic.
• Invite the team to place one sticky note in each topic’s histogram to grade how satisfied they are with the team’s performance for that topic. Sticky notes placed on the same topic and number are stacked.
• Wait until everyone has placed their stickies.

Click to Enlarge

• Discuss the results for each topic in turn. Where there is low satisfaction or a wide-spread of satisfaction grades dig into why this is.
• As potential corrective actions are identified by the team, especially for topics with mostly low numbers, note them down.

Click to Enlarge

This version of Satisfaction Histogram has a number of advantages. First of all the selection of topics means that it can be targeted to certain problem areas. Note that the technique can also be varied to allow the team to suggest topics. This can be done by leaving one histogram blank for the team to suggest the topic during the session. As the team becomes more familiar with the technique you can allow them to suggest all of the topics to be scored for satisfaction.

Secondly it is very visual. At a glance everyone can see the topics where the team is satisfied, dissatisfied or in disagreement. This allows the team to focus on the topics where they belive they are most lacking or conflicted about.

Technique 3 – Circles

Circles is more commonly known as Circles and Soup. I dislike the “Soup” metaphor so I refer to the technique simply as Circles. In addition when I run this technique I replace “Soup” with “Concern”. I understand that the technique is based on Stephen Covey’s book Seven Habits of Highly Effective People.

The idea behind circles is to get the team to focus their energies on what they can change and not to waste time worrying about what they cannot affect.

A Circles retrospective can be run by following these steps:

• Define what an impediment is to the team:
  • “An impediment is anything that prevents you or the team from delivering work as efficiently as possible. An impediment is anything that blocks you working or slows you down.”
• Distribute sticky notes and markers to the team.
• Ask the team to write down all of the impediments encountered in the sprint, one per sticky note, and have them post them onto a whiteboard.
• Wait until everyone has posted all of their impediment ideas.

Click to Enlarge

• Ask the team to identify and remove any duplicate impediment stickies.

Click to Enlarge

• Draw three concentric circles on the whiteboard and label them, from the inside out, “Control”, “Influence” and “Concern”.

Click to Enlarge

• Define what each of the circles means to the team:
  • Control – Impediments for which the team can take action to remediate.
  • Influence – Impediments for which the team can collaborate with or make a recommendation to an outside entity to remediate. For example, another team, group or line management.
  • Concern – Impediments over which the team has no ability to Control or Influence.
• Invite the team to collaboratively place each of the impediments in the appropriate circle.
• Encourage and guide any debate as to what should go where. 
• Wait until all of the impediments have been placed in one of the circles.

Click to Enlarge

• Go through each Control impediment one at a time and have the team:
  • Gain an understanding of what each impediment is.
  • Identify remedial actions that are within the team’s control and write these on the whiteboard.
• Go through each Influence impediment one at a time and have the team:
  • Gain an understanding of what each impediment is.
  • Identify contacts and recommendations to influence their remediation and write these on the whiteboard.
• Review the Concern impediments to gain an understanding of what they are.
• Note that as the impediments are discussed the team may identify actions that had not previously occurred to them.  This can cause the impediments to move inward. For example an impediment that was initially placed in Concern may move to Influence or Control.

Click to Enlarge

Circles is my new favourite technique but I use it sparingly. The reason I try not to overuse it is because it focuses very much on impediments and does not have the “celebration of success” aspect that is built into most other retrospective techniques. However, it is a powerful technique for sprint retrospectives as well as for other purposes. It is, for example, ideally suited to holding retrospectives into releases especially those that proved to be problematic.

Sprint Retrospective Techniques 2

A year ago I published a post on Sprint Retrospective Techniques that I employ to help my team to continuously improve. Since then I have tried out many other techniques to keep things fresh for the team. In this post I present three more simple techniques I have found to be especially effective.

Technique 1 – The Cool Wall

The Cool Wall is my favourite retrospective technique at the moment as it is not only very effective but also a lot of fun. I discovered it while browsing blog posts on the web looking for new retrospective techniques to try out.  I am a fan of the UK motoring show Top Gear and this technique is based on an occasional segment from the show, “The Cool Wall“.

In the show the presenters Jeremy Clarkson and Richard Hammond decide how cool various cars are by placing pictures of them in various categories labelled: “Seriously Uncool”, “Uncool”, “Cool”, and “Sub Zero”. The show involves audience participation but ultimately the presenters (especially Clarkson) decide how cool each car is (usually overriding the audience).

For the retrospective version of The Cool Wall the cars are replaced by cards that represent positive practices or behaviours that the team engage in. For example, ‘Continuous Improvement’, ‘TDD’, ‘Listening to Customer Feedback’, etc.

The Scrum Master plays the part of the presenter while the team take on the role of the studio audience. For each card the Scrum Master asks the team:

“How cool are we at…<thing written on card>”

The better the team decides they are at the thing written on the card the cooler the category they agree to place it in. The Scrum Master then places the card on the board in the agreed “coolness category”. The most important difference between the retro technique and the TV show (and the reason it works as a retro technique as opposed to as entertainment) is that the audience/team decide on “coolness” not the presenter/Scrum Master.

The technique requires a little preparation. Beforehand the Scrum Master should prepare the behaviour/practice cards. The content should be topical to the particular team and their current circumstances. I also create small voting cards for each “coolness” category to allow the team to efficiently vote rather through the yelling and shouting that happens in the TV show. This also prevents the team from aligning themselves with the first vote that is shouted out.

Click to Enlarge

The next step is to draw the cool wall on a large whiteboard complete with the headings  “Seriously Uncool”, “Uncool”, “Cool”, and “Sub Zero”:

Click to Enlarge

The session proper can now begin. The Scrum Master produces each card in turn and asks the team how cool they think they are at what is written on it. The team use their voting cards to display their choice. If there are wildly differing opinions on “coolness” then discussion can ensue until some consensus is reached. At this point the Scrum Master places the card on the board in the appropriate “coolness” category and moves onto the next card. Just like in the show it is permissible to place a card between two categories where agreement cannot be reached. This voting and discussion process proceeds until all cards have been placed on the Cool wall:

Click to Enlarge

With all of the cards on the board it is time to move onto the next step. One card at a time the team discuss the things they are “Seriously Uncool” and “Uncool” at doing and identify corrective actions to improve their “coolness” at doing the thing on the card. I tend to write the key points of the discussion and any corrective actions onto the board as we go for future reference:

Click to Enlarge

Technique 2 – Lean Coffee

I have written about Lean Coffee before in reference to the  Lean Agile Glasgow meetups. Lean Coffee is a great technique for democratising meetings which is also suitable for retrospectives. The democracy comes from the team providing the topics and prioritising them for discussion.

While I allow an hour for most retrospective sessions I run I find that a Lean Coffee retrospective session requires up to two hours for a full discussion of the most important topics to take place. It is also the only type of retrospective that I run with the team sitting down as it does not require the use of a board.

The session follows this format:

1. Everyone takes a few minutes to write up one or more stickies with topics they would like the team to discuss in the retrospective.
2. Go through the stickies one by one with the author briefly explaining their question or topic (one minute should suffice for each).
3. Everyone dot votes on the topics they most want to discuss. Each attendee gets three votes to spend – they can put multiple votes on any one topic and can vote for their own topics if they so wish.
4. A Personal Kanban is created with three columns: To Do, In Progress, Done. The In Progress column is WIP limited to 1. Stickies are used to create the headings (see picture below).
5. All topics are placed under the To Do column in priority order according to the number of votes they have received.
6. The top topic is moved from To Do to In Progress.
7. A 15 minute discussion ensues around the topic. A smart phone is handy to do the timing. If discussion around the topic dries up before the 15 minutes are up then progression to the next step comes early. Any corrective actions that are raised during the discussion should be noted down for agreement at the end of the session.
8. The topic is moved to the Done column and the next To Do topic is moved to In Progress.
9. Repeat from step 6 until the session time or topics are exhausted.

Click to Enlarge

Technique 3 – Questions Retrospective

The final technique is the Questions Retrospective. The format involves posing a series of question to the team about how things have gone from their perspective. For example, here are some questions which I have gleaned from various sources and that I think make for a good generalised set:

• What Worked Well?
• What Should We Do Differently Next Time?
• What Did We Learn?
• What Don’t We Understand That Needs To Be Clarified for Future?
• What Made You Mad?
• What Made You Laugh?

You can target specific topics by introducing specific questions to address them, for example, to explore an event, good or bad, that has occurred in the preceding sprint.

Note that while this technique works well for sprint retrospectives I find it to be especially powerful for project retrospectives where a longer period of time is being considered. All of the pictures below were from a recent project retrospective I ran hence the sheer number of answers that were given.

In preparation for the session I send out the questions to the team in advance to encourage as much feedback as possible. In the case of a project retrospective I do this several weeks in advance. I also encourage the team to bring any answers they have pre-written on stickies so that ideas they have before the session are not lost and to speed the session up a bit.

Immediately before the session starts I write all of the questions onto a large white board:

Click to Enlarge

When the team members have all arrived the session can proceed:

1. Explain the meaning of the questions to the team and provide any necessary clarifications so that everyone is on the same page
2. Encourage the team to place stickies with their answers under each question
3. Wait until everyone has posted all of their answers. Team members can post as many answers to each question as they like
4. Go through each question one at a time
5. Have the team group similar answers to the particular question together into common themes
6. Discuss each grouping one at a time identifying and recording any corrective actions

Click to Enlarge

You Can Never Have Too Many Techniques

Keeping retrospectives engaging, and therefore effective, requires constant work on the part of the Scrum Master. Having a static set of techniques, however tried and tested they may be, is not enough and we have to keep innovating. I find I have to constantly seek out new techniques to accomplish this. Fortunately Agile practitioners are a generous bunch and new techniques are constantly being published on their blogs.

I have not been taken with every technique I have read about or gone on to try out and frequently make my own small adaptations to those I do use to increase their effectiveness for my team’s particular circumstances. This amounts to quite a lot of work but the rewards in the form of continuous improvement are worth it.

Perhaps in another year’s time we’ll see the publication of Sprint Retrospective Techniques 3.

Managing Retrospective Actions

In my previous post on Sprint Retrospective Techniques I outlined several approaches teams can use to identify corrective actions to drive continuous improvement. However, I have learned from experience that identifying corrective actions in a retrospective is only part of the battle.

To ensure that the team get the full benefit from their proposed actions they must be appropriately managed. Without such management valuable corrective actions can get lost or unnecessarily delayed and the team can lose faith in the retrospective process. The end result can be a stalling of continuous improvement which is a disaster for an agile team. This post outlines a couple of measures I take to effectively Manage Retrospective Actions.

Agreeing the Actions

The starting point for retrospective action management is in the retrospective itself. If the session has been successful then at the end there will be a set of corrective actions that have been identified by one or more team members. The Scrum Master should go through each action in turn to confirm that the entire team agrees that it is valid. A valid action is one that will improve the team’s productivity without incurring undue cost. Reviewing the actions reinforces their importance and gets everyone in the team in agreement that they are worth implementing.

You may find that the team cannot agree on which actions are worth doing. If the debate hits an impasse then dot voting can be used to break the deadlock. Dot voting can also be useful if there are too many corrective actions for a team to handle. The team can use dot voting to prioritise the most important actions for short term implementation. Lower priority actions that the team does not have the bandwidth for can be dropped for now. Do not worry about losing them as, if they have value, they will crop up again in future retrospectives when they may be more viable for implemention.

Retrospective Actions Board

At this point I have seen teams create stories for each of their actions that then go into the product backlog. I don’t do this because the actions are not stories at all. They are instead things that the team can do to make the business of implementing stories quicker or easier. They can represent documentation, changes to process, improved tooling and so on. What they are not is functionality for the end user. They should not therefore be prioritised with stories.

However, the corrective actions need to go somewhere or they may be forgotten and never implemented. As I believe that retrospective actions are so important and their implementation can be so crucial to a project’s success I make them as visible as possible using a Retrospective Actions Board:

Click to Enlarge

A retrospective actions board is just like a physical task board except the cards on it hold the agreed retrospective actions rather than stories. Actions that have not been implemented reside in the To Do column, those in flight are in the In Progress column and those that the team have actioned sit in the Implemented column. As the unimplemented actions sit right in front of the team every day they cannot be forgotten. In addition everyone can see what actions have been done. This means that the team can see real progress towards their own continuous improvement.

It is one thing to make the actions visible but how do we ensure that they actually get picked up? It is up to the Scrum Master to reinforce the message that any team member can pick up a retrospective action for implementation. After all the team agreed on the actions because they all believed that the actions would make the business of implementing stories quicker, easier, simpler, would result in less bugs, etc. There is therefore nothing wrong with a team member improving the team’s ability to do work by implementing actions while at the same time others carrying that work out by implementing stories. Initially the Scrum Master may have to get involved to ensure that the balance between actions and stories remains optimal. Having a WIP limit on the In Progress column is one way of doing this. However, a self organising team will find a productive balance very quickly and such intervention will rarely be necessary.

Electronic Retrospective Actions Tracking

The Retrospective Actions board is a powerful information radiator for continuous improvement but it is not the whole story. In addition to the physical board I find it informative to keep an electronic history of the actions a team agrees. I do this because with a steady stream of implemented actions the Implemented column on the board will quickly fill up and need to be cleared down. The history of what the team has achieved is then lost. In addition the history can record meta data about actions such as when they are identified, when they were implemented. I call this Retrospective Actions Tracking and it is represented by a page in the team’s wiki:

Click to Enlarge

The tracking page is a permanent record of every retrospective action that has been agreed and its current state. The colour coding indicates actions that are waiting to be implemented (red) or have been implemented (green). I also record the sprint retrospective in which the action was agreed and the sprint in which it was actioned (if applicable). As you can see all of the team’s sprints are named after (good) beers. It is also interesting to record in sprints how long it takes the team to make good on the actions (Sprint Lag). If a successful team ever needs a reminder of the importance of retrospectives and of their progress towards improvement a quick review of this page will reassure them.

The tracking page is also useful for identifying actions that are not being carried out. If an actions sits unimplemented for many sprints after it has been agreed it is worth asking why. It could be that the action is blocked. A blocked action is no less an impediment to the success of the project than a blocked story and may require the Scrum Master’s intervention to facilitate its removal. Alternatively you may find that the action is simply obsolete and that the team no longer believes it its implementation to be worthwhile. In this case, and with the team’s agreement, the action can be removed from the tracking page and the physical actions board.

Action Post-Implementation

Finally it is important to come full circle at the next retrospective. The Scrum Master should review the Retrospective Actions Tracking page prior to the retrospective to see what actions have been implemented in the last sprint. They should use this information in the retrospective to celebrate the team’s continuous improvement success at the same time that completed stories are celebrated. This reinforces to the team that they are making good on the agreed actions just before they identify another set. This helps keep the flow of actions coming.

Summing Up

Retrospective actions can sometimes be neglected. I’ve done it myself with a previously held and incorrect belief that actions would just get done because they were obviously important. However, it is not as simple as that. The actions need to be thoroughly agreed, made visible, their completion actively encouraged and their successful implementation celebrated. Only with these steps in place can a team make the most of the great ideas they have in retrospectives.

DIY Sprint Retrospective Techniques

A few month’s ago I wrote about several Sprint Retrospective Techniques that I have found to be particularly effective. I noted that having several techniques in my arsenal allowed me to keep retrospective sessions fresh for my team. This has helped to ensure that we have a steady flow of corrective actions to aid us in our quest for continuous improvement. Since writing that post I have been rooting around on the web looking for other techniques to add to my tool kit.

One useful source for retrospective techniques I have found is the Agile Retrospective Resource Wiki. It lists more than a dozen retrospective techniques in varying levels of detail. While I have made use of several of the techniques listed in the wiki I have found that none of the remaining techniques fit with my team’s current requirements. Some strike me as being overly complex (simplicity is a major factor when it comes to an effective technique) while others are designed for a specific type of issue that we do not need to explore at this time. Rather than give up and stick with the same set of retrospective techniques I thought I would have a go at creating one of my own. This post describes my experience creating my first DIY Sprint Retrospective Technique.

I reckoned that creating a workable general purpose technique would be beyond me on my first attempt. By general purpose I mean that you can apply them to identify any kind of issue. Good examples of general purpose techniques are my favorite three techniques: The Wheel, The Sail Boat and Mad Sad Glad . However, special purpose techniques which aim to address a specific type of issue have their place. So I settled on creating a special purpose technique to address a particular problem my team was having.

The issue in question was boredom. My background as a software developer leads me to take this issue seriously because I know from experience that developers are usually creative individuals. They like to solve interesting problems and stretch their minds. While not every task can be interesting an overload of dull activities can demotivate a team of developers. Demotivation will slowly kill a team’s velocity and has to be addressed. Additionally boring tasks can be an indication of repetition and unnecessary work. Eliminating repetition through automation can improve  a team’s velocity.

I observed signs of boredom creeping in during the stand ups as expressed by the team in their use of language and in the tone they used when describing their progress. I decided to nip this in the bud by exploring the issue in the next retrospective using a new custom retrospective technique.

Click to Enlarge

For the new technique I drew inspiration from an unlikely source: a Dilbert book I owned more than a decade ago. It was a type of employee survival handbook written in the Dilbert style. I recalled that it contained a four square grid diagram that was used to describe different types of manager. I have recreated this from memory here but probably do not have the labels quite right.

Despite the obvious comedy around this example (you really don’t want your own boss to be in the smart/evil quadrant) the basic idea of the four square grid looked suitable for my needs. I modified it to my requirements and ran the retrospective as follows.

Step 1: First of all I drew a square on a white board and divided it horizontally into two halves. One half was labelled “Interesting” while the other was labelled “Dull”.

Click to Enlarge

Step 2: I asked the team to think about the things they had done over the sprint and write out a sticky for each. For each task they were to decide whether or not they had found the work to be dull or interesting and place the sticky in the appropriate half.

Click to Enlarge

Step 3: Once all of the tasks had been placed on the board I then asked the team to write the rough amount of time each task took on their own stickies. These values could be expressed in terms of hours or days and did not need to be exact. I then divided the square vertically into two further halves which I labelled Short and Long.  With this second split in place I asked the team to split the tasks into one time category or the other depending on how they had taken relative to each other. Tasks that took hours moved to the Short quadrants while those that took days migrated to the Long quadrants.

Click to Enlarge

Step 4: We now had four quadrants representing the following groupings of tasks: short interesting tasks, long interesting tasks, short dull tasks and long dull tasks. Of most interest from these is the long dull tasks. These represented the types of work which generated the most boredom for the team and perhaps the best opportunity for automation. We discussed each of the long and dull task stickies in turn and identified actions to shorten or eliminate them. While the main corrective actions fell out of this quadrant of the grid we also found it fruitful to have a discussion about the shorter dull tasks and the remaining work which was considered to be more interesting.

Click to Enlarge

All in all I think that the session went rather well. We identified several corrective actions for the longest boring tasks. When implemented these actions have the potential to make work more interesting for the team and eliminate waste effort in the project.

I could have run the session far more simply. I could instead have asked the team to share which tasks they had found to be large and dull. I could still have used the grid for this by drawing it in its finished form upfront and asking the team to place tasks in the dull and long quadrant.  However, I do not think that we would have benefited as much from this shortened approach. This is because it would have been much harder for team members to answer one big question with several dimensions than to follow the process outlined above. The technique answered the same big question by asking a series of simpler questions. The long running dull tasks simply emerge by following the steps.

Focussing on one question at a time is the key to why this technique works:

1. Of the tasks you did which were dull and which were interesting?
2. How long did each task take?
3. Which tasks took the shortest and longest time?

From these simple questions and the division of the grid the issues are automatically identified ready to be addressed.

With the success of the technique in identifying long-running dull tasks I gave some consideration to generalising the technique to identify other types of issues. It turns out that this be can achieved easily with only two variables: the subject written on the stickies and the labels used on the grid.

The type of subject used on the grid can be anything. For the above example it was tasks from the last sprint. It could just as easily be bugs, stories or support issues or anything else that the team routinely does in a sprint.

The grid labels can also change.  The above example uses interesting vs dull and short vs long. Some other examples are:

• Shorter v Longer (than estimated velocity)
• Missing v Complete (story requirements)
• Collaborative v Non-Collaborative (task execution)
• Simpler v More Complex (than planned)
• Planned v Unplanned (stories in sprint)
• Finished v Unfinished (stories in sprint)

Knowing what goes on the stickies and what labels to use on the grid is a matter of knowing what impediments a team is suffering from. This is a core skill for any effective Scrum Master.

Click to Enlarge

Here is another concrete example I intend to use for my team’s next retrospective. For this retrospective I want to identify where missing story requirements are hurting our velocity. I will run the same technique as before with a couple of modifications. The changes will be to have the team post up user stories they completed in the last sprint and to use shorter v longer (than estimate) for the x-axis and missing v complete (requirements) for the y-axis. Any stories that wind up in the bottom-right grid (longer than estimated stories with missing requirements) may be instances where missing requirements are impeding us to a large degree. Corrective actions identified here may help us eliminate the issue in future.

Despite my coming up with this technique independently I doubt it is entirely original. However, I feel I have to give it a name anyway. The name I have chosen is Quartering. I think this is quite descriptive as that is exactly how the technique operates. The team’s activities in the last sprint are split into four quarters to reveal which may have been executed less than optimally.

The main lesson I have learned from this whole exercise is that I do not need to rely on others to come up with useful, general-purpose retrospective techniques. Anyone can do it themselves with a little imagination and a minimal amount of effort. There is no excuse not to continually change retrospective approaches when you can invent your own. This is especially true if people publish their own working ideas as is the case with the Agile Retrospective Resource Wiki.

On that note, if you think that Quartering may be of some use within your own retrospectives then please feel free to use it. I would be interested to hear about your experiences with it and any of your own DIY Sprint Retrospective Techniques.

Sprint Retrospective Techniques

Note: since writing this post I have come up with a new sprint retrospective technique called Quartering.

Note 2: you can find even more simple and effective sprint retrospective techniques in my follow up posts Sprint Retrospective Techniques 2 & Sprint Retropective Techniques 3.

When interviewing prospective Scrum Masters there are a number of questions I ask them about their retrospectives. First of all I ask if they hold retrospectives with their team after each sprint. I then ask how they run their retrospectives. Finally I ask if they vary how they run their retrospectives. The answers to these questions are one gauge I use to measure the the candidate Scrum Master’s level of experience. I focus so much on retrospectives because how they are run is crucial if a Scrum team is to function efficiently.

Holding retrospectives is vital to Scrum teams who are looking to continuously improve (and a Scrum team that is not looking to continuously improve isn’t worthy of being called a Scrum team). Holding retrospectives after every sprint is a must if a team is to maintain its pace of improvement. Having a technique for running retrospectives is important for imposing a structure on the team’s discussion. However, having many varied techniques is essential to keep the exercise interesting for the team and to prevent great ideas for improvements from drying up. Retrospectives that become staid are little better than not holding them at all.

I have encountered several retrospective techniques over my time as a Scrum Master. Here are three simple techniques which I find work well.

(each technique requires the following resources: whiteboard, white board markers and stickies/post-it notes).

Technique 1 – The Wheel (also known as the Starfish)

1. Draw a large circle on a whiteboard and divide it into five equal segments
2. Label each segment ‘Start’, ‘Stop’, ‘Keep Doing’, ‘More Of’, ‘Less Of’
3. 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?
4. Encourage the team to place stickies with ideas in each segment until everyone has posted all of their ideas
5. 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
6. Discuss each grouping as a team including any corrective actions

The steps are illustrated in the images below:

Click to Enlarge

Click to Enlarge

Click to Enlarge

Technique 2 – The Sail Boat (Or speed boat. Or any kind of boat)

1. 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
2. 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
3. Wait until everyone has posted all of their ideas
4. Have the team group similar ideas together
5. Discuss each grouping as a team including any corrective actions going forward

The pictures below show a couple of retrospective boats:

Click to Enlarge

Click to Enlarge

Technique 3 – Mad Sad Glad

1. 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
2. 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
3. Wait until everyone has posted all of their ideas
4. Have the team group similar ideas together
5. Discuss each grouping as a team identifying any corrective actions

The pictures below illustrate the technique:

Click to Enlarge

Click to Enlarge

What Are the Techniques Good For?

So that describes the process for each of the techniques. You probably noticed that the techniques are broadly similar. Each divides the whiteboard into areas for different categories of ideas. The team is then invited to place their ideas into each category. The team then groups similar ideas together. Finally the team goes through each grouping identifying corrective actions.

So why do I use these particular techniques? What is good about them? There are a few reasons.

I like all of these techniques because they are simple. They can be explained to a team very quickly. They require only basic materials. They can proceed from start to finish in well under an hour and you still end up with a good set of corrective actions.

All of the techniques encourage the entire team to participate. Each team member can place their own ideas on the board with equal weight. If instead ideas came forth via a discussion more vocal team members could take over while shyer team members would withdraw. Where there is no initial discussion this cannot happen and the team benefits from everyone’s input.

The grouping exercise is also key because the team members do it not the Scrum Master. They are again participating directly and putting their own stamp on the exercise by deciding which ideas are related. Also with the grouping in place corrective actions become easier to identify and prioritise. If, for example, there are double the number of stickies for one grouping as opposed to another then it is obvious to all that the first grouping probably represents the more pressing issue.

As the team is so involved in the retrospective from start to finish they get a justified feeling of ownership over the process and any corrective actions that are identified.

With these techniques the Scrum Master’s job is also easier. They have a structure for their retrospectives and do not have to do all of the work in the session. The Scrum Master simply keeps the process moving perhaps using improvisations. For example, when picking the next grouping to discuss they may ask the team to dot vote for the most important groupings or ask a team member to pick what is most important to them. Such minor changes are important to keep even varying retrospective techniques fresh.

Those are the similarities. It is important to note that there are also differences between the techniques. The differing categories between each technique are key. They lead to different types of ideas being raised as they each make teams think in a different way.

The Sail Boat, for example, is very simple. What is helping us? What isn’t helping us? However, you can elaborate on the process. I like to add rocks to represent risks that could ‘sink the project’. You could also add a sun to represent ideas for the team’s hopes.

The Wheel takes the core idea of the sail boat’s sails and anchors further. It not only asks what is making the team faster or slower but also goes into more granular detail about what the team should start/stop, do more of/less of or simply continue doing as before.

My personal favourite is Mad Sad Glad. The categories do not focus on the back and white of team productivity but instead look at the types of emotions the team experienced over the sprint. This can elicit some very interesting ideas. I especially like the distinction between Mad and Sad. Both are obviously negative but each can attract quite different issues from a team.

The Mad Sad Glad technique can also be extended. For example, I sometimes add a fourth category labelled ‘Scared‘ where the team can post the things that they fear. For instance, the team may fear that they will not make a crucial delivery.

So on the face of it the techniques are similar. However, they elicit different types of feedback and different corrective actions. They also inject a bit if fun into retrospectives. Finally with the application of many techniques retrospectives do not become boring affairs and the team’s ideas for improvements do not dry up.

So now that the team is armed with corrective actions what do they do with them? I will cover this topic in a future post.