After the Storm
Documenting what went wrong
Post-Crash Retrospective — XR Demo Environment
Pulse Works — Facilitated by Ren · Notes by Hina
What Went Well
- Tetsu identified and resolved the rendering pipeline failure within 3 hours
- Team mobilized quickly despite it being a Friday evening
- Client communication was handled promptly — Saki sent a status update to Director Kudo within 20 minutes of the crash
- The Kanban board made it easy to see which tasks were blocked by the outage
What Didn’t Go Well
- Only Tetsu had the knowledge to diagnose the crash — single point of failure
- No rollback procedure existed for the demo environment
- Three team members waited idle for 2.5 hours while Tetsu debugged
- The crash was caused by an untested configuration change pushed without review
- No monitoring or alerts were in place to detect the failure early
Action Items
- Tetsu: Document the rendering pipeline architecture by end of next sprint
- Ren: Establish a change review process for environment configurations
- Hina: Research monitoring tools and present options by Thursday
- Team: Schedule cross-training sessions on critical systems — starting next week
Saki brought Ren coffee — he smiled for the first time all day. [crossed out]
Retrospective
Definition A meeting held after a project phase or event to evaluate what went well and what didn't.
Components Structured agenda (what worked, what didn't, what to change); safe environment for honest feedback; documented outcomes; assigned follow-up actions.
Related lessons learned, action item, process improvement
Example The post-crash retro above follows a classic three-section format. Ren facilitated; Hina captured notes. The structured approach surfaced issues nobody had raised during the crisis itself.
Lessons Learned
Definition Knowledge gained through project experience that can benefit future work.
Components Context of the experience; what was expected vs. what happened; insight gained; recommended future behavior.
Related retrospective, root cause, continuous learning
Example "Only Tetsu could diagnose the crash" is not just a problem — it's a lesson learned about the danger of knowledge silos that should inform how the team structures future work.
Root Cause
Definition The fundamental reason for a problem or defect.
Components Distinguishing symptoms from causes; systematic investigation; may involve multiple contributing factors; leads to corrective action.
Related lessons learned, process improvement, retrospective
Example The surface problem was "the demo crashed." The root cause was an untested configuration change pushed without review — a process gap, not a technical fluke.
Process Improvement
Definition A deliberate effort to enhance efficiency or effectiveness of a process.
Components Identifying the current state; defining the desired state; implementing changes; measuring results.
Related root cause, retrospective, continuous learning
Example Ren's action item — establishing a change review process for configurations — is a process improvement designed to prevent the same root cause from recurring.
Action Item
Definition A documented task assigned to a team member with a deadline.
Components Clear description; assigned owner; due date; success criteria; tracked to completion.
Related retrospective, process improvement, lessons learned
Example "Hina: Research monitoring tools and present options by Thursday" is a well-formed action item — it names the owner, the task, and the deadline.