Book Excerpt: Agile Retrospectives
A key Agile practice, retrospectives help teams examine what went right and what went wrong on a project. But traditionally, retrospectives (sometimes unfortunately called "post-mortems") are only held at the end of the project - too late to help. Agile teams need retrospectives that are iterative and incremental, to accurately find problems and design solutions that help teams improve early on, when improvement yields the most benefit.
In addition to publishing the chapter for our readers, we asked the authors a few questions about the making of their book:
Esther: Yes, we've both used Norm's book. In fact, we're both mentioned in it. I've known Norm since 1991, and for a long time he kept telling me, "You have to meet Diana. You really have a lot in common and your skills are complementary." He finally engineered a meeting by asking us both to co-convene the first Retrospective Facilitators Gathering with him (which still meets annually). We've been having fun working together ever since.
What we wanted to add to Norm's book was the idea that you don't have to wait until the end of a project to do a retrospective. Even if you aren't on an Agile team, you can hold retrospectives at releases, milestones, or at regular intervals to improve the way the team is working.
Diana: Since Norm wrote about retrospectives at the end of projects, he described situations that benefited by bringing in an experienced facilitator from outside the team. We wanted to show that team leaders and team members could lead the process themselves for short, tightly-focused iteration retrospectives. We talked to Norm as we were starting this book, and encouraged us to go forward with the project.
InfoQ: Can you tell us a real story about a team has that found retrospectives a helpful tool?
Diana: We hear lots of stories. One that immediately comes to mind is about an XP team that consistently used retrospectives to improve their processes. They challenged themselves to think up innovative experiments for the next iteration. One of their experiments looked at finding the sweet spot for time spent pair programming with different members of the team. Arlo Belshee presented an experience report at the Agile2005 conference on the increase in productivity they created ("promiscuous pairing").
Esther: I remember talking to one team who had most of their engineering practices worked out, so they used their retrospectives to work on handling conflicts. Over time—and by taking time to inspect, experiment, and build skills and confidence one iteration at a time—they learned how to navigate the sort of "normal " conflicts that come up on every team. When there was a major disagreement, they had both the skills and the trust to handle the issue within the team. And as a side benefit, because they were dealing with all the stuff on the team, their manager could spend more time on eliminating organizational blocks and obstacles. Which, of course, made it easier for the team to build software.
InfoQ: What one message do you want people to hear about retrospectives right now?
Esther: Teams don't get better unless they step back and inspect and adapt their methods and interactions. Retrospectives are the mechanism to do that.
Which brings us back to our exclusive book excerpt: Chapter 10: Make It So.
Andy: Feedback is essential to Pragmatic Programmers; retrospectives are an invaluable technique to gather and act on feedback from the whole team. Esther and DIana's book is a down-to-earth, pragmatic approach to facilitating on-going retrospectives.