Scrum Notes 2013-20

| contents

Seeking 100% Value ▶️

What value do you get from the scrum events? This was the question posed to a team when I heard the usual "Scrum has too many meetings" complaint. I asked each member to write a % number for each event they attended. The picure above is the result.

On average then, this is how much value the team assessed their scrum events to have:

  • Sprint Planning: 43%
  • Daily Scrum: 63%
  • Sprint Review: 61%
  • Sprint Retrospective: 53%
  • Grooming1: 50%

If I went to meetings, that on average gave me only 50% value I'd likely share the mindset that there are "too many meetings in scrum".

I actually don't believe that scrum has too many meetings. I believe that scrum has exactly the right amount of meetings. We meet in order to align i) with our customers, and ii) with each other. Without alignment we get lost, we work on things of dubious value, and we have no idea who cares about what we do. Still, as a once-upon-a-time developer myself, I know I'd rather write code than spend time in meaningless meetings, so I can identify with the frustration.

A common solution to this problem is to stop doing scrum, or reduce the number of alignment events. In the case above sprint planning would be the first to go—with only 43% it is the biggest time drain. But if we don't plan—which means to make decisions on what to do next in order to achieve our purpose—then what do we work on? Vagueness and disgruntlement will will be our companions for the next week or two, or until that urgent extra meeting where we are called together to be told we're working on the wrong thing, or working too slowly—or both (!)

So often I've heard words to the effect of "Scrum doesn't work for us so we are going to do Kanban". Kanban is seen as the soft option, allowing teams to meet less, talk less, and worst of all shy away from the dysfunction that scrum has began to unearth. Kanban isn't intended to be a cop out, but sadly that is how it's so often perceived by those who struggle with scrum.

The problem is not too many meetings, it is too many ineffective meetings. This comes back once again to organizations seeing scrum as a process, and missing the principles. Telling people to meet every day, when in fact they are all working on different tasks for different features and have nothing to share with each other is surely a waste of time, likewise meeting with a PO who hasn't given forethought to her requests, or attempting a retrospective when no one is willing to actually take action to change anything.

Rather than abandoning alignment, get better at it. Make your scrum events useful. Or at least attempt to. Begin each event with a clear, prioritized agenda. Start and finish on time. Avoid rabbit holes. If you are bored, disconnected or confused, say so. Ask for clarity, get involved, challenge, confront, ask questions. If you find yourself at a scrum event where you are not adding value and not getting value (the two usually go hand in hand) then seek a way to steer the event towards value, or as a last resort leave the room. Do something meaningful instead. But don't disengage. Afterwards, reflect on the event with your team mates, and plan and prepare for the next event to go differently.

Every event you attend—indeed every work meeting of any kind—should have 100% value for 100% of the participants. If your event falls short of this, reflect and improve.

Scrum events, when effective, engage and motivate people, establish focus, allow everyone to be aligned on the journey, and reduce unnecessary waste. The Scrum events are not overhead, but sometimes the attitudes are.

1 The term 'grooming' was dropped from the Scrum Guide in July 2013, but still current at the time of writing (and the time of this exercise) so it has been retained here, despite my dislike of the term. Whether called grooming or refinement this aspect of Scrum has always been described as an ongoing activity, and never as a specific event or meeting. In practice however, many teams put regular time aside each sprint to refine their backlog.


Palo Alto, 14/03/2013   comment