Category: Enterprise DevOps

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 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?

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. 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 arise, what 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 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 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. 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 that says “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 prevent 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 speed bumps 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 are 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 would 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. 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 knowledge, better collaboration and alignment throughout the whole organization. So, you should really think intentionally about what you want from these meetings.

— John Lafleur