Here’s the situation: a department with 5 development teams, several of which are starting to do Scrum. The Scrum Masters have a problem. They couldn’t fix impediments. Not being part of management, they weren’t taken seriously by the rest of the organization. Escalating every second impediment to management wasn’t working either. When impediments don’t get fixed, Scrum doesn’t work and everybody gets demotivated. Here’s a shot at solving the problem…
One: Identify an Escalation Team (ET) who will be responsible for handling issues when the ScrumMasters get stuck. This consists of the Department Manager and his immediate reports. One of the ScrumMasters is also ScrumMaster for this group.
Two, following Karl Scotland’s description of Kanban, embark on a four step process:
The value stream for impediments is pretty simple:
Three: Find a strategically located spot for the Kanban board, ideally someplace where every, especially management will see it. This creates visibility for the problems (and for those trying to solve them).
Four: Working with the board. Every significant impediment gets put on the central Impediments board. Every day that a ticket is on the board, tick mark goes on the card. When the ticket is done, it gets green dot if the team is happy with the result, and a red dot if not (i.e. management said, “sorry we cannot fix this problem.”) The goal is to resolve impediments as quickly as possible and to have as high a percentage of green dots (= team happy) as possible.
My team hasn’t looked at limiting WIP or establishing Cadence yet. It’s tempting to put up a scoreboard, counting how many impediments got to done (with a red or green stamp) within one day, 2 days, 3 days, etc. A natural extension would be to set up a paralell board for improvements coming out of the retrospectives. This would give the ET a natural two week rhythm.
This approach creates a feedback loop between Management and operational staff. It gives immediate visibility to the problems and reminds people who might not want to cooperate with a lowly, powerless ScrumMaster that management is watching. It might even offer a metric for evaluating how effectively management is supporting its teams.
How do you get management integrated into the Scrum process? How do you make management responsible for making the process work?