Save your team from a long and meaningless retro.
Here's how I improve retrospectives by making them shorter yet more focused.
The team I was working with was considering stopping their attendance at the retrospective. Despite their experience, their daily work was hindered by legacy issues, leading to unnecessary delays in making changes to the codebase.
Amid all this effort, they had a two-hour retrospective where they talked and talked, but there was no valuable outcome. They began discussing skipping it, feeling that their time would be better spent coding.
As I was trying to better understand the issues, I went for coffee with a couple of engineers and asked why they didn’t like this meeting anymore.
“We just sit for two hours and mostly talk about feelings and subjective impressions. I don’t understand the value of doing that!” expressed Max, one of the most senior engineers on the team. “I don't have enough material to talk about for 2 hours every time” sighted Tim, another team member.
I decided it was time to take charge. That day, I told the team that all the meetings they participated in should feel like a good investment of their time. If this was not the case, we needed to reconsider and do something else.
When Do I See the Need to Simplify the Retrospective?
There is no universally 'right' or 'wrong' structure for retrospectives. Some teams find the traditional 5-step retrospective to be effective, as they appreciate the opportunity to discuss multiple topics and consistently achieve improvements. This framework encourages divergent thinking, facilitating the exploration and generation of a wide range of ideas.
But what is always important is to have a meaningful result from this meeting. This means two things:
Figuring out the most important thing to work on
Agreeing on what to do next.
The extended retrospectives could help with achieving that, but there are clear signs that simplification is needed:
An effective strategy to make the retro more useful and simple.
“Life is really simple, but we insist on making it complicated.”
― Confucius
We'll simplify the retrospective into two essential steps: Reflect and Act. Initially, we'll identify the 1% we want to change, then concentrate on actionable solutions. In other words, we discuss less, but whatever is discussed is meaningful.
Step 1: Reflect (5 to 10 minutes)
This involves reflecting on how the team is performing. Are we progressing smoothly or do we have bottlenecks? Do we frequently rework and reevaluate tasks?
How can we make sure this step is more focused? I suggest two options that can be used alone or in combination
Option 1: Ask questions
Asking questions is part of the typical retrospective schema, but we want to make it more efficient and focused. Let's create specific questions and concentrate on a topic that's important to us.
Option 2: Use data
We can use numerous data points to identify our bottlenecks and other issues. Data is crucial because observing a pattern in the data indicates that issues are genuinely impacting the team's performance.
Try looking at this data:
Analyze the Cycle Time for the last few months. Cycle time is the duration it takes to complete a task or process, from start to finish.
One common place to find this data would be the control chart in the Jira tool:
In this graph, we observe a time series where the vertical axis represents the number of days taken to complete a task. The graph also includes the average value and standard deviation. For more insights on properly filtering and interpreting this data, refer to our cycle time guide.
To optimize team performance, focus on keeping cycle time stable. Identify tasks with the longest cycle times first, as these represent the most significant challenges. This approach helps maintain a low and consistent average cycle time.
The Burndown chart (for Scrum teams) helps us identify the impediments preventing us from completing our initial plans.
This graph illustrates the team's progress in completing planned work over time. It provides historical data on whether we complete all tasks and helps identify reasons for any incomplete work.
Create your own data series
Another strategy to consider is creating your own data series. You can do this by asking the same question on a scale from 1 to 5 before and after implementing specific initiatives. This approach allows you to track changes and measure the impact of your actions over time.
“On a scale from 1 to 5, how good is our knowledge sharing in the team?”
Or even ask about feelings:
“On a scale from 1 to 5 how is the mood in the team?”
To make this approach valuable, collect data points and present trends to the team. This enables focused discussions based on objective information. Analyzing data should be a standard practice, even in shorter retrospectives, as it helps the team focus on facts rather than biased impressions.
Step 2: Act (20 to 30 minutes)
The team should engage in a discussion and collectively decide on the actions they will take. While this may seem straightforward, it can be challenging. This difficulty often arises from either a lack of constructive elements in the conversation or uncertainty about the actions to take.
If you find yourself in either of these situations, you can try the following:
Lead the conversation if it lacks constructive elements.
When the team is spending too much time discussing the problem without transitioning to the solution phase, you can attempt to guide the conversation using this framework:
Formulate your ideas into actionable outcomes.
When the team has ideas about what to try, but they are unsure if these ideas will lead to the desired outcome, consider framing it as an experiment.
What outcome do we expect?
What we will try?
How will we know we have achieved it?
How do we measure the success of the new approach?
The success of this strategy is all about making the retrospective more effective. We can assess the results by analyzing the data over time. Some examples are:
Cycle time will be more uniform
The Burndown chart will look complete at the end of our iteration
Team data points will look better over time
In the team I worked with, many felt that our retrospectives weren't helpful, even though we discussed a lot of things. To address this, I changed our approach to focus on using data.
By analyzing the data, we discovered that the main problem was that investigation tasks were taking too long to complete. While regular tasks usually took 3 or 4 days, investigations were taking up to 2 weeks. This issue wasn't noticed before because we didn't use data in our retrospectives.
To fix this, we implemented a new process to ensure that one person didn't work on the same investigation task for too long without getting feedback from the team.
As a consequence, we stop creating knowledge silos and we were reacting faster to learning.
Thank you for reading. To delve deeper into the topic, you can access the full article or request a call with us.