A deeper understanding on…

The Sprint Retrospective

Road to PSM III — Episode 20

Sjoerd Nijland
Dec 8, 2018 · 11 min read

🥅 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 Dev 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 on the complexities of the work. They agreed to spend more time instead on improving the way the events are organised, 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.

Working on the Death Star is not an excuse to not have fun…

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 honouring 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 on what happens during the Sprint. This can serve as a reminder or record for the future, but could end up becoming a wasteful artefact 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:

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 doesn’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 onboard 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 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 visualising 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 to introduce an Architecture Runway, Design Sprint, QA Sprint, Hardening Sprint or the dreaded ‘Sprint Zero’.

Did anyone mention 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 too 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 artefacts. 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 levelling 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 organisations 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 a response to very specific both complex and dangerously straightforward scenarios. What’s more, you need to demonstrate a deeper level 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 on 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 practises, learning Product Owner techniques that benefit maximising value and understanding how Scrum can be organised 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-organisation 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.

Oh wait, one more thing, check out this great read by Justin Bériot on his road to PSM I!

Do you want to share an article in Serious Scrum? Connect with us and make it happen!

Also, you’re all invited to the Serious Scrum Slack workspace. Come join the conversation!

Serious Scrum

Content by and for serious scrum practitioners.

Thanks to Willem-Jan Ageling and Justin Bériot.

Sjoerd Nijland

Written by

Scrum nerd (PSMIII, SPS, PSPO, PSD), Agile geek (PAL), Athletic Developer.

Serious Scrum

Content by and for serious scrum practitioners.