Table of contents
In Chapter 1, you learned the basics of an agile retrospective. What is a retrospective? What’s the value of a retrospective? Who should attend the retrospective? And more. We also briefly touched on the 5 phase model introduced by Diana Larsen and Esther Derby in their book Agile Retrospectives: Making Good Teams Great.
Now, we’re going to dive into more detail on this approach.
It was time for the team’s retrospective. Everyone sat down and you could hear, see, and almost feel the groans in the room. “Not again. These retrospectives don’t actually accomplish anything and I have so much to do.”
Bob, the team’s Scrum Master, kicked off the retro. “Welcome everyone! Just like last time, let’s go around the table and everyone can talk about what’s working and what’s not, and then offer some solutions.“
Cindy took out her phone. Joan opened her email on her laptop. Rahul just looked bored.
Maya was the first to speak up. She had been on the team the longest and knew the code inside and out. She always seemed to speak first. “The biggest problem to me is the low quality of the codebase. So many of you just commit code without thinking about how to make it better. If you all would just be more intentional about the code you write, we’d be better off.“
“That’s not the reason why there are so many bugs, Maya!” John responded. “You’ve been here the longest, and if you had only spent the time documenting the code at the beginning, the rest of the developers would have a better idea of what’s in your head!“
“Not again,” thought Erica. “Those two always argue. And the crazy thing is that the number of bugs in the code has been decreasing for months!“
And, stop. This retrospective is leading nowhere good, and it only just began! Why? What specifically went wrong in just the first few minutes?
Problem One: Lack of engagement
Cindy, Joan, and Rahul aren’t paying attention. As John and Maya get into their argument, Erica checks out. You can only imagine how the rest of the team is feeling.
Problem Two: Lack of alignment
While John and Maya argue about why the codebase lacks quality, Erica silently doesn’t even agree with the premise. The team doesn’t agree on the issues at hand.
Problem Three: Jumping to solutions
Both Maya and John jump to solutions far too fast without investigating alternatives, diving into root causes, or looking at the bigger picture.
To fix these issues, the team should have followed the five phased approach to effective agile retrospectives. Let’s take a look.
Want to know when the next chapter is available? Sign up below to be among the first to receive each chapter.
The first phase of a retrospective is a chance for the team to “check in”. Many teams skip this phase, and that’s a big mistake! When I first learned about this stage, I admit I was skeptical. My bias, like many people with an engineering background, is to jump right into analyzing problems and finding solutions. I’ve since changed my outlook.
1. It gives everyone a chance to context switch
Retrospectives require an entirely different mindset from the day-to-day grind of working on a product or project. By taking a few minutes to set the stage before getting into the heart of the retrospective, the team has the chance to switch from thinking about the last thing they were working on to thinking about the bigger picture.
2. It encourages participation
According to Marc Loeffler in his book Improving Agile Retrospectives, “someone who is silent at this stage is likely to remain so for the rest of the retrospective.” 😶 If you want more people to participate in the rest of the retrospective, now’s your chance! Make sure everyone says at least one word during this phase.
3. It grabs everyone’s attention
Many people are in meeting after meeting, day in and day out, and see the retrospective as yet another meeting to attend. If you use Setting The Stage as an opportunity to have some fun, you’ll also grab their attention for the rest of the conversation. (If you don’t believe me, think about the last conference you were at. If the speaker hooked you in the first few minutes, were you more or less likely to listen to the remainder of his or her talk?)
So how does it work in practice? While there are lots of activities you can choose from, here are a few of my favorites:
Ask all participants to answer a question using just a single word (feel free to change this to a single sentence, if you prefer). Example questions include:
And so on. Use your imagination! Also realize that it’s okay for someone to pass. If they don’t feel comfortable answering the question, don’t make them. Simply saying “I pass” can be enough to get them involved.
Now, if you’re like me, you might doubt the value of this exercise. Trust me, I’ve been there! But here’s an example from a real life retrospective that changed my mind. One person on that team was named Jeff (not his real name). Jeff was usually a positive person who brought energy to any situation. But over the past day or two, the team had been noticing that Jeff was acting a bit down in the dumps. It was unlike him. During Set The Stage at that retrospective, the facilitator asked the group a one word check in question: “How are you feeling right now?” Everyone went around the table round-robin style. When it was Jeff’s turn, he said: “Terrible. I’ve been meaning to tell everyone, but I learned a few days ago that my mom has Stage 4 Cancer. Sorry I’ve been so down in the dumps.”
Now, if the team had jumped right into the rest of the retrospective, they might have been annoyed at Jeff’s negative attitude. But because of the one word check in activity, the team’s understood why Jeff was acting that way. They were able to provide emotional support and the team felt closer to one another. That’s the impact of Setting The Stage.
Some people shy away from verbally checking in to the retrospective. For these people, Constellations is a fantastic exercise because it allows you to answer simple questions without speaking. 😲 How is that possible? 🤔 Here’s how it works:
First, clear the space. Move tables and chairs out of the way. Then ask everyone to come to the center of the room.
Explain to the group that you are going to make a statement and that you’d like everyone to move themselves closer or farther away from you to indicate the level of agreement or disagreement with the statement.
For example, you might say: “I am happy with the results of the iteration.” Then watch people move close to you to indicate they agree or farther away from you to indicate they disagree.
Not all statements have to be related to work. In fact, I encourage you to make this fun! For example, you might say: “Star Wars is better than Star Trek” or “Android is better than iOS” Not only will statements like these be fun and engaging, you might learn a thing or two about your teammates!
Encourage other people on the team to make statements, too. You’ll know when the activity is done when the energy starts to drop in the room.
Many teams struggle with follow-through on their Action Items. For those teams, it can be useful to start each retrospective with a review of the team’s Action Items from the previous retrospective. I learned this technique from Sven Winkler.
Create five columns on a poster board: Action Item, More Of, Less Of, Keep Doing, and Stop Doing. Then write down each outstanding Action Item on a sticky note and put it in the Action Item Column. Have each person put a dot, an “X”, or a sticky note in the column that best represents how they feel about it. Here is an example:
The second phase of the retrospective gives your team the chance to look back at your iteration to create a shared understanding of the events that shaped the present. The Gather Data phase is actually the only phase that fits the classical definition of the word retrospective (which literally means “looking back on or dealing with past events or situations”)!
Objective Data is sometimes referred to as “hard data”. Objective Data is any information that can be measured and verified. There are a lot of different types of Objective Data. Here are just some:
Types of Objective Data:
Note that you don’t have to bring all of this data to every retrospective (though you certainly can). Instead, bring the data that you think would be most interesting given the context of what’s going on.
In contrast to Objective Data, Subjective Data is sometimes referred to as “soft data”. And Subjective Data is just as important as Objective Data! Subjective Data includes personal opinions, feelings, and emotions on the team. Whereas Objective Data presents the facts, Subjective Data can reveal what your team thinks is important about the facts.
Here are some questions you can ask to gather Subjective Data:
Alternatively, you can turn Subjective Data into measurable information. For example, you could setup a Team Radar to ask your team how it is doing living up to the Scrum Values from 1 to 5 (1 being “poor” and 5 being “excellent”). By aggregating the results across the team, you have turned subjective feelings into measurable data.
On Retrium, Team Radar looks like this:
Gathering Data is critical. But it’s also critical to do it right. There are a number of pitfalls to watch out for.
1. Do not bring data that focuses on individual team members (at the detriment of others)
For example, you might collect data around the introduction of bugs into the repository. Who committed which bugs and who fixed them? While this data might be useful in other contexts, the retrospective should not be used to compare and contrast individual performance. What to do instead: bring data around the total number of bugs introduced to the repo and the total number of fixes issued across the entire team.
2. Do not falsely present Subjective Data as Objective Data
For example, you might suspect that some team members are working on side projects during the sprint (at the request of management) without alerting the rest of the team. You believe this might be reducing down the team’s throughput. You haven’t collected Objective Data to know for a fact that this is happening, it’s merely a suspicion. Don’t tell the team that this is a fact! What to do instead: bring this issue up while your team gathers Subjective Data, so that your teammates know its an unproven opinion at this point.
3. Do not collect more data than you need
Collecting and tracking data takes time and effort, so it’s important to track only the data you need and nothing more. I bet you can think of a time when data was tracked without a clear purpose (“that’s just how we’ve done it in the past”). If there’s no reason to collect data, then don’t.
4. Do not share data outside The Team without permission
Data can easily be abused and misused. Data that you collect for the retrospective should be for The Team only. If people on your team suspect that the data you are collecting is not only for The Team, but also for management, stakeholders, or anyone else not on The Team, they will no longer feel safe.
What are some activities you can use to Gather Data? Here area just a few:
I sometimes find it difficult to remember what I had for dinner last night, let alone what happened over the course of the previous two weeks! That’s why the Timeline activity can be so helpful: it jogs people’s memories about what happened. Timeline can be especially helpful for teams with longer Sprint Lengths (if you have a 4 week sprint, I’m looking at you!), or for a Project or Release retrospective.
In this activity, your team will be building out a timeline of all the events that occurred during the iteration. Set up a whiteboard in which the x-axis represents time. No need to be precise here (“on Day 2 what happened? On Day 3 what happened? etc”). Instead, what matters is overall trends (“towards the beginning of the sprint, this happened. In the middle of the sprint, this happened. etc”).
Take your time. Have people write down whatever events occurred that were meaningful to them, or had an impact on the team. These can be technical events like “we merged in code from another branch”, personal events like “I was sick and took a day off”, or events outside the team’s control like “we learned there will be layoffs in the coming weeks”.
The important thing is to make sure there is a shared understanding of what occurred.
This popular retrospective technique helps highlight your team’s emotions during the iteration (bringing to light Subjective Data exclusively). To run Mad Sad Glad, simply setup three poster boards around the room titled Mad, Sad, and Glad. Ask everyone to privately write on sticky notes what they felt Mad about, what they felt Sad about, and what they felt Glad about. Once everyone is done brainstorming, have everyone place their sticky notes up on the board.
Then, ask your team questions like:
Lean Coffee™ is a way of constructing an agenda for the retrospective based on what the team collectively wants to discuss the most. Here is out it works:
Using Lean Coffee™, you can quickly identify topics the team wants to discuss that they actually care about.
Want to know when the next chapter is available? Sign up below to be among the first to receive each chapter.
Ok, so you’ve Set The Stage to get everyone “checked in” and you’ve Gathered Data to build a shared understanding of the facts. Now it’s time to analyze the data you’ve collected to discover insights and to find root causes.
Generating Insights encourages you to think deeply about issues, which helps to expand your horizons by helping you see the big picture.
So many teams fall into the trap of Solution Finding before they know what problem they are trying to solve. These teams identify something interesting in the data and jump to conclusions about what to do to fix the problem.
Here’s an example. The team might have Gathered Data and discovered that they did not work on any Retrospective Action Items during the sprint. They immediately jump into trying to find solutions to that problem. Within a few minutes, they’ve identified a number of possible fixes:
I could go on and on. But which one of these solutions is the right one? How do you know? Without Generating Insights, it’s just a guess. It’s my opinion versus yours. It’s who talks first or who is the most convincing.
Generating Insights provides your team with the opportunity to analyze the issue and to make sure whatever you Decide To Do will have a high likelihood of success.
Going back to our example, if the team used the 5 Whys technique to analyze why they were not working on their Retrospective Action Items, they might have discovered that the real root cause of the issue was not that people forgot about the Action Items but that no one felt responsible for them. Look again at the list of potential solutions above. Do any of these address the actual issue? Not really.
Instead, The Team might simply record down who is responsible for the Action Items during the retrospective. Without taking the time to Generate Insights, you might never have arrived at that conclusion.
One of the easiest ways to understand the power of Generating Insights is by using the 5 Whys activity. 5 Whys is a facilitation technique that helps you discover the root causes of an issue. It is no more complicated than its name suggests. Here are the two easy steps to running 5 Whys:
That’s it. Really. Of course there is no magic to asking “why” five times in particular. You might ask “why” three times or eight. Feel free to stop once you arrive at the root cause.
To take 5 Whys to the next level, consider breaking your group into smaller subgroups of 2-4 people. Have each subgroup perform the 5 Whys exercise independently, and then ask each to report their findings back to the larger group. Breaking into small subgroups can help encourage more people to participate in the discovery process.
Here’s an example of 5 Whys in action, using baseball as an analogy. Don’t worry, if you’re not a baseball fan. It will still make sense. (Also this is not a real example: I’m not an expert on the Baltimore Orioles and the analysis here is made-up.)
Issue: The Baltimore Orioles missed the playoffs
Using 5 Whys, we have connected the dots between The Baltimore Orioles missing the playoffs and the need for the team to hire a strength and conditioning coach. Imagine if you hadn’t run 5 Whys. Would you have ever arrived at that conclusion?
Force Field Analysis is a great way of identifying the factors that 1) support the topic (or drive the change forward), and 2) oppose the topic (or prohibit the change from happening). The team can then move on to identify what actions it can take to reinforce the driving factors and to lessen the impact of the prohibiting factors.
Here’s how it works.
Try Retrium. It guides you through the retrospective process
Start today for free!
Now that you’ve analyzed the issue at hand, it’s (finally) time to make it actionable. Your team will love this phase — fixing problems is what Solution Focused engineers want to do most. Engagement shouldn’t be a problem. The focus here is making sure you pick the best action for the upcoming iteration.
As you learned in Chapter 1, the purpose of the retrospective is to enable Actionable Team Learning. That means that the insights you discovered during the last phase of the retrospective must now be translated into Action Items or experiments so that the team has the opportunity to change.
Most teams naturally understand the need to Decide What To Do, even if they’ve never heard of the 5 phase approach to retrospectives. They simply want to come up with ideas for improvement. But a minority of teams simply see the retrospective as an “opportunity to complain”. These teams fail to come up with concrete actions and therefore find that retrospectives rarely (if ever) become agents of change. Many of these teams call retrospectives “checklist items”. They do them because “Scrum said to”. They find little to no value in the retrospective and will eventually stop doing them altogether.
Don’t fall into that trap. Use this phase of the retrospective to pick the right thing to work on so that your team can see the benefits of the retrospective.
This is a popular retrospective technique that is often misused. Many teams start their retrospective with Start Stop Continue. That’s jumping into Solution Finding way too fast. Use this technique to help brainstorm a list of potential actions the team can take after it has identified an issue it wants to work on during Generating Insights.
For example, you might have used Force Field Analysis to find the strongest supporting and inhibiting factors for a change item. Use Start Stop Continue to propose actions the team can take to increase the strength of the supporting factor and decrease the strength of the inhibiting factor.
After your team has generated the list of actions, use Dot Voting to prioritize which actions the team most wants to work on.
When you’ve generated a list of potential actions, it can be difficult to know which one to work on next. Dot Voting can help. A more powerful way is to use Impact, Effort, and Energy mapping.
Here’s how it works:
Now that you have mapped out the Impact, Effort, and Energy of each potential action, the team can discuss which action makes the most sense. For example, an action that has low effort, high impact, and high energy, would be a great candidate to commit to. An action that has high effort, low impact, and low energy, is likely one you should skip.
In the image above, the first potential action would be a good candidate (it has high impact and low effort), as would the third (it has a lot of energy).
* Use relative size measurements for estimation. For example, you can use t-shirt sizes (small, medium, large, extra large) to compare each idea. What matters is the relative sizes compared against each other (“this one is bigger than that one”), not the accuracy of any individual item.
How you write your Action Items makes a big difference. One option is to use the SMART template. But for teams that have people with strong opinions, that’s sometimes not enough.
Let’s think about this fictional scenario: the team is trying to decide which action to take in order to reduce the number of bugs produced in the upcoming iteration. Jennifer argues passionately for trying out pair programming. Randy disagrees and argues vehemently for trying out TDD. They can’t come to an agreement, and tensions flare. What should the team do? How can it pick between the options?
That’s where hypotheses and experiments come in. If Jennifer had said, “I hypothesize that by implementing pair programming, the number of bugs in our upcoming iteration will be reduced. I don’t know that this will work, it’s just a guess, but let’s try”, then Randy’s reaction might not have been so strong. He might respond, “I don’t think that will work, but it’s worth a shot.”
Using hypotheses and experiments helps your group move from consensus decision making to consent decision making. When actions are presented as solutions, teams tend to want to build consensus to make sure they all agree that it is the right solution. When actions are presented as hypotheses, teams are less inclined to resist trying new things out (even if they don’t agree it’s the optimal experiment to run).
Here’s a template from Luís Gonçalves that you can use to write your Action Items as hypotheses:
We hypothesize by <implementing this change>
We will <solve this problem>
Which will have <these benefits>
As measured by <this measurement>
Use Retrium to allow people to submit ideas anonymously.
Start today for free!
Congrats on making it to the end of the retrospective! Many teams make the mistake of ending the meeting before closing the feedback loop in this phase. Closing The Retrospective takes just a few minutes and it’s well worth your time.
When you’re in a rush, it may seem like skipping this last phase of the retrospective is okay. But if you do, you’re missing out on some important benefits.
Many teams have a retrospective ground rule: What Happens in the Retro Stays in the Retro. By that, they mean that in order to increase trust and create a sense of psychological safety, the team should feel comfortable knowing that nothing that is discussed in the retro leaves the room.
But sometimes things the team learned in the retrospective should be shared outside the team. What if the finding could help other teams succeed? What if the team needs help on a particular issue from someone else in the organization? That’s when Closing The Retrospective with this activity makes sense.
Here’s how it works:
The answer might be “no” and that’s okay! But if the answer is “yes,” document what The Team has authorized to be discussed outside the room.
Just like with the One Word Check In, simply ask your team a question and ask them to respond in a single word or short phrase. You can do this verbally or have everyone write down their response on a sticky note and hand them to you as they leave.
Here are some example questions:
Don’t limit yourself to these questions. Be creative. Use it as an opportunity to collect feedback in an effort to improve the retrospective experience next time.
For teams that love to live in the digital world, this technique can be a fun Close The Retrospective activity. Here’s how it works:
For example, someone might choose a gif like this one to express that they feel closer to the rest of The Team or that they feel particularly happy about solving a problem:
Someone else might choose a gif like this one to indicate they are excited to get started on an Action Item:
Running the Retro as a Gif exercise is more than just fun. It also gives you a sense of how the team is feeling after the retrospective is over. You can use this information to improve next time.
Let’s go back to how we started: with the example team. If you recall, Bob (the Scrum Master) started the retro by going round robin and asking everyone what should be improved. Immediately, a number of team members checked out. Then Maya and John got into a disagreement that Erica thought didn’t even matter.
Let’s replay that retrospective using the 5 phase approach we just outlined and see the difference it can make.
Scrum Master Bob has prepared the space ahead of time for the Constellations exercise. He moves all the chairs and tables to the side to create an open space.
As the team walks in, he asks everyone to join him in the middle of the room and he explains how he will start by making a statement and he’d like everyone to physically move closer or farther away from him to indicate their level of agreement with what he’s about to say.
“The best Marvel movie was the original Iron Man.”
Everyone laughs. Most people move far away from him. Cindy shouts, “No way! The Avengers movies are so much better!” Erica laughs, “You’re crazy. It’s all about Thor.”
There was a brief pause before Maya says, “Can I make a statement?“
“Of course!” Bob responds.
“The best place to take vacation is the beach,” exclaims Maya.
Most of the team excitedly moves very close to Maya. But not Jordan or Mike, who move as far away as possible. “The beach is for lazy people. My ideal vacation is in the mountains,” says Mike. Jordan nods his head and responds, “I never knew you enjoyed hiking. So fun! We’ll have to go sometime.“
The team continues with a series of statements until the energy leaves the room and Bob recognizes it’s time to move on.
What did this accomplish?
Everyone waits to hear what’s next. Bob says, “Next up, we’re going to run a Development Practices Radar. We’ll use this to collect some subjective data about what the team thinks we’re doing well and not doing well. Based on what we learn, we will pick a narrow focus for the rest of the retrospective.”
Bob continues: “The six topics of consideration are: Testing Practices, Shared Coding Standards, Managing Technical Debt, Clarity of Scope, Ability to Focus, and Deployment Process.“
“Let’s start with Testing Practices. What does that mean to you?“
Rahul responds, “To me, Testing Practices means the way we check our code for correctness.”
“That sounds right. But I’d also add it includes manual testing,” Cindy responds.
“Great,” says Bob. “Now that we have a shared definition of Testing Practices, I’d like each of you to write down on a sticky note a number from 1 to 5 indicating how well we are doing in this area. 1 means there’s not much we are doing well. 5 means we’re doing as well as could be expected.“
Everyone thinks for a moment, then writes down their responses. “Perfect. Who would like to volunteer to collect the responses?“
Rahul volunteers and everyone hands him their sticky notes.
The process continues for each spoke of the Development Practices Radar. At the end, Bob asks each of the volunteers to calculate the average for their set of sticky notes.
“Here are the results,” says Bob. Bob draws a Team Radar on the whiteboard:
“Wow. I wasn’t expecting that!” says John. “I was sure the lowest average rating was going to be on Managing Technical Debt, but that’s actually one of the highest!“
“With this new information, is everyone okay focusing only on Shared Coding Standards for the rest of the retrospective? It seems there’s a lot of room for improvement in that area,” asks Bob.
The team agrees.
What did this accomplish?
“Let’s spend some time analyzing Shared Coding Standards to see what’s truly going on,” says Bob. “First, start thinking about what forces are helping you maintain good quality Shared Coding Standards. What’s working in your favor? Whenever you think of something, jot it down on a sticky note.“
“It’s important,” Bob continued, “to not filter anything out right now. Just write down whatever you think of. We’ll narrow down our choices later.“
“I’ll set a timebox of 5 minutes. Go!“
Everyone starts thinking on their own and the sticky notes start piling up.
“Time’s up!” A few people quickly finish writing down their last idea.
“Next, I’d like you to think through all the forces that are preventing you maintain good quality Shared Coding Standards. What’s working against you? I’ll set another timebox of 5 minutes. Go!“
More sticky notes are created and before long, the timebox is up. Everyone looks at Bob.
“Now, please self-organize into subgroups of 3-4 people. Discuss what you wrote down and pick 1-2 supporting factors and 1-2 prohibiting factors that you’d like to bring to the broader group. Whenever you’re ready, put those factors up here on the whiteboard. I’ll set the timer for 5 minutes. Go!“
Everyone organically splits into smaller subgroups. You can hear the energy in the room as Bob walks around making sure everyone knows what to do.
“Time’s up! Finally, let’s vote on the issues you think are strongest in each column. You can only vote on 2 issues per column. Go!“
When the votes are tallied, it turns out that the strongest driving force towards good quality Shared Coding Standards is the fact that by default everyone’s development environment is setup using a standard configuration. And the strongest restraining force that is preventing improvement in the team’s Shared Coding Standards is the lack of agreement on what those standards should be in the first place.
John pipes up. “If we took the time, I bet we could come up with agreements on our coding standards. What do the rest of you think?“
“Absolutely,” Erica responds. “I’m glad this came up. It would be great to be on the same page about this.“
What did this accomplish?
“Perfect. It sounds like we’re ready to move on to coming up with an action we can commit to as a team,” says Bob. “What I’d like for you to do next is to start brainstorming what the team can do to come to agreement on this. I know it can be a contentious issue! I’ll set a 5 minute timer. Go!“
As the team brainstorms actions, Bob draws a single horizontal line on the whiteboard. On the left hand side of the line he writes the word “Low Impact” and on the right hand side of the line he writes the word “High Impact”.
When the timer is up, Bob says: “Ok folks. Come on up to the board and put your ideas somewhere onto this line to indicate how impactful you think your idea might be. Don’t be afraid to move other ideas around so that we have a view into how impactful each idea is compared to the others.“
Everyone on the team comes up to the board and places their ideas onto the line. Some conversation ensues as sticky notes are moved around, but within a minute or two, the group is done.
That’s when Bob draws another line onto the whiteboard, this time a vertical line half way down the middle. On the top of the line he writes the word “High Effort” and on the bottom he writes the word “Low Effort.”
“Now, move the sticky notes up or down to indicate how much effort they will take. Go!“
The resulting diagram looked like this:
Almost immediately, John said: “The only idea with high impact and low effort is using an automated process like Prettier. It will make all our code follow the same standards automatically!”
“I can’t believe this wasn’t obvious before,” Mary responded.
Everyone agreed — this made a lot of sense. It would remove the arguments. Remove the need for documentation that needed to be kept up to date. And it wasn’t even hard to accomplish.
“Let’s do it!” everyone agreed.
The power of retrospectives, Bob thought to himself.
What did this accomplish?
“Almost done, everyone! Come back to the center of the room. I’d like everyone to stand in a circle.“
The group looked at each other, puzzled. John made a snarky comment, “Not another game, Bob. I thought we were done!“
“Almost,” Bob said. “I want these retrospectives to work for you. So before we call it a day, I’d like for you to pick up one sticky note and write down just one thing I can do better next time. It’ll help me improve the retrospective experience for you.“
Everyone wrote something down.
As the team started walking towards the door, Mary said, “Bob, I want to thank you. That was so much better than any other retrospective I’ve ever been a part of. I felt like you really helped us as a team.”
Bob just smiled.
What did this accomplish?
Want to know when the next chapter is available? Sign up below to be among the first to receive each chapter.
So you’ve mastered the 5 phases of a successful retrospective. 🔥 Up next: how to become a better facilitator during each of the phases.
.png){kind=small}
.png){kind=icon}