More on this book
Community
Kindle Notes & Highlights
Then ask everyone in the room to speak. When someone doesn’t speak at the beginning of the retrospective, that person has tacit permission to remain silent for the rest of the session. Since the point of the retrospective is to help the group think and learn together, you need everyone’s participation.
Every Voice At the end of one retrospective, Brenda piped up. “I’m surprised I talked so much.” Others nodded in agreement. “Yeah, Brenda usually keeps quiet. I’m really glad she talked so much this time. She had a lot to say.” “How did you persuade me to talk?” Brenda asked.
The answer was simple: the retrospective leader asked her to say her name within the first five minutes. This sounds too simple to be true, yet it works.
As the team develops or adjusts their working agreements, notice what comes up. Working agreements are often a clue to what people are worried
We never regret spending time setting the stage—and neither should you. “Saving” time by skipping this part costs time later. When people don’t speak early, they may not contribute at all—and may not buy into the team’s insights and decisions. When they don’t know the approach, people have trouble focusing and may take the group on a tangent. Team values and working agreements help keep the conversations and interactions productive.
have different perspectives on the same event. Gathering data creates a shared picture of what happened. Without a common picture, individuals tend to verify their own opinions and beliefs. Gathering data expands everyone’s perspective.
Start with the hard data: events, metrics, features or stories completed, and so forth. Events can include meetings, decision points, changes in team membership, milestones, celebrations, adopting
new technologies—any event that had meaning to someone on the team. Metrics include burndown charts, velocity, defect counts, number of stories completed, amount of code refactored, effort data, and so forth. Encourage people to refer to team calendars ...
This highlight has been truncated due to consecutive passage length restrictions.
Hard facts are only part of the data. Feelings are at least half the story. Feelings tell what’s important to people about the facts and about the team.
Rather than ask directly how people feel, try asking the question a different way: When were you excited to come to work? When was coming to work “just a job”? When did you dread coming to work? What were the high points? What were the low points? How was it to be on this iteration? When were you [fill in an emotion word—mad, sad, surprised...]? Questions like these let people talk about how they experienced the iteration without using the F word (“feelings”).
Thorough data gathering, and including both facts and feelings, leads to better thinking and action in the rest of the retrospective. Without a shared picture, people are working from a narrow set of data—their own. When people look only at their own data, the team is less likely to commit to changes and experiments. Without feelings data, the team may not address the topics that are most important to them.
Generating insights allows the team to step back, see the big picture, and delve into root causes. When you skip generating insights, your team may not understand how events, behaviors, and circumstances affect their ability to develop software. Time spent generating insights helps ensure that when your team plans an improvement, it’s one that will make a positive difference.
Change happens in the course of normal work. Teams who believe their retrospectives are a waste of time often keep their improvement plans completely separate from their daily work plans. When the plans are separate, no one finds time to do the “extra” work.
Using this structure—Set the Stage, Gather Data, Generate Insights, Decide What to Do and Close the Retrospective—will help your team do the following: Understand different points of view. Follow a natural order of thinking. Take a comprehensive view of the team’s current methods and practices. Allow the discussion to go where it needs to go, rather than predetermining the outcome. Leave the retrospective with concrete action and experiments for the next iteration.
useful goal helps answer the question, what will achieve value for the time invested?
Useful goals for retrospectives include the following: Find ways to improve our practices. Discover what we were doing well. Understand reasons behind missed targets. Find ways to improve our responsiveness to customers. Rebuild damaged relationships.
“Continuous process improvement” may work for a couple of iterations. After that, it’s stale. Switch to a different goal. After you’ve considered the context, propose a goal to the team. If the team doesn’t buy into the goal, ask the team to describe a goal.
