Eine Rückschau: Agile Breakfast Konstanz – Teamcharta

Es war eine außergewöhnliche Einladung – @scrumphony hatte mich im Sommer gefragt, ob ich Lust hätte bei der Scrum User Group Lake Constanz zu sprechen. Die hatte ich.

In der ruhigen und winterlichen Kulisse empfing uns der Bodensee in einer der schönsten Locations, in denen ich bisher gesprochen habe: Ein renovierter Wasserturm, direkt am Ufer des Sees, im obersten Stockwerk mit zwei ausgebauten Räumen versehen, die wir nutzen konnten.

Wie wir zu Beginn meines Vortrags schnell feststellten, war jedoch keiner wegen des Gebäudes hier. Die unterschiedlichen Motivationen der Gäste im vollständig belegten Raum erfassten wir vorneweg (siehe Bild).

Ein Anliegen meines Vortrags sollte es sein, Bewußtheit für die Andersartigkeit von Menschen zu schaffen und den Hintergrund von Konflikten zu thematisieren.

Als Lösungsangebot konnten die Zuhörer die Teamcharta für Scrum Teams und das Harvard Verhandlungsmodell als Inspiration, um strittige Situationen besser behandeln zu können kennenlernen.

Eine Teamcharta ist ein gemeinsam erstelltes Dokument, welches diese Teile enthalten kann:

•  Rollen (Wer gehört zum Team, in welcher Funktion?)
•  Verantwortlichkeiten (Wer darf was?)
•  Prozessvereinbarungen (Wie lange ist unsere Iteration?)
•  Regeln des Zusammenlebens (Handys aus im Meeting?)
•  Meetingzeiten (Wann ist das Daily Scrum?)
•  Technische Vereinbarungen (Testgetrieben? Testcoverage?)

Gerne verwende ich ein Mindmap-Diagramm, um alle Aspekte optisch ansprechend abzubilden. Der Ausdruck gehört dann an die Wand des Teamraums.

Die rege Diskussion um den Einsatzbereich des Werkzeugs im Anschluß des Vortrags machte Spaß und mündete darin, dass eine Teamcharta für sehr gute Teams das Zusammenfinden erleichtert, normale Teams am meisten profitieren und schwierige Teams, also solche mit nicht aufgearbeiteten Problemen auf der Beziehungsebene der Mitglieder, mit einer Teamcharta so deutlich auf den Konflikt gestoßen werden, dass man sich den Einsatz vorher gut überlegen darf.

Ansonsten gilt: Alles kann, nichts muss. Gestaltet das Dokument so, wie es für das Team funktioniert und Konsenz und Dissenz werden transparent. Ein weiterer Schritt zu einem Hochleistungsteam ist dann zurückgelegt.