Run simplified systems for two full cycles before declaring success — one cycle could be luck
Validate simplified systems by running them for at least two full cycles before declaring success, as one cycle cannot distinguish between successful simplification and lucky conditions.
Why This Is a Rule
After simplifying a system — removing a process step, eliminating a tool, reducing a workflow — the first cycle always looks good. The system feels lighter, faster, and easier. But one successful cycle can't distinguish between "the simplification worked" and "this cycle happened to be easy." Maybe no edge cases arose. Maybe the workload was unusually light. Maybe the removed component would have caught an error that hasn't appeared yet.
Two full cycles provides the minimum statistical confidence that the simplification survives real-world variance. The second cycle includes different conditions — different workload levels, different edge cases, different external pressures. If the simplified system handles the second cycle without the removed components being missed, it's validated. If problems appear in cycle two that cycle one didn't surface, the simplification was premature.
This rule prevents the "simplification euphoria" failure: declaring victory after one easy cycle and dismantling the old system permanently, only to discover in month two that the removed component was load-bearing.
When This Fires
- After removing a process step, tool, or workflow component
- When evaluating whether a simplification should be made permanent
- After a "trial period" of a simpler process
- Any system change designed to reduce complexity
Common Failure Mode
Declaring success after one smooth cycle and permanently removing the old system. "We ran without the QA review step for a sprint and nothing broke — let's make it permanent." But the sprint might have had a light bug load. The second sprint reveals three bugs that the QA step would have caught. Always run the old system in parallel for two cycles, or maintain the ability to revert.
The Protocol
After any system simplification: (1) Run the simplified system for two full cycles (sprints, weeks, months — whatever the natural cycle is). (2) During each cycle, track: did anything fail that the removed component would have caught? Did the simplified system handle edge cases? (3) After two successful cycles → declare the simplification validated and make it permanent. (4) After any failure in cycle 1 or 2 → either restore the removed component or redesign the simplification to handle the failure case.