A deeper understanding on…
The Sprint Retrospective
Road to PSM III — Episode 20
(Revised for the 2020 Scrum Guide)
“Finally, the Sprint is over. Let’s share EVERYTHING THAT SUCKED! The Scrum Master will tells us in a nice way how screwed we really are. That sounds like an excellent way to end the Sprint!”
On a map from here to there, ^ that will get you NOWHERE.
The Sprint Retrospective is an opportunity to reflect on people, processes, and tools. And, we must hold each other accountable as professionals.
Let’s do that respectfully.
Recognizing our efforts and receiving validation from our peers anchors trust. We must do so to create a stronger sense of belonging for everyone.
The Retro is an opportunity to make our work more meaningful, enjoyable, and sustainable.
🥅 Purpose.
“The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.” — The Scrum Guide.
During the ‘Retro’ the Scrum Team inspects itself. They create an improvement plan for the next Sprint. Yes, a real plan, not just a selection of sticky notes with vague comments like ‘improve communication’. No, an actual plan, with who, what, why, when, where, and how.
It’s time to level up!
🤔 Who attends?
The entire Scrum Team.
During the Retro the entire team will create an improvement plan that involves everyone. Each Sprint your team will upgrade itself from Team version 0.1 towards Supercalifragilisticexpialidocious Team version 13.3.7 to over 9000.
Should external managers join for “transparency”? Absolutely NOT. “transparency” must not be weaponized to impede self-management.
Participation
A Product Owner once approached me saying she felt that the Developers would be more open if she would not join the Retrospective. Besides she felt she had more pressing matters to attend to. I suggested she’d bring that up during the retro to find out why that is and to figure out how to work on that.
She revealed she felt she had little to contribute to how the team does its work. She felt like an outsider as she couldn’t understand all the technical jargon. When she did try to contribute her ideas she felt she wasn’t taken seriously.
The retro is not just about the work processes and tools, but very much about people and relationships too.
Developers regretted that and credited her courage to bring this up. A developer mentioned he valued she was putting forth the effort to develop a better understanding of the complexities of the work.
Another example was shared by Willem-Jan Ageling where he experienced a case where the Product Owner was not even allowed to join the Retro …seriously?!
In another instance, a Scrum Master claimed he didn’t need to attend the Sprint Retrospective, believing his responsibility was merely to ensure it happened. This assumption is fundamentally incorrect. The Scrum Master participates as a team member. The Scrum Master often plays a critical role in facilitating, ensuring it is a safe space for open discussion, fostering collaboration, and helping the team identify actionable improvements.
Ideally, the vibe during the retro is positive and even fun. Despite conflict and challenges, which is only natural to the work, there generally is much to be excited about.
The Scrum Master can work with other team members in various ways the Retrospective remains a positive and valuable event for all. I encourage teams to experiment with playful formats to inspire creativity and positivity.
🕗 How long?
Max. 3 hours for a monthly Sprint. For shorter Sprints, this is usually less. A two-week Sprint could have a 90-minute time-box. It’s best to keep it consistent.
🗓 When?
“At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.” — Agile Manifesto
A Sprint Retrospective is held at the end of the Sprint after the Sprint Review. But anytime is a good time to improve! You don’t have to wait for the retro to plan improvements. Scrum is all about improving continuously.
“If any aspects of a process deviate outside acceptable limits or if the resulting product is unacceptable, the process being applied or the materials being produced must be adjusted. The adjustment must be made as soon as possible to minimize further deviation.” — SG
I recently talked to someone who told me they only had a retro each quarter as part of an ‘innovation’ day.
With Scrum, every day is an innovation day. A Sprint is not a Sprint if it didn’t include a Sprint Retrospective.
How to avoid a bore….
Yes, the words ‘repetition’, ‘iteration’ may sound ceremonious and ritualistic. It sounds like something that could kill creativity. That couldn’t be further from the truth with Scrum. Leveling up as a team requires a lot of creativity. There are plenty of creative formats to try, and you can invent your own.
I could suggest these:
- Retromat,
- Fun retrospectives,
- Service design methods,
- Thinking Routines
- The retrospective card game,
- Retrospective Radar
- Liberating Structures
- Agile Retrospective Wiki
Please share more fun resources in the comments!
Formats are great, but its people that make it worthwhile and engaging. No one likes to be stuck in a repetitive loop with people moaning and complaining.
There is so much to learn from things that are working well. Take time exploring why something is going well, and how that can be useful in areas where the team can level up.
The Retrospective motivates us to listen… I mean really listen… to what our colleagues have to say. This means we need to demonstrate patience and active listening skills. When you’re in a team their problems are your problems (and visa versa).
Disagreement….
Scrum Masters are not therapists. A Retrospective is not a confession booth either. Yet it is a place that needs to be psychologically safe and where team members can find (emotional) support for the challenges they face at work. Remember the Scrum Values? Yeah, you are going to need them big time during this event.
Openness and courage must not be weaponized so you can roast your colleagues.
“Scrum Team members respect each other to be capable, independent people.”
— The Scrum Guide
It’s okay to disagree. It’s a cliché I know. Unfortunately, we all generally suck at dealing with disagreements. These can result in compromises. Teams may even end up settling for (less than) mediocracy if only to avoid conflict.
Conflict
Sometimes disagreement turns into conflict.
Embrace that there will be drama when teams engage in honest, open communication. When facing hard challenges head on, individuals will be tested on their respect for each other’s capabilities. Will they lay the blame elsewhere, or will they stand up for each other and support the personal growth of their peers?
Not all conflict should be avoided! When people speak up without fear of reprisal, it sparks constructive conflict. It takes courage to confront tough problems and hold each other accountable, ensuring adherence to ethical and professional standards. This drama — rooted in transparency, mutual respect, and accountability — is essential for fostering a high-performing team.
Here are some types of constructive conflicts:
- Idea Conflict: Encourages diverse perspectives and creative solutions.
- Process Conflict: Helps improve workflows and smoothen collaboration.
- Values Conflict: Defines and upholds ethical and professional standards.
- Role Conflict: Covers overlaps and gaps and stimulates growth and ownership.
- Information Conflict: Promotes evidence-based decision making.
There are different levels of conflict. There are minor everyday disagreements and misunderstandings with limited disruptions and escalations. There are moderate disagreements that erode trust, disrupt relationships, hinder collaboration, and weaken team dynamics. And major existential conflicts that impair productivity, damage mental health, undermine team cohesion, and erode organizational effectiveness.
With lower-level conflict, there is hardly ever a need to intervene. Trust that your peers can work through their minor conflicts as capable professionals. Listen with empathy and consider actively doing nothing.
With moderate and major conflicts, the team’s effectiveness is being impaired. There are impediments to a good flow that can put the goals of the team at risk. That requires a more hands-on approach. This can call for more strict mediation and facilitation with the intention to re-establish focus on the goal.
Tired of change….
Constant change is very demanding. Change and anxiety are a pair. Not all anxiety is bad, but I cannot stress the risk of prolonged stress enough. Making sure everyone is keeping up and maintaining a sustainable pace is paramount.
Attempting too many improvements at once will impede the team from improving. Sprints shouldn’t be death marches. It might be hard for team members to speak up about the need to lower the bar when it is overstretching. Some of the biggest threats to sustainable pace is an overly motivated team or coaches that continuously press and push more and more improvements and experiments.
Faux improvements
Don’t by shy to call out regressions masquerading as improvements. For example, a team might be inclined to fall back to their older habits.
Here are some examples of faux-improvements:
- Skipping Scrum Events for “Efficiency”
The team decides to combine or skip events like the Daily Scrum, claiming it will save time and increase productivity. In reality, this undermines transparency, reduces collaboration, and erodes opportunities for inspection and adaptation, leading to less effective teamwork. - Watering Down the Definition of Done
The team relaxes the Definition of Done to deliver faster, thinking it will increase velocity. Instead, this creates technical debt, reduces quality, and damages trust with stakeholders, as work is not truly “done” by professional standards. - “Fake Sprints” Like Sprint 0 or Design Sprints
The team creates “preparation” Sprints such as a Sprint 0, architecture runways, or a Design Sprint, claiming it’s necessary for better execution later. This undermines the core commitment of Scrum: delivering a Done Increment every Sprint. These fake Sprints delay delivering value, erode stakeholder trust, and create the illusion that progress can happen without producing usable outcomes. Instead of delivering results, the team risks falling into waterfall-like habits under the guise of agility. - Extending the Sprint Length to “Get More Done”
The team increases the Sprint length, claiming it will reduce pressure or allow for more substantial deliverables. This diminishes opportunities for regular inspection and adaptation and makes the team less responsive to change. - Introducing Rigid Workflow Rules
The team imposes strict rules, like individual ownership of work items, and exhaustive definitions of “Ready”. While clear responsibility is necessary, over-regulation stifles collaboration, creativity, and responsiveness to changing priorities. - Adding More “Roles”
Additional roles are introduced. This dilutes collective ownership and the team’s self-management capabilities. People can develop skills and take on responsibilities without the need for introducing new roles.
These suggested ‘improvements’ are hacks to go back to a more traditional way of working. That said, one must also not be completely blind or ignorant in dismissing such suggestions. Team members will throw out terms like “dogma” to get out of Scrum’s simple but rather strict controls.
ScrumButs
I have no trouble with calling deviations from Scrum as “ScrumButs”.
ScrumBut: “We Scrum, but… (here is how we are not)”.
Scrum does not work with ScrumButs. Scrum only works with ScrumAnds.
ScrumAnd: “We Scrum, and… (what else)”.
Gosh, that sounds awfully dogmatic, right? If that’s what you think, I hope I can change your mind. So here is my take on it:
As long as teams improve at Scrum, it’s okay to accept deviations. As long as team members are open about them and support each other in resolving them, they demonstrate professionalism.
It is not professional, if you ask me, to undermine Scrum by intentionally introducing deviations or blocking improvements to Scrum.
If that doesn’t sound very “agile” of me, fair enough. The goal is not to practice perfect Scrum for its own sake. The purpose of Scrum is to help people create value by delivering adaptive solutions to complex problems. To achieve this, everyone involved must respect the framework and continuously work together to improve within and beyond it. Scrum may not be the only way, and that’s fine — but if you’re playing football, you won’t win any fans (or games) by insisting the sport would be better played with sticks instead of feet.
But what could a Scrum Team do when improvements are in conflict with organizational standards? Well, that’s what the Scrum Master is accountable for. The Scrum Master is leading change in the organization to support its Scrum adoption. They help employees and stakeholders understand and enact an empirical approach for complex work. They (help) remove barriers to Scrum. Tough job, I know!
Back to leveling up.
Where the Sprint Review is about leveling up the Product, the Sprint Retrospective is about leveling up the Team.
The Definition of Done is the bridge between the team’s capabilities and what’s needed to sustain and increase the quality of the product. Good Scrum teams make their DoD more stringent over time as they improve their professional practice.
Next episode (season final):
