Selbstorganisierte Teams – so klappt’s

Die Fähigkeit, sich selbst organisieren zu können, ist grundlegend in allen agilen Methoden inklusive Scrum. Tatsächlich sind selbstorganisierte Teams eines der Grundprinzipien des Agilen Manifests, das besagt, dass „die besten Architekturen, Anforderungen und Designs von selbstorganisierten Teams stammen”.

Wenn es darum geht, wie ein angestrebtes Ziel am besten erreicht werden kann, werden sich einige Teams dafür entscheiden, die Entscheidungen für alle wichtigen technischen Fragen einer Person im Team zu überlassen.

Andere Teams werden sich dafür entscheiden, die Verantwortung für technische Entscheidungen entlang von technischen Grenzen aufzuteilen: Der Datenbank-Experte trifft Datenbank-Entscheidungen und der Programmierer mit der meisten Erfahrung mit Python trifft die Python-Entscheidungen.

Wieder andere Teams entscheiden sich vielleicht dafür, dass derjenige die Entscheidung treffen kann, der gerade an dem jeweiligen Feature arbeitet, er aber dem Team die Resultate der Entscheidung mitteilen muss.

Nicht jedes agile Team ist auf die gleiche Weise selbstorganisiert

Hierbei gibt es zwei Hauptpunkte:

• Nicht jedes agile Team wird sich auf die gleiche Weise selbst organisieren und das ist völlig okay.
• Man wird die Arbeit besser organisieren können, wenn man das kollektive Wissen des Teams nutzt, statt sich nur auf das Wissen eines einzelnen Personalchefs zu verlassen.
  Der Vorteil von selbstorganisierten Teams ist nicht, dass das Team eine optimale Art der Organisation seiner Arbeit findet, die ein Manager verpasst hat ihnen zu zeigen. Dem Team zu erlauben, sich selbst zu organisieren, hat vielmehr den Vorteil, dass sich das Team ermutigt fühlt, selbst für die Erledigung ihrer Arbeit verantwortlich zu sein.

Können wir von agilen Teams wirklich erwarten, selbstorganisiert zu sein?

Eine weitverbreitete Kritik gegenüber selbstorganisierten Teams ist: „Wir können nicht einfach acht beliebige Personen zusammenwürfeln, ihnen sagen, sie sollen sich selbst organisieren, und dann ein positives Ergebnis erwarten”.

Nun ja, ich bin mir nicht sicher, ob es nicht grundsätzlich problematisch ist, acht beliebige Personen zusammenzuwerfen und ein positives Ergebnis zu erwarten, aber ein agiles Team sollte ohnehin nicht aus einer Gruppe wild zusammengewürfelter Leute bestehen. Tatsächlich sollten diejenigen im Unternehmen, die für die Initiierung eines Scrum Projekts verantwortlich sind, die einzelnen Teammitglieder mit Bedacht auswählen.

Das Management übt subtile Kontrolle über die Selbstorganisation aus

In dem Originalpapier zu Scrum The New New Product Development Game identifizierten Takeuchi und Nonaka die „subtile Kontrolle” als einer der sechs Prinzipien. Personalentscheidungen werden als eine der Hauptverantwortlichkeiten des Managements genannt.

Die richtigen Leute für ein Projektteam auszusuchen und gleichzeitig Veränderungen der Gruppendynamik zu beobachten, sowie wenn nötig Teammitglieder hinzuzufügen oder aus dem Team zu nehmen ist eine der Hauptverantwortlichkeiten des Managements.

„Wir nehmen ein älteres und etwas konservativeres Teammitglied in das Team auf, sollte das Team zu radikal werden”, erläuterte ein Manager bei Honda. „Nach gründlicher Überlegung wählen wir mit großer Bedacht unsere Projektmitglieder. Wir analysieren die unterschiedlichen Persönlichkeiten, um herauszufinden, ob sie miteinander klar kommen.”

Die richtigen Leute ins agile Team nehmen

Wenn Sie ein Personalchef sind oder anderweitig die Zusammenstellung der Teams in Ihrem Unternehmen beeinflussen, sind hier einige Dinge, die Sie beachten sollten:

Berücksichtigen Sie alle benötigten Disziplinen von agilen Teams
Für interdisziplinäre Teams ist es wichtig, dass alle Fähigkeiten, die von der Idee bis zum fertigen implementierten Feature nötig sind, im Team repräsentiert sind. Das kann bedeuten, dass das Team anfänglich etwas größer ist als erwünscht.

Mix aus verschiedenen technischen Qualifikationsniveaus in agilen Teams

Wenn es um die Teamgröße geht, sollte man immer versuchen, ein ausgewogenes Verhältnis der unterschiedlichen Qualifikationsniveaus im Team herzustellen. Wenn ein Team über drei Senior Entwickler verfügt und keine weniger erfahrenen Programmierer hat, müssen die erfahrenen Entwickler auch weniger wichtige Features programmieren, die sie vielleicht langweilen.
Nicht nur, dass ein Junior Programmierer diese Arbeit vielleicht gerne erledigt hätte, er würde sicher auch von der Zusammenarbeit mit dem erfahrenen Kollegen profitieren.

Ausgewogenes Verhältnis von Fachwissen in agilen Teams

Zusätzlich zu einem ausgewogenen Verhältnis der technischen Fähigkeiten sollten wir auch ein gutes Gleichgewicht herstellen zwischen den Teammitgliedern, die über ein tiefes Fachwissen verfügen, und dem Problem, das wir zu lösen versuchen.
Das soll nicht bedeuten, dass wir niemals ein Team haben sollten, das komplett aus Fachexperten besteht, wenn wir die dazu Gelegenheit haben. Stattdessen sollten wir besser die langfristigen Ziele der Organisation in Betracht ziehen.
Eines dieser Ziele ist sicherlich der Aufbau von Fachexpertise im Unternehmen. Das zu erreichen wird schwierig sein, wenn alle Fachexperten in ein und demselben Team sind.

Vielfalt in agilen Teams

Vielfalt kann vieles bedeuten: Geschlecht, Herkunft und Kultur sind nur einige Beispiele. Ebenso wichtig kann es aber sein, wie unterschiedlich die Teammitglieder Probleme angehen, wie sie Entscheidungen treffen, wie viele Informationen sie für eine Entscheidung benötigen usw.
Nachforschungen haben ergeben, dass homogene Teams zwar schneller Konsens schaffen als heterogene Teams. Sie schaffen dies allerdings nur, weil sie nicht in der Lage sind, alle möglichen Optionen in Betracht zu ziehen.

Durchhaltevermögen beim Zusammenstellen agiler Teams

Auch agile Teammitglieder brauchen eine Weile, um zu lernen, gut zusammenzuarbeiten. Versuchen Sie daher, Teammitglieder, die in der Vergangenheit gut zusammengearbeitet haben, auch weiterhin im gleichen Team zu behalten. Wenn Sie ein neues Team zusammenstellen, denken Sie auch darüber nach, wie lange die Teammitglieder voraussichtlich zusammenarbeiten können, bevor einige oder sogar alle Teammitglieder wieder anderen Verpflichtungen nachkommen müssen.

Häufige Einwände gegen selbstorganisierte Teams

Es gibt einige Einwände gegen die Selbstorganisation von Teams:

1) Eine dominante Person trifft alle Entscheidungen

Eine häufige Befürchtung ist, dass eine dominante Persönlichkeit – bspw. der technische Leiter – entscheidet, dass Selbstorganisation bedeutet, dass er oder sie alle Entscheidungen trifft.

Oder aber eine dominante Persönlichkeit zwingt dem Team seine oder ihre Meinung auf, bevor das Team überhaupt die Chance hatte, das Thema zu besprechen.

Sobald Sie so etwas beobachten, sollten Sie die jeweilige Person zur Seite nehmen und über die Problematik aufklären. Geben Sie der Person zu verstehen, dass sie, auch wenn sie davon ausgeht, die richtige Lösung zu kennen, manchmal die eigene Meinung zurückhalten und anderen die Gelegenheit geben sollte, ihre Gedanken mitzuteilen.

Fragen Sie die Person, ob sie glaubt, dass das Team in der Lage wäre, die richtige Entscheidung zu treffen, wenn sie ihre Gedanken eher als Meinung als als unanfechtbare Entscheidung formulieren würde.

Nehmen Sie die Hilfe dieser Person als Mentor für das Team in Anspruch – ihre Aufgabe sollte es nicht nur sein, sicherzustellen, dass die richtigen Entscheidungen getroffen werden, sondern eher dass die Teammitglieder wachsen und auch in zukünftigen Projekten die richtigen Entscheidungen treffen können, in denen diese Person vielleicht nicht für sie da ist.

2) Mein Team erwartet, dass der Scrum Master alles organisiert

Eine zweite Sorge, die viele haben, ist, dass das Team zu passiv ist für die Selbstorganisation und stattdessen erwartet, dass der Scrum Master oder Coach voran geht und wichtige Entscheidungen für sie trifft.

Wenn dies passiert, sorgen Sie dafür, dass die Teammitglieder verstehen, dass es der Job des Scrum Masters ist, sie zu unterstützen, und nicht, ihnen die Entscheidungen abzunehmen. Wenn Sie selbst in der Doppelrolle Scrum Master/Teammitglied sind, müssen Sie natürlich nicht immer Ihre Meinung unterdrücken und dürfen sich ruhig auch zu Wort melden.

Auf jeden Fall sollten Sie nach Möglichkeiten suchen, andere zu involvieren und nicht selbst alle Entscheidungen alleine zu treffen. Fragen Sie zum Beispiel erst die anderen Teammitglieder, bevor Sie selbst Ihre Meinung preisgeben.

3) Das Team ist zu unerfahren für die Selbstorganisation

Ein dritter Einwand gegen die Selbstorganisation ist oft, dass die Teams zu unerfahren sind, um sich selbst zu organisieren.

Ich habe noch kein Team gesehen, dass zu unerfahren war für die Selbstorganisation. Wenn Teammitglieder genug Erfahrung haben, um ein Softwareprodukt zu bauen, haben sie mit großer Wahrscheinlichkeit auch genug Erfahrung, um herauszufinden, wie sie selbstorganisiert arbeiten können.

Wenn nicht, sollten Sie das Team mit Training und Coaching unterstützen.

In den meisten Fällen bedeutet dieser Einwand aber nur, dass man dem Team nicht zutraut, so selbstorganisiert zu sein, wie man es gerne hätte. So ein Pech! Üben Sie subtile Kontrolle über das Team aus; und zwar mit Hilfe der Teamzusammenstellung und des Ziels, das Sie dem Team vorgeben, und nicht durch das „Wie” bei der täglichen Arbeit des Teams.

Lerne wie du selbstorganisierte Teams leitest und unterstützt

Agile Führung, Servant Leadership und das Leiten selbstorganisierter Teams muss erlernt werden. Eine agile Führungskraft wird ganz anders gefordert als eine hierarchische Form der Vergangenheit.

Wenn du tiefer in die Themen wie Selbstorganisation und agile Führung eintauchen möchtest, empfehlen wir dir die Teilnahme an einem Training zum Agile Leader oder, wenn du dich mehr für die Prozesse und Strukturen hinter dieser Art der Führung interessiert bist zum Certified ScrumMaster.