Retrospectives: Why you need them, and how to get them right
Unless you are a one person team, you are working with a process. It can be an explicit and defined process like Scrum or Kanban, it can be something of your own concoction, or even just a set of unspoken rules and expectations among you and your coworkers.
The thing about processes is that they can either be the best thing for your team’s productivity, or they can be the reason your team never delivers anything on time. Sadly, most processes tend to gravitate towards the inefficiency end of this spectrum. That’s why when people think of processes they usually have an alarm bell going off in their head. They perceive the process as something that gets in their way, stops their flow, dictates their actions and generally just slows them down. And with good reason: Who among us was not victimized by coma inducing meetings, or conventions that consume precious time without actually producing any tangible value?
Process tends to become inefficient in a similar way to how software tends to become bloated: It contains bugs, it accumulates useless features over time, and it gets filled with ad hoc solutions to problems that no longer exist. Process, like software, can easily become cumbersome to the point of embarrassment. Unless, that is, someone cares enough to stop every now and then and clean it up.
This is true no matter what kind of process you have in place. This is why you need to hold retrospectives at regular intervals.
Let’s start by defining what a retrospective is
According to the Scrum guide, the retrospective is “an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint” (https://www.scrum.org/resources/what-is-a-sprint-retrospective)
If I would change anything about this sentence, it’d be “inspect itself” to “inspect its process”. The retrospective is less about individuals and much more about how individuals work with each other. It is a common pitfall in retrospectives that people get hung up on what certain individuals did right or wrong. Pointing fingers is worse than a waste of time, it breaks down the spirit of cooperation and trust in the team. The retrospective assumes that people are well intentioned and want the team to succeed. If that’s not the case, then those individuals need to be handled on the HR/management level.
In retrospectives we deal with the way of working, rather than with the work itself.
With this in mind, here are a few tips for running a productive Retrospective
Have clear, actionable outcomes
Most meetings succeed or fail on whether they manage to produce crystal clear outcomes. The retrospective is no exception. Most retrospectives feel like a waste of time because the focus tends to be on raising issues and discussing them rather than trying to distill clear changes to the way of working.
Since the retrospective is about improving the team’s process, its products should fall into one of the following three categories:
1) Removal of a process component
2) Adjustment of a process component
3) Creation of a process component
By process component I mean a small part of the process: A convention, a rule, some way of working. process component is an agreed upon, written down rule that the team agrees to follow. It could be broad, like “We hold a Backlog Refinement meeting every Tuesday”, or it could be narrow, like “the Backlog Refinement meeting is only about epics, not stories”. The scope matters less than the specificity. By specificity I mean the degree to which when you read it, you know exactly what is expected, and whether it’s clear what kind of behavior would violate the process. This clarity is key to maintaining a healthy process over time.
A healthy retrospective dialog will produce various kinds of conversations, like complaints, praises, general remarks, or other things that do have value in being expressed and heard. They certainly have a place in a retrospective and they help with figuring out how the process should be changed. But these conversations are only there to facilitate the goal of the retrospective. You need as a team to figure out how to distill these conversations to concrete process changes.
Don’t be afraid to challenge assumptions
Many teams have some deep seated process components that everybody assumes are a basic fact of life. This assumption makes them hard to challenge, even when most members know in their bones that these process components are not serving any constructive purpose.
Let’s take the daily stand ups of Scrum for example. You may have experienced firsthand how in some teams stand ups have the tendency of taking much more time than allotted. The 15 minutes stand up consistently extending to 30 minutes or much, much more is a scenario most of us had the displeasure of experiencing. Yet, few teams challenge the necessity of a daily standup even when it is clearly dysfunctional in their team.
Remember that process components only exist to help the team. If your stand ups always exceed their timebox or if team members find them an unproductive daily drag, they can and should be challenged in the retrospective. Have no mercy for process components that impede the flow: either alter them or remove them. Once a process component is removed it becomes clear quite fast whether it ever had any value. If it did, identify what that value is and devise a process component that brings that value back.
The one process component that should be guarded from discarding is the retrospective itself, without which constructing and maintaining a healthy process will be left to random chance.
Hold the retrospective at regular intervals
You can’t tell in advance if a change to the process is going to work out or not. Every change requires a trial period. Making sure to hold the retrospective at regular intervals (following the same guidelines for a Sprint interval) will allow you to constantly try out process changes.
Did your team decide in this retrospective to get rid of the daily standups? You now have a 2 weeks trial period to see what it’s like to have no standups. That should give the team plenty of time to get a feel for whether the new reality is an improvement, without causing too much disruption to the team if the change wasn’t actually beneficial. Next retrospective you will review this change and decide whether it improved or impeded the team’s workflow, and adjust accordingly.
The fixed interval lets you schedule all future retrospectives at once, instead of having to find a slot each time. In my experience, the latter approach will result in retrospectives being continually postponed. Retrospectives provide most of their value as a continuous, ongoing activity that looks back on a given time period in order to adjust the upcoming time period. As a singular events that happen sporadically you will find that most of this value is lost.
Insist on clear, unambiguous and measurable changes
A common retrospective anti pattern is changes that are subjective and unclear. “Write more tests”. What does “more” mean, and how much “more” do you need to satisfy this rule?
If it is not very simple to see whether you are following a process component or violating it, it’s a bad process component. The process has to be composed of dead simple and obvious components, so that it can quickly grow to be second nature. A constantly evolving process that is hard to keep in mind will not work out, as people will constantly have to look up how they should be working. A constantly evolving process that is designed to be easy to follow, however, will cause very little overhead with each introduced change.
Pay close attention to the wording of retrospective outcomes and become allergic to words like “more”, “less”, “should”, “shouldn’t”. If you can, convert the outcome to “If X then Y” or “Always X” or “Never X”. Strive towards clear as daylight outcomes that cannot be misinterpreted or unmeasured.
Let failures happen. Investigate them in the retrospective
This one is a bit situational, but holding retrospectives regularly does open up the possibility of postponing reaction to process or team mistakes and failures, rather than having to deal with them on the spot. When you know you will have an avenue to address a mistake or a failure in the forum of the entire team, you don’t have to respond to it on the spot and address it. There are benefits to be had by letting failures unfold and only picking them up for discussion at the upcoming retrospective. Discussing the failure with the team rather than one on one often leads to more insights on the failure and how it can be avoided. Waiting a bit before reacting to mistakes also gives you time to collect your thoughts and avoid over reacting on the spot. But the most important one, to me, is that the team learns best from failures, and best adopts process changes when they clearly see the failure the change is trying to address. Better yet if they propose the change themselves.
Example template for a Retrospective meeting
This is the template I am currently using with my team. There are many ways to hold a constructive retrospective; I chose to present my current template to illustrate the points above and to get you started with coming up with your own approach.
“Did we make it” is basically answering the question “did we meet our sprint goals”?
In our team we have two types of sprint goals. The first is a group of epics, a subset of our planned sprint work, that we marked as the most valuable to moving our product forward. If we have 5 epics planned for this sprint, we typically mark two of them as Sprint Goals. This goal is fairly objective; whether we finished the sprint goal epics is pretty much evident.
The second sprint goal is to end the sprint with a stable, releasable product iteration. If we finished all our epics and stories for the sprint but ended up with a product that is less usable and less stable than before, the sprint is considered to be a failure. This is somewhat more subjective, and we try to be honest regarding how we feel about the stability of the product at the end of the sprint.
“Felt right / Didn’t feel right” is an open invitation for people to share what made them enjoy their work this sprint, and what detracted from their enjoyment. There is no need to go into or solve every issue that is brought up. The idea is to warm up people to participate and to prepare the grounds for looking at the process and seeing if it needs adjustments according to how people felt this sprint.
The real heart of the Retrospective is the Process review. This is where the actionable items are generated . In “thing we want to try”, we put down changes to the process that we want to pilot in the upcoming sprint.
In “Thing we tried and want to keep” we put changes that were piloted and proved themselves.
In “Thing we tried and want to throw away” we put process components that we don’t want anymore. They usually come from “Thing we want to try” or from “Things we tried and want to keep”, but not necessarily.
Over time, the “Things we tried and want to keep” column becomes an overview of the team’s current process.
Finally, “Action items” is for assigning process related tasks to an individual. These tasks are usually an exploration into a process change we want to implement but need more information regarding technical or organizational difficulties.
Here’s an example of a filled template from an actual retrospective with my team:
Note that the “things we want to try” column contains two items that directly address things that were brought up in “Didn’t feel right” (“make future sprint swimlanes on epic board” relates to “epic list is unclear” and “guild session to be brought up in stand up” relates to “guild meeting was not shared”). However, not every item in “didn’t feel right” was addressed. Not everything requires addressing (the one time OSS licensing training, for example), and sometimes it takes an issue to pop up in multiple sprints to realize we need to find a fix for it and for the fix to become apparent.
In “Things we tried and want to throw away”, we discovered that writing detailed user stories feels like a waste of time, and that short stories with a good title was enough.
“Things we want to keep” seems to be loaded, but it’s an accumulating column, containing all the things we put in there in previous retrospectives. As long as something still works for us, we keep it in there. Having it visible in the retrospective helps us to quickly evaluate whether we’re still happy with the process changes we’ve made.
Do retrospectives
Often perceived as another Scrum fluff, retrospectives are the unsung heroes underpinning any successful process. The difference between a good process and a bad one is the difference between a fun place to work where your team usually meets its goals, and a stressful environment where nothing gets done on time and dissatisfaction and resentment rules the day. Surely holding a regular meeting dedicated to process improvement is worthy of your time.