Difference between revisions of "Cruise missile"
m (Cosmetics.) |
(Therefore += {{p|small is beautiful}} and {{p|ka-ching a day makes product owner hurray}}) |
||
Line 12: | Line 12: | ||
*Incorporating any changes in the spec while the item is in progress—like a cruise missile—often is a shorter path than nudging it after it hits the original target. | *Incorporating any changes in the spec while the item is in progress—like a cruise missile—often is a shorter path than nudging it after it hits the original target. | ||
*Responding to change is a core value of the {{p|agile manifesto}}. | *Responding to change is a core value of the {{p|agile manifesto}}. | ||
*Shorter lead times make following and hitting the moving target easier (more effective and efficient) | *Shorter lead times make following and hitting the moving target easier (more effective and efficient). | ||
*Freezing the specification during implementation requires (significant) adjustments and nudging after it hits the original target. To freeze the spec, have the item: | *Freezing the specification during implementation requires (significant) adjustments and nudging after it hits the original target. To freeze the spec, have the item: | ||
**refer to a specific revision of the spec; | **refer to a specific revision of the spec; | ||
**include a copy the relevant parts of the spec (‘copy on write’). | **include a copy the relevant parts of the spec (‘copy on write’). | ||
|therefore full=Only start working on an item | |therefore full=Only start working on an item when the specification is stable beyond a minimum level and when the effort to implement it is expected to be below a couple of days—{{p|small is beautiful}} and {{p|ka-ching a day makes product owner hurray}}. Include the item’s stability measure in the {{p|ready to build}}. Follow any and all changes in the specification while the item is in progress. | ||
|new=Consider to track the number of spec changes while the item is in progress. Trigger a {{p|retrospective gathering}} if it exceeds a predetermined threshold (for example, 3). Tighten up your {{p|ready to build}} to get the {{p|user story}} more stable, hence a lesser moving and volatile target. | |new=Consider to track the number of spec changes while the item is in progress. Trigger a {{p|retrospective gathering}} if it exceeds a predetermined threshold (for example, 3). Tighten up your {{p|ready to build}} to get the {{p|user story}} more stable, hence a lesser moving and volatile target. | ||
}} | }} |
Revision as of 09:11, 16 May 2014
…working on getting items ready to ship, that is, tested and accepted according to functional and technical design.
✣ ✣ ✣
Getting the item done as quickly and efficiently as possible, ensuring that it passes all tests and is ready to ship, even when the requirements and specifications change while the item is in progress. That is, how can you hit a moving target?
Forces
- If the moving target outpaces the implementation effort, you will never hit it—it outpaces and ‘outcompetes’ you.
- A more stable target is easier to hit.
- Incorporating any changes in the spec while the item is in progress—like a cruise missile—often is a shorter path than nudging it after it hits the original target.
- Responding to change is a core value of the agile manifesto.
- Shorter lead times make following and hitting the moving target easier (more effective and efficient).
- Freezing the specification during implementation requires (significant) adjustments and nudging after it hits the original target. To freeze the spec, have the item:
- refer to a specific revision of the spec;
- include a copy the relevant parts of the spec (‘copy on write’).
Therefore:
Only start working on an item when the specification is stable beyond a minimum level and when the effort to implement it is expected to be below a couple of days—small is beautiful and ka-ching a day makes product owner hurray. Include the item’s stability measure in the ready to build. Follow any and all changes in the specification while the item is in progress.
✣ ✣ ✣
Consider to track the number of spec changes while the item is in progress. Trigger a retrospective gathering if it exceeds a predetermined threshold (for example, 3). Tighten up your ready to build to get the user story more stable, hence a lesser moving and volatile target.
✣ ✣ ✣