Over the years, I’ve heard a wide variety of opinions on the topic of “retrospectives”, which exists to “plan ways to increase quality and effectiveness,” according to scrum.org.

But some people seem to hate retrospectives. So what if your team decides not to do them?

While I’m happy to admit that the format of many retrospectives borders on silly, I believe the content of retrospectives (when done appropriately) to be very valuable. In fact, it’s one of the two “formal” methods I advocate for continuous improvement in my course Ship better code faster (the other being the postmortem).

But the content of a retrospective doesn’t need to fit the form of a biweekly meeting, with post-it notes and brainstorming sessions.

If you and your team are able to reflect on your performance and behavior, and actively seek ways of improving regularly without a regularly-scheduled retrospective meeting, then please, don’t waste your time!

On the other hand, if your team is stagnant, or unable to communicate effectively about how to improve things, then maybe a Scrum-style retrospective would be a good place to start.