Plan my session
Plan a concrete work block with agenda, roles, preparation, and a copyable result artifact.
Session: Family Tree Analysis
The plan translates the method into a concrete facilitated work block. Your inputs flow directly into the session brief and work artifact.
Method session with 2-6. The plan uses the existing method logic and the runsheet.
RunsheetUse the session for shared understanding. Contributions are collected visibly, assumptions are aligned, and open differences remain traceable in the artifact.
The session works directly toward Family Tree Diagram. After the session, the artifact should be shareable, reviewable, or reusable.
- 1
Phase 1: Target incident as anchor
20-30 minSet target incident as root: symptom, trigger, contributing factors, affected components. Add tags (for example, payment, retry-loop, deploy-window). Limit to maximum 5 characteristic factors. Hint: If target incident cannot be compressed into five factors, it is a multi-event incident and should be split into multiple trees.
FacilitatorFamily Tree Diagram - 2
Phase 2: Search parent generation
30-45 minSearch incident archive for incidents with overlapping tags. For each candidate check common factors, time distance, owner, component. Require at least 2-factor overlap as parent criterion. Hint: Including all similar incidents as parents dilutes the picture. Keep entry criteria strict: at least two overlapping factors; otherwise classify as sibling or cousin.
FacilitatorPattern-Notizen - 3
Phase 3: Add ancestor generations
30-45 minFind parents for each identified parent. Limit to three generations, otherwise tree becomes unreadable. Mark cross-generational connections as dashed lines. Hint: If connections are still found in third generation, this often indicates a systemic cause reproducing for years. That is the most valuable finding.
FacilitatorSystemische Maßnahmen - 4
Phase 4: Name patterns
30-45 minMark recurring cross-generational factors (e.g., always Friday deploys, always Service X, same on-call handover). For each pattern, name a cause and reach (how many incidents). Hint: Patterns are not correlations. For each pattern, explain mechanism. Without mechanism, pattern is only statistics.
FacilitatorFamily Tree Diagram - 5
Phase 5: Systemic actions
30-45 minFor each pattern, define systemic action. Not incident-specific, but for entire pattern. Assign owner with mandate beyond a single service. Success metric: pattern no longer appears in future trees. Hint: Actions at single-service level treat symptoms. If the pattern is "Friday deploys," a freeze on that day addresses the family.
OwnerPattern-Notizen - 6
Publish artifact
10 minCheck the artifact for completeness, define location, set version or status, and name review recipients.
OwnerFamily Tree Diagram
Session Brief
For invitations, boards, tickets, PR descriptions, or workshop notes.
session-brief.md
Session Brief: Family Tree Analysis
Goal
Artifact: Family Tree Diagram
Working Question
Which earlier or parallel incidents form a family with the target incident, and what systemic patterns become visible through that relationship?
Context
Target incident description; list of suspected similar incidents from the last 3-24 months; postmortem archive or incident tracker; common tags or categories.
Setup
- Format: Method session
- Duration: 2-4 h
- Mode: Workshop or async
- Participants: One analyst with RCA experience (lead); one to two participants from target incident; one owner familiar with previous postmortems; optionally a systems reviewer from adjacent area.
- Owner: One analyst with RCA experience (lead)
- Participation mode: Team round, shared work and alignment
- Outcome logic: Finish artifact
Participation Logic
Use the session for shared understanding. Contributions are collected visibly, assumptions are aligned, and open differences remain traceable in the artifact.
Outcome Logic
The session works directly toward Family Tree Diagram. After the session, the artifact should be shareable, reviewable, or reusable.
Input
Whiteboard or diagram tool (draw.io, Miro, FigJam) with family tree layout (target incident at bottom, ancestors above); incident database extract or postmortem archive; comparison table with columns for incident, date, factors, recurrence indicator; pattern tags.
Preparation
Target incident as root node at bottom. Empty parent rows above. Prepare pattern tags (e.g., deploy-window, cron-conflict, dependency-drift). Keep comparison table on second sheet.
Agenda
-
Phase 1: Target incident as anchor (20-30 min) Owner: Facilitator Action: Set target incident as root: symptom, trigger, contributing factors, affected components. Add tags (for example, payment, retry-loop, deploy-window). Limit to maximum 5 characteristic factors. Hint: If target incident cannot be compressed into five factors, it is a multi-event incident and should be split into multiple trees. Output: Family Tree Diagram
-
Phase 2: Search parent generation (30-45 min) Owner: Facilitator Action: Search incident archive for incidents with overlapping tags. For each candidate check common factors, time distance, owner, component. Require at least 2-factor overlap as parent criterion. Hint: Including all similar incidents as parents dilutes the picture. Keep entry criteria strict: at least two overlapping factors; otherwise classify as sibling or cousin. Output: Pattern-Notizen
-
Phase 3: Add ancestor generations (30-45 min) Owner: Facilitator Action: Find parents for each identified parent. Limit to three generations, otherwise tree becomes unreadable. Mark cross-generational connections as dashed lines. Hint: If connections are still found in third generation, this often indicates a systemic cause reproducing for years. That is the most valuable finding. Output: Systemische Maßnahmen
-
Phase 4: Name patterns (30-45 min) Owner: Facilitator Action: Mark recurring cross-generational factors (e.g., always Friday deploys, always Service X, same on-call handover). For each pattern, name a cause and reach (how many incidents). Hint: Patterns are not correlations. For each pattern, explain mechanism. Without mechanism, pattern is only statistics. Output: Family Tree Diagram
-
Phase 5: Systemic actions (30-45 min) Owner: Owner Action: For each pattern, define systemic action. Not incident-specific, but for entire pattern. Assign owner with mandate beyond a single service. Success metric: pattern no longer appears in future trees. Hint: Actions at single-service level treat symptoms. If the pattern is "Friday deploys," a freeze on that day addresses the family. Output: Pattern-Notizen
-
Publish artifact (10 min) Owner: Owner Action: Check the artifact for completeness, define location, set version or status, and name review recipients. Output: Family Tree Diagram
Closeout
- Update result artifact: Family Tree Diagram
- Define location, version, and review recipients.
- Define owner, next step, and review date.
Work artifact
Pre-filled starting point based on the matching template.
work-artifact.md
Family Tree Diagram: Family Tree Analysis
Working Question
Which earlier or parallel incidents form a family with the target incident, and what systemic patterns become visible through that relationship?
Context
Target incident description; list of suspected similar incidents from the last 3-24 months; postmortem archive or incident tracker; common tags or categories.
Participants
- Owner: One analyst with RCA experience (lead)
- Participants: One analyst with RCA experience (lead); one to two participants from target incident; one owner familiar with previous postmortems; optionally a systems reviewer from adjacent area.
Input
Whiteboard or diagram tool (draw.io, Miro, FigJam) with family tree layout (target incident at bottom, ancestors above); incident database extract or postmortem archive; comparison table with columns for incident, date, factors, recurrence indicator; pattern tags.
Template
Family Tree Analysis Canvas
Context
What is this method used for?
Core question
Which question should be answered at the end?
Input
Which data, observations, or materials are available?
Working area
- Area 1:
- Area 2:
- Area 3:
- Relationships / patterns:
Output artifacts
- Family tree diagram:
- Pattern notes:
- Systemic actions:
Open questions
- ...
Next step
Owner, date, success signal.
Completion Check
- Family Tree Diagram is complete enough for review:
- Location:
- Version / status:
- Review by:
- Next step:
Next Step
- Review result
- Mark open questions
- Schedule review or decision
Family Tree Analysis Working Template
View templateCompact working template for Family Tree Analysis with context, input, output artifacts, and next step.canvas
family-tree-analysis-working-template.md
Compact working template for Family Tree Analysis with context, input, output artifacts, and next step.
Family Tree Analysis Canvas
Context
What is this method used for?
Core question
Which question should be answered at the end?
Input
Which data, observations, or materials are available?
Working area
- Area 1:
- Area 2:
- Area 3:
- Relationships / patterns:
Output artifacts
- Family tree diagram:
- Pattern notes:
- Systemic actions:
Open questions
- ...
Next step
Owner, date, success signal.
- Working question, owner, and target artifact are visible.
- The result fits Family Tree Diagram.
- Date and target incident in header. For later similar incidents, add new root with link to existing tree, or extend existing tree. Keep pattern list as a living document.
- Open questions are noted as follow-ups.
- The next review or decision point is scheduled.