In short
The root cause of a missed milestone is usually a decision made months earlier, not the team that was visibly late at the end. Finding it requires replaying the program's decisions in order — each warning, who saw it, and what was deferred — which is only possible if those decisions were recorded as they happened.
Why do retrospectives get it wrong?
They rely on memory and interviews, weeks after the event. People remember the end of the story. So the finding is the last symptom: “verification was late.” The request for more engineers that was deferred three months earlier is forgotten.
What does a real root cause look like?
On one program, samples missed by seventeen days. The replay showed: coverage flagged off-trend 104 days out; two engineers requested and deferred to a quarterly review at 87 days; a timing impact flagged at 62 days; a freeze deferred at 41 days with the cascade predicted but not escalated; an integration failure at 28 days. The cause was the deferred capacity request.
What needs to be recorded?
For every significant change:
- What drifted, and when it was first visible.
- The suspected cause at the time.
- What was done about it, or deliberately not done.
- Who approved that.
- What happened as a result.
Why record the fixes that failed?
Because a memory that only keeps the successes teaches nothing. Knowing which interventions merely moved a slip downstream is as useful as knowing which ones saved the date. Tymeline writes every cycle to the record, whether or not the repair worked, and the next program starts with it.