Wie spät ist es eigentlich? Ein Praxisblick auf die Teamuhr

Vermutlich hat jeder, der in einem Team arbeitet, schon mal von Teamentwicklung, der Teamuhr oder ähnlichem gehört. Die Teamentwicklung erleben wir mal mehr, mal weniger bewusst. Deren Ziel ist, dass aus einer Gruppe von Menschen ein performantes Team entsteht. Aber wie geht das eigentlich? In diesem Artikel reflektieren wir unsere eigenen praktischen Erfahrungen in einem Softwareentwicklungsteam. Dabei wird deutlich: Es gibt nicht den einen Uhrmacher, der die Uhr stellt. Vielmehr wird gemeinsam an der (Team-)Uhr gedreht; jeder im Team trägt dazu bei.

In diesem Artikel teilen und diskutieren wir (reale) Begebenheiten, die wir in unserem Team erlebt haben. Unser Artikel ist also keine theoretische Abhandlung über Methoden und Werkzeuge der Teamentwicklung. Vielmehr ist das Anschauungsobjekt unser Team. Wir entwickeln und betreiben ein Softwaresystem im Kundenauftrag und sind cross-funktional aufgestellt: Zum Team gehören Backend- und Frontend-Spezialisten, ein Product-Owner, ein Informationsarchitekt, ein Scrum-Master und ein halber UX Designer. In unserer Firma herrscht weitgehend Team-Autonomie und eine Kultur der gegenseitigen Wertschätzung. Gute Voraussetzungen also für erfolgreiche Teamarbeit. Doch dafür es bedarf noch weiterer Zutaten!

Etwas Theorie

Wir stellen zwei Modelle für Teamarbeit vor, die uns geeignet erscheinen, die Dynamik in Teams zu verstehen.

Die Teamuhr

Dieses Modell geht auf Beobachtungen des Psychologen Bruce Tuckman [5] zurück, der bemerkte, dass in vielen Beschreibungen von Teamentwicklungen vier Phasen (hier stark verknappt dargestellt) immer wieder auftreten:

• Forming: das Team kommt zusammen, man sucht Orientierung bzgl. Zielen, Führung und Teamstruktur.
• Storming: Widerstand und Konflikte treten im Team auf.
• Norming: Das Team schafft neue Umgangsformen, Prozesse, Strukturen, Rollen und Befugnisse werden geklärt.
• Performing: Das Team arbeitet performant, jeder hat seine Rolle(n) gefunden.

Die Phasen laufen in der o. g. Reihenfolge ab und gehen ineinander über (eine fünfte Phase, Adjourning, wurde in einer späteren Überarbeitung des Modells hinzugefügt und beschreibt die Auflösung eines Teams am Ende der gemeinsamen Arbeit [6]). Jedoch ist die Entwicklung nicht mit dem Beginn der Phase Performing abgeschlossen. Ereignisse wie Wechsel im Team, Veränderung der Aufgabe oder des Umfeldes – kurz, neue Situationen – starten die Phasen neu. Daher das Modell einer Uhr, auf der der Zeiger am Ende einer Runde schon die nächste beginnt. Tröstlich für alle die schon stürmische Phasen im Miteinander im Team erlebt haben: Storming ist normal! Jeder erlebt das. Und die Phase kommt immer wieder. Mit etwas Glück und Geschick wird sie jedoch mit der Zeit kürzer und lässt sich leichter in ein Norming überführen.

Fünf Dysfunktionen

Das zweite Modell, dass wir hier kurz anreißen, stammt von Patrick M. Lencioni und beruht auf der Grundlage von Erfahrungen in Manager Teams (in seinem Buch “Die 5 Dysfunktionen eines Teams” sehr spannend und deutlich genauer als im Folgenden beschrieben). Das Modell nennt fünf typische Probleme (Dysfunktionen) von Teamarbeit, bei denen jeweils eines zum anderen führt:

• Das Grundproblem ist fehlendes Vertrauen (versteckte Agenden, unbekannte Mitarbeiter, Angst vor Schaden der eigenen Position).
• Dies führt zu Scheu vor Konflikten (keine Offenheit im Team, Gefühle nicht verletzen, keine Rache provozieren).
• Daraus folgt fehlendes Engagement (ohne Konfliktbereitschaft keine leidenschaftliche Debatte, Ziele und Absprachen werden nicht gemeinsam erkämpft oder wenigstens mitgestaltet, wichtige Punkte werden nicht geklärt).
• Ohne Engagement für die Ziele des Teams kommt es zu Scheu vor Verantwortung (man hält sich raus, übernimmt selbst keine Verantwortung und fordert auch keine Verantwortung ein).
• Die Kette endet schließlich bei fehlender Ergebnisorientierung (wo niemand für die Teamziele verantwortlich ist, folgt jeder seinen eigenen Zielen).

Ergebnisorientierung ist jedoch unerlässlich, wenn mehrere Menschen das gleiche Ziel erreichen sollen/wollen. Um diese zu erreichen, muss vorn in der Kette begonnen werden, die Weichen richtig zu stellen. D. h. die Grundlage für erfolgreiches Teamwork ist Vertrauen im Team.

Im Rest des Artikels betrachten wir verschiedene Aspekte in der Team-Entwicklung, exemplifizieren diese mit realen Erfahrungen aus unserem Team, ordnen sie Phasen der Teamuhr zu und beschreiben unsere Sicht auf die Ereignisse:

Schlüsselmomente – Forming

Das Forming, die Findungsphase, setzt den Grundstein der Teamentwicklung. Sie bietet die Gelegenheit, Vertrauen zwischen den Teammitgliedern aufzubauen. Als wir mit dem gemeinsamen Projekt gestartet sind, waren einige Teammitglieder noch in alten Projekten eingebunden oder saßen entsprechend ihrer Spezialisierung in Büros mit Kollegen der gleichen Disziplin. Das Team begann also über mehrere Räume und Etagen verteilt zu arbeiten. So entwickelten sich in dieser Zeit eigentlich zwei Teams, die parallel an Themen arbeiteten und sich nur zum Daily Scrum getroffen haben. Die einzelnen Sub-Teams waren für sich erfolgreich, jedoch ging die gemeinsame Richtung verloren. Wir zogen daraus Konsequenzen und unser Umzug in ein gemeinsames Büro wurde Prio 1.

„Zusammenziehen“ ist ein Schlüsselmoment, egal ob man in ein Teambüro zieht oder in eine Studenten-WG. Wer sitzt wo, wie erfolgt die Aufteilung – muss man losen oder einigt man sich? Wie wird ein neuer Mitbewohner willkommen geheißen? Gibt es das große Essen am Abend mit allen oder sitzt man mit Tütennudeln alleine da, bzw. alleine am Einrichten der Entwicklungsumgebung. Räumliche Nähe hilft beim Kennenlernen, ja erzwingt es sogar. Beziehungen über die Arbeit hinaus entstehen in gemeinsamen Pausen, bei „über-den-Tisch“-Gesprächen, bei gegenseitiger Hilfe mit kurzen Wegen – kurz, im gemeinsamen Alltag. Der gemeinsame Raum kann auch virtuell sein, dann sind die Herausforderungen beim Gestalten der Schlüsselmomente aber andere.

Wir erinnern uns: Die erste Phase der Teamuhr ist durch die Suche nach Orientierung gekennzeichnet, also auch durch Unsicherheit und Verwirrung. Es geht zunächst darum, dass die Teammitglieder sich miteinander bekannt machen und ihre Zugehörigkeit zur Gruppe absichern. Gerade hier entscheiden Schlüsselmomente ob wir Vertrauen zu den Kollegen fassen, was unsere ersten Eindrücke über sie sind und welche Schlüsse wir über den zukünftigen Umgang miteinander ziehen.

Wir haben es selbst in der Hand, ob wir mit “First Date”-Stimmung ins Kennenlernen gehen oder ob wir gleich mit den Schwiegereltern starten wollen. Wie beim Beispiel mit der WG kommt es auf alle an, eine gemeinsame Basis zu schaffen. Gelungene Schlüsselmomente erleichtern den Einstieg in das Team und sie fördern Vertrauen. Weitere wichtige Momente sind z. B. der erste Fehler und die ersten Meinungsverschiedenheiten (vgl. Dysfunktion 2: Scheu vor Konflikten). In diesen Momenten wird der Weg für die Zukunft gesetzt. Wollen wir gemeinsam neue Wege erkunden oder nur keine Fehler machen? Suchen wir offen nach Lösungen oder beharren wir auf unserer Meinung oder lassen ohne eigenes Engagement andere entscheiden?

Erwartungen – Storming

Ein Aspekt, der häufig zu persönlicher Unzufriedenheit und dann zu Konflikten führt, ist die enttäuschte Erwartung. Jedes Mitglied des Teams bringt seine eigenen Erwartungen, Vorstellungen und Vorhaben mit ins Projekt. Zur Laufzeit gleicht man dann (bewusst oder unbewusst) diese Erwartungen mit der Realität im Projekt ab und stellt ggf. Differenzen fest. Typische Themen, bezüglich derer viele Erwartungen im Vorhinein existieren, sind z. B. die Gruppenstruktur (wer hat welche Rolle? [1]), die Entwicklungsmethodik, Technologien, Code-Styles, Testing, etc. Auch ganz profane Themen wie Pünktlichkeit oder generell das Verhalten miteinander können zu Konflikten führen.

In unserem Projekt gab es verschiedene Erwartungen zur Projekt-Methodik. Ganz klar war: Wir machen Scrum. Aber was erwartet jeder einzelne davon?

• Scrum ist eine Methode, der wir diszipliniert folgen, wie sie in der Literatur beschrieben ist.
• Scrum ist einen Methoden Baukasten, aus dem wir uns nach bei Bedarf bedienen.
• Scrum heißt, dass wir uns alle zwei Wochen zum Planning treffen.
• Scrum heißt, dass wir Tasks zu Sprints zuordnen. Besonders eilige Tasks werden dem aktuellen Sprint zugeordnet.

Egal welchem Statement man zustimmt, Enttäuschung ist vorprogrammiert, wenn die Realität eher einem der anderen Statements entspricht. Unklarheiten in der Projektmethode führen zu Unklarheiten über die zu erledigenden Aufgaben und schließlich zu Konflikten darüber, wer wann was eigentlich zu erledigen hat. In unserem Team haben wir festgestellt, dass keiner unsere Umsetzung von Scrum als zielführend empfand. Um den Konflikt zu lösen hatten wir zwei Möglichkeiten:

1. Wir einigen uns auf Scrum und passen unsere Arbeitsweise entsprechend an.
2. Wir suchen uns eine Methode, die besser zu unserer Arbeitsweise passt und den Projektgegebenheiten gerecht wird.

Lencioni [4] schreibt u. a., dass Teams, die nicht unter der dritten Dysfunktion leiden (also: engagierte Teams), „Richtungswechsel ohne Zögern und Schuldgefühle“ vornehmen. In diesem Sinne haben wir uns für Option 2 entschieden und gemeinsam mit unserem Kunden auf Kanban umgesattelt – eine Methode, die sehr gut zu unserem Projekt passt, da sie viel Flexibilität in der Task-Priorisierung erlaubt und vor allem auf die Minimierung von Bottlenecks im Workflow mit Tasks optimiert. Mit dem Wechsel von Scrum zu Kanban haben wir unsere tatsächliche Arbeit nur wenig angepasst (hauptsächlich die technischen Details der Umsetzung von Kanban). Geändert hat sich aber das Verständnis davon, was möglich und was gewünscht und gefordert ist, und damit entstand eine stark verbesserte Zielorientierung.

Enttäuschte Erwartungen bergen Konfliktpotential und oft schwelen diese längere Zeit, bevor sie von den Beteiligten offengelegt werden. Damit diese frühzeitig offen bekannt werden, ist Vertrauen die Grundlage und räumliche Nähe eine gute Voraussetzung. Wenn im Halbscherz ein Satz wie „Na, Scrum hätte ich mir aber anders vorgestellt.“ fällt, so kann man frühzeitig den Konflikt erkennen. Um möglichst von vornherein Enttäuschungen vorzubeugen, bietet es sich an, Erwartungen zeitig im Projekt gemeinsam offen zu besprechen und zu managen.

Wie spät ist es eigentlich auf der Teamuhr? – Storming, Norming

Im Modell der Teamuhr gehen Phasen ineinander über, und die Uhr läuft jederzeit weiter. Wie erkennt also ein Team, wo es sich gerade befindet? Wir haben für unsere „erste Messung“ einen Meilenstein im Projekt zu einem Project-Midway-Review genutzt. Der Fokus lag dabei weniger auf der entwickelten Software als tatsächlich auf dem Team selbst. Gemeinsam haben wir ein Teamprofile oder auch Team-Radar erstellt: Dabei werden Themen bestimmt, die auf einer Tafel, Brownpaper, o. ä. auf je einer Achse wie Speichen eines Rades angeordnet werden. Wir haben Themen zum Projekt (z. B. Zielklarheit), zum Team (z. B. Wissensverteilung) und zur eigenen Person (z. B. persönliche Entwicklung) gewählt. Jedes der Themen wird von jedem Teammitglied bewertet, indem ein Punkt (mit Stift oder Sticker) auf einer Stelle der Achse markiert wird. Die Achse dient dabei als Skala. Innen ist der schlechtmöglichste Wert, ganz außen der beste. Optional kann mit einem Post-It noch ein erklärendes Wort angebracht werden. Außerdem kann man seine Bewertung für die anderen erläutern. Das entstandene Bild zeigte unsere Qualitäten aber viel wichtiger auch unsere offenen Themen auf – Themen, bei denen die Bewertung niedrig war oder Themen, bei denen die Bewertungen weit gestreut waren (Meinungsverschiedenheiten).

Um anhand des Team-Radars die richtige Uhrzeit ablesen zu können bedarf es des Vertrauens, sich im Team offen äußern zu können, ohne selbst Schaden zu nehmen. Interessant ist, dass jeder bewerten darf aber auch muss. So ist das Ergebnis tatsächlich ein Produkt des gesamten Teams.

Bei unserer ersten Anwendung der Methode haben wir uns viel Zeit und einen Moderator genommen und 14 Themen bearbeitet. Das Format hat für uns so gut funktioniert, dass wir es inzwischen einmal im Quartal in etwas kleinerem Umfang (acht Themen, kein Moderator) durchführen, um regelmäßig einen Blick auf die sich immer drehende Teamuhr zu werfen (exemplarisch dargestellt in Abbildung 1).

Das bewusste Wahrnehmen der Team-Phase und der einzelnen Themen ist die Voraussetzung für die Steuerung des Teams. Themen mit Meinungsverschiedenheiten (Storming) können bewusst angegangen werden um dafür gemeinsame Vereinbarungen (Norming) zu schaffen. Themen, die das gesamte Team positiv bewertet, kann man feiern!

Ziele – Norming, Performing

Aus unserem ersten Blick auf das Team-Radar ergab sich eine große Streuung beim Punkt Zielklarheit. Gerade als Product-Owner benötigt man solche Informationen. Sie bedeuten, dass die Produktvision nicht beim gesamten Team komplett angekommen ist und nicht jeder sieht, wie die eigene Arbeit auf die Teamziele einzahlt. Wir haben daraufhin nach einer Methode gesucht, wie man gemeinsam Ziele entwirft und diese nachhält. Entschieden haben wir uns für Objectives and Key Results (OKRs, vgl. Abbildung 2), eine Methode, bei der man in regelmäßigem Turnus Ziele (Objectives) vereinbart, die mittels einiger weniger, messbarer Ergebnisse (Key Results) erreicht werden sollen [3].

Unsere OKRs hängen seitdem öffentlich im Teambüro und werden wöchentlich im Teammeeting bearbeitet. Es werden die aktuellen Top-Themen der Woche besprochen und geprüft, wie unser Fortkommen bei den Quartalszielen ist.

Unser erstes Team-Radar nach der Einführung von OKRs zeigte eine deutlich geringere Streuung auf der Achse „Zielklarheit“ und eine positive Entwicklung. Wir haben entschieden OKRs weiter zu nutzen und neben dem Team-Radar in unseren Alltagsgebrauch zu überführen.

Ein Schlüssel ist aus unserer Sicht das gemeinsame Erarbeiten der Ziele. Dies passt zu Lencioni [4], denn nur wer die Ziele mitgestaltet hat (durchaus in leidenschaftlicher Debatte), wird bereit sein, Verantwortung für diese zu übernehmen (Vermeidung von Dysfunktion 4).

Es sind die kleinen Dinge

Bisher haben wir in diesem Artikel die großen Themen betrachtet; Methoden, die ein Team in den ersten Phasen der Teamuhr aufsetzen kann. Was aber braucht es noch, um ins Performing zu kommen und lange zu bleiben? – Gerade die kleinen Dinge sind hier entscheidend! Um im Kontext des WG-Beispiels zu bleiben: Eine WG bleibt nicht stabil, weil der erste Abend schön war und ihr die Schlüsselmomente und den Putzplan gestaltet habt. Über einen langen Zeitraum funktioniert es gut, wenn der Alltag passt: viele kleine Dinge, die immer wieder stattfinden, wie der Einkauf, die Hilfe an der richtigen Stelle, das gemeinsame Aufwaschen in der Küche.

Die folgenden „kleinen Dinge“ haben wir in der Projekt-Praxis als sehr wertvoll erlebt:

• Jeder hat eine Stimme! – Jeder darf und muss sich beteiligen; in der Retrospektive, im Team-Radar, bei den OKRs, etc.
• Räum den Müll weg! – Jeder im Team packt mit an und es gibt keine Arbeiten, um die man sich drückt. Jeder sollte die Spülmaschine ausräumen, wenn sie fertig ist, egal ob Geschäftsführer/in oder Praktikant/in
• Habt Spaß! – Gemeinsam lachen können ist ein Zeichen für Sicherheit, schafft Verbindung und Gemeinsamkeiten. Auch die NASA ist überzeugt, dass nur mit Clowns im Team die Reise zum Mars klappen wird [1,2].
• Wiedersteh dem Reflex, für andere eine Lösung zu suchen! – Kein Problem ohne Lösung; die Lösung sollte aber gemeinsam/selbst gefunden werden. Der Grad an Verantwortung, die ich für „meine“ Lösung übernehmen werde, ist ungleich höher als der für eine fremde Lösung.
• Lass das Team alleine! – Läuft es auch ohne die Führungskraft, kann jeder im Team einfacher Verantwortung übernehmen und Vertrauen aufbauen. Nur als Eskalationsinstanz ist die Führungskraft gefragt.

Fazit

Es gibt keinen Uhrmacher, der alleine die Teamuhr auf „Performing“ stellen kann – Teamentwicklung ist die Aufgabe des gesamten Teams. Dabei muss man sich immer wieder bewusst machen, wie es dem Team aktuell geht, in welcher Phase man sich vermutlich befindet. Die im Artikel beschriebenen Methoden und Werkzeuge sind keine Blaupause und kein Masterplan, sie haben uns aber geholfen und wir können empfehlen, sie im eigenen Team mal auszuprobieren. Die Erfahrungen, die wir gemacht haben, fassen wir zum Abschluss als Appell verkürzt zusammen:

• Gestaltet Schlüsselmomente gemeinsam!
• Erzeugt keine Erwartungen, die Ihr nicht erfüllen könnt!
• Die Teamuhr läuft immer weiter, nutzt die Chance, die „aktuelle Zeit“ abzulesen!
• Übernehmt gemeinsam Verantwortung für eure Ziele!
• Achtet dauerhaft auf die kleinen Dinge!

Quellen

[1] J. Johnson, J. Boster, and L. Palinkas (2003): Social roles and the evolution of networks in extreme and isolated environments. Journal of Mathematical Sociology, Volume 27, Issue 2-3 (Routledge Taylor & Francis Group).

[2] J. Johnson (2019): Human Exploration Crews: Informal Social Roles, Team Viability and Conflict. AAAS Annual Meeting 2019, Washington DC.

[3] John Doerr (2018): Measure What Matters: OKRs: The Simple Idea that Drives 10x Growth. Portfolio Penguin.

[4] Patrick M. Lencioni (2014): Die 5 Dysfunktionen eines Teams. Wiley-VCH.

[5] Bruce W. Tuckman (1965): Developmental sequence in small groups. Psychological Bulletin (APA Publishing).

[6] Bruce W. Tuckman, Marry Ann C. Jensen (1977): Stages of small-group development revisited. Groups & Organization Studies, Volume 2, Issue 4 (Sage Journals).