Uncharted Waters

Nov 7 2016   11:39AM GMT

Agile Retrospective Ideas

Justin Rohrman Justin Rohrman Profile: Justin Rohrman


A few things happen at the end of every agile release cycle if you’re dong agile ‘by the book’– a demo to show off what will be delivered to the customer, a meeting to start talking about what to develop for the next sprint, and a retrospective.

The retrospective is an airing of grievances with teeth. People talk about what went well over the past two weeks. But more importantly, they talk about what didn’t go well and what they what they might do about. In my experience, the retrospective is a sign of dysfunction.  Not the retrospective itself, driving toward improvement is good, but the fact that there is a dedicated meeting.

Let me tell a couple of stories.

My first encounter with retrospectives was around 2006. At the end of each sprint, our (fairly large) development team would go into sequestration for an hour or two to talk about the sprint. The byproduct of this meeting was a couple of lists on a white board. There was a column for what went well, and one for what didn’t go well. The column of things that didn’t go well was normally longer. From this list, we were supposed to pick of few things that we wanted to do different over the next two weeks. Something we could experiment with and ideally make life, the product, or both better for everyone.


We made our lists. Some of the ideas would get picked up and tried, some would stay on the vine and be forgotten about. Inevitably, people would get busy with the task of building software. Retrospectives were a net positive at that company, but only marginally.

Retrospectives were fast and painful at another company. We scheduled some time after every release to talk about what happened. This group was more introverted, so it took some time to warm up and get the conversation moving. Our manager would usually get frustrated with the pace of conversation and take over. Rather than developers talking about their take on the release, we spent 20 or 30 minutes listening to this manager talk about what he thought went wrong, and what we were going to do next time. Afterwords, we would talk on chat (sans-manager) about what a waste of time that was and then get on with our days.

So, Antipattern?

There are plenty of stories about people being happy with retrospectives, about how they helped development teams. Those are my stories about how I have experienced them not working. I think that retrospectives are an antipattern in software development, but in the same way that scrum, or kanban or any other framework designed to reduce the number of decisions people need to make are. These frameworks can be a sign of trouble. Companies that don’t know what they need to improve or how they could make improvement pick up these decision frameworks to make things a little easier.

Using a retrospective is a sign that there is trouble, but it is also a sign that a team is starting somewhere. The more I read about the average of agile practice, the more I value what XP has to offer. Rather than meetings to talk about what happened, there is a flow. Groups can make observations about what happened, make decisions about how to move forward, and then go off in that direction without waiting. Given the choice, that is where I would want to be.

Retrospectives may be an antipattern, but that might not be such a bad thing. They are a sign that something can be improved, and if development teams have the power to focus on improvement maybe eventually they don’t need the structure of a retro and can just take action.

 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: