- Rhythmen und Zeiten für Standup Meetings, Releases, Retrospektiven usw.
- Umgang mit Bugs und Blockaden
- Definitions of Done für die einzelnen Prozessschritte (also welche Bedingungen müssen erfüllt sein, damit eine Aufgabe in die jeweilige Erledigt-Spalte verschoben werden darf?)
- Regeln für den Umgang mit verschiedenen Aufgabentypen und Serviceklassen: Was passiert beispielsweise, wenn ein Hotfix in das System gelangt? Wird das entsprechende Ticket dann als nächstes gezogen? Oder werden dann alle anderen Aufgaben unterbrochen?
- Kapazitätszuteilungen: Wie hoch soll der Anteil der jeweiligen Aufgabentypen sein, die sich jeweils im System befinden (z.B. 70% Features, 20% Infrastruktur, 10% Bugs).
- Service Level Agreements: Welche Durchlaufzeiten garantieren wir unseren Kunden und Stakeholdern mit welcher Termintreue (z.B. "Bugs werden in 95% aller Fälle innerhalb von 3 Tagen behoben").
- Eskalationsregeln: In welchen Fällen werden Probleme an das Management eskaliert?
- ...
In dieser expliziten Form unterstützen die Regeln die Teammitglieder nicht nur dabei, eigenständig gute Entscheidungen zu treffen. Sie helfen darüber hinaus auch dabei, sachliche Diskussionen zu führen.
Dabei ist es wichtig, dass die Regeln nicht von oben herab diktiert werden, sondern dass die Teammitglieder sich darauf committen können, mit diesen Regeln zu arbeiten (auch wenn sie nicht jede Regel lieben werden). Natürlich können (und sollten) die Regeln mit der Zeit angepasst werden - wiederum gemeinsam im Team.
Zusätzlich zu den Regeln gibt es eine Reihe weiterer Elemente, die gut sichtbar platziert werden sollten, um sich so einen Informative Workspace im XP-Sinne zu schaffen:
- Eine Legende, was die verschiedenen Ticketfarben bedeuten.
- Tracking-Diagramme
- Abwesenheiten, Urlaube, Krankheiten usw.
Links
- In dieser Präsentation finden sich schöne Ideen für Visualisierungen (z.B. eine Insel mit Palmen, auf die alle Kollegen gezeichnet werden, die gerade Urlaub haben): http://agileevangelists.co.uk/responsive-kanban-board/