Overcoming reluctance towards Retrospectives.

This post was inspired by Mike Cohn’s: Does a Scrum Team Need a Retrospective Every Sprint?

We at CatapultLabs realized that it is very often that we find a team member that either does not perceive the full value of having an Agile Retrospective session every sprint or that is simply boring and unwilling to take part in a retrospective. There’s always someone asking around if retrospectives are really necessary.

In this post, we list the most common objections to retrospectives that we hear from team members, and we’ll also briefly describe how to deal with those arguments in your team. We took inspiration in Mike Cohn’s article, where he tried to counter every argument he hears on a team that is trying to get away with not having a retrospective session every sprint.

Our team is TOO GOOD for retrospectives. We rarely come up with anything to be improved. There’s no point in running retrospectives, so we want to stop.

It is highly unlikely that your team is so good, that there are no improvements worth making. There’s always that little detail that will come up. You need to take the time. In fact, if no more issues are coming up, rather than thinking you can’t improve anymore, you should make some changes and find the adequate dynamics for your team.

Retrospectives are BORING.

No one said retrospectives should be a walk in the park, or even exciting. But we can’t blame a developer if a meeting goes out of topic or timeframes are not respected. You’ll find yourself sometimes discussing in great lengths small details that not everyone considers interesting. Maybe your facilitator is not the most entertaining person there is, but there’s always a way to liven meetings up.

Mix things up, change the schedule of the meeting, or even change the facilitator. You’ll benefit from the change in style. Change the venue. Try a retrospective with a different format. (i.e. a retrospective of tools used, of services required, a retrospective of retrospectives, etc).

Another way to spice things up and have a good flow during the session is to use a retrospectives tool. There are several out there on the market, such as Agile Retrospectives for Confluence or Agile Retrospectives for Jira, to host the sessions inside your Jira project for even easier follow-up. Tools can help you make your retros more efficient, engaging, dynamic and easier to follow-up.

Our team is too busy with real work. We have no time for retrospectives.

If you hear something like this coming from your team, then they has a very shortsighted view. A shortsighted team will put more importance and value on the few lines of code that can be done during the 30 minutes that the retrospective takes. 30 minutes of your schedule can result in findings that you would never imagine being a problem. You SHOULD be able to take 30 minutes by the end of every sprint if you want to improve in the next sprints.

We don’t like retrospectives.

Just like there are people who claim retrospectives are boring, there’s also people who simply don’t like them. And you know what? It may be time to say “too bad” for those team members. Everyone is expected to be professional and not all of the aspects of a job are enjoyable.

If retrospectives are helping the team, the team should be doing them. Too bad for those bored people.

The Exception: When is it ok NOT to do a retrospective every sprint?

There is one situation where is conceivable to skip retrospectives after a sprint. Here’s when. Only if your time complies with ALL of the following, may you consider not to do a retrospective every sprint. (Not every sprint, does not mean to get rid of them completely).

The team is really good. Like really, reeeeally good. This means, they are familiarized with Agile methodologies, they keep delivering after every sprint, and they are also comfortable with the team and the product they are working on.
They’ve already tried different dynamics to make sure a retrospective isn’t boring.
Every team member understands the value of doing other tasks other than just the more pleasant work.
The team understands the importance of investing in improvements that won’t pay back immediately.
The team already works in short sprints. We’re talking 1 or 2 weeks sprints.

Agile methodologies call is to have one every single sprint, but it also calls for sprints of up to 4 weeks.
Even if your team complies with ALL of the above, and for some reason decided to take shorter sprints your Scrum Master should still try to encourage the team to have retrospectives every sprint. However, you should be open to the possibility of having retro sessions every other sprint to make it a more fruitful session and avoid repetition.

Remember, ONLY if your team has a very, very high level of performance and understanding of Agile methodologies AND works short sprints, can you conceive having a retrospective every other session. Otherwise, you should be having them EVERY single sprint. Even great teams that have longer 4-week sprints should not skip having one by the end.

If your team does retrospectives, or if it doesn’t, be sure to check out Agile Retrospectives for Confluence. and Agile Retrospectives for Jira The perfect tools for running retrospectives and keep your team engaged, assign and follow up action items, and as a result, a state of constant improvement.

What other excuse have you heard from your team? Let us know in the comments, and Happy Retros!

Trying to improve your #Agile practices? OR are you getting started with Agile? Are you in a remote team? Check out our products for Agile teams at CatapultLabs. We focus on making agile ceremonies more effective and easier to adopt for remote teams.

Check out our Atlassian tools:

Follow us on our networks:
Facebook: /CatapultLabsTeam
YouTube:CatapultLabs
LinkedIn: @CatapultLabsTeam
Email: hello@catapultlabs.com
And Subscribe to our blog below!