Die Black Box der Scrum Teambildung
Scrum ist ein Rahmenwerk, das eine Struktur für agiles Arbeiten vorgibt. Entstanden ist die Idee im Bereich der Softwareentwicklung, da die Erfinder von Scrum festgestellt haben, dass ein iterativ-inkrementelles Vorgehen mit regelmäßigen, strukturellen Feedbackschleifen schneller zu funktionierender Software führt. Die Teams in diesem Rahmenwerk sollen sich selbst organisieren, auf Augenhöhe miteinander arbeiten und selbst entscheiden, wer idealerweise mit welcher Aufgabe betraut wird. Offenheit gegenüber den Kompetenzen der anderen Teammitglieder und offene Kommunikation wird groß geschrieben. Es gibt keine Projektleiter oder Manager, sondern nur eine Gruppe gleichgestellter Entwickler, die auf Augenhöhe mit dem Product Owner (dem Produktverantwortlichen und der Schnittstelle zur volatilen Umwelt / dem Kunden) und dem Scrum Master (einem Coach und Unterstützer / Ermöglicher, der sich als sogenannter „servant leader“ versteht) agieren. Im Vordergrund steht das Ziel, in jeder Iteration ein „working piece of software“ zu entwickeln. Die Basis der Zusammenarbeit ist das agile Mindset aufbauend auf dem Agilen Manifest, das alle Teammitglieder verinnerlicht haben sollten.
Das Team in Scrum
Unter diesen Bedingungen wird durch das Scrum-Framework (idealtypisch) mit Hilfe konsistenter Strukturen und klarer Ablaufregeln die Umweltkomplexität soweit reduziert, dass Scrum-Teams schnell und effektiv, agil und kundenorientiert und mit stetig hoher Wertschöpfung arbeiten. Die eierlegende Wollmilchsau also, mit der die Herausforderung der Globalisierung (immer komplexere Wettbewerbsstrukturen und Umwelt) und der digitalen Transformation (immer stärkere Nutzung von intelligenter Technik bis hin zur sog. Vernetzungsgesellschaft) entspannt angegangen werden können. So funktioniert zumindest die graue Theorie. Die Crux an der Idee selbstorganisierter Teams im Scrum-Framework ist jedoch die Tatsache, dass hier die Prozesse, die bei der Teambildung eine Rolle spielen nicht betrachtet oder beachtet werden. Wenn ein Team aus hierarchisch gleichgestellten Individuen besteht, die ihre Aufgaben in der Interaktion mit den anderen Mitgliedern SELBST entwickeln sollen, sind die relevanten Teambildungsprozesse besonders interessant.
Das Fünf-Phasen-Modell des Teambildungsprozesses
Bruce Tuckman – ein US-amerikanischer Psychologe, Organisationsberater und Hochschullehrer an der Ohio State University – entwickelte schon 1965 ein Fünf-Phasen-Modell des Teambildungsprozesses¹:
Forming-Phase
Zu Beginn steht die Forming-Phase, in der das Team den ersten Kontakt aufnimmt und sich kennenlernt.
Storming-Phase
Nachdem die erste Schüchternheit verflogen ist, folgt die Storming-Phase, bei der jedes Teammitglied seinen Platz finden bzw. erkämpfen muss. Trotz der propagierten „Augenhöhe“ kann es auch in Scrum-Teams zu Kämpfen um Macht und Status kommen, man denke nur an das viel beschworene Beispiel des „Star-Entwicklers“ im Team, der unausgesprochene Privilegien nutzt und unter dem non-verbalen Schutz des Managements außerhalb des Teams steht. Während der Storming-Phase ist die Produktivität des Teams eher gering, in Scrum-Sprache ausgedrückt: Die Team-Velocity ist (noch) gering, d.h. in diesem Sprint werden vergleichsweise wenige Storypoints erarbeitet.
Norming-Phase
Nach dem Kampf folgt die Norming-Phase, in der Regeln und Übereinkünfte getroffen werden, um ein effektives Arbeiten zu ermöglichen. Im Rahmen des Scrum-Frameworks sind diese (Ablauf-)Regeln für die Zusammenarbeit bereits festgelegt. Hier ist der Scrum Master gefragt, den Teammitgliedern das Verständnis von Scrum nahe zu bringen. Er muss erläutern, was der Sinn bspw. der Daily Stand-ups ist oder die Retrospektive so moderieren, das hinsichtlich möglicher Komplikationen bei der Zusammenarbeit eine für alle nachvollziehbare Lösung gefunden werden kann.
Trotz dieser vordefinierten Regeln wird es in jedem Scrum-Team auch implizite Regeln geben, die sich bspw. * auf die Expertise einzelner Mitglieder beziehen (wie sich ein Mitglied als Experte in einem Fachgebiet profilieren kann), * auf die Frage beziehen, wie mit Fehlleistung umgegangen wird oder wie opportunistisches Verhalten (TEAM = Toll, Ein Anderer Macht‘s /lazy co-working) erkannt und geahndet wird.
In diesem Zusammenhang sind die einzelnen Teamrollen von immenser Bedeutung, die der Engländer Meredith Belbin 1965 anhand seiner Team-Forschung identifizierte². Er entwickelte ein Modell aus neun Teamrollen, wobei er * drei handlungsorientierte Rollen (Macher, Umsetzer, Perfektionist), * drei kommunikationsorientierte Rollen (Koordinator, Teamworker, Weichensteller) und * drei wissensorientierte Rollen (Erfinder, Beobachter, Spezialist) als relevant identifizierte. Anhand seiner Forschung ging Belbin davon aus, dass ein möglichst heterogenes Team mit allen Rollen am effektivsten arbeitet.
Performing-Phase
Nach der Norming-Phase folgt nach Tuckman die Performing-Phase, in der das Team – jetzt mit gemeinsamen Regeln und einer gemeinsamen Identität/Vision ausgestattet – am effektivsten arbeitet und eine hohe Velocity aufweist.
Adjourning-Phase
Zum Ende des Projektes, mit Abschluss der Aufgabe folgt dann noch die Adjourning-Phase, in der echte „Trauer-Arbeit“ geleistet werden muss. Das Team, das sich zusammengerauft und gut funktioniert hat, trennt sich wieder. In Abhängigkeit von den Erfahrungen aus dieser Adjourning-Phase werden die Teammitglieder in einem neuen Scrum-Team agieren. Idealerweise erreicht ein Scrum Team die Performing-Phase innerhalb des ersten Sprints. Da Tuckmans Modell jedoch keine Automatismen impliziert, ist es in der Realität möglich, dass sich die beschriebenen Phasen (mit Ausnahme der Forming-Phase) immer wieder wiederholen (schlimmstenfalls in jedem Sprint) oder dass die Performing-Phase nie erreicht wird.
Das Team als soziales System
Auf Basis der (Luhmann’schen) Systemtheorie³ sind nicht die einzelnen Individuen Kern der Betrachtung, sondern ihre Kommunikation / sozialen Interaktionen mit anderen Individuen. Organisationen und Teams als soziale Systeme müssen zum eigenen Grenzerhalt die Binnenkomplexität reduzieren, d.h. sie müssen Handlungsmuster und ein Sinnraster generieren, auf dessen Basis sie in die unendliche Vielfalt der Möglichkeiten der Umwelt eine Ordnung legen. Soziale Systeme müssen sich zunächst erstmal „schließen“, um anschließend eine Öffnung für die Umwelt zu schaffen. Erneut wird deutlich, dass nicht nur die aktuelle Kommunikation / Interaktion relevant ist, sondern auch die bisherige Sozialisation und die Erfahrungen der Individuen, denn nur auf Basis ihrer (in der Vergangenheit etablierten) Sinnraster können Individuen kommunizieren.
Diese Logik stützt auch die Argumentation Belbins, dass heterogene Teams effektiver arbeiten als homogene: Über je mehr unterschiedliche Sinnraster ein soziales System (Team) verfügt, desto mehr Anknüpfungspunkte ergeben sich zur Bearbeitung der Umweltkomplexität. Wenn jedoch Handlungsstrukturen und Sinnraster aufgrund von Kommunikation und Interaktionen entstehen, ist auch eine gemeinsame (Unternehmens-/Team-) Vision erst ex post erklärbar. D.h. eine Teamidentität, eine Unternehmenskultur folgt der Kommunikation und entsteht bzw. ändert sich im Nachgang zur Interaktion. Das bedeutet aber auch, dass vorgegebene Werte und Visionen nicht ex ante plan- und steuerbar sind. Man kann folglich eine agile Unternehmenskultur nicht „managen“, sondern man kann nur ein agiles Mindset vorleben und kommunizieren und muss abwarten, was die einzelnen Teammitglieder (auf Basis ihrer eigenen Sinnraster) daraus machen.
Der im Rahmen von Scrum sehr hoch gehaltene Wert der Offenheit ist folglich ggf. gar nicht anschlussfähig und wird von den Teammitgliedern evtl. gar nicht umgesetzt bzw. verinnerlicht (weil ein Teammitglied bspw. früher gelernt hat, dass Offenheit karriereschädlich ist). All diese Ausführungen verdeutlichen, wie komplex die selbstorganisierte Teambildung ist und wie viele Dimensionen bei der Etablierung von Scrum und agilem Arbeiten berücksichtigt werden müssen.
Fazit und Schlussfolgerung
Möglicherweise erreicht ein Scrum-Team, das in der Mehrheit aus Softwareentwicklern besteht, die aufgrund ihrer (vermutlich) sehr ähnlichen Persönlichkeit, Expertise und Sozialisation eher als homogen einzuschätzen sind, gar nicht die nötige (Rollen-)Heterogenität, um in die effektive Performing-Phase eintreten zu können. Phänomene wie Groupthink oder die In-Group / Out-Group-Abgrenzung können zudem zu einem Wahrnehmungs-Bias führen. Folglich könnte ein (homogenes) Scrum-Team im ungünstigsten Fall sogar „betriebsblind“ werden, also genau dass, was Ken Schwaber und Jeff Sutherland mit der Entwicklung ihres Scrum-Frameworks verhindern wollten.
Es bleibt zu resümieren, dass zur Bildung eines (dauerhaft erfolgreichen) Scrum-Teams sehr viel mehr Aufwand dazu gehört, als der Scrum-Guide vermuten lässt: Angefangen bei der „richtigen“ Auswahl der Teammitglieder bis zur (kaum steuerbaren) „richtigen“ Kommunikation von Werten und Visionen. Aus der jahrelangen Personalauswahl-Forschung wissen wir, wie schwer es ist, die eigenen Mitarbeiter „richtig“ einzuschätzen. Auf Basis systemtheoretischer Logik wird sowieso die eigene Beobachtung (und Interaktion) den Beobachtungsgegenstand verfälschen! Darüber hinaus optimieren sich Individuen fortwährend in ihrem sozialen System. Sie nehmen die entstehenden Kräfte (oft unbewusst) wahr und passen sich ihnen an, was eine geplante Teamentwicklung fast unmöglich macht.
Am Schluss bleibt die Frage, was ein selbstorganisiertes, agiles Scrum-Team abseits von der Lehre der Scrum.org tatsächlich ist: Wirklich die Lösung für die Herausforderung der digitalen Transformation? Oder vielleicht nur: alter Wein in neuen Schläuchen?
Hinweise:
Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.
[1] Beschreibung des Phasenmodells nach Tuckmann auf Wikipedia: https://de.wikipedia.org/wiki/Teambildung#Phasenmodell_nach_Tuckman
[2] Beschreibung der Teamrollen nach Belbin auf Wikipedia: https://de.wikipedia.org/wiki/Teamrolle#Teamrollen_nach_Belbin
[3] Niklas Luhmann, „Soziale Systeme: Grundriss einer allgemeinen Theorie.“ Suhrkamp Verlag; 1. Auflage 30. März 1987
Barbara Hilgert hat im t2informatik Blog weitere Beiträge veröffentlicht, u.a.
Mit Working Out Loud Kompetenzen für agiles Arbeiten entwickeln
Scrum als Grundlage für „Neues Lernen“
Braucht es ein digitales Mindset?
Barbara Hilgert
Barbara lebt in Schleswig-Holstein und arbeitet in Berlin & Lübeck. Sie ist agile Coach, berät kleine und mittelständische Unternehmen zur Thematik der digitalen Transformation und hat viel Know-how in den Bereichen Teamentwicklung und (New) Learning. „Wissen teilen ist Macht“ ist nicht nur ihre Lebensmaxime, die Entwicklung dieses Mindsets ist auch das Ziel ihrer Beratungen und Qualifizierungen: Die Ausbildung eine der Kernkompetenzen für die Zukunft der Arbeit und eine wichtige Voraussetzung für die kollaborative Netzwerkarbeit und „Neues Lernen“.