The Improvement Board Nobody Reads

The retrospective is producing a list instead of change, and the Scrum Master's ownership is a large part of the cause.

Symptoms map directly to causes:

• 27 open items is a work-in-progress problem. Nothing finishes because everything is nominally in flight. Cap improvements in flight at one or two.
• The Scrum Master writes and chases the actions - so the team owns none of them. The Scrum Master should own the follow-up rhythm; the team owns the actions and the evidence.
• The same three topics recur because the team keeps generating actions against symptoms rather than causes. Spend the time on one theme and go deeper: five whys on the build server, with data.
• Re-explaining old ground means the previous session's output is not being reviewed. Open every retrospective with ten minutes on the last experiments: what did we try, what happened, what do we learn.

Change the format: start from data rather than feelings (build duration trend, interruptions per week, cycle time), pick one theme, and leave with at most two experiments - each with an owner, a date, and the measure that will tell the team whether it worked. Ending with a shorter, sharper list is the improvement.

Run two tracks at once: change the system, and reduce the pain while you wait. These are different jobs and conflating them is why the items have been open for nine sprints.

Track 1 - escalate with numbers, not anecdotes. 'The build server is slow' is dismissible; 'the build takes 40 minutes and runs about six times a day across eight developers, roughly 4-5 hours a day of waiting, close to a sprint of capacity every two sprints' gets onto the central IT change board with a cost attached. Same for the interruptions: count escalation tickets per week and the stories they disrupted, then take that to the VP of Sales. The Scrum Master's role is precisely to remove impediments the team cannot remove itself - quietly absorbing them is a failure of the role.

Track 2 - mitigate locally and explicitly. The team can split test suites, parallelise or cache builds, and agree an intake channel with a named support rotation so Sales has one route in and a response commitment. Treat mitigations as temporary relief, not as closure of the item.

And a stakeholder fix, not just a technical one: the VP of Sales is behaving rationally because escalating works. The durable answer is an agreed service level between Sales and the team, owned by someone senior enough to hold it.

Measure outcomes of the experiments, not activity on the board.

'Number of improvement actions completed' is a vanity metric - the team already has 27 of those and is no better off. Instead, choose a small set of measures tied to the experiments chosen, and baseline them before starting:

• Build duration and build queue time.
• Interruptions per week reaching developers, and their source.
• Cycle time from 'started' to 'done'.
• Escaped defects.

Two disciplines make this work. First, review the measures at the start of the next retrospective, not in a quarterly report - the feedback loop has to be short enough to change behaviour. Second, be willing to conclude an experiment failed and drop it. A team that cannot abandon an action will accumulate a board of 27 again within two quarters.

The deeper signal of success is a shift in who owns improvement: if in three sprints the actions are proposed and driven by team members rather than by the Scrum Master, the retrospective has started working regardless of what the numbers say.