Team-Charta

Bild: Wikimedia Commons / Hrvatski Sabor - Public Domain

Fragt man agil arbeitende Teams woran sie sich in ihrer täglichen Arbeit ausrichten gibt es als Antwort meistens die bekannten Klassiker: den Scrum- oder Kanban-Guide (oder die Entsprechung in der jeweils angewandten Methode), die dazugehörenden Werte und grundlegende Regeln wie z.B. die Definition of Done. Viele Teams haben darüber hinaus aber noch ein weiteres Dokument: die Team-Charta (auch Team Charter, Team Agreements oder Ähnliches).

Das derartige Chartas weit verbreitet sind liegt an der Natur der agilen Frameworks. Bewusst geben sie nur einen groben Rahmen vor, der dann von jedem Team mit unterschiedlichen Konventionen, Abläufen oder Quality Gates ausgestaltet werden kann. Dass das nicht versehentlich in nicht zielführender Weise geschieht soll durch die jeweiligen Werte sichergestellt werden, zu denen sich die Ausgestaltung in keinem Widerspruch befinden soll.

Die Meetings in dem die meisten dieser Ausgestaltungen stattfinden sind normalerweise die jeweiligen Retrospektiven, Kaizen-Events, o.Ä. Das hat den Vorteil, dass diese selbstgegebenen Regeln und Vereinbarungen immer aktuell gehalten werden können, der Nachteil ist aber, dass es schnell unübersichtlich werden kann. Zu wissen was wann in welchem Termin beschlossen wurde wird mit der Zeit (und dem wachsenden Umfang) immer schwieriger. 

Um diesem Problem zu begegnen kann es Sinn machen die selbstgegebenen Regeln und Vereinbarungen in einem einzigen zentralen Dokument festzuhalten, das dann immer wieder aktualisiert werden kann. Genau dieses Dokument ist es, dass dann als Team-Charta bezeichnet wird. Idealerweise ist es an einem zentralen Ort zu finden, z.B. an der Wand des Team-Raums, auf der Intranet-Startseite des Teams oder weit oben im jeweiligen Ordner-Baum.

Beispiele für Inhalte einer solchen Team-Charta sind der Umgang mit Pünktlichkeit und Timeboxing (kann gerade bei Teammitgliedern mit unterschiedlichen kulturellen Hintergründen sehr hilfreich sein), die Festlegung ob im Zweifel Dokumentation oder Kommunikation wichtiger sind, Vereinbarungen über Präsenz-Tage, meeting- und störungsfrei zu haltende Uhrzeiten, Verhaltensregeln für Meetings und Konfliktsituationen und vieles mehr.

Abzuraten ist von Inhalten die bereits an anderen Stellen festgehalten sind, etwa von Produkt- oder Mehrwert-Definitionen (gehört eher in Produktvision/Produktziel), von Vereinbarungen zu technischen und Qualitäts-Standards (gehört eher in Definition of Done/Policies) oder von Liefergegenständen und Lieferdaten (gehört eher in Product Roadmap/Product Backlog). Bestenfalls entsteht dadurch redundante Datenhaltung, schlimmstenfalls entstehen Widersprüche und Unklarheit.

Um es nachvollziehbar zu machen - eine derartige Team-Charta könnte so aussehen:

Wichtig bei Team-Chartas ist, dass es sich um lebende Dokumente handeln soll, die regelmässig aktualisiert, erweitert und wieder verschlankt werden sollten. Besonders das Letzte ist etwas das häufig vergessen wird, dabei aber von hoher Wichtigkeit ist - sobald die selbstgegebenen Regeln und Vereinbarungen in Summe zu umfangreich werden wird es schwer sie im Gedächtnis zu behalten und übersichtlich darzustellen. Auch hier gilt: im Zweifel ist weniger mehr.

Zuletzt noch ein Tipp aus der Praxis: in vielen Leitfäden wird neu zusammengestellen Teams empfohlen eine Team-Charta zu erstellen bevor die gemeinsame Zusammenarbeit beginnt. Das ist gut gemeint, führt aber selten zu guten Ergebnissen, da die Teammitglieder sich zu diesem Zeitpunkt noch gar nicht gut genug kennen können um zu wissen an welchen Stellen es wichtig ist, sich auf bestimmte Dinge zu einigen. Die Einigungen gehen dann oft am Bedarf vorbei.

Bessere Erfahrungen habe ich damit gemacht nach einem oder zwei Sprints oder Monaten zu fragen ob eine Team-Charta überhaupt gewünscht ist und erst dann die Inhalte zu erarbeiten. Normalerweise hat sich bis dahin herauskristallisiert ob Regelungsbedarf besteht, und wenn ja welcher. So ist das Ergebnis wesentlich bedarfsgerechter und die Akzeptanz und Nutzung wesentlich besser.