The hidden life of agile work: follow one item through its waiting

Earlier this week, we looked at the gaps between active steps: the time when an item is ‘in progress’ but nobody is working on it.

To make those gaps visible, follow one item through its journey.

Start small.

Choose a recently completed piece of work and reconstruct what happened from the moment it started to the moment it finished.

Continue reading The hidden life of agile work: follow one item through its waiting

The hidden life of agile work: most delays happen while nobody is working on the item

An item can spend days ‘in progress’ while nobody is actively working on it.

Someone has started it. Everyone involved is busy. Yet the item is waiting for an answer, a review or its turn in somebody else’s queue.

If we want to understand why delivery takes so long, we need to notice the gaps between the work.

Continue reading The hidden life of agile work: most delays happen while nobody is working on the item

The Sprint ends, but the work’s history does not disappear

A Sprint gives a team a useful rhythm. At its end, we inspect what we have achieved and plan what comes next.

But unfinished work does not become new work just because a new Sprint has begun. It carries its history with it.

Continue reading The Sprint ends, but the work’s history does not disappear

Scrum Master as systems steward, not process police

The common misunderstanding

One of the most persistent misunderstandings about the Scrum Master role is that it exists to enforce process.

  • Ceremonies must happen.
  • Rules must be followed.
  • Frameworks must be complied with.

Seen this way, the Scrum Master becomes a kind of process police officer – checking attendance, correcting behaviour and reminding people what Scrum says should happen.

But that framing misses the point of the role entirely.
Scrum does not exist to be obeyed.

It exists to help teams work effectively in complexity.
And complexity does not respond well to enforcement.

Continue reading Scrum Master as systems steward, not process police

When ‘keeping people busy’ feels safer than finishing work

One question I’ve heard repeatedly from managers moving towards agile ways of working is this:

“But what happens if someone finishes their task early?”

On the surface, it sounds like a practical concern.
Underneath, it’s often something else entirely.

What’s really being expressed is anxiety about visibility, value and safety in an uncertain system.

Over time, I’ve come to see this as a clash between two different value systems.

Continue reading When ‘keeping people busy’ feels safer than finishing work