How to remove recurring problems from your Retrospectives

I think the Sprint Retrospective is the most challenging event in Scrum. This event is for the whole Scrum team to inspect and adapt everything but the product itself.

The 2020 Scrum Guide acknowledges that applying Retrospective improvements is not always successful:

Many articles have been written about Retrospectives: How to make them efficient, valuable and positive. This event is very challenging because it has to deal with very difficult problems. The value of Retrospectives should be measured by the success of the improvements it delivers: Has the quality level gone up? Did the team become faster or more flexible? Did the team gain a better understanding of their challenges? In reality, Retrospectives usually become shallow and deliver less valuable outcomes.

Even if good improvements are discovered, the challenge remains to actually apply the improvements. Being disciplined enough to follow up the improvements is largely controllable by the team. The Scrum Master should be able to help the team to make it happen.

Good results from your own improvements give a positive boost. But the opposite is also true. A team that fails to improve or faces recurring intangible problems loses hope, can become depressed and indifferent. Recurring problems drain energy because they appear to be unsolvable.  

I have worked with many teams that did pretty good Scrum but due to recurring problems, they lost faith and became cynical.  Recently, a developer pointed out he was sick of seeing the same test data problem on the Retrospective canvas and proposed to never discuss it again “because it cannot be solved anyway”. He applied the “spheres of control” by S.Covey and was ready to accept the shortcomings of the development system. So much for inspection and adaptation.

Recurring problems emerge as a result of system dynamics. The root causes for these problems are not in the team, they are outside the team and outside the span of control of the team. (If not, your team has difficulty solving problems for which they are the cause. Solving those is not the scope of this article). However, the team is part of the problem. They are a part of the development system where the problems surface. But whatever the team undertakes at their level, they will never be able to sustainably fix the problem. That’s because the team’s improvements (interventions in the system) are not changing the overall emergent behaviour of the system. Sometimes there is a short term positive effect, but the problems resurface later in time. This is a source of frustration.

Let’s assume the Product Owner brings to the table that the team never finishes all the work in the Sprint. The Product Owner wants to improve this to make the team more predictable. During the Retrospective, the team discovers that many unfinished user stories contain a task that is assigned to the Content Management Team (the CMS team). In previous Sprints, the Product Owner has set up numerous discussions and meetings with the CMS team’s PO. There is close collaboration: during refinements, our team anticipates CMS work and creates Jira tickets for the CMS team. However, the CMS PO needs to prioritise the CMS-work coming in from many other teams and sometimes can or can’t finish the work within the next Sprint: There is a dependency on our team on the CMS team. This dependency causes our team to be unable to forecast reliably. And we are in no position to change that. Every solution we agree upon will be sub-optimal as long as we stick to the concept that the CMS responsibilities remain external to our team.

Since systemic problems have causes outside our team, we need to also take them outside the team for solving them. LeSS offers an event additional to Scrum called the Overall Retrospective. This event is for all Scrum teams sharing the same Product Goal and work in the same Sprint Rhythm. We need the team Retrospectives to finish first. They will deliver the input for the Overall Retrospective are the systemic problems that teams cannot solve within their team. Usually this event is held early in the first week of the new Sprint. The participants are the Product Owners of all involved Scrum Teams, developers representing their teams and management. The power of this meeting lies in the fact that management participates. They have the mandate to take decisions at a level that will fix the systemic problems permanently. But we don’t want this event to become a management meeting. That’s why some (but not all) developers participate to provide context and details. Not having developers participating in the event will reduce its effectiveness.

To solve the CMS-problem from the example above, the CMS capabilities need to be added to our team. This is a systemic change that breaks with the organizational rule that Scrum teams are responsible for a specific component (in this case the CMS component). It will require the CMS team to allow other teams to do ”their” work. This is a difficult change that requires management support and expert coaching. It might be that management does not agree to hand off CMS permissions. They might suggest a much milder solution, which is also good but not ideal. At least the problem now is transparent, an experiment is agreed upon and results can be monitored and discussed in the next Overall Retrospective.

How to introduce the Overall Retrospective in your company?

My experience is that there are too many meetings already. Proposing to add another meeting to the PO’s and manager’s agendas is a no-go. I have been more successful in repurposing existing meetings. I (Scrum Master), ask PO’s and managers what recurring meetings they attend during the Sprint that are not Scrum events. There probably will be some leadership team meeting, a Scrum of Scrums or a PO-sync. Roughly follow these steps to add the Overall Retrospective to your Scrum:

• Ask if it is OK to join existing non-Scrum meetings.
• Observe what is discussed and choose the meeting that looks most like an Overall Retrospective.
• Change what is needed such as inviting developers, adding a top-level manager and agree to focus on cross-team problems.
• If there is an impediment list, make that list official and transparent.
• Feed the impediment list with the systemic problems discovered by the teams.
• Agree that management owns the impediment list and that the goal of the Overall Retrospective is to solve all issues on the list.
• Report progress in the Sprint Review.
• Rename the meeting to be the Overall Retrospective.
• Schedule it in your Sprint cadence right in the beginning of the new Sprint.
• Clarify its purpose to all teams.
• Have a Scrum Master facilitate the event.

The Overall Retrospective gives the teams the prospect of an official event to address recurring problems. The Overall Retrospective closes the feedback loop for organisational learning.