Richtlinien explizit machen

Implizite Regeln verursachen Probleme:

• Menschen treffen unterschiedliche Annahmen
• Konflikte entstehen über „wie wir Dinge tun"
• Neue Teammitglieder kennen die ungeschriebenen Regeln nicht
• Verbesserungen sind schwierig, weil die Ausgangslage nicht klar ist

Explizite Richtlinien sind schriftliche, sichtbare Vereinbarungen darüber, wie Arbeit durch Ihr System fließt.

Sie müssen nicht komplex sein. „Wir reviewen PRs innerhalb von 4 Stunden" ist eine Richtlinie. „Blockierte Elemente kommen an den Anfang der Spalte" ist eine Richtlinie. „QA startet nur, wenn Unit-Tests bestanden sind" ist eine Richtlinie.

Eintrittskriterien: Was muss wahr sein, damit Arbeit in eine Phase eintritt?

• „Bereit für Dev: Akzeptanzkriterien geschrieben, Designs angehängt"
• „Bereit für Review: Alle Tests bestanden, keine WIP-Commits"

Austrittskriterien (Definition of Done): Was muss wahr sein, um zu verlassen?

• „Entwicklung fertig: Code reviewed, CI grün, Dokumentation aktualisiert"

WIP-Limits: Wie viele Elemente können in dieser Phase sein?

• „Dev: Maximal 3 Elemente in Bearbeitung"

Handhabungsrichtlinien: Was passiert in bestimmten Situationen?

• „Blockiert: Blocker-Tag hinzufügen, im Standup besprechen, nach 24 Stunden eskalieren"
• „Prioritätskonflikt: Senior Dev entscheidet, bei Bedarf an Lead eskalieren"

Zeitrichtlinien: Erwartungen bezüglich Timing?

• „Code-Reviews innerhalb von 4 Arbeitsstunden abgeschlossen"
• „QA startet innerhalb von 1 Tag nach Bereitschaft"

Auswahlrichtlinien: Wie wählen wir aus, woran wir als Nächstes arbeiten?

• „FIFO innerhalb der Prioritätsklasse"
• „Kundenbezogene Bugs vor internen Issues"

Richtlinien sollten sichtbar sein, nicht in Dokumenten vergraben, die niemand liest.

Optionen:

• Auf dem Board: Schreiben Sie Richtlinien über oder neben jede Spalte
• Verlinktes Dokument: Führen Sie ein lebendes Richtliniendokument, verlinken Sie es vom Board
• Tooltip/Hover: Digitale Boards unterstützen oft Spaltenbeschreibungen
• Header-Karte: Die erste Karte in jeder Spalte beschreibt die Richtlinie

Der Test: Kann ein neues Teammitglied die Richtlinien innerhalb von 5 Minuten verstehen, wenn es das Board betrachtet?

Review-Kadenz: Richtlinien sind nicht statisch. Überprüfen Sie sie in Retrospektiven:

• Befolgen wir diese Richtlinie?
• Hilft oder schadet diese Richtlinie?
• Was fehlt?

Auferlegte Richtlinien bleiben nicht haften. Gemeinsam erstellte Richtlinien schon.

Prozess zur Erstellung von Richtlinien:

1. Aktuelle Praxis beobachten: „Wie entscheiden wir tatsächlich, woran wir als Nächstes arbeiten?"
2. Meinungsverschiedenheiten ans Licht bringen: „Es klingt so, als würde Alice nehmen, was am ältesten ist, aber Bob nimmt, was am kleinsten ist?"
3. Kompromisse diskutieren: „Was sind die Vor- und Nachteile jedes Ansatzes?"
4. Richtlinie vereinbaren: „Versuchen wir FIFO für die nächsten zwei Wochen"
5. Sichtbar machen: Schreiben Sie es auf das Board
6. Überprüfen und anpassen: „Wie hat FIFO funktioniert? Sollten wir anpassen?"

Schlüsselprinzip: Richtlinien sind Experimente, keine Gebote. Wenn eine Richtlinie nicht hilft, ändern Sie sie.

Über-Dokumentation: 20 Richtlinien pro Spalte, die niemand liest. Beginnen Sie mit 2-3 wesentlichen Richtlinien pro Phase.

Unter-Durchsetzung: Richtlinien existieren, werden aber routinemäßig ignoriert. Entweder setzen Sie sie durch oder löschen Sie sie.

Starre Regeln: „Niemals WIP-Limit unter keinen Umständen brechen." Die Realität ist unordentlicher. Erlauben Sie Urteilsvermögen, während Sie die Ausnahme sichtbar machen.

Fehlende Eskalation: Was passiert, wenn Richtlinien in Konflikt geraten oder zusammenbrechen? „Wenn WIP-Limit erreicht ist und dringende Arbeit eintrifft, an Teamleitung eskalieren."

Veraltete Richtlinien: Regeln von vor sechs Monaten, die nicht mehr passen. Überprüfen Sie Richtlinien regelmäßig.

Individuelle Richtlinien: „Bobs Arbeit durchläuft kein Code-Review." Fairness ist wichtig. Richtlinien sollten für Arbeit gelten, nicht für Personen.