The Scrum sprint cycle calls for a team to do a retrospective at the end of each sprint. Yet in almost every Certified Scrum Master 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.
I want to briefly counter each of those arguments and say why you should still do a retrospective every sprint. Then, I'll tell you why 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.
In fact, it's one of my biggest issues with the term "best practice." Like sirens singing to us from the rocks, best practices can tempt us to relax and stop the effort of continuous improvement that is essential to Scrum.
In her book Implementing Lean Software Practices, Mary Poppendieck quotes Taiichi Ohno, originator of the Toyota Production System, as saying, “There is something called standard work, but standards should be changed constantly. Instead, if you think of the standard as the best you can do, it’s all over. ... [If we establish something as the] best possible way, the motivation for kaizen [continuous incremental improvement] will be gone.”
Don't take away your team's motivation for continuous improvemetn by letting them believe they've already figured out th e best way and have no room for improvement. It just isn't true.
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. (Here's a simple way to run a retrospective, which happens to be my favorite.)
For example, mix things up by asking a Scrum Master 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.)
Marc Loeffler’s book Improving Agile Retrospectives offers good advice on retrospectives, especially on doing them quickly. Read it and give some of the ideas a try. 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 also 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.
