How To Rethink Sprint Retrospectives To Shape A Better Culture

What if sprint retrospectives could be rethought so that it stimulates more motivation and learning for the team at every iteration?

DATA

August 11, 2020

John Lafleur

Summarize with AI:

How To Rethink Sprint Retrospectives To Shape A Better Culture

If you have been in a scrum team (or even an agile software development team), you most certainly have had or heard about sprint retrospectives, or gone through them. They often happen after the team showcases the work done during the sprint during the sprint reviews or demos. The original intent behind retrospectives is to help the team learn and improve faster as a whole, with an iteration at every sprint. What if sprint retrospectives could be rethought so that it stimulates more motivation and learning for the team at every iteration, and have its value spread across the whole organization? Growing knowledge and awareness within your team is great, but growing knowledge and awareness in your whole organization (including other departments) is better.

The fact is retrospectives are part and parcel of the engineering culture, but also the company culture. In this article, we will quickly go over the current way of doing retrospectives, before seeing the different ways their impact can be strengthened.

What is a sprint retrospective? Well at least, the current understanding

There are plenty of resources about what a sprint retrospective is. Simply put, the sprint retrospective meeting lets you analyze your process in the previous sprint and create a plan for improvements in the next. It gives the scrum team the opportunity to ask and address questions such as:

What did we do right in the previous sprint?
What did we do wrong in the previous sprint?
What should we start doing in the next sprint?
What should we stop doing in the next sprint?
What can we do to improve productivity?

You want to keep these simple and short, and possibly use some templates, so that the team can easily memorize and improve on every iteration. You would want to keep the team focused, otherwise it can just turn in a social gathering. And the retrospective can even include some thinking about the retrospective process itself. Nothing is out of bounds.

Be careful to avoid bashing or criticizing, as well as allowing boredom. If the same question is repeated at every retrospective, your team might not participate anymore. If the same questions arises, how can we do differently so that it is finally fixed?

Overall, the end goal is self-improvement as a team that always strives to perform better as a team, as well as self-improvement for every individual, scrum master and product owner.

What’s wrong with current sprint retrospectives?

There is nothing wrong with the way we handle retrospectives currently, per se. It’s just that there are huge missed opportunities. Sprint retrospectives are about growing the team as a whole as well as all its team members. And, think of the possibilities if we were able to do the same across the organization?

Actually, sprint retrospectives are much more part of the organizational culture than we might initially think. It’s among the few things that happen on a weekly or bi-weekly basis with other team members. Doing sprint reviews, demos and retrospectives in the right way will shape your team and individual growth, in addition to the organization’s talent retention.

Sure, there are a few well-documented things that you need to be wary of when doing a retrospective. I’ll list them fast, but won’t dwell on them because that is not the point of this article.

Boredom: Having the same questions asked regularly will get your team bored and the feeling that retrospectives are useless. One way to avoid this is to change things a bit. Iterate on the retrospective itself, or have a different retrospective meeting leader each time.
Lack of candid conversation: Without conversations, feedback and ideas flowing, retrospectives are useless. It’s important to foster participation from everybody. If you see a lot of blank stares, it might be useful to think about other ways to get participation such as putting ideas on paper anonymously. But at some point, your team needs to feel comfortable to share their ideas without fear.
Ego: It’s vital to put the team productivity above individual needs. So there shouldn’t be any place for emotions, as it will thwart honest conversations from happening.
Disagreements: It’s more than okay to disagree. There is a quote: “diversity in counsel, unity in command”. The more disagreements, the more ideas will be flowing, and the end result will be the best ideas. However, once an agreement is made, everybody needs to unite behind the decision
Conflicting agreements: Let’s face it, that can happen. In the end, a decision needs to be made, and as stated above, then everybody needs to get behind the decision.
Tired of change: Attempting too many improvements may actually impede the team from improving. In that case, making sure everyone is keeping up is the most important. Sometimes it’s best not to change anything, but just to retry as becoming good at something takes time and persistence. Also, it might mean it’s time to iterate on the sprint retrospective itself.

4 ways to rethink and improve sprint retrospectives

Now, let’s see what we can do to improve retrospectives, as well as spread its benefits throughout the organization by improving its culture. Some of these points will directly address some of the speedbumps mentioned above.

1. Positive reinforcement

You need to be very explicit about positive learning, so you have more willingness to share within the team. It might be interesting to rename the “retrospective” to“wins”. For instance, “sprint wins” or “week wins” if you do those every week, or “Friday wins” if the retrospective happens on Fridays.

The name will emphasize that we are here to improve and not blame. “Wins” can also remind people of the demos, as the new features and work done can be considered new product wins.

2. A ship-it culture

Software only creates value for customers once it’s shipped. That’s a fact.

Shorter cycle times lead to both higher productivity and higher satisfaction, there has been quite a lot of study on this. Only presenting work that has been shipped during the sprint demo will emphasize this point and will spread a culture of shipping fast and often. You shouldn’t present work that’s almost done or waiting to be merged to master. Deploying a developer’s work is what is most exhilarating for the developer.

By promoting a shipping culture, your team will gain more confidence and will express more motivation thanks to creating this high-velocity momentum sentiment.

3. High energy and inclusive

We already mentioned some retrospective techniques - only shipped features, no blaming, only positive learning. But that’s not enough if you want to have the full attention of the whole team during those retrospectives. For this reason, you need the retrospective meetings to be high-energy with time limits. Time limits can make them actually fun for both presenters and audience, as there is some kind of challenges. And everybody loves fun challenges.

But also, you need to make the whole team participate. Some teams might not have shipped anything in the sprint or week. Still, you need to find ways to make everyone part of the meeting, through questions or participation to the discussion.

Finally, why do we have sprint retrospective meetings only within teams? They create new learning opportunities for the other teams too. That’s why they should be inclusive to anybody in the team, but also to all the other teams (well, until the size of the meeting is no longer sensible).

4. Cross-functional as learning can be

Coming back to the last point about learning opportunities, it’s also a missed opportunity for other departments, too. For example, if sales and marketing better understood the progress of projects, they will gain a better understanding of how software engineering actually works. Companies that succeed have teams that respect each other’s work and collaborate well together.

Plus, it’s awfully hard to predict who needs what information in a big company. So leaving the retrospective meetings open to anyone could help people get the information they need.

So it’s worth the effort to invest in making attendance as easy as possible - support for remote people, etc.

Would you still do intra-team retrospectives?

Should these meetings stay only within teams? Should you have intra-team retrospectives with all the discussions, before a general one with only the demos and learnings?

The point of this article is that sprint retrospectives are a great opportunity to drive more learning, better collaboration and alignment throughout the whole organization. So, you should really think intentionally about what you want from these meetings.
Let us know how your ideal retrospective meeting looks like in your comments. We got some great inspirations from Kellan Elliott-McCrea.

About the Author

John Lafleur

John Lafleur is the COO and Co-Founder of Airbyte.

Try Airbyte Agents

Be among the first to explore our new platform and get access to our latest features.

Try it free

How To Rethink Sprint Retrospectives To Shape A Better Culture

Try Airbyte Agents

Related posts