Does a Scrum Team Need a Retrospective Every Sprint?

The Scrum sprint cycle calls for a team to do a retrospective at the end of each sprint. Yet in almost every Certified ScrumMaster course I teach, I'm asked if teams really need to do a retrospective every sprint.

Usually the logic of the questioner is along the lines of:

• Our team is so good, we rarely come up with anything to improve at, so we want to stop.
• We find retrospectives boring, so we want to stop.
• We're too busy with real work (or retrospectives take too long), so we want to stop.
• We simply don't like retrospectives, so we want to stop.

So, in this blog post, I want to briefly counter each of those arguments and say why you should still do a retrospective every sprint. Then, I'll end the post by saying maybe--just maybe--you don't really need to do a retrospective every sprint after all. (Did I surprise you with that? Read on ...)

The Team Is Too Good for Retrospectives

Your team is not too good that it cannot get better. I’ve worked with teams that have been doing Scrum for over 10 years, doing retrospectives every two weeks, and they can still identify ways to improve. It is highly unlikely that your team is so good there are no further improvements either to be identified or worth making.

Retrospectives Are Too Boring

No one said a retrospective should be as exciting as the latest Hollywood blockbuster. But there are things you can to do to liven them up.

For example, mix things up by asking a ScrumMaster from another team to facilitate your retrospective. The change in style can help. (Be sure to return the favor.) Change the venue, possibly holding a retrospective outdoors, even while walking.

Try a totally different format for the meeting. For example, many teams fall into a habit of always looking for new practices to adopt. Dedicate your next retrospectives entirely to discussing what should be dropped from the team’s process. (And, no, “dropping retrospectives” is not allowed.)

Geoff Watts and Paul Goddard offer ten different formats for retrospectives in their video course on retrospectives. Watch it and try some your team hasn’t tried. There are plenty of ways to prevent a retrospective from being boring.

The Team Is Too Busy for Retrospectives

A team that says it is too busy to dedicate time to getting better is taking a very shortsighted view of the future.

In his Seven Habits of Highly Effective People, Stephen Covey used the analogy of a woodcutter cutting a tree for days with a saw. Eventually the saw becomes dull. But with a short-term attitude, the woodcutter will never stop to sharpen the saw.

A Scrum team with a similarly short-term view will never take thirty minutes out of its schedule to look for improvements. Instead they’ll put too much value on the little bit of code that could have been developed during those 30 minutes.

The Team Doesn't Like Retrospectives

This is somewhat a variation on retrospectives being boring. I’ve listed it separately because it does go beyond retrospectives being boring or becoming mundane to some team members. Some team members just flat out don’t like them.

And for those team members, that may just be too bad because everyone on the team is expected to be a professional. And professionals do all parts of their jobs, not just the parts they want to do.

As soon as I finish writing this post, I need to rewrite it to make it better. That isn’t as fun. Then I need to proofread it. That’s not fun at all. Then I have someone else read it. And then I have to accept or reject edits to it. That’s not fun at all.

Not every part of our job gets to be fun. If some team members don’t like retrospectives, but if retrospectives are helping the team find ways to improve, the team should be doing them.

When It's OK Not to Do a Retrospective Every Sprint

But I also said I’d let you know when it’s OK not to do a retrospective every sprint. So, when is that?

If your team:

• Is really good.
• Has made significant efforts to make sure retrospectives aren't boring.
• Is not too busy to invest in improvements that don’t pay them back immediately.
• And understands the value of doing other than just the most pleasant work.

… and if they work in short sprints, I'll say it's OK for the team do retrospectives less frequently.

Here's why. The general Scrum rule is to run sprints of four weeks or less. So a team that truly wanted out of retrospectives could just adopt a four-week sprint.

Consider a team that has chosen one-week sprints for a variety of good reasons. But this team so detests retrospectives that they switch to a four-week sprint just to conduct retrospectives less frequently.

This would be a bad change, unless the change is appropriate for reasons other than just a desire to do retrospectives less frequently.

And so, a good ScrumMaster should really encourage the team to do retrospectives every sprint, arguing against the four objections covered above. But the ScrumMaster should be open in some rare cases to a team doing a retrospective perhaps every other sprint when using one- or two-week sprints.

I want to be clear that I always try to talk a team out of this. I always try to convince teams to do retrospectives every sprint. But if a team really has achieved a very, very high level of performance and is doing short sprints (usually one week), I am willing to acquiesce to their arguments.

I'll then have them do a retrospective every other sprint. And for most teams, that is more frequent than teams doing four-week retrospectives.

What Do You Think?

Do you ever skip retrospectives? Under what circumstances do you think it’s OK (if ever)? Let me know what you think by joining the conversation where this post originated on my blog, here.