Continuous Improvement over Retrospectives

The Retrospective is Scrum's most powerful tool for sustaining and improving productivity. After each sprint, the team gathers the most critical pain points and agrees on a few specific ones that should be dealt with during the next sprint. Success is tracked from sprint to sprint.

The value of Retrospectives

Harnessing the power of retrospectives, the organization gains transparency on why developers are impedited and through the improvement activity, productivity is brought to whole new levels. 

In organizations strongly embracing change, it is not rare for newly formed Scrum teams to see a productivity boost of well over 200% within a couple of months.

Yes, you read right: Retrospectives are the key to hyperproductivity.

What happens when you don't have Retrospectives?

Well, that one is easy to answer. The team gets into a treadmill of delivering feature after feature, sprint after sprint, release after release, year after year. The same old problems linger, get persistently ignored and nothing changes until someone and disrupts the process.

The most common kind of disruption here is that developers simply get fed up and leave. The next type of disruption is that the next "powerful methodology" comes up and because it promises so much better results, Scrum gets abandoned. Those are still okay. But what if the disruption is that a competitor throws out a much better product, delivering much faster and cheaper - and takes over your customers?

In Waterfall projects, people conducted either "Lessons Learned" after each major Release - or "Post Mortem" after each failed project (to the point that Post Mortem became the Standard project closure process). But hardly ever was anything done about it.

Retrospectives try to change this behaviour by frequently inspecting and adapting the process. You fix what's broken rather than cleaning up the shambles.

So - why should ne not have can anyone say Retrospectives are bad? Well, they are not "bad". But they are a suboptimal state. Consider the following a stimulation of thought rather than bashing.

Why having Retrospectives is bad

Deferral of thought

Oftentimes, team members purposefully do not think about improvement until the Retro, because the Retro is the time to bring up issues. This is not an inherent problem of Retros, but of mindset. It is absolutely false to consider that we should not think about Continuous Improvement when we are outside the Retro meeting.

Deferral of solution

In each Retrospective, the team will agree on the most pressing 1-3 issues, so that productivity is not replaced with internal improvement. Unfortunately, this kind of thinking is absurd: If the team has too many issues, it may simply be better to solve them all at once before loading up yet more technical debt.

If there are pressing issues that damage productivity more than their resolution costs, why should you defer the solution for a couple sprints?

Absolution for suboptimal work

One of the major outcomes of Retrospectives are adjustments to the Definition of Done. On the flip side, the DoD is immutable for the duration of a sprint. However, if team members are already aware that their DoD is suboptimal, they should not adhere to inefficient standards but rather do what common sense dictates: Huddle, resolve, continue efficiently.

Thinking within the box

Retrospectives are team-centered. Purposefully, external stakeholders are NOT invited, as the Scrum Primer states. Is it right to consider all problems to be local when everyone knows they are not? Maybe, the team can't even see a problem until an external stakeholder escalates and then there's an emergency: Sprint termination, crisis meetings and general panic. Is this necessary?

Why would you give the team a forum to speak their entire mind - but not to the customer? Is their opinion worth less than that of the developers? Especially if they could help with the solution! So - how will the team harness the improvement potential that others could offer?

Problem thinking

A key element of Continuous Improvement is problem solving. But it isn't the only element. This is not intrinsic to Retros, but to the practice implemented in many teams. When do they have time to think about mastering their expertise, turning Good to Great? As long as there are pressing issues, solving a problem may defer the strife for excellence. However, it may be better at becoming exceptional in one area than becoming okay in all areas.

Summary

It is good to have Retrospectives. If your reason for not conducting Retrospectives is that "We don't find anything to improve" or "We can't accomplish anything anyways" - that's your #1 pressing problem and reason to call an emergency Retrospective.

On the other hand, Retrospectives are on the same line as any other Scrum event: It is good to have them, but it is better to work in flow: As soon as something comes up, harness it. Do not batch up, do not defer. Involve stakeholders, engage customers. 

Everyone should be on a continuous watch for improvement potential and should jump at every opportunity to produce a positive bottom line for the team, the company, the product - and the customer.