The Final Retrospective
Bringing closure to the team
7 March 2017
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
That's how I felt when my manager told me the contract had fallen through and we were out of a job in a week. It wasn't personal or performance based — defense contracts don't always make sense.
I still felt gutted, and I know our manager did, too. Despondent, he said, "Let's cancel the standups next week — there's no point."
"I disagree," I said. "Let's hold the meetings anyway. It can't hurt to give people some space to talk. We don't need to do the planning meeting, but we should have the review and retrospectives."
After the weekend passed, we went into the retrospective with heavy hearts. As the meeting start time came, an awkward quiet settled over us.
"So . . . " piped up one of the programmers, in his wonderfully sarcastic voice. "Is there anything anyone would change?"
That broke the tension and we all had a good, morbid laugh over the change in our circumstances. The change in our team — even if we all get hired at the same place, the culture won't be the same, and we'll all have to adjust to new ways, new tools, new people.
"Good place to start," I said. One of the developers suggested a "bitch session," and I agreed — we gave space for everyone to vent a little bit about their worries and fears. About health insurance and finding another remote job. About letting go of a product that has been eight years in the making. We talked about what the next steps are for us — who's looking where, and what our options are. We also discussed the logistics of the draw-down — capturing passwords and accounts for third-party tools currently tied to our work emails, deleting personal data, returning computers, and filing paperwork.
As things wound down, I finally said, "Well, this is a retrospective meeting, and we don't have to discuss how to change and improve our Scrum for the next sprint. But I would like to have a quick go-around to highlight what we did right, not just in the last sprint, but overall as a team."
There was another silence, but it was thoughtful this time. Finally, they started talking. It was easy to be productive in our team. Nobody got in anyone's way. Everyone was professional and independent. Once we had started using Daily Scrums, we brought organization to chaos, and our communication with the client improved immensely.
One of our senior developers finally captured what I'd been unable to say: "I felt like this was an actual team. That's rare." Everyone agreed. Coming together as a functional team, staying functional, avoiding blame culture — if I had to identify one thing I was proud of in my time here, it was the sum of all of that.
As the meeting ended, there was less of a sense of trauma over the loss of our jobs. Sure, we're all still worried. But we're also all finishing up what tickets were still lingering, closing out bugs, wrapping up a few tasks, and packing our laptops up to send back to the corporate office. We aren't weeping. We might be worrying on a personal level, but we aren't cut adrift and still reeling.
The primary purpose of the retrospective meeting is to improve for the next sprint. But secondarily, it serves as an important human interaction with the rest of the team. At the end of a project, especially one that ends abruptly, holding that space can be a valuable way to bring closure for your team and help them transition more easily into their next positions.
Current rating: 5 (1 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.