Meine Session planen

# Session Brief: 5 Whys

## Ziel
Artefakt: Root Cause Notes

## Arbeitsfrage
Welche steuerbare Ursache hinter dem Symptom kann das Team mit einer konkreten Countermeasure beheben?

## Kontext
Konkretes Problem als ein Satz mit Datum und Auswirkung; Incident-ID oder Ticket-Link; relevante Logs oder Graphen der letzten 24 Stunden; bekannte Workarounds.

## Setup
- Format: Methoden-Session
- Dauer: 15-30 min
- Modus: Workshop
- Teilnehmende: Ein Facilitator, der die Kette führt und neutral nachfragt; zwei bis fünf Personen mit direktem Systemkontakt (mindestens ein Engineer, ein Operator); ein Scribe, der jede Antwort wörtlich mitschreibt.
- Owner: Ein Facilitator, der die Kette führt und neutral nachfragt
- Beteiligungsmodus: Teamrunde, gemeinsames Arbeiten und Alignment
- Ergebnislogik: Artefakt fertigstellen

## Beteiligungslogik
Nutze die Session für gemeinsames Verständnis. Beiträge werden sichtbar gesammelt, Annahmen werden abgeglichen und offene Unterschiede bleiben im Artefakt nachvollziehbar.

## Ergebnislogik
Die Session arbeitet direkt auf Root Cause Notes hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

## Input
Whiteboard oder Miro-Board mit vertikaler Kette aus sechs Boxen (Problem + 5 Whys); Stift; Timer; Link zum auslösenden Ticket oder Incident-Report.

## Vorbereitung
Problem-Satz oben in die erste Box schreiben. Fünf leere Boxen vertikal darunter. Timer auf 20 min. Regel ansagen: keine Namen, nur Mechanismen. Antwort jeder Box wird Ausgangspunkt der nächsten Why-Frage.

## Agenda
1. 0-2 min (2 min)
   Owner: Facilitator
   Aktion: Problem als beobachtbares Symptom formulieren: was, wann, wie oft, welcher Effekt. Keine Vermutung über Ursache. Hinweis: Wenn der Satz schon eine Ursache enthält („weil X kaputt war“), neu schreiben. Sonst springt die Kette zu spät ein. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Root Cause Notes

2. 2-15 min (13 min)
   Owner: Facilitator
   Aktion: Why-Kette aufbauen: Pro Box eine Why-Frage, eine Antwort, durchgängig auf Mechanismen statt Personen. Nach jedem Why prüfen, ob die Antwort durch Logs oder Daten belegbar ist. Hinweis: Spätestens beim dritten Why sollte die Antwort technischer oder prozesshafter werden. Bleibt sie auf der Verhaltensebene, fehlt Datenzugang oder Systemkenntnis. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Countermeasures

3. 15-22 min (7 min)
   Owner: Facilitator
   Aktion: Stoppkriterium prüfen: Ist die unterste Antwort durch das Team selbst änderbar? Wenn nein, einen Why zurückgehen oder den Pfad verzweigen. Hinweis: Häufig endet eine Kette zu früh bei „der Service ist alt“. Das ist keine steuerbare Ursache; entweder weiter oder zweite Kette parallel. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Root Cause Notes

4. 22-30 min (8 min)
   Owner: Owner
   Aktion: Eine bis drei konkrete Countermeasures notieren, je mit Owner und Zieldatum. Countermeasure muss die identifizierte Ursache adressieren, nicht das Symptom. Hinweis: Wenn die Countermeasure „Monitoring verbessern“ lautet, ist es eine Detection-Massnahme, keine Ursachenbehebung. Beides notieren, klar trennen. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Countermeasures

5. Artefakt veröffentlichen (10 min)
   Owner: Owner
   Aktion: Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen.
   Output: Root Cause Notes

## Abschluss
- Ergebnisartefakt aktualisieren: Root Cause Notes
- Ablageort, Version und Review-Empfänger festlegen.
- Owner, nächster Schritt und Reviewtermin festlegen.

# Root Cause Notes: 5 Whys

## Arbeitsfrage
Welche steuerbare Ursache hinter dem Symptom kann das Team mit einer konkreten Countermeasure beheben?

## Kontext
Konkretes Problem als ein Satz mit Datum und Auswirkung; Incident-ID oder Ticket-Link; relevante Logs oder Graphen der letzten 24 Stunden; bekannte Workarounds.

## Beteiligte
- Owner: Ein Facilitator, der die Kette führt und neutral nachfragt
- Teilnehmende: Ein Facilitator, der die Kette führt und neutral nachfragt; zwei bis fünf Personen mit direktem Systemkontakt (mindestens ein Engineer, ein Operator); ein Scribe, der jede Antwort wörtlich mitschreibt.

## Input
Whiteboard oder Miro-Board mit vertikaler Kette aus sechs Boxen (Problem + 5 Whys); Stift; Timer; Link zum auslösenden Ticket oder Incident-Report.

## Vorlage
# 5 Whys Arbeitsvorlage

## Ziel

Einfache Technik, um von Symptomen zu tieferliegenden Ursachen vorzudringen.

## Kontext

Wann und wofür nutzen wir diese Methode?

## Input

Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?

## Durchführung

Kurze Notizen entlang des Run Sheets.

## Ergebnisartefakte
- Root Cause Notes:
- Countermeasures:

## Annahmen und offene Fragen

- ...

## Entscheidung / Nächster Schritt

Owner, Datum und Erfolgssignal.

## Fertigstellungscheck
- Root Cause Notes ist vollständig genug für Review:
- Ablageort:
- Version / Status:
- Review durch:
- Nächster Schritt:

## Nächster Schritt
- Ergebnis prüfen
- offene Fragen markieren
- Review oder Entscheidung terminieren