The importance of Retrospectives

"Can't we just skip the Retrospectives when we don't have the time?"

While I am myself not a big fan of the Retropective events that I see in many Scrum teams - when considering skipping Retrospectives, we solve the wrong problem: Retrospectives are Scrum's engine of Continuous Improvment. What matters is not the event, but that the team is constantly taking active steps of improvment. Retrospectives just kick-start the mindset of improvement.

The case for Retrospectives

• The purpose of the Retrospective is finding significant improvement potential. 
•  Significant, from a statistical point of view, is 5% or above. 
•  "5% or above" means, "Something worth at least 2 hours a week" 
• Investing 2 hours every 2 weeks to find something worth 2 hours per week already paid off within a single Sprint. 
•  A team improving by 5%, 25 times a year, will operate at over 300% of their original performance after a year - yes, they will be three times as effective as when they started!
•  A team skipping half of their Retrospectives, doing only 10 a year, will have improved to 150% of their original performance after a year - give or take variation, it will appear as if this team hasn't improved and is almost at their original level.
• A team having effective Retros every Sprint will visibly outperform a team skipping half of their Retros - to the point where they deliver twice the value per time. 
• Or, stated differently - a year down the line, a team doing effective Retros will be worth as much as two teams skimping Retros, and as much as three teams without any effective Retros.

The Bang for the Buck

A team investing into effective Retrospectives is worth twice as much to the company as a team which values delivery over improvement.

Teams taking Retroespectives seriously lead to an organization needing fewer people to deliver the same value. Hence, less coordination. Hence, teams get more autonomy, because they don't need to fit into a management corset.

Hence, developers can spend more of their time doing what they like best: writing code, not sitting in meetings. That makes them happier. And happy brains are more productive.

Also, since developers in such teams are worth so much more to the company, they are worth every cent - a great argument for negotiating higher pay.

Effective Continuous Improvement makes everyone a winner: Customers, getting better products quicker. The company, getting more value without hiring extra people. Developers, who get better working conditions, and deserve higher pay.

Retrospective Antipatterns

We have already touched the first antipattern: Skimping Retrospectives. Every lost opportunity of a Retrospective is an improvement not happening, putting the team behind on their potential, sacrificing a lot in the future to gain very little right now.

Skipping Retrospectives usually happens because teams have ineffective Retros. Each Retrospective that didn't deliver a significant improvement outcome was a waste. Hence, teams need to figure out how to get more value out of their Retro. Hint for Scrum Masters - There's a surprisingly low correlation between form and effectiveness of a Retro.

The third antipattern is giving up too early on improvement: If there are impediments towards improvenent, these need to be resolved, rather than taken as a reason to not improve.

If you feel that Retrospectives don't make you better, then improving that is your highest priority.

True story

I don't like formal Retrospective events all that much, but I do like a good continuous improvement process (CIP). Retrospectives are just one way to do it. CIP can be done totally informal. I just want to tell you this story to see how Retrospectives can transform a team.

One of my teams had a 2-hour lunch break every day. This "break" included having a walk, and talking about improvements. 

After 2 months, we delivered in a week what others would do in a month.

Within 3 months, we finished a project we had forecasted to take roughly half a year. 

Spending only 6 hours a day at our desks.

That's the power of Continuous Improvement done right.

Notice:

In the Post-Scrum Manifesto, I explain why active, continuous improvement is better than Retrospectives - and also, what you might be getting wrong about your Retrospectives at the moment.