Only move forward

At McLaren they say, “We only move forward.”

…you are are running a kanban board and an item is pulled into a state (e.g. Test) and it appears the item still has unfinished work from earlier states.

✣  ✣  ✣

Since metrics drive behavior, collecting good and self-generated metric data can generate improvement actions that increase productivity—backing the item up to one of its earlier states messes up your metric data.

For example, you are running a kanban board and an item is pulled into Test, say. Testing the item uncovers that the item is not ready for Test, and still shows uncompleted work from the previous stages like analysis, design or development. It shouldn't have been pulled into the Test state in the first place.

One way to address this, is to eject the item out of the Test state and back in To Do to go through the loop again (and again and again until it meets the Ready for Test admission criteria). This feels quite natural, and sounds logical. The big drawback is that this messes up your metrics and therefore graphs like the cumulative flow diagram.

A better approach is to mark the item as blocked—put a pink sticky note on it—and leave it in its current state, and note what still needs to be done. Get it done until it meets all admission criteria for the next state. Tracking this will trigger improvement actions. Keeping the item in its current state, not backing up to any previous state, will keep your metric data intact.

Bottom line: Do not back up. Severe tire metrics damage. At McLaren they say, “We only move forward.”

Therefore:

Only promote items—never back them up to a previous state—and mark the item blocked until all earlier work completes.

✣  ✣  ✣

If you are running scrum, make sure you track done. Also, a blocker waiting room can further visualize and help you work on the right items at the right time.

Tighten up your babushka of value and explicit policy when appears to be a structural issue.

✣  ✣  ✣