If your team isn’t doing retrospectives regularly, here’s what happens: at the end of the project, you gather your team to select, debate, and document the hard-won lessons you learned throughout the course of the work. Fantastic! Insights are mined and polished, and everyone leaves the meeting feeling cathartic. But what happens next? Before you begin your next project, are you likely to pore over the lessons? Frame and hang them above your cubicles? If your team is like mine, probably not — we’re busy.
So how do you keep the insights from wasting away in a Google Doc? Instead of waiting until the end of the project, find and implement improvements regularly.
Okay, what’s a retrospective?
A retrospective is a meeting (or, in the language of Scrum, a “ceremony”), in which the team reflects on the last sprint in order to decide how they can improve. A cornerstone of agile software development is the idea of continuous adaptation — that teams must constantly fine-tune their process and their work to accommodate changing requirements, interpersonal dynamics, internal resource competition, and a hundred other things. This continuous approach to reflection is a shift from typical waterfall processes, in which space to reflect and suggest improvements is only available at the end of the project. Retrospectives are the most essential tool in the Agile toolbox for facilitating adaptation.
A few words about what retrospectives are not:
- Retrospectives are not blamestorming sessions. If the fresh scent of the last sprint is a foul one, contributors may be primed to dole out blame for perceived failures—or worse—gang up on a particular person. While constructive criticism is essential in these meetings, the facilitator should focus the conversation on discovering root causes in order to craft solutions for the next sprint. Despite the moniker “retrospective,” these meetings are really about the future.
- Retrospectives are not a hugfest. Some teams, especially high-performing teams, may want to avoid the hard work of examining failures and instead pat themselves on the back. While every team deserves a feel-good retrospective from time to time, no team is immune to improvement. If your retrospectives consistently end with a round of kumbaya, you’re doing it wrong. A well-facilitated retrospective will typically suss out at least one or two issues that deserve attention.
- Retrospectives are not a locker-room pep talk. If managers are invited to retrospectives, they may use them to motivate, question, or force changes or improvements. While there is certainly a place for managerial oversight in Agile development, retrospectives are not it. Team members should be free to express their opinions and feelings without having to impress or coddle a manager. The simplest way to ensure this is to not invite the managers. If they must be present, have them assume an observer role without speaking privileges.
So how do you retrospective?
My favorite format for retrospectives is the Agile Sailboat. The upshot of the exercise is that the team imagines themselves in a boat and collaboratively maps the external and internal forces that sped or slowed their progress during the last sprint. It’s a kitschy way of soliciting structured feedback, and since each team member is required to share at least a few ideas on sticky notes, the discussion isn’t tilted towards louder contributors.
There are plenty of other formats for retrospectives too, including the Celebration Grid, Start — Stop — Continue, and lots more. Whatever format you use, the aim is to create a safe space for your team to evaluate their strengths and weaknesses and design corresponding improvements for the next sprint.
More important than the format for the retrospective is the tone. In a team environment, each person’s success is tied to the success of the team as a whole. Everyone must know they’re being heard, and everyone must know that sharing about a personal improvement is not seen as a professional failure.
A note about improvements. Steve Jobs was famous for forcing his employees to focus on just one or two big things at a time. As painful as these choices may be, humans just aren’t very good at changing things, so we have to do it slowly. At the end of your retrospectives, there will likely be a wealth of proposed improvements to choose from, but ask the team to settle on just one or two realistic ones, and forget the rest. You might feel as though you’re leaving some great ideas for improvements on the table, but if they’re that great, they’ll resurface again in future retrospectives.
Finally, commit to implementing the improvements, and then actually implement them. During your next sprint planning meeting, don't just plan the work you'll be doing, plan a method for implementing your improvements. If you do this well on a regular basis, your team will begin to believe they can tackle whatever problems arise.
The best way to document lessons is not to write them in a Google Doc; it’s to integrate them into your culture immediately. By facilitating the opportunity to identify improvements regularly, and embedding them in your process continually, your team will adapt to its ever-changing environment faster—which, I believe, is what it means to be Agile.