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.

Explore posts in the same categories: Agile, Scrum

Tags: Agile, Retrospectives, Scrum

You can comment below, or link to this permanent URL from your own site.