Der Zusammenhalt von Scrum-Teams begünstigt den Mißerfolg. Diese etwas provokante These soll die Aufmerksamkeit lenken darauf, dass eine Führungskraft erfolgreiche Scrum-Teams nicht vernachlässigen und sie „einfach mal machen lassen“ sollte. Es gibt je nach Betrachtungsperspektive verschiedene Parameter, die den Erfolg von Teamarbeit fördern. Exemplarisch seien hier aus Gründen der Einfachheit eine Klarheit hinsichtlich der sachlichen Ziele (Sachebene) und der persönlichen Verhaeltnisse der Gruppenmitglieder untereinander (Beziehungsebene) genannt. Mit der Zeit entsteht dann häufig in Teams eine hohe Kohäsion, es entwickeln sich Gruppennormen.

Gruppenkohäsion ist definiert als das Ausmaß wechselseitiger positiver Gefühle und bedeutet, dass die Mitglieder einer Gruppe sich so stark mit der Gruppe identifizieren, dass sie ein „Wir-Gefühl“ entwickeln. Dies ist der Zusammenarbeit auf der Sachebene förderlich, da es für Entlastung des einzelnen Gruppenmitglieds sorgt. In erfolgreichen Teams nun kann diese hohe Kohäsion und die Gruppennormen den Keim zum Mißerfolg bergen. Der Grund dafür sind zwei Phänomene: Gruppendenken (Groupthink) und Gruppenpolarisierung (Group Polarization).

Groupthink bezeichnet eine Situation in Gruppen, in der Argumente, welche der aktuelle Arbeitshypothese widersprechen, systematisch ausgeblendet werden. Unter Group Polarization versteht man eine Tendenz, dass Entscheidungen in Gruppen extremer (z.B. riskanter oder auch vorsichtiger) ausfallen als die gemittelte Summe der Einzelentscheidungen der Gruppenmitglieder.

Was tun?
Wenn man anhand der möglichen Ursachen für Gruppenpolarisierung (eine breitere Basis an Argumenten im Team gegenüber Einzelmeinungen und eine Ausrichtung an einem sozial erwünschten Ergebnis) sich typische Scrum–Teams vergegenwärtigt, so lässt die Vielfalt an Funktionsgruppen, aus denen Scrum–Teams zusammengesetzt sind (Analytiker, Entwickler, Tester, etc.) eine Meinungsvielfalt erwarten. Hieraus lässt sich die These ableiten, dass eine solche Meinungsvielfalt für eine nur schwach ausgeprägte Entscheidungstendenz in der Gruppe sorgt, so dass auch die Gruppenpolarisierung milder sein dürfte, als sie es in nach Funktionsgebieten getrennten Gruppen wäre.

Somit ergibt sich als Ableitung einer Intervention für die Praxis, Meinungsvielfalt im Team durch hinzuziehen externer Experten gezielt zu fördern. Beispielsweise könnte auch durch die Einrichtung von sogenannten Scrum of Scrums und Communities of Practice der Abschottung von Gruppen entgegengewirkt und die Meinungsvielfalt gefördert werden. Darüber hinaus ermöglichen Retrospektiven eine Reflexion auf das Gruppengeschehen, gleichsam ein aus der Gruppe Heraustreten und von außen Betrachten.

Diese Wirkungszusammenhänge lassen die These zu, dass Scrum–Teams einem möglichen Gruppendruck, Groupthink oder Group Polarization entgegen wirken, wenn in ihnen die Meinungsvielfalt durch Heterogenität genutzt werden kann. Hierzu kann es erforderlich sein, dass der Moderator der Retrospektive abweichende Meinungen explizit willkommen heißt, beispielsweise durch die Rolle des Advocatus Diaboli, der es als Aufgabe hat, dagegen zu argumentieren. Es lässt sich  jedoch auch ein Gegenbeispiel konstruieren: Das erfolgreiche Scrum–Pilotprojekt, welches isoliert einige sehr erfolgreiche Sprints absolviert hat und in dem die Kohäsion stärker wirkt als die Meinungsvielfalt durch Heterogenität und bei dem es durch einen schwachen Scrum Master nicht gelingt Meinungsvielfalt und ein Storming (im Sinne der Teambildungsphasen nach Tuckman) zur Geltung kommen zu lassen.

Diese  Argumentation zeigt die Bedeutung, die projektinterne Retrospektiven einerseits und ein ein projektübergreifender Gedankenaustausch (Scrum of Scrums, Communities of Practice) andererseits zur Verhinderung von Groupthink und Group Polarization haben.

Was steckt hinter Groupthink und Group Polarization?
Gruppenpolarisierung kann dann auftreten, wenn in einer Gruppe mit vorherrschender Meinungstendenz zu einem Thema über dieses Thema  diskutiert wird. Aktuell werden folgende Ursachen für eine Gruppenpolarisierung gesehen:

Der Informationseinfluss: Eine breitere Basis an Argumenten und Informationen innerhalb der Gruppe sorgt für eine Stärkung der vorhandenen Gruppentendenz und somit eine Polarisierung.
Der soziale Vergleich: Diskussionen in der Gruppe führen zu einer erhöhten Verbindlichkeit und Extremisierung der vertretenen Meinung in  Richtung des in der Gruppe gewünschten sozialen Ergebnisses.

Eine Konsequenz der Gruppenpolarisierung ist, dass isolierte Gruppen von Gleichgesinnten stärker zur Extremisierung neigen, weil es eine stärker vorhandene Gruppentendenz gibt. Das Internet wirkt in diesem Sinne polarisierend für Gruppen. Es ist offensichtlich, dass eine  Polarisierung die Güte der Entscheidungen tendenziell beeinträchtigt, da eine sie eine Beschränkung des Entscheidungsspielraumes darstellt.

Als  Groupthink wird eine Beschränkung in der Suche nach und Prüfung von Lösungsmöglichkeiten bezeichnet, der Gestalt, dass der Fokus in der  Gruppe auf Konsens gelegt wird und nicht darauf, weitere Optionen zu finden und zu bewerten. Die Gruppe beschränkt sich selbst, indem der  dominante Wunsch nach Konsens dazu führt, alternative Lösungsoptionen nicht zu prüfen oder gar nicht erst zu suchen. Es ist offensichtlich,  dass dies die Wahrscheinlichkeit von suboptimalen Entscheidungen erhöht, da ein solch dominantes Streben nach Konsens ebenfalls eine  Beschränkung des Lösungsraumes darstellt.

Bekannt wurde Groupthink durch die Arbeiten von Janis (1972), der politische Entscheidungen, die sich als schwere Fehler herausgestellt hatten (z.B. die Invasion in der Schweinebucht auf Kuba), rückblickend auf ihre Entstehungsgeschichte untersuchte. Wesentliche Grundbedingung für Groupthink ist eine hohe Gruppenkohäsion, da hier am wenigsten mit abweichenden Meinungen zu rechnen ist. Groupthink ist somit auch eine mögliche Ursache für Group Polarization.

Die Wahrscheinlichkeit für Groupthink erhöht sich,  wenn die Gruppe abgeschottet von Informationen von außen ist und durch Homogenität hinsichtlich der Zusammensetzung die Uniformität  innerhalb der Gruppe verstärkt ist. Werden diese Umstände dann noch durch Streß ergänzt wie er z.B. durch Zeitdruck bei der Entscheidungsfindung entsteht, so erscheint eine kritische Prüfung von Alternativen nicht möglich zu sein und Gruppendenken droht. An dieser  Stelle ist die Führungskraft gefragt, solche Tendenzen im Vorfeld abzusehen und den Scrum Master als Prozeßverantwortlichen bei der  Umsetzung von Maßnahmen zu unterstützen, die einer Gruppenpolarisierung und einem Gruppendenken vorbeugen, indem beispielsweise die Etablierung von Scrum of Scrums oder Communities of Practice gezielt gefördert wird.

In meiner Ausbildung zur systemischen Beraterin habe ich einige interessante Werkzeuge kennengelernt, deren Anwendung ich mir sehr gut in den Arbeitssystemen der IT und damit meine ich nicht nur im agilen Umfeld, vorstellen kann. Seit Anfang 2010 versuche ich mich intensiver daran, das ein oder andere Werkzeug auf typische Arbeitssituationen unseres IT-Umfeldes anzupassen und experimentell auszuprobieren, um für einen Transfer zu sorgen. Ziel ist es, meine zu Anfang genannte Hypothese zu überprüfen: Stellt das Werkzeug einen Gewinn dar oder nicht? Mit Gewinn meine ich, ist das Werkzeug mit seinen Interventionen in unserer Arbeitswelt wirkungsvoll.

Wer nicht weiterlesen möchte, sondern gleich den ersten von 4 Filmen schauen will, biegt hier bitte ab

Für die Geduldigeren geht’s hier weiter und später zum Film…
In diesem Zusammenhang habe ich auf der SEACON 2010 erstmals live während einer Retrospektive des real existierenden XING-Teams “Internal System Administration” den Einsatz eines Reflecting Teams ausprobiert. Das Team bestehend aus Oliver Stoldt, Bjarne Sander, Sebastian Schneider, Carlo Hohenbrink und Teamleiter Kai Lippok geht nach Kanban vor. Der Kontakt kam über Susanne Reppin, ebenfalls von XING AG zustande. Nach unserem ersten gemeinsamen Gespräch hat sich das Team spontan bereit erklärt, eine Retrospektive auf der SEACON vor Publikum durchzuführen.

Was hat mich motiviert, das Reflecting Team auszuprobieren?
Die Methode des Reflecting Teams wurde von Tom Andersen entwickelt und wird in der systemischen Therapie verwendet. Die Grundstruktur besteht darin, dass eine Trennung zwischen einem gecoachten System (hier: Kanban-Team) und einem beobachteten System (hier: Reflecting Team) hergestellt wird. Dabei beteiligt sich das Reflecting Team nicht aktiv am Gespräch, sondern wird durch zu einem bestimmten Zeitpunkt aufgefordert nach bestimmten Regeln zu reflektieren. Auf diese Weise kann eine zusätzliche Beobachtungsebene und Außenperspektive erzeugt und genutzt werden, um die Reflexionsfülle an Erkenntnissen zu erhöhen und diese wieder dem Projektteam zugute kommen lassen.
Diese Reflexionsfülle, die meines Erachtens durch die wertschätzende Rückkopplung der externen Betrachtung ausgelöst wird, begeistert mich in meiner Arbeit immer wieder.

Die Live-Präsentation haben wir mitgefilmt und auf 4 Filme aufgeteilt. Ich bedanke mich für den mutigen Einsatz seitens des Teams und die Freigabe des Filmmaterials seitens der XING AG.

Film-Besetzung:
Kanban-Team: Oliver Stoldt, Bjarne Sander und Carlo Hohenbrink als Teammitglieder.
Der Kanban-Coach und Teamleiter Kai Lippok wurde von Susanne Reppin, Senior Project Managerin vertreten von XING AG.

Reflecting Team: Markus Witter und Bernd Oestereich von oose Innovative Informatik GmbH.

Moderation & Leitung: Claudia Schröder

Und nun “Film ab” http://vimeo.com/album/1487572

Vor ein paar Tagen haben sich ein paar oose-Kollegen über ihr jeweiliges Verständnis der Scrum-Hindernisliste unterhalten und ich habe einmal die wichtigsten Aussagen (mit meinen Worten) zusammengetragen, wobei wir nicht den Anspruch hatten, einen Konsens zu finden, sondern die verschiedenen Ansichten auszutauschen.

Was ist die Hindernisliste und welchen Zweck hat sie? Eine Hindernisliste ist eine Sammlung von schriftlich formulierten Hindernissen, deren Lösung ein Team besondere Aufmerksamkeit geben möchte. Typischerweise wird die Hindernisliste während des täglichen Teamtreffens und während der Retrospektiven bearbeitet.

Die Hindernisliste ist neben der Planungswand und dem Abarbeitungsdiagramm (Burndown Chart) eine der drei expliziten teamspezifischen Scrum-Artefakte, die im Teamraum stets sichtbar und zugänglich sein sollen.

Eine Hindernisliste ist keine Zu-Tun-Liste, sondern eher eine Problemliste. Sofern sich eine oder mehrere Personen gefunden haben, die sich um die Beseitigung eines Hindernisses kümmern, können diese Personen auf der Liste vermerkt werden.

Die Hindernisliste hat den Zweck, die Aufmerksamkeit der Beteiligten gezielt auf bestimmte Hindernisse (Impediments) zu lenken, um die Wahrscheinlichkeit zu erhöhen, dass sich ein oder mehrere Personen finden und entscheiden, sich der Klärung und Beseitigung des Hindernisses anzunehmen. Es geht also vor allem darum, Hindernisse sichtbar und auf sie aufmerksam zu machen sowie sie zum Kümmern bereit zu stellen.

Größe der Liste. Aus diesem Grunde darf die Hindernisliste nicht zu lang werden, weil sich dann die Aufmerksamkeit zu sehr verteilt und dadurch unfokussiert wird. Die Elemente der Hindernisliste können nach gefühltem Leidensdruck priorisiert werden, um die Fokussierung der Aufmerksamkeit noch gezielter zu steuern.

Es existiert die Gefahr, dass die Hindernisliste zu einer großen Sammlung von “Man müßte mal …”-Punkten wird. Kleinkram gehört nicht auf die Hindernisliste. Wenn die Liste trotzdem zu lang wird, stimmt wahrscheinlich etwas Grundsätzliches nicht (Rahmenbedingungen, Vorgehensweise, Rollenwahrnehmung, Einhaltung der Scrum-Regeln etc.), was dem Scrum Master eigentlich schon hätte auffallen sollen.

Umgang mit den Hindernissen. Manche Hindernisse müssen erstmal “abhängen” (reifen), bevor eine Lösung sichtbar wird. Bei manchen Hindernissen reicht es bereits, sie ins Bewußtsein zu rufen, um Veränderungen auszulösen.

Die Einträge in einer Hinderliste sollten danach unterschieden werden, ob sie innerhalb (interne Hindernisse) oder außerhalb (externe Hindernisse) des Einflussbereiches des Entwicklungsteams liegen. Die internen Hindernisse sind im Normalfall vom Entwicklungsteam selbst zu lösen, die Lösung der externen Hindernisse wird meistens vom Scrum Master veranlasst. Unabhängig davon, wer die Lösung eines Hindernisses übernimmt, darf das Entwicklungsteam sich nicht darauf verlassen, dass dieses damit weg ist.

Die Elemente der Hindernisliste sind eher transient (flüchtig) als persistent. Anstatt also eine Hindernisliste regelmäßig zu aktualisieren, könnte ebensogut regelmäßig die alte vernichtet und eine ganz neue Liste aufgesetzt werden. Manche Hindernisse erledigen sich im Laufe der Zeit von alleine, werden unwichtiger oder von anderen in der Aufmerksamkeit verdrängt.

Während eine Retrospektive vertraulich ist und die besprochenen Inhalte zunächst einmal grundsätzlich den Teilnehmerkreis nicht verlassen sollen, ist die Hindernisliste prinzipiell auch für andere sichtbar. Die auf der Hindernisliste aufgeführten Punkte sind also die, die der Teilnehmerkreis einer Retrospektive bewußt nach Außen freigibt.

Umgang mit heiklen Hindernissen. Dabei stellt sich schnell die Frage, was mit den heiklen Themen ist, die zwar wichtig genug sind, um auf die Liste zu kommen, deren team-externe Veröffentlichung aber möglicherweise bestehende Konflikte verschärft oder neue auslöst? Hierauf gibt drei Antworten:

1. Sofern ein solches Hindernis auftaucht, ist dies ein Signal an das Team, sich unmittelbar und eingehender mit dem Hindernis zu beschäftigen und die passende Formulierung des Punktes für die Hindernisliste bereits als Teil der Lösung anzusehen. In vielen Fällen geht es erst einmal darum, die eigentlichen Ursachen zu finden und nicht nur auf die Symptome und Folgen zu schauen sowie die eigenen Anteile an dem Hindernis zu erkennen und von den (dann deutlicher formulierbaren) externen Anteilen zu unterscheiden.
2. Der primäre Zweck der Hindernisliste ist, die Aufmerksamkeit des Teams zu fokussieren. Die Einträge auf der Liste sind also Merker für das Team, sie müssen für das Team verständlich sein, nicht aber zwingend für Externe. Heikle Themen können also vorübergehend so abstrakt formuliert werden, dass sie extern eine geringere Reibungsfläche bieten, intern aber dennoch die Aufmerksamkeit des Teams erreichen.
3. Die Hindernisliste ist nur ein Mittel, Hindernisse zu lösen und nicht für jedes Hindernis ist die Hindernisliste das passende Mittel.

Retrospektive, Veränderungsziele, Aufgaben. Die Hindernisliste ist ein Artefakt, das Eingang in die Retrospektive findet und anschließend neu bzw. aktualisiert als ein Ergebnis einer Retrospektive herauskommt. Dabei sollte das Team während der Retrospektive möglicherweise unmittelbar Maßnahmen oder Veränderungsziele vereinbaren, so dass das Team gar keinen Bedarf mehr verspürt, die auslösenden Hindernisse auf der Hindernisliste zu verzeichnen. Dann bleiben vor allem die externen Hindernisse für die Hindernisliste übrig.

Für Lösung mancher Hindernisse ist es ausreichend, wenn das Team sich einfach etwas Bestimmtes vornimmt, sich ein Veränderungsziel setzt. Beispielsweise: “Bevor jemand die Testfälle für ein Akzeptanzkriterium programmiert und der Product Owner gerade nicht da ist, erläutert er einem anderem Teammitglied kurz sein Verständnis davon und läßt die eigene Auffassung von dem Akzeptanzkriterium vom anderen kritisch hinterfragen.” Solche Absichtserklärungen oder Ziele betreffen die eigene Arbeitsorganisation des Teams, also die Frage, wie das Team die Aufgaben löst, und dazu kann das Team jederzeit eigenständig Vereinbarungen treffen. Dazu bedarf es keiner expliziten Aufgaben in der Iterationsplanung.

Manche Hindernisse erfordern eigens geplante Aufgaben und gehören daher in das Iterationsplanungstreffen mit dem Product Owner. Beispielsweise: “Wir nehmen uns in der nächsten Iteration alle zusammen drei Tage Zeit, um die in Datenbankprozeduren enthaltenen Geschäftsregeln in die clientseitigen Geschäftsobjekte zu verlegen.” Solche Aufgaben sind dem Product Owner vorzuschlagen, den es davon zu überzeugen gilt, denn er entscheidet über die Prioritäten und den geschäftlichen Nutzen. In der Folge entstehen also ggf. neue Aufgaben, so dass diese Punkte nicht mehr auf der Hindernisliste vermerkt werden müssen.

Sonstiges. Neben der Hindernisliste kann es sinnvoll sein, auch eine Erfolgsliste anzulegen, um sich zu vergegenwärtigen, welche prozessualen und arbeitsorganisatorischen Verbesserungen bereits erreicht wurden.

Am 26. November habe ich auf den XP-Days in Hamburg in einem 10-minütigen WildCard-Slot ein Experiment frei nach Fritz Simon zum Thema Kommunikation in selbstorganisierten Systemen ausprobiert: Dazu stellen sich Freiwillige in einem Kreis auf. Statt eines Namens überlegt sich jeder Mitspieler eine Nummer zwischen 100 und 999. Jeder nennt anschließend diese laut im Kreis und jeder versucht sich so viele Nummern (als Empfängeradressen) der anderen Mitspieler zu merken. Dann geht das Spiel los, dazu fängt ein Mitspieler an, eine genannte Nummer laut zu rufen und den Empfänger mit einem Ball anzuspielen. Der Empfänger spielt wieder jemanden unter Nennung seiner Nummer an und so fort. Stimmen Nummer und Empfänger nicht überein, geht der Ball zurück an den Absender – wie bei der Post. Simultan werden die angespielten Nummern auf einem Flipchart visualisiert. Nach 5 Minuten endet das Spiel und wir widmen uns dem visualisierten Ergebnis.

Anmerkung zum Foto: Eigentlich wollten wir ab der Hälfte der Spielzeit die Verbindungslinien in blauer Farbe weiter zeichnen, um zu visualisieren, welche Verbindungen sich stabilisiert haben. Doch dann war die Zeit doch schon um [...].

• Das soziale System “Unternehmen” oder auch “Team” besteht aus Kommunikationen und Interaktionen
• Die Mechanismen, welche Kommunikationsmuster prägen, sind ungerecht: Sie haben weder mit Leistung oder anderen Werten zu tun, die dem Beobachter wichtig sein mögen. Dessen ungeachtet führen sie dazu, dass sich Strukturen bilden und diese sich stabilisieren.
• Soziale Systeme verhalten sich prinzipiell extrem konservativ und reproduzieren ihre Strukturen “Das haben wir schon immer so gemacht!” In Mundart: Matthäus-Prinzip “Denen, die haben, wird noch gegeben, denen die nicht haben, wird noch genommen oder “Der Teufel scheißt immer auf den größten Haufen”.

• Wer in einem sozialen System “mitspielt” hat die (Mit-)Verantwortung an entstehenden Kommunikationsmustern. Jeder “Mitspieler” entscheidet autonom über seine Kommunikationen und Interaktionen, es gibt keinen Kommunikationsplaner von außen!
• Wer ein intelligentes, soziales System aufbauen will, muss sich Gedanken über die impliziten und expliziten Selektionskriterien der Kommunikationen machen, die dazu nötig sind.

Retrospektiven und Lessons-Learned-Workshops sehen auf den ersten Blick sehr ähnlich aus: Das Team schaut zurück und zieht seine Schlüsse. Retrospektiven macht man halt häufiger. Also doch nur alter Wein in neuen Schläuchen?

Schauen wir zunächst einmal den klassischen Lessons-Learned-Workshop an. Typischerweise findet er am Ende eines Projekts oder nach bedeutenden Meilensteinen statt, wenn er aus Zeitgründen nicht gleich ganz ausfällt. Vordergründiges Ziel ist dabei, sogenannten Best-Practices zu identifizieren, um sie der Organisation und Folgeprojekten zur Verfügung zu stellen. Auf der Beziehungsebene geht es vor allem darum, einen Abschluß zu finden und, wie es so schön heißt, in Frieden auseinander zu gehen. Das angenehme an Lessons-Learned-Workshops ist, dass man das Gelernte selbst nicht mehr anwenden muss, denn im nächsten Projekt ist sowieso alles anders.

Retrospektiven ihrerseits sind ein kontinuierlicher Teil der Arbeit eines Projektteams. Das Team reflektiert zunächste den eignen Entwicklungsprozess sowie die Zusammenarbeit innerhalb des Teams und mit Stakholdern. Daraufhin werden Thesen zu den zugrundliegenden Ursachen für Probleme aufgestellt, um dann Maßnahmen zu entwickeln, wie der laufende Entwicklungsprozess verbessert werden kann. Auch der Umgang mit sozialen Spannungen und Konflikten hat in der Retrospektive seinen festen Platz. Abschließend entscheidet das Team, was es konkret und sofort an seiner Arbeitsweise ändern möchte.

Der entscheidene Unterschied ist, dass das Team in seinem Projekt selbst unmittelbar Änderungen vornimmt und ausprobiert, wie es besser sein könnte. Am Ende des Projekts hat das Team damit tatsächlich etwas gelernt und nicht nur schlechte Erfahrungen gemacht. Diese Lessons-Learned über neue Best-Practices und den Weg, den das Team gegangen ist, sind es dann tatsächlich auch Wert, gesammelt und weitergegeben zu werden.

Wie wärs, vielleicht starten Sie Ihr nächster Projekt doch einmal mit einer Retrospektive? Es könnte sich lohnen!

Und wenn Sie noch Anregungen suchen, schauen Sie gerne mal bei unserem “Workshop Retrospektiven” vorbei …