Challenging Sprint Retrospectives

An essential question in the use of Scrum seems to be ” How can we make our (Sprint) Retrospectives more fun? ”

When digging a bit deeper, I always end up puzzled. I always end up wondering about the value and the level of team engagement. I wonder what sort of fun they are looking for. I wonder about the understanding of Scrum. I wonder about the subject of inspection and adaptation at their Sprint Retrospective. I wonder what purpose they are using Scrum for.

I wonder because Done Increments are at the heart of Scrum, crucial to optimally use empiricism as a way to increase agility. I wonder about the real purpose of a Sprint Retrospective when so few teams are able to actually deliver releasable versions of product, no later than by the end of a Sprint, Sprint after Sprint after Sprint. And that inability only increases proportionally, if not exponentially, with the number of teams when delivering one product.

If Scrum was to be reduced to one purpose, and one purpose only, that is the creation of a Done Increment in a Sprint.

Not achieving that purpose today is not failure. Failure is to stop moving towards that purpose. Failure is to stop inspecting and adapting towards that purpose. Not creating Done, releasable versions of product means sub-optimal use of Scrum. The danger is to stop challenging that status-quo.

Understanding that Scrum Masters are all about helping teams and organizations in understanding and enacting Scrum, following might be a great way to start your next Sprint Retrospective:

• Scrum Master: “Have we delivered a Done, releasable version of product this Sprint?”
• Team: “No.”
• Scrum Master: “What can we do about that?”

Next to checking in with the team on their sense of engagement, how is that to kick off a professionally challenging Sprint Retrospective? Wouldn’t you expect that to initiate some serious reflections? Wouldn’t you expect the team to start initiating improvements that will help them and the organization get more from employing Scrum? Does that not lead to considering what actually is defined as “Done”, and what is needed to achieve that state of work and quality?

Committed, connected and engaged people will have serious conversations about:

• How to increase effectiveness through collaboration, autonomy & self-organization?
• What skills & knowledge are needed and (un)available?
• Are our development practices & standards appropriate and up to par?
• How are our access, knowledge and use of infrastructure, tooling & automation?
• What are the quality standards & guidelines that we should take into account?
• What are the toughest Impediments? Does our Scrum Master know? Can we help in the removal of them?
• How can we increase our focus? Can we stop attending external meetings? How can we eliminate other forms of work of low value?

How is that as a start for identifying some ‘fun’ experiments and improvements in the next Sprint?

I that doesn’t engage people and appeal to their sense of professionalism, check what is needed to increase the level of team engagement. If reflecting, considering and investigating such questions doesn’t engage people, find out what is killing engagement.

I wish you fierce, focused and engaged Sprint Retrospectives. It’ll be seriously fun. Fun and happiness are important. Engagement however is the key. Fun is no replacement for team engagement. Fun techniques are no replacement for serious conversations.