Difference between revisions of "Only move forward"
(Zeroth version.) |
m (<strike>tire</strike>) |
||
| (4 intermediate revisions by the same user not shown) | |||
| Line 6: | Line 6: | ||
|wish=Collecting good and self-generated metric data can generate improvement actions that increase productivity. | |wish=Collecting good and self-generated metric data can generate improvement actions that increase productivity. | ||
|so=Only promote items—never back them up to a previous state—and mark the item blocked until all earlier work completes. | |so=Only promote items—never back them up to a previous state—and mark the item blocked until all earlier work completes. | ||
|image=Tire-Damage-Road-Traffic-Signs.png | |||
|prologue=At McLaren they say, “We only move forward.” | |prologue=At McLaren they say, “We only move forward.” | ||
|wish full=Since {{p|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. | |wish full=Since {{p|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. | ||
|background= | |background=For example, you are running a {{p|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. | ||
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 {{p|cumulative flow diagram}}. | 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 {{p|cumulative flow diagram}}. | ||
Often, you can't even move it back since the proper state is full (meets the {{p|work in progress limit}}). | |||
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. | 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. | ||
Visualizing that the item is blocked implies that: | |||
*the item needs more work, is waiting on some event to happen before it can be promoted; consider using a different color for sticky notes that indicate incomplete previous states that can be resolved by the team (as opposed to waiting for an external event to happen); and | |||
*the first action for the team is to swarm the item and unblock it (assuming this behavior is {{p|explicit policy}}). | |||
Have your {{p|explicit policy}} support activities ‘foreign’ to the current state. For example, analyzing and developing code is okay when the item is in the Test state. You can even generalize this by saying that all activities are allowed in any state to secure that the item meets the admission criteria for the next state. | |||
Bottom line: Do not back up. Severe <strike>tire</strike> metrics damage. At McLaren they say, “We only move forward.” | |||
|therefore full=Only promote items—never back them up to a previous state—and mark the item blocked until all earlier work completes. | |therefore full=Only promote items—never back them up to a previous state—and mark the item blocked until all earlier work completes. | ||
|new=If you are running {{p|scrum}}, make sure you {{p|track done}}. You can also park the item in the {{p|blocker waiting room}} to further visualize and help you work on the right items at the right time. | |||
Tighten up your {{p|babushka of value}} and {{p|explicit policy}} when appears to be a structural issue. | |||
Be careful not to overuse ‘blockers’, as they will lose their value. | |||
}} | }} | ||
Latest revision as of 06:45, 21 January 2014
- 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.
Often, you can't even move it back since the proper state is full (meets the work in progress limit).
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.
Visualizing that the item is blocked implies that:
- the item needs more work, is waiting on some event to happen before it can be promoted; consider using a different color for sticky notes that indicate incomplete previous states that can be resolved by the team (as opposed to waiting for an external event to happen); and
- the first action for the team is to swarm the item and unblock it (assuming this behavior is explicit policy).
Have your explicit policy support activities ‘foreign’ to the current state. For example, analyzing and developing code is okay when the item is in the Test state. You can even generalize this by saying that all activities are allowed in any state to secure that the item meets the admission criteria for the next state.
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. You can also park the item in the blocker waiting room to 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.
Be careful not to overuse ‘blockers’, as they will lose their value.
✣ ✣ ✣