Cruise missile

From Pearl Language
Revision as of 09:00, 16 May 2014 by Martien (talk | contribs) (New++)
Jump to navigation Jump to search

…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 (done done) 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 if the specification is stable beyond a minimum level. Include the item’s stability measure in the ready to build. Follow any and all changes in the spec 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.


✣  ✣  ✣