Retrospective First Principles

What is your take on the Retrospective: A routine exercise at the end of a Sprint, supported by standard operating procedures? Or a critical part of a Scrum team’s journey of continuous improvement? As you may assume, I advocate for the latter. In my experience, Scrum teams start utilizing Retrospectives to their full potential when they embrace a short set of Retrospective first principles, outlining the essence of the Why, the What, and the How.

For classic nerds: “Molon labe (Ancient Greek: μολὼν λαβέ, romanized: molṑn labé), meaning ‘come and take [them][…]’”

The Scrum Guide on the Sprint Retrospective

According to the Scrum Guide, the Sprint Retrospective serves the following purpose:

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.

The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.

The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.

The Sprint Retrospective concludes the Sprint. It is timeboxed to a maximum of three hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

Source: Scrum Guide 2020.

By any standard, this is a compelling pitch of the benefits of Retrospectives, addressing the Why, the What, and the How.

Suppose a Scrum team takes inventing on behalf of customers and creating valuable, viable, feasible, and usable products seriously. In that case, it should be highly motivated to diligently close this feedback loop at the team level every Sprint. Furthermore, everyone should look forward to identifying how to make the next Sprint better and more enjoyable: Are we still progressing towards the team goal? (Regarding the “goal” aspect, the Retrospective resembles the Daily Scrum — inspecting the progress towards the Sprint Goal — and the Sprint Review: inspecting the progress towards the Product Goal.) 

Nevertheless, many Scrum teams struggle to find their “mojo” regarding Retrospectives. Sometimes, Retrospectives are rushed or even skipped. More often than not, defying the Retrospective first principles, they resemble more a routine drill than an exciting opportunity to come together as a team and figure out the next step to Scrum mastery. The tragedy is that the further you go down the road of the routine drill, the less valuable Retrospectives become, justifying rushing or skipping them. It is almost a self-fulfilling prophecy. However, you can break this vicious cycle with a short set of Retrospective first principles.

The Retrospective in 15 Theses

These are my 15 Retrospective first principles in no particular order:

• Closure: Retrospectives have a closing effect not just technically but also mentally. The Sprint is over, have some rest, and reset. The next round of the game starts shortly. (Therefore, having closure does not materialize when you skip or postpone the Retrospective.)
• Force: Retrospectives require intrinsic motivation; the aspiration to improve as a team continuously needs to be shared cause among all team members. No one can enforce participation in Retrospectives.
• Creativity: There are Retrospectives beyond Confluence’s “good, bad, action items” template. Instead of merely ticking the Retrospective box on the Sprint checklist, tailor them to the team’s needs. Practices like Liberating Structures or exercises and games aggregation sites like Retromat offer ample opportunity even with a limited budget.
• Same old, same old: Routine kills Retrospectives. What is a desirable feature of the Daily Scrum—reducing the cognitive load—can potentially obstruct Retrospectives effectively. (Stick with the time slot, though.)
• Variety: Change formats and locations frequently. Any new approach heightens attention and increases alert levels, probably leading to new insights. 
• Data: As a Scrum Master, regularly collect data from the Scrum team in advance of the Retrospective and visualize it over time. In my experience, anonymous surveys work best. Moreover, there are simple tools like to Retrospective mailbox that also allow for providing anonymous feedback. Just because we tell ourselves that there is psychological safety within the Scrum team, not everyone needs to see it that way. Include them nevertheless by giving them a voice outside the Retrospective session.
• Accountability: Retrospectives quickly turn into cargo cult Scrum without following up on agreed-upon action items. Therefore, identifying a directly responsible individual (DRI) is critical to running successful Retrospectives. (Spend five minutes at the beginning of each Retrospective on checking in on open action items; offer support where it is needed.)
• Superior: Retrospectives often fail when one team member is another team member’s line manager. In this case, the hierarchy impedes psychological safety. As Scrum Master, you want to learn from the subordinate among the team members if they still feel represented during Retrospectives. Sometimes, the Scrum Master needs to act as a go-between until the organization fixes the situation while respecting Scrum’s spirit. (The same applies when team members on the internal payroll also decide on contract prolongations of the contractors on the Scrum team.)
• Other people: Occasionally, invite outsiders to Retrospectives as a Scrum team but do not make it a regular habit with every Retrospective. Reaching out to stakeholders and (line) managers improves building trust and delivers new insights. A suitable format for a stakeholder Retrospective is, for example, the Meta Retrospective. 
• Discretion: Confidentiality is critical to creating psychological safety, too. Never leak anything from a Retrospective to outsiders. Bar anyone outside the Scrum team from accessing the minutes. 
• Equality: The need of respecting Scrum values should be obvious. Nevertheless, you always find well-meaning Scrum teams where some team members are “more equal” than others. The imbalance is easy to spot: a sign of good team communication is equally distributed speaking time. (Learn more: Google’s Project Aristotle.)
• Diary: From a Scrum Master perspective, journaling and thus documenting significant events is a beneficial practice for preparing Retrospectives. Automated Slack notifications, [insert the version control system of your choice] comments and pull requests, Jira entries, etc., are no adequate substitutes for a journal in my experience.
• Master of ceremonies: Just because Scrum Masters are supposed to facilitate Scrum events does not mean they facilitate every Retrospective. On the contrary, Scrum Masters participate as team members in every Retrospective. Instead, everyone on the Scrum team should be capable of facilitating Retrospectives. Start practising so early. 
• Outside the box: The scope of Retrospectives goes far beyond the usual “good-bad-improvement” narrative. Retrospectives are designed to work on issues like working agreements, tools, skills, your Definition of Done, Product Goals, personas, strategy, product discovery, processes, or business models. Free your mind, and the rest will follow, opening new perspectives on how the Scrum team can continuously improve.
• Ambition: Don’t push too far your dreams of China in your hands. When it comes to change, the steady drop holes the stone. No one benefits when your Scrum team tries to go a bridge too far.

Conclusion

There are many ways in which a Sprint Retrospective can become a failure, even if it looks suitable at first glance. Therefore, simply adhering to the previously sketched Retrospective first principles does not guarantee success. However, they provide an excellent start to reflect as a team on what is going on at this critical part of a Scrum team’s journey of continuous improvement.

What Retrospective first principles do you appreciate? Please share those with us in the comments.