Was steckt dahinter?

Die 5 Dysfunktionen eines Teams

Ja, in Teams läuft es nicht immer rund. Das merken wir Coaches von it-agile in unserer täglichen Arbeit. Wie sollte man nun diese Probleme angehen? Dazu nutzen wir bewährte Modelle, die uns helfen, die Situation in Teams zu verstehen. Ein solches Modell möchten wir heute vorstellen: Five Dysfunctions of a Team (Die 5 Dysfunktionen eines Teams) von Patrick Lencioni.

Abwesenheit von Vertrauen

In diesem Modell sind die fünf Dysfunktionen in einer Pyramide angeordnet, um auszudrücken, dass eine Ebene der Pyramide die vorherige als Voraussetzung braucht - im positiven wie im negativen Sinn. Auf unterster Ebene steht die Abwesenheit von Vertrauen. Wenn Teammitglieder einander nicht vertrauen, dann werden die folgenden Ebenen auch nicht funktionieren können. Vertrauen bildet damit nach Lencioni die Grundlage für wirkungsvolle Teams. Um Vertrauen in einem Team aufbauen zu können, muss man als laterale oder hierarchische Führungskraft zeigen, dass man selbst verletzbar und fehlbar ist. Eine angemessene Fehlerkultur ist somit der Schlüssel gegen fehlendes Vertrauen in Teams.

Angst vor Konflikten

Auf der zweit-untersten Ebene der Pyramide befindet sich die Angst vor Konflikten. Auf der Kostenseite steht laut Lencioni, dass nicht die besten Entscheidungen getroffen werden können, weil Konflikte vermieden werden, die für die Entscheidungsfindung wichtig sind. So gibt es gesichtswahrende Entscheidungen, die nicht die besten sind. Oftmals behandeln sich Teammitglieder gegenseitig wie rohe Eier. Eine Konfliktkultur, in der Teammitglieder auch unangenehme Dinge ansprechen können, ist hierfür essenziell.

Hier ist unser Kollege Markus zu sehen.

Autor

Markus Gärtner

Mehr zum Autor

Mangel an Selbstverpflichtung

Auf der nächsten Ebene der Pyramide finden wir einen Mangel an Selbstverpflichtung. Lencioni beschreibt auf der Kostenseite Mehrdeutigkeiten unter den Teammitgliedern, die zu keinem gemeinsamen Verständnis führen: Angst vor Versagen, häufige Zweifel, ob der eingeschlagene Weg der richtige ist und als Folge wiederkehrende Diskussionen. Man traut sich nicht so richtig und sammelt lieber noch mehr Daten, um dann vielleicht irgendwann eine Entscheidung zu treffen. Klare Deadlines verhindern hier ewige Diskussionen. Eine Analyse des „Worst-case Szenario“ hilft auf dieser Ebene, indem klar wird, was im schlechtesten Fall bei Entscheidungen eintreten kann und wie man dann damit umgehen sollte. Das schafft Sicherheit.

Vermeidung von Verantwortung

Auf der weiteren Ebene finden wir Vermeidung von Verantwortung. In agilen Entwicklungsteams kann man eine solche Vermeidung z.B. durch folgende Aussage erkennen: “Ich brauche alle Akzeptanzkriterien genau beschrieben, bevor ich den Product Backlog Eintrag im Sprint bearbeiten kann”. Verantwortung wird abgewälzt und man versucht, sich abzusichern. Teamregeln, die den klaren Support aller haben, das Setzen und Veröffentlichen von Zielen und Erwartungen sind Möglichkeiten, eine solche Verantwortungsvermeidung abzubauen.

Unaufmerksamkeit für Resultate

Auf der obersten Ebene der Pyramide finden wir zuletzt Unaufmerksamkeit für Resultate. Ultimativ ziehen hier Teammitglieder ihr eigenes Programm durch, statt auf die Resultate der gemeinsamen Bemühungen zu achten. Das führt nach Lencioni zu erratischen Erfolgen und zu Stagnation. Durch die resultierende Demotivation gehen Teammitglieder verloren, die ergebnis-orientiert sind. Dagegen helfen öffentlich deklarierte, klare Ziele und Belohnung von Ergebnissen, die sich an diesen Zielen orientieren.

Wie hilft mir das Modell bei der Arbeit mit Teams?

Für die Analyse ist es für einen Coach hilfreich, das Team von der obersten Stufe aus zu betrachten: Gibt es wenig Bemühung für gemeinsame Resultate oder beobachtet man noch etwas, was tiefer geht? Die unteren Ebenen bilden die Voraussetzung für den obersten Teil. Trauen sich die Teammitglieder untereinander nicht und man beobachtet ein hohes Maß an Firmen-Politik, sollte die unterste Ebene auf der Pyramide im Fokus des Coachings stehen. Nimmt man als Coach Konfliktvermeidung wahr, dann sollte man sich darauf fokussieren, erstmal die bestehenden Konflikte transparent zu machen und konstruktiv anzugehen. Fokussiert sich der Coach eine oder mehrere Ebenen zu hoch, arbeitet man leider am Grund der Probleme vorbei.

Das Modell kann gut dazu benutzt werden, um Change-Experimente für sich zu definieren. Man setzt sich einen Zeitraum, in dem man das Team mit einem Experiment beobachten will. Beispiel: Setze eine Deadline für Entscheidungen, um zu sehen, ob das Team an einem Mangel an Selbstverpflichtung leidet. Werden dadurch ewige Diskussionen vermieden und das Team konzentriert sich auf das Sammeln der wirklich notwendigen Daten, um etwas zu entscheiden?

Die Auswertung eines solchen Experiments liefert neue Rückschlüsse, inwiefern das Team jetzt weitergekommen ist oder ob man erforschen sollte, ob nicht eine andere Ebene adressiert werden sollte. Bringt einen das, was passiert, auf die Vermutung, dass das Hauptaugenmerk doch woanders in der Pyramide liegen sollte? Dann starte ich als Coach auf einer anderen Ebene ein Experiment. Beispiel: Werden nach der Intervention Deadlines eingehalten und es kommt zu Entscheidungen, die aber im Fehlerfall in Schuldzuweisungen enden, gibt es keinen Mangel an Selbstverpflichtung, sondern von Vertrauen. Dort sollte man dann als Coach intervenieren, um eine maximale Wirkung zu erzielen. Ansonsten gerät man in Gefahr, an Symptomen „herumzudoktoren“.

Auch das „Five Dysfunctions of a Team“ ist am Ende nur ein Modell, welches wie andere Modelle auch nicht alle Facetten der Realität abdeckt. Trotzdem kann es nützlich sein, um typische Probleme in Teams zu finden und den Teams dann zielgerichtet zu helfen. Abschließend sei noch bemerkt: Ja, es gibt auch Teams, wo es rund läuft. 
 

Hier ist unser Kollege Markus zu sehen.

Über den Autor

Markus Gärtner

Markus arbeitet seit 2010 als Organizational Design Consultant, Certified Scrum Trainer (CST) und Agile Coach für it-agile. Markus präsentiert regelmäßig auf agilen Konferenzen und widmet sich dem Schreiben über agile Softwareentwicklung, Software Craftsmanship und Software Testen, vornehmlich in einem agilen Umfeld. 

Veröffentlichungen (u. a.)

E-Mail:Twitter:LinkedIn:

Mehr von Markus Gärtner

Unser it-agile Lagerraum

Möchten Sie mehr erfahren?

Tauschen Sie sich mit unseren Expert:innen aus und lassen sich zu Schulungen, Coaching oder Wissensthemen beraten.

 

+ 49 40 4135 848-0    info@it-agile.de    Online Termin buchen

Agile Coaching von it-agile

Kennen Sie eigentlich schon it-agile?

Die Expert:innen zu agiler Arbeit und agilen Methoden

Kund:innen wollen begeistert werden. Mit innovativen Produkten, durch Schnelligkeit, Transparenz und auch Verlässlichkeit. Unsere erfahrenen Agile Coaches sorgen gemeinsam mit Ihren Teams und Führungskräften dafür, auch in komplexer Umgebung Ihre Ziele nicht aus dem Auge zu verlieren und implementieren die richtigen agilen Methoden für nachhaltige Veränderung.

  • Wir integrieren Pragmatismus mit Idealismus
  • Wir befähigen Sie nachhaltig ohne Abhängigkeit von uns
  • Wir erzeugen Kundenfokus mit wirkungsvoller Agilität
agile review Magazin

agile review

Unser Kundenmagazin 

In unserem Magazin stellen wir Artikel rund um agiles Arbeiten für Sie zusammen. Das Spektrum reicht von methodischen Themen wie Scrum und Kanban über Agile Leadership bis hin zu technischen Aspekten wie agilem Testen und flexiblen Architekturen.

  • Als Abo oder Einzelausgabe erhältlich
  • Digital oder Print
  • Einzelne Artikel sofort digital verfügbar

Wissens- und Lesenswertes

Das könnte Sie zu agiler Arbeit auch interessieren

Die 5 Dysfunktionen eines Teams

Agile Teams

Die fünf Dysfunktionen sind in einer Pyramide angeordnet, um auszudrücken, dass eine Ebene der Pyramide die vorherige als Voraussetzung braucht.

Agile Teams

Ein Haufen abhängiger agiler Teams ergibt noch kein agiles Unternehmen. Die übergreifenden Themen führen zu extremen Overhead, schlechter Vorhersagbarkeit und langsamer Time-To-Market. Diese Probleme…

Agile Teams

Wir hören immer mal wieder, dass Entwickler:innen Scrum hassen - wegen der vielen Meetings. Was steckt dahinter?

it-agile Newsletter

Sichern Sie sich regelmäßige Neuigkeiten, Inspiration und Tipps zu agiler Arbeit, Konferenzen, aktuelle und neue Termine für unsere Schulungen sowie vieles mehr.


* Benötigte Angaben