The power of a retrospective to improve a team’s ability to deliver business value is hard to deny. Given the demonstrable power of the technique, why does it occasionally fail to live up to expectations? Three (ish) primary issues that affect the value of retrospectives are ritualization, lack of follow through and management interventions. These issues can cause the team or organization to enter a downward spiral of disillusionment that will inevitably end with the abandonment of the technique.
The ritualization of retrospectives occurs when the process becomes more important (or at least as important) as the results. There are numerous reasons for this issue, but we’ll tackle two here: overcommitted teams who don’t have time to reflect and boredom (wake me up when it’s over). Teams that are so overburdened and can’t find a mechanism to get un-overburdened will always stay that way (a Catch 22). The ritual of the retrospective will usually be fulfilled so that they team can start planning the next sprint or iteration. In essence, they need to check the process box so they move to the next step. The Scrum Master or coach needs to help the team address the root cause of the problem, whether that is team-driven over-commitment (taking too much work) to being told to take too much by management. If a team is in an over-committed position more than occasionally, the Scrum Master may be part of the problem. That means that outside coaching is needed. If the root of the problem is technique boredom, the Scrum Master or another team member should learn another technique (such as timelines, the Sailboat, de Bono’s Thinking Hats or the 4 L’s). All Scrum Masters should know at least nine techniques for retrospectives.
Lack of Follow Through:
The worst mistake any team can make is to perform a retrospective then do nothing with the results. While the discussion itself may have been invigorating or cathartic, in the end the team wasted its time. Consider that if you held a two hour retrospective with a team of eight people and then did nothing with the results you would have cumulatively wasted two full days of effort that could have been used to deliver value to your organization. Every retrospective should identify at least one goal or idea for improvement. That goal should be added to the sprint backlog and addressed just any other piece of work that the team has committed to deliver. As soon as a team feels that their time is being wasted, they will begin looking for a reason to abandon retrospectives. Teams that fall into this pattern should seek external coaching support to get back on track.
Note there is a specialized example of the “lack of follow through” syndrome that occurs occasionally. Teams focus on issues in the retrospective that are outside of their ability to control. For example, I recently observed a team that was letting the fact that their office environment was noisy and that they could not have a dedicated team room consume them. The organization had grown substantially and was attempting to find additional office space, but the process was taking longer than the team liked. The Scrum Master should have helped them understand that there were other process improvements that could be made or alternate mechanisms for addressing the issue, rather than fixating on an issue they could not control. In the end, the team had a heart-to-heart discussion with the owner, which mollified the team (they did understand the status of the expansion plans). The team also received training on retrospectives and facilitation.
Retrospectives, are a team exercise. In a sprint retrospective the team is comprised of a Scrum Master (or coach), Product Owner and development team. No one else, with the exception of an occasional outside facilitator, should attend. As soon as managers or other outsiders begin attending the conversation will change to become more guarded and territorial. In my experience when outside observers are included, the goal often shifts from process improvement to position improvement. The Scrum Master must make every effort to police the team boundary and ensure the free flow of information within the retrospective.
The retrospective can’t become ritualized to the point that it lacks meaning. Each retrospective needs to provide a platform for the Agile team to reflect on their performance and to determine how they can achieve more. This is a team activity that requires a free flow of conversation and ideas in order to maximize effectiveness. That means someone needs to facilitate the process and police the boundary. No team is perfect and all teams can learn and improve on a continuous basis. Most obstacles to effective retrospectives are solvable with a bit of coaching and education if you recognize the obstacles before you abandon the technique.