Why your retrospectives aren’t generating continuous improvement

#1: Not all retrospective formats are conducive to gathering improvement data

When you type in retrospectives in Miro, you get a variety of templates. This is usually what people have in mind when they think of retrospectives. 

Two of my personal favorites are:

• The 3 piggies houses: helps the team categorize areas in which they are strong (brick house), where they are average (stick house), and where they could use improvement (straw house). This format can provide great insights and help your team learn about their strengths and weaknesses. 
• The high performance team tree: helps the team understand what performance looks like. While this format was originally used to teach scrum to new teams, people loved it so much that they began using it in retrospectives. Your team can design the tree based on their unique values and it’s great to help them understand what success looks like for them.

While these two examples can be useful, beware of the “cool” retrospectives. They are good for generating awareness, deep discussions, and gathering information. It’s what they were created for. However, they are not good for continuous improvement, cognitive overload, making developers speak, and gathering data. 

If in every sprint you’re utilizing complex formats that need to be set-up and orchestrated and result in deep conversations, both team leaders and members are going to be exhausted. Not to mention, they aren’t a favorite of developers (who are more focused on their software) and you aren’t even really gathering data. The team might uncover that they feel they could be collaborating better, but that isn’t data. You still have to dissect that. 

There is nothing about these “cool” retrospectives that will lead us towards continuous improvement. You keep generating insights, but how actionable are they? You may reach some opportunities depending on the skills of the coach or the team, but the format in itself isn’t very conducive. 

There are some scenarios in which these formats are great, such as when you are forming a team. They help the team get to know eachother better. They can also be useful after some milestones are hit in a big project and you’re looking to start anew. They are not retrospectives for continuous improvement, however.

You should pick a format of retrospectives that allows you to have actionable, usable data on which you can consistently follow up. 

This leads us to the next point…

#2: In order to improve, you first need to define improvement and continuously measure it

Just like if you were trying to become a better runner, you need to determine what factors you are going to measure to track your improvement. Speed? Distance? Heart rate? These are all possibilities. (Check out this blog post for more details on how to effectively measure improvement.) The same is true when it comes to improvement in our teams. Instead of just practicing retrospectives, we need to move towards improving results through measurement. 

As you enter a retrospective with the insight of continuously improving, you want to look into something that is not random or trending. It is based on something you agreed on as a team that you would be following for a while. It is continuous. 

How do you decide what you want to follow up on? It’s really very simple: you ask one question. Maybe it’s even something that a “cool” retrospective helped you determine! It could be anything and be very broad. Is our pace sustainable? Are we delivering with quality? Are we delivering the right thing? 

Lean in to the broad question and now, you need to determine how to go about answering that question. Pick one or two things max to measure at first. You can’t improve if you are always looking at something different. You can build a dashboard based on your question to help you track and visualize your data.

Maybe you are asking the question “do we have a sustainable pace?” Your team suggests answering this question by measuring the amount of bugs, overtime, and missing release dates. Combine these and discuss how to get this info, even if it’s manually. Every sprint you’re going to look at what these numbers are telling us. 

It can happen that over time, the numbers aren’t really telling you much. You can then engage in some deep conversations. But whatever is happening here, it’s good to remember that you are already working from a perspective of looking ahead on the pre-agreed improvement.

Why data for improvement in retrospectives

Data-based retrospectives help improvement as:

• Improvements are tangible
• Simpler to organize and to participate
• Discussions and points actionable
• Gathering data
• Can be run faster and more effectively
• Can be run by anyone
• Brings transparency

It is important to watch out for disappointment when the numbers don’t budge, and data being gamed. 

Remember, if it’s worth improving, it can be measured. By understanding the impact, you can determine how to measure it. For example, if the team feels they are not collaborating enough with team ABC, think about what happens as a consequence of that. Do builds break because we don’t talk enough? Is that what is contributing to our bugs? If they think so, then measure those things.

If you can’t transform it into something tangible, it is just a complaint. You start to have a different relationship with improvement and the things that are worth discussing with the team. Whatever you feel is hurting, is worth improving. It should be defined and then can be measured. 

So, if I can sum it all up for you: 

Ask a question that is worth answering, decide what to measure, and gather and analyze the data regularly. For months. 

If you can do this, you’re well on your way to continuous improvement.