Agile retrospectives help teams to find and do actions to improve continuously. There are different ways to do follow up on the actions and to evaluate if actions are leading to better team performance and more value delivered to customers.
In the blog post retrospective values Lonnie Weaver-Johnson explores the reasons why teams cancel retrospectives and provides tips to get the most from doing retrospectives. One of the reasons for cancellation is that actions coming out of a retrospective are not done:
Another common reason for skipping is there is no follow through. Teams have not seen any change result from their discussions so they quit having them. After all, how many times has your HR department put out a company survey and then never shared the results or worse yet, never acted on them. People don’t want to spend time providing information that won’t result in something.
Lonnie provides some tips to assure that actions are being done:
If ScrumMasters expect people to give their time and open up, we better demonstrate action. Walk away with a small number of action items after the team has prioritized which items should be corrected first. Summarize the list at the close of the Retrospective including who is working on what. Then, ScrumMasters should bring those items up a few times at the end of the next Sprint’s Daily meetings. The ScrumMaster should ask questions about progress being made on the Retrospective items and also report on the items that were assigned to him/her at the end of the Daily meeting.
Corinna Baldauf wrote the blog post retrospective fatigue? how to increase follow-through on action items. She explains why having actions from retrospectives done is important:
The whole point is to inspect and adapt, i.e. to change something. If few of the retrospectives’ action items ever get implemented and bear fruit it’s frustrating. Ultimately it leads to retrospective fatigue where teams are unwilling to participate in the retro anymore, because “What’s the point anyway? Nothing ever changes!”
In her blog she described several possible reasons why retrospectives are not resulting in actions that are done. One of them is reluctance by people who need to take action. Corrina provides some ideas on how to address this:
In some cases, tasks are “forgotten” on purpose, because the responsible person is hesitant to do it. This is rampant with confrontational tasks such as “Talk to Team Brony about how their late code pushes harm our deployment and testing schedule”. Those are often conveniently forgotten. This might help:
- Deadline – less room for “I’ll do it tomorrow”. Ideally create a calendar entry.
- Can someone else take over or accompany?
- Talk through the confrontation beforehand and how to handle crucial confrontations
- Premium solution: Have a company-wide training in communication
Well, are you happy with your progress? Or is there a “waste of time”-feeling in the air?
If so, start writing down the action items and review them daily or in the next retrospective. A Try-Keep-Board (see image in section C) is a good place to start.
In the blog post create tangible retrospective actions Chris Smith describes how actions from retrospectives can be used to change course in a project when needed:
Retrospectives are only as valuable as the improvements they instigate. Sometimes, even though a team may have identified the right area of their project/process/codebase to improve, the corrective actions they decide on may fail to have a discernible effect. For example, a team may want to introduce a weekly customer support rota because the entire group is feeling impeded by the number of support requests being received. This rota is drawn up and is respected for the first week, so things start to seem better. Beyond that first week though, there’s a good chance the rota will start to get forgotten and the problem will return.
It can help to introduce an artifact to make a retrospective action tangible and follow up if it is done as Chris explains:
(…) the support rota is much more likely to become entrenched if there is a visual token reminding people every day that it exists and is something they agreed to do. In my team we’ve done this by placing a big picture of an ogre on the desk of the person on rota duty. When a support request comes in, there is no debate about who’s responsibility it is to ensure the request is handled.
How can we know if the actions coming out of retrospective have introduced valuable changes? Matt Wrye wrote a blog post agile retrospectives = reflection in which he describes the learning cycle from agile and lean:
One of the principles of lean that I have learned is create a learning organization through Learn-Apply-Reflect. This principle helps drive home the importance of reflection. Many people and organizations do a great job of learning something new and then trying to apply it. Where most people and organizations fail is forgetting to reflect. The reflection step is where all the learning and applying comes together to understand how what was learned can best be applied in the organization. What worked? What didn’t work? What should be kept? What should be changed?
Reflecting on the results from retrospective actions helps team to fine tune their way for doing continuous improvement using retrospectives:
Agile uses planned retrospectives, usually once a week, to take a time out and gather the team to understand what is working and they should continue doing. As well as what is not working and should be changed or thrown out.
The agile team takes the learnings from the week, apply them and then have a planned reflection time a week later. The agile methodology does a great job of fostering the principle of creating a learning organization.
Mohit Jain described in introspect the retrospective how a team can measure their performance and get insight into the impact of retrospective actions:
In order to avoid subjective or qualitative remarks, I suggest teams to go for a rating system wherein they give a score between 1 (lowest) and 10 (highest). At the end of this poll, your team would have a scorecard for its sprint, where it's easy to find out the best- and the worst-performing areas.
After a team agrees upon the weak areas they can use retrospectives to find improvement actions. By frequently measuring their performance they can see if retrospective actions are helping them to improve:
The score may give your team a structured approach to meet and discuss; however, as a ScrumMaster, it is equally important for you to regularly monitor the value being derived from these meetings. For this, I recommend you maintain a trend report comparing the scores from all your sprints.
By analyzing the progress tracked on the scorecard over several sprints, you should be able to identify:
- Valleys: Issues that have consistently been scoring low or have been in a downward trend.
- Plateaus: Issues that have stabilized over time but not yet reached the "green zone." This may indicate a move toward stagnation or indifference brewing in your team.
- Peaks: Aspects of your team that have continually improved over time, or have sustained themselves in the "green zone" for a considerable time.
How do you do follow up on your retrospective actions?