Breaking through those key impediments gives your team a strong sense of progress and motivation. It overcomes the number one motivation killer: the sense of inertia, that nothing ever changes (for the better) around here.
The Sprint Retrospective is perhaps the most important event in Scrum. In this episode, Richard and Peter share their two favorite ways to make the Sprint Retrospective meeting way more effective. If your team’s retros have become boring, repetitive, or just a waste of time, these two key moves will bring them back to life.
Resources Mentioned in the Episode
The Art of Focused Conversation book
HBR piece on the British cycling team
Our Facilitating Effective Retrospectives online course
Related Episodes
Why Scrum works when it works
Effective Sprint Planning
How To Have a More Effective Daily Scrum Tomorrow
Effective Sprint Reviews
Learn More About Scrum
Certified Scrum Product Owner Workshop (virtual, instructor-led)
Certified ScrumMaster Workshop (virtual, instructor-led)
Agile & Scrum Crash Course (online, self-guided)
Facilitating Effective Retrospectives (online, self-guided)
Episode Transcript
Peter
Welcome to the Humanizing Work Show!
Richard
Today’s episode is the fifth in our series about Scrum. If you haven’t yet, check out the first in the series on “Why Scrum Works When It Works,” which lays out our overall thinking about Scrum and how to use it well. We’ve also covered the Sprint Planning, Daily Scrum, and Sprint Review meetings in the past few episodes. It’s all available at humanizingwork.com/show.
Peter
Today we’re talking about the Sprint Retrospective, which we believe is the most important meeting in Scrum. Too many retrospectives use a standard format every time, like “Stop, Start, Continue”. While those types of retros might get you some initial improvement, they quickly hit their limits. They’re kind of like training wheels, where, yes, you are riding a bike, but the transition to actually riding without the training wheels is a big shock. Most people don’t know this, but training wheels teach you the exact opposite body response to balance from what you need when riding a bike without them. You turn away from falls on training wheels, but into them on a real bike. Basic approaches like “Stop, Start, Continue” get you riding the bike of improvement, and usually just within the team boundary. As soon as you hit the limit of what they can accomplish, which usually happens within a few Sprints, the next level of improvement requires some creative thinking and potentially influence systems outside of the team. At that point, you need to take the training wheels off, but now you’ve taught your team the exact wrong habits for a retrospective. Habits like “I’ll just send my ideas in ahead of time”, and assuming individual conclusions and proposals without reasoning together as a group will do the job. In this episode, we’re going to share how to break those habits or avoid getting into them in the first place, so that your team can continue improving, both within the team boundary and by influencing the systems around it.
Richard
Before we jump into the episode, a quick reminder to rate and review the HW Show in your podcast app, or if you’re watching on YouTube, please subscribe, like, and share today’s episode if you find it valuable to you.
Ok, let’s talk about retros…
A team I was coaching had fallen into the common retrospective rut. They were using most people’s default approach: What worked? What didn’t? What should we try?
In the early days, this approach had led to rapid cycles of improvement, and the team was functioning reasonably well. But then the retros started becoming less useful, less transformative.
The answers to the first two questions—what worked and what didn’t—after a while started becoming more specific to individuals or to specialties and were often things that weren’t that big a deal. It felt like people were just trying to find something to say. Then the third question—what should we try—was often just like a suggestion box of random ideas, not particularly structured or strategic.
The ScrumMaster for this team realized his team wasn’t really having a conversation about the same thing. Each participant had their own experience and ideas from the sprint. The team was collecting those but not really engaging with them as a whole. He decided to deliberately collect some shared data and to facilitate a conversation around that data.
Going into the next retrospective, the ScrumMaster collected various artifacts: the sprint backlog, a list of emergency items added during the sprint, notes from the Sprint Review, the last few sprints’ cumulative flow diagrams, and more. He taped those to the wall in the meeting room. At the beginning of the retro, he asked participants to walk along this display on the wall and take it all in. Then, he facilitated a conversation about what stuck out to people, what patterns they saw, what seemed important, and eventually, what opportunities for improvement the data suggested.
The team realized that for several sprints, they’d been starting lots of work separately and then not getting most of it done. Yet somehow, this hadn’t come up in a previous retrospective. Because this was the first time they all looked at data about the team’s collective experience and reasoned about it together.
From this discussion, they decided to try an experiment with a work-in-progress limit and made a big leap forward in their collaboration as a team.
Use the Focused Conversation approach
This story points to our first tip: use the Focused Conversation approach for your retrospectives.
The Focused Conversation approach is a four part structure for a group decision-making meeting like a retrospective. It comes from one of our favorite facilitation books: The Art of Focused Conversation by R. Brian Stanfield. Focused Conversation is sometimes called the ORID approach after the four parts of the conversation structure.
The first part, the O in ORID, is about Observation. In Observation, the group collects and/or reviews a pool of shared, objective data. In a Sprint Retrospective, this sounds like:
- What objectively happened in the last sprint?
- What did we plan to do? What did we actually get done?
- What impediments came up during the sprint?
Often in a Sprint Retrospective, the data already exists somewhere, and the ScrumMaster or other facilitator can bring artifacts that already collect that data.
The next part, the R in ORID, is about Reflection. The Reflection stage captures individuals’ personal reactions to the data, their feelings about it, and makes those visible to the group. In a retro, this might sound like:
- Looking at the data, what do you feel particularly energized or motivated by?
- What do you feel demotivated or frustrated by?
We often visualize this with dots or icons on the data.
Third, we go to the I in ORID, Interpretation. This is where we’re looking for shared meaning in the data. It sounds like:
- What patterns do you see?
- What seems to contribute to our effectiveness as a team?
- What things seem to impede our productivity as a team?
Finally, the D in ORID, Decision. This part asks, “So what?” What are we going to try in the next sprint. If a team does the previous three parts of the conversation well—observation, reflection, and interpretation—it’s usually pretty clear what to work on next, so the decision part of the conversation tends to go quickly. If this part is contentious, it may be useful to back up and work towards a shared interpretation of the data before talking about next actions.
Peter
My first experience of the power of good retrospectives came on my very first Scrum team, the team responsible for Adobe’s audio products like Audition. Prior to using Scrum, our team had distinct phases of development, with different teams responsible for each phase. The first phase was product management coming up with the feature set for the next release and capturing that in a Product Requirements Document, or PRD. The next phase was design, where our UX folks would start creating the user interface designs for the new features in the PRD. At around the same time, technical leaders would begin working out the architectural changes required under the hood to support the new features. Once that was all in place, software developers (or the Engineering team as we referred to them) started coding up the new features. Several months later, the QA team would start testing the features written by the engineering team, accumulating a long list of bugs to be fixed. Finally, we’d start fixing the bugs and try to get everything out the door for the planned release date.
When we adopted Scrum, all of those phases were condensed into a single Sprint. And we didn’t know much about how to do it well, other than to try to get all of those parts done in a Sprint. There was limited literature at the time to help us, so many of our improvements came from being disciplined about holding disciplined retrospectives every Sprint.
Our first Sprints looked like a condensed version of what we did before: some feature descriptions and details by Product Management (now the Product Owner) led up to Sprint Planning. Then in the first few days of the Sprint, technical leads and designers would do their part. Next, the engineering team would start coding up the features. Finally, towards the end of the Sprint, the QA team would get the green light to start testing. But often that handoff to testing was pushed later and later in the Sprint as the engineering team encountered unexpected delays, as is the nature of complex work. So the last few days were a huge time crunch for the testers trying to get their part done. Often, testing didn’t finish and so the next Sprint would be a mix of testing finishing up items from the prior Sprint while engineering got started on the next set.
The first several retrospectives tried to tackle this challenge by imposing stricter handoff deadlines, involving the engineering team in the testing phase of the Sprint, and other approaches, but none of those attempts made things any better. Finally after Sprint 8, we decided we needed a breakthrough. At some point during the retrospective, someone asked “hey, if every time a developer checked in any small piece of code, we just asked ‘how might we test that small change’, what would happen?” A developer responded “well, then QA would start writing bugs on code that wasn’t all the way done yet”. We asked “well, what if we just asked the tester to only test the thing that should be working from the change?” “Well, maybe,” the developer responded, “but that’s never worked before. It seems like we’d just be doing a lot of busy work before the code is really ready”.
As the ScrumMaster, I started to see how this change could really help us do Scrum well, but the hesitation on the team was palpable. I responded by suggesting that we just try it for one sprint to see how it goes. At the next retro, we’d review how that worked and abandon it if the results were worse. Sprint 9, the next Sprint, felt like being on a different team. Sprint Planning was less about task assignment and more about dividing the features into very thin, testable slices. Design, engineering, and QA were all working together in the early days of the Sprint and throughout the end. And it was the first Sprint we’d ever done where everything we pulled in got tested and marked done before the Sprint Review.
Tip 2: Treat every Sprint like an experiment
That simple idea, to “treat it like an experiment”, is our second tip. Making process changes can feel like an all-in, do-or-die change, which causes everyone’s defenses to kick in and push back. Treating a change like a temporary thing we’ll experiment with for a limited time relives the pressure of predicting everything that could be good or bad about a potential change. Now, Sprints feel like short process experiments. That important change made a huge difference for our team. We’d discovered what the agile community now knows very well: splitting backlog items into small “vertical slices” is a keystone habit of effective teams. Now we know the patterns for making that work. Back then we just experimented our way into them.
Maybe your team is facing some challenge that feels intractable. Maybe other teams in the industry haven’t run into it before or haven’t shared what they learned. Great! Use the Focused Conversation to identify a small experiment to try in the next Sprint. Breaking through those key impediments gives your team a strong sense of progress and motivation. It overcomes the number one motivation killer: the sense of inertia, that nothing every changes (for the better) around here.
Richard
Some of your retrospectives will result in big, revolutionary changes, like the ones we’ve described here. Most of them won’t, they’ll just be evolutionary improvements.
Peter
Right. There’s a great story about Sir Dave Brailsford taking over for the British cycling team in 2002 when British Cycling didn’t have much to celebrate. He decided to focus on 1% marginal gains to every part of the program. Those small improvements led to massive change over time, with British Cycling taking seven out of 10 gold medals in the 2008 Beijing Olympics. (https://hbr.org/2015/10/how-1-performance-improvements-led-to-olympic-gold).
Richard
Holding disciplined retrospectives every Sprint using the Focused Conversation approach and treating the next steps as experiments will help you make similar 1% improvements most of the time, and occasionally, when you really need it, will unlock those big breakthroughs that will help your team excel!
Peter
If you want to go deeper on improving your team’s retros, these two tips are just a sample from an online course we created called Facilitating Effective Retrospectives. There are lots more tips in the course to make you a better facilitator, especially for distributed teams who need to have effective virtual meetings. We’ll link to the course in the show notes.
Last updated