What Scrum Lacks and the Misuse of Retrospectives

Banner image for the article

A sprint retrospective is supposed to be a time for self-reflection by a team; a timeboxed event in which the team can identify things they are doing well and not doing so well, things they could start doing and stop doing; it’s a time when they can find ways to improve individually and as a team.

In my experience very few retrospectives are focussed internally; instead most of them are focussed on the positives and negatives of external teams and the impact those external teams have on the team performing the retrospective. I know the Scrum Master is supposed to help remove the impediments and help coach the team to remove them, but if the Scrum Master is serving multiple teams, doesn’t feel empowered to act or doesn’t agree with the team that the impediment exists them this system does not work. In my opinion there needs to be an additional feedback loop for the team to report external issues to the organisation.

In sprint retrospectives I’ve seen a number of different methods used. Starfish retrospectives, PANCAKE retrospectives, Good Bad Confusing retrospectives, versions of each of these that include an MVP, and versions that include “cake” (highlighting anyone who went above and beyond their duties). In all of these I’ve found that teams tend to focus outwardly for the negatives and inwardly for the positives. When an MVP or “cake” section is added it is almost exclusively for people within the team. On some rare occasions the team has focussed exclusively on external influences, but never have I been in a retro where the team is focussed on themselves.

So, why do teams focus externally? I believe it is a sign of a culture of fear and blame; and also, a sign that the Scrum Master is not able to perform their role to the required level.

# Reflections of Culture

I see a team focussing externally as a significant sign of a culture of fear and blame. This isn’t to say this culture exists within the organisation, more that it is perceived to exist. In a newly formed team the perception could be due to previous experiences in other teams or other organisations; in a team that has recently had some staff changes it could be an influence from the incoming team members; in a stable team it could be that nothing has been done to correct the team’s perception. Having said this, I believe it is far more common that a team does not feel safe to raise issues, they fear that they will be punished for the negative items they raise (either as a team or individually).

# Scrum Master Duties are not Fulfilled

As well as being a reflection of culture, an external focus by the team could be a sign of inadequate servant leadership. I’ve seen this occur when an organisation practices “fake agile” and still operates in a command and control style, when a Scrum Master is serving multiple teams, and when the Scrum Master role is undertaken by an individual within the team who is not empowered to fulfil the role.

In a “fake agile” environment, the external influences raised will often be related to the selection of tasks, the allocation of resources or the modification of priorities midway through a sprint. In all of these cases, an organisation is not utilising Scrum and is instead undertaking some derivative of Scrum. I’ve seen cases where a team is not given the opportunity to select what tasks to perform, instead the task selection is dictated and only the quantity of tasks is chosen by the team. I’ve seen cases where teams are unstable, staff are added and removed depending on resourcing requirements elsewhere, and silos mean that a team is constantly dependant on external teams or individuals. I’ve also seen cases where part way through a sprint a new task is added, given higher priority than the sprint goals, and the team has to react to it. In all of these cases the team has identified significant external negatives during the retrospective, and in all cases the Scrum Master has played a significant hand in enabling these external influences to occur.

When a Scrum Master is serving multiple teams and is unable to fulfil the Scrum Master role to an appropriate level for one or more teams, then a team that is feeling underserved will see the other teams as competition. If the other teams are seen as competition, then the team performing a retrospective will try to beat the other team and this is easily achieved through the identification of negative external impacts from the other teams.

In situations where a Scrum Master is selected from within a team (possibly the role is rotated through team members, but not always), an organisation must have a high level of agile maturity and an agile mindset to enable this person to perform the role adequately. I’ve been a part of teams that have an informal Scrum Master within the team; this person’s performance is measured by their output and as such they do not focus on the Scrum Master duties. In these situations, the person is also unlikely to have the empowerment to work toward resolving external negative influences.

# Enough Problems, Give me a Solution

Despite raising a number of issues that are highlighted by a retrospective that is externally focusses, the solutions are relatively simple to define. All the solutions are found in the Scrum Guide; it exists for a reason, and that is because it improves employee consistency, output, outcomes and happiness.

Of course, I said the solutions are easy to define, but they definitely aren’t east to enact.

If your team doesn’t feel safe, then the organisation needs to work to changing the culture or needs to find a way to demonstrate to the team that it is a safe place. Thankfully demonstrating the safety is easy if the culture already exists; if the culture doesn’t exist then you have a big task ahead of you.

If you’ve adopted agile roles and ceremonies but still operate under command and control structures, then change the management style. Again, another massive task, but if done properly, one that will have huge benefits.

If your Scrum Master isn’t performing their role then identify why. Do their beliefs align with Scrum or are they a manager in disguise? Are they overloaded and can’t give the teams the attention they need? Are they, or do they feel disempowered? There are far too many reasons to list here, but as an organisation you need to identify and resolve the issue.

If the team doesn’t have a formal Scrum Master, then the organisation needs to modify their performance measures for the individual that is performing the Scrum Master duty to ensure they are given the focus the role requires. The organisation also needs to ensure this person is able to raise external issues and seek to resolve them.

Once these issues are resolved, then the team will run out of external negatives and can be coached to focus inwards on ways to improve the team.

# But What About the Missing Element?

The missing feedback loop from the team to the organisation is a much more complex problem than any of the ones I’ve just raised. Providing a team with an open channel for feedback is a key requirement; this channel must be able to bypass the Scrum Master when required. To enable this channel senior management must be willing and able to accept negative feedback, but more than that, they must actively encourage it.

Apart from suggesting this channel needs to exist, I do not feel experienced enough to make a suggestion for including such a channel in a document as broad reaching as the Scrum Guide. I know how I would implement such a channel within organisations I’ve worked at, and I know that in many of those organisations such a channel would not be useable due to a mis-alignment with agile values and principles.