Chapter 15
The Sprint Retrospective

Todd worked with a Scrum team that was adding new features to a fitness application. They had just completed their second sprint review, with many stakeholders present. There were a few tense moments between the stakeholders and the product owner but overall the sprint review was a success.

Immediately afterward, the development team and Scrum master gathered for the sprint retrospective. Here’s how it unfolded:

Matt [developer]:

I’d really like to try some pair programming next sprint. I’m struggling a bit to understand the one pattern that we’re using. I mean, I’m doing it, but I’m just not sure it’s the best way. It would be nice to have an extra set of eyes.

Peter [developer]:

I disagree. We’re getting a ton done working the way we are now. You saw it—the stakeholders and product owner are happy, so why mess with our approach? Matt, I’ll send you an online article about the pattern. You should be understanding this by now. I don’t understand why you’re not picking it up.

Other developers:

[Silent, awkwardly staring down at notepads.]

Scrum Master:

This seems like an opportunity, perhaps a chance to try some pair programming. Who wants to try that with Matt?

Peter:

I’m out. I don’t have time for that—it’s a complete waste of time. My improvement for this next sprint is for us to get better at estimating. I’ve got to go. It’s time for lunch, and my time is better spent coding than sitting in meetings. You’re the Scrum master—you keep the product owner and stakeholders happy while we code. Your job is to keep us out of meetings. My job is to actually deliver things. [Storms out.]

Every sprint after that, the tension kept rising until development team members rarely spoke. The product they delivered to the customer reflected the lack of communication within the team—the application was buggy and the user interface wasn’t cohesive. After several conversations and chances, the customer fired the entire team because of their inability to get the job done.

Each sprint retrospective is a chance for the Scrum team to reaffirm its commitment to continuous improvement. A team uses the time to reflect on team dynamics, quality, defining “done,” and seeking ways to improve the way we deliver potentially releasable products every sprint. Without approaching this event openly and finding ways to improve every sprint, your product, its quality, and the people working together on it will suffer.

Scrum is just a framework. People are the power behind the roles, events, and artifacts. If we as a team are not collaborating, helping, supporting, and challenging ourselves to improve, we’re missing a crucial opportunity to improve the way we serve our customers.

In this chapter, we explore some of the sprint retrospective anti-patterns that Scrum teams experience. Remember that there are two sides to Scrum: the people and the technology—and during a retrospective, the team needs to explore both.