A deeper understanding on…
The Sprint Retrospective
Road to PSM III — Episode 20
🥅 Purpose.
“By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint.” — The Scrum Guide.
During the ‘Retro’ the Scrum Team inspects itself. They create a plan on how to adapt during the next Sprint. The Sprint Retrospective is an opportunity for the team to develop transparency and to inspect and adapt.
It’s time to level up!
🤔 Who?
The entire Scrum Team.
During the Retro the team will create an improvement plan. Each Sprint your team will upgrade itself from Team version 0.1 towards Supercalifragilisticexpialidocious Team version 13.3.7 to over 9000.
Participation
A Product Owner recently approached me saying she felt that the Development Team would be more open if she wasn’t to join the Retrospective. I suggested we’d bring this up during the Retrospective to find out why that is and to figure out how to work on that. During this Retrospective, she revealed she felt she had little to contribute over how the team does its work. She felt like an outsider as she couldn’t understand all the technical jargon used by the Development Team. When she did try to contribute she felt she wasn’t taken seriously. One time the group even started laughing when she asked a question.
The Retrospective is not just about the work processes and tools, but very much about people and relationships too.
During the Retrospective, she learned that the team did value her participation. Her team members regretted they laughed and credited her courage to ask the question. They mentioned they valued she was taking the time to develop a better understanding of the complexities of the work. They agreed to spend more time instead of improving the way the events are organized, including the Retro so it would be more valuable for her.
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 case, a Scrum Master argued he didn’t have to participate all the time. When the Scrum Guide refers to ‘Scrum Team’ this implies the whole Scrum Team. The Scrum Master can’t butt out saying he should only make sure the event takes place and for attendants to understand its purpose. During this event, the Scrum Master participates as a Scrum Team member. What’s more, the Scrum Master has an important mission during this event:
“The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint.” — The Scrum Guide [emphasis added]
A Scrum Team also works toward improving the work-environment and its morale.
The above quote from the Scrum Guide also reveals another clause: encouraging improvements within the Scrum Framework. Take note. It says ‘encourages’ not ‘enforces’.
🕗 How long?
Max. 3 hours for a monthly Sprint. For shorter Sprints, this is usually less. It is not uncommon for teams to reduce the time-box relative to a Sprint’s duration. A single week Sprint could have a 45-minute time-box. It’s best to keep it consistent. I personally encourage teams to experiment with various formats and yeah… I admit I cheated at times by not honoring the consistency of the time-box. 🌬🍅
🗓 When?
A Sprint Retrospective is held at the end of the Sprint after the Sprint Review. Anytime is a good time to improve. You don’t have to wait for the Retro to implement or align on improvements. Scrum is all about improving continuously. The Retro is an official opportunity occurring at consistent intervals. At times though you might want to park it for the Retro so as to remain focussed towards achieving the Sprint Goal. That naturally is okay too. If I may, I suggest a ‘sprint log’ or ‘sprint timeline’ (call it what you will). This not part of Scrum, but could be a technique enabling the team to keep track of what happens during the Sprint. This can serve as a reminder or record for the future but could end up becoming a wasteful artifact too. When applied right, this improves transparency about what actually happens during a Sprint and this, in turn, could benefit predictability and adaptability.
I also heard about teams who only have Retros every X sprints or so.
Each iteration in Scrum involves transparency, inspection, and adaptation, not just on the product, but also the team itself and its work environment. A Sprint is not a Sprint if it didn’t include a Sprint Retrospective (or any other Scrum Event for that matter).
But how to avoid a bore….
Yes, the words ‘repetition’, ‘iteration’ and ‘routine’ may sound like it gets dull and rigid. It sounds like something that could kill creativity. That couldn’t, however, be further from the truth in context to Scrum. Upgrading the product, the team, and the work environment requires a lot of creativity. There are plenty of formats to try and Scrum really promotes you to do some small controlled experiments creating your own.
I could suggest these:
- Retromat,
- Fun retrospectives,
- Service design methods,
- The retrospective card game,
- Retrospective Radar
- Liberating Structures
- Agile Retrospective Wiki
and I hope you too are willing to share more fun resources in the comments.
The formats themselves might spice things up, but it’s the participation that makes the Retro fun and worthwhile. No one likes to be stuck in a repetitive loop of people moaning and complaining.
You should not need to depend on the fun factor and the changing of formats for the Retrospective to be effective. If there is a sense alteration is needed, it could even hint towards issues with how the retro is viewed or how people participate.
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 focus. Sure one might not always value the input given by others. One might think something along the line of ‘his problems, not mine’. But that’s not how teamwork works. Their problems are your problems.
Put the needs of the team above that of your own. Scrum is teamwork.
Disagreement….
Now, the Retrospective is not a confessional nor a mushy wushy coaching session for psychological and emotional support. Scrum Masters are not psychoanalysts.
Remember the Scrum Values? yeah, you are going to need them big time during this event.
Sometimes shots get fired.
Openness and courage don’t mean you get to roast your colleagues, customers, and employer. Well… only if you can do this in a respectful way [radical candor], with a practical plan on how to improve. It’s okay to reflect on someone’s performance (or lack thereof), as long as:
“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. In Scrum, however, we align and develop transparency so we can raise our level of competence. We work on living the Scrum Values so we can do just that.
Tired of change….
Constant change is very demanding. This will create anxiety. Not all anxiety is bad, but I cannot stress the risk of prolonged stress enough. Making sure everyone is on board and keeping up is paramount. Sometimes it’s best not to change anything, but just to retry as becoming good at something takes time, persistence, and focus. Improvement doesn’t always relate to doing something new or changing something up. Attempting too many improvements 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 at times. 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.
Improvements as impediments
At times I encounter the most ridiculous kind of impediment: the “we do nothing until it’s improved” kind. For example, a team argued it was too much work (and they didn’t have the time) to keep visualizing work so they stopped doing it. They argued they first wanted approval for a tool to be implemented where they could do this digitally. Now there is nothing wrong with suggesting and facilitating improvements, but that doesn’t exempt the team from its responsibility to make work visible.
Faux improvements
Now a team may suggest regressions illusively masked as improvements. For example, a team might be inclined (consciously or not) to fall back to their older habits, but mask it with Scrum/Agile terminology. A team could, for example, suggest introducing an Architecture Runway, Design Sprint, QA Sprint, Hardening Sprint or the dreaded ‘Sprint Zero’.
These suggested ‘improvements’ are simply terminology 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 either. In a Sprint it is sometimes okay to (perhaps ironically) take a few steps back. Dogma too might impede a team at times. But in such cases let’s just call them by their right names. You could even phrase them as ScrumButs: “We Scrum but… cannot yet deliver a working increment this Sprint”. It’s not bad to have ScrumButs, but it is bad when they are not transparent.
Conflicting improvements
What about suggesting improvements that are not in line with organizational standards? Well, Scrum comes with its escape clauses:
“During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done”, if appropriate and not in conflict with product or organizational standards.” — The Scrum Guide [emphasis added]
So what could a Scrum Team do when it desires improvements that are in conflict with product or organizational standards? What if it is about improving an existing standard, or standards between multiple teams? A Scrum Master could help facilitate the interactions needed to help find a way. A team can make such standards transparent through the definitions of “Done”.
Definitions of “Done”
We already covered that the definitions of “Done” help create transparency over the artifacts. They are needed to keep them in shipshape condition. It promotes integration when multiple Scrum Teams are in play.
But what happens if these definitions themselves end up impeding the team’s ability to deliver a “Done” increment in the Sprint? Now, this is the kind of stuff you will need to be able to answer in practically no time during a PSMIII assessment. So work with what you know to be true. The Scrum Team uses Definitions of “Done” to define a Sprint Goal and to create its forecast during the Sprint Planning… During a Sprint a Scrum Team doesn’t lower their quality standards. hmmm. What else.
“If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.” — The Scrum Guide
The team adapts. As soon as possible. So first things first. With the above statement and the explicit mention of the term ‘must’ it gives us a strong clue on how to answer such a question. In this case, the team detects it cannot deliver an increment according to the transparency created over the increment by the (new) definitions of “Done”. Not meeting those would make the resulting product unacceptable.
The team has to adjust their process or ‘material being processed’. This adjustment must be made as soon as possible. Sure it may take a few retries to learn how to get it right. But it isn’t served if it isn’t right. A general rule of thumb could be to take the time to (learn how to) make it right, then (learn to) do it at speed. It’s not done until it’s done.
Back to leveling up.
Retrying something should be fun. It often takes a number of retries before we can level up and it surely takes a few iterations before we get something right. I know this is easier said than done, but Justin Bériot put it really well in this article about what Scrum and Super Mario have in common:
You’re likely familiar with the cliché to fail fast. But I guess it comes down to the mindset to simply be willing to try, even though you know you might fail. It works in an environment when ‘trying’ is valued over ‘succeeding’. That is damn hard in the modern corporate landscape. The modern ‘result-driven, first time right’ corporate landscape leaves little room for failure. That incites fear. A fear that trumps the fear of missing opportunities. The latter mindset makes organizations rigid and prone to disruption. We covered this in one of the first episodes on transparency with the story about the Emperor’s New Clothes.
I hope you and your team will be able to counter this well. It takes courage and commitment. When I recently asked a CEO about what he appreciated most about a Scrum Team. And he simply sent me this quote referring to their mindset:
He was spot on.
Nearing the end of this series
I (barely) passed the PSMIII when I started this series. I discovered that my journey only had just begun and aptly named this series Road to PSMIII. One of the biggest challenges of PSMIII is the ability to put into your own words in a short time response to very specific both complex and dangerously straightforward scenarios. What’s more, you need to demonstrate a deeper level of knowledge of Scrum. The questions could be along the line of ‘X happened… now what?!’. After the assessment, I felt like I would have been able to answer them even better if I had developed a deeper understanding of how the pillars, values, artefacts, roles and events in Scrum relate.
So this is the twentieth episode of the series. You journeyed the guide with me where I tried to put it into my own words why the Guide says what is says and what it all means… to the best of my current ability. I put a lot of thought and heart into it. But Scrum doesn’t start and end with the Scrum Guide. Getting yourself prepped and ready means deep-diving into Scrum Developer practices, learning Product Owner techniques that benefit maximizing value and understanding how Scrum can be organized at scale (Nexus). So maybe you can help motivate me to do a second season... a road to mastery.
Know that earlier assessment results (PSMI and II) reveal where you still need to work on. These could be about truly understanding the difference between self-organization and cross-functionality. Can you explain why (and how) the two combined promote creativity, productivity, and flexibility? Don’t err by confusing cross-functionality with multi-disciplinary; the folks at Scrum.org will be picky about the terminology you choose.
I’m pretty sure I could write this whole series again with all this new awesome stuff I have learned thanks to all your feedback. In the upcoming season finally, I’ll recap some essentials, learnings along the way, and leave you with some awesome tips and tricks.
Nyland out.
The Road to PSM III is being reformatted to The Road to Mastery!
Part I: Down the Rabbit Hole is now available.
