Wenn Scrum nicht funktioniert, Schuld auf andere geschoben wird, ein Grundvertrauen im Team fehlt oder auf sonstige Weise eher individuell gearbeitet als im Team kollaboriert wird, dann funktioniert eigentlich das Teamwork nicht. Auch der Scrum Guide spricht davon, dass für Scrum ein cohäsives Team benötigt wird – kein Team, kein Scrum.
Ich habe in meiner Reise als Scrum Master oft festgestellt, dass die Vorteile von Teamwork gar nicht verstanden werden. Und wie soll aus Einzelkämpfern ein Team werden, ohne dieses Verständnis?
Glücklicherweise hat Patrick Lencioni ein Modell geschaffen, das die Basis von Teamwork erklärt, uns die Vorteile verständlich macht, und uns auch zeigt, wie wir für echtes Teamwork sorgen können.
Der Titel “5 Dysfunctions of a Team” ist schon recht reißerisch, was sicher auch für die guten Verkaufszahlen und den Impact dieses Modells dienlich war. Da ich hier ja kein Buch verkaufen muss, übersetze ich das Modell lieber in die positiv formulierte Variante “5 Behaviours of a Cohesive Team” bzw. die “5 Verhaltensweisen der Teamfähigkeit”. So nenne ich die Ebenen auf Deutsch und Englisch:
Die Ebenen des Modells bauen als Pyramide aufeinander auf, was bedeutet, dass die unteren Ebenen gegeben sein müssen, damit die Ebenen darüber funktionieren können:
- Ohne Vertrauen keine Konfliktfähigkeit, weil man der fragilen Beziehung keine Konflikte zutraut.
- Ohne Konfliktfähigkeit kein echtes Commitment bzw. keine echte Verantwortungsübernahme, weil man nichts unterstützt, bei dem die eigene Meinung nicht gehört wurde und somit eine (subjektiv) schlechte Entscheidung getroffen wurde.
- Ohne Verantwortungsübernahme keine sinnvolle Rechenschaftspflicht, also kein Einstehen für die Verantwortlichkeit des Teams, und auch kein Zur-Verantwortung ziehen der anderen Teammitglieder.
- Ohne sich gegenseitig auf Kurs zu halten, funktioniert es auch nicht, den richtigen Kurs und die passende Zugkraft bei den Ergebnissen aufrecht zu erhalten.
Im Folgenden erkläre ich die Ebenen von unten nach oben und nenne Tools, Methoden und Literaturverweise, die helfen können, diese Ebenen im Team zu festigen und das Teamwork zu fördern.
Vertrauen
- Hier geht es darum, genug Vertrauen zu den anderen Teammitgliedern zu haben, um sich verletzlich zu zeigen. Das heißt: man vertraut dem Team so sehr, dass man Fehler bereitwillig eingesteht, Schwächen zugibt, nach Hilfe fragt, etc.
- Der Verbundene Scrum Wert ist Offenheit. Sich offen zu zeigen und seine Arbeit transparent zu machen ist genau die Art von Verletzlichkeit, die sich Lencioni als Basis dieser Stufe wünscht. Scrum benötigt diese Offenheit als Transparenz, ohne die Inspect and Adapt (die Basis von Scrum) nicht funktioniert.
- Fehlendes Vertrauen aufzubauen funktioniert nur über Vorschussvertrauen. Dieses selbst zu geben, ist notwendig.
“The only way to make a man trustworthy is to trust him.”
~Henry Lewis Stimson (U.S. politician)
- Tools für Meetings und Retros, um Offenheit zu fördern, sind die Prime Directive und die Vegas Regel. Lencioni schlägt die Personal Histories Excercise vor.
Konfliktfähigkeit
- Lencioni spricht beim Thema Konflikte über Alltagskonflikte. Er geht davon aus, dass die Unterschiedlichkeit der Teammitglieder erst den Wert von Teamwork ausmachen. Das heißt aber auch, dass jede Meinungsverschiedenheit, jeder Unterschied in den Fähigkeiten bereits zu Konflikten auf der Sachebene führt. Konflikte sind also völlig normal. Nichtsdestotrotz gibt es Menschen, die sich mit ihren Ideen so identifizieren, dass eine Ablehnung ihrer Idee sie verletzt oder sie sich abgewertet fühlen.
- Hier geht es darum, das Ego schweigen zu lassen, wenn es um die besten Ideen geht. Die anderen Köpfe im Team sind genauso schlau, wie ich. Daher muss ich auch meine tollen Geistesblitze gehen lassen, wenn das Team andere Ideen besser findet.
- Ideen werden oft als Ausdruck der eigenen Meinung angesehen, und wenn die eigenen Ideen und Meinungen abgelehnt werden, dann ist das für einige Menschen respektlos. Nicht desto trotz sind wir subjektive Wesen, die die eigenen Ideen und Einstellungen automatisch für die besten halten (siehe Bestätigungsfehler) – was aber deswegen nicht unbedingt stimmt. Daher ist es wichtig, seine Ideen nicht als Identität zu verstehen, und als Team gemeinsam alle Ideen zu hören und gemeinsam zu entscheiden, welche die beste ist.
- Der Verbundene Scrum Wert ist Respekt. Jeder hat einen anderen Lebensweg, andere Expertise, andere Talente und ein anderes Mindset. Diversität ist ein großer Vorteil jedes Teams, aber nur, wenn man Andersartigkeit wertschätzen und nutzen kann.
- Tools sind Moderationstechniken wie Dynamic Facilitation oder Facilitierungstechniken wie Liberating Structures, die dafür sorgen, dass sich alle gleichermaßen beteiligen können. Des Weiteren empfehle ich die Prime Directive als Teamregel.
Commitment
Commitment meint mehrere Dinge:
- Das Engagement innerhalb des Teams, also den vollen Einsatz, den man zu geben bereit ist.
- Die Fähigkeit, auch wirklich hinter den Teamentscheidungen und Regeln / Working Agreements des Teams zu stehen, selbst wenn ich eigentlich eine andere Entscheidung / Regel favorisiert hatte (die ich dank meiner Konfliktfähigkeit aber zurück stehen lassen kann).
- Commitment meint aber auch die Übernahme von Verantwortung – was essenziell ist für die Selbstorganisation des Teams. Die Übersetzung ins Deutsche ist generell etwas schwierig, deswegen benutze ich den Englischen Begriff auch mit meinen deutschsprachigen Teams.
- Der Verbundene Scrum Wert ist Commitment. Logisch.
- Tools und Techniken, um das Commitment im Team zu fördern, finden sich in Facilitators Guide to Participatory Decision-Making von Sam Kaner. Es gibt aber auch einen Haufen Leadership-Literatur zu dem Thema Haltung, hier empfehle ich gerne Coaching Agile Teams von Lyssa Adkins oder Turn the Ship around von L. David Marquet.
- Generell empfiehlt sich eine coachende Herangehensweise, um Commitment zu fördern. Wenn eine Idee im Team entsteht, statt durch eine Führungsperson (wie den Scrum Master) vorgegeben zu werden, dann stärkt das nicht nur die Selbstwirksamkeit und die Moral, sondern auch das Commitment zu dieser Idee. Die eigenen Lösungen sind attraktiver als die Top-Down-vorgegebenen Ideen, die wir umsetzen müssen.
Accountability
- Während es bei der Konfliktfähigkeit vorrangig um Ideen geht, geht es bei der Accountability um das Verhalten der Teammitglieder. Sind wir dank gesunden Commitments sicher, dass die ganze Gruppe sich auf Ziele, Prozesse, Methoden und Regeln geeinigt hat, wird es nichts desto trotz immer Ausreißer geben, die sich aus unterschiedlichsten Gründen nicht an die gemeinsam beschlossenen Entscheidungen halten (konnten). Bei der Stufe der Accountability geht es darum, Verantwortung zu übernehmen, indem man andere zur Verantwortung zieht. So kann man den Regelbruch besprechen und Lösungen finden, wie die Regeln entweder in Zukunft eingehalten werden können oder die Regeln geändert werden können, falls sie das beste Handeln nicht adäquat beschreiben.
- Um das Verhalten von Teammitgliedern zu kritisieren, brauchen wir nicht nur Offenheit (damit ein problematisches Verhalten zugegeben wird), Respekt (um uns nicht über den anderen zu stellen und ihn zu verurteilen, sondern rein aus unserer Brille am besten Gewaltfrei zu kommunizieren) und Commitment, um uns überhaupt auf gemeinsame Regeln zu besinnen, sondern auch eine gehörige Portion des Scrum-Wertes Mut. Teammitglieder zur Verantwortung zu ziehen kann persönlich genommen werden, wir müssen also darauf Vertrauen, dass der andere mit konstruktiver Kritik umgehen kann, und dass wir nur gemeinsam eine Lösung suchen wollen.
- Die Gewaltfreie Kommunikation nach Rosenberg hilft uns, dass man uns nicht missversteht. Working Agreements (also Regeln, die wir schriftlich festgehalten und auf die wir uns innerhalb des Teams committed haben) helfen uns, konkret zu beschreiben, wie wir arbeiten wollen – so dass wir uns leichter zur Verantwortung ziehen können.
Results
- Wenn man bis hier alle Stufen in seinem Team erfüllt sieht, hat man bereits ein sehr schlagkräftiges Team mit maximaler Performance. Es geht aber nicht nur darum, dass das Team am selben Stang zieht, sondern auch, in welche Richtung. Am Ende misst sich das Team an greifbaren Ergebnissen, nicht an Performance. Jeder einzelne kann jedoch unheimlich viel Arbeit schaffen, Bugs und User Stories erledigen, und vielleicht sogar vorarbeiten – ohne dass am Ende das Sprintziel erfüllt ist. Aber nur das Sprintziel zählt, weil es eben einen konkreten Nutzen beschreibt, ein echtes Ergebnis. Wer da nicht von seinem “ich bin aber ein hochbezahlter XYZ”-Ego herunterkommen kann, und auch mal testet, wenn es grade an Tests mangelt, der wird trotz hoher Performance (viele programmierte Lines of Code und Commits) für schlechte Ergebnisse des Teams sorgen, weil das Endprodukt beispielsweise ungetestet und damit nicht auslieferbar ist.
- Der Verbundene Scrum Wert ist Fokus. Sich auf das Richtige konzentrieren, und die nicht getane Arbeit (den Waste) maximieren.
- Tools sind die Sprintziele und Product Goals von Scrum oder auch die Eisenhower Matrix zur Priorisierung.
Wie kann ich diese Ebenen überprüfen?
Ich wurde zu diesem Thema im Podcast “Systemisch Agil” mit Martin Schenkenberger und Florian Zapp interviewt – dort könnt ihr die Vorgehensweise erfahren, die ich mit den anderen Scrum Mastern bei meinem damaligen Wirkungsort erarbeitet habe und welche Erfahrungen wir damit gemacht haben: Systemisch Agil – The Five Dysfunctions of a Team – Deep Dive mit Tim Dellas
Wenn du weitere Infos zu meinem Vorgehen, den benutzten Excel-Dateien oder zu dem Workshop an sich hast, melde dich gerne.
