Teamgröße: Eine:r mehr ist eine:r mehr – plus eins. Oder vielleicht doch nicht?

Ich werde oft gefragt, welche Teamgröße die richtige ist. Die Antwort ist einfach und unbefriedigend: Es kommt darauf an. Es lohnt sich aber etwas darüber nachzudenken.

Bevor ich hier bei intersoft meinen Platz gefunden habe, habe ich in meiner beruflichen Laufbahn einigen Firmen bei der Implementation von agilen Arbeitsmethoden und beim Teambuilding geholfen. Dabei habe ich gelernt: Crossfunktionale Teams sind eine großartige Sache. Je mehr das Team vom Gesamtprozess selbst leisten kann, umso autonomer kann es liefern. Es muss auch nicht jede:r alles können, aber eben nicht nur eine:r. Das Ganze kann dann zu hohen Teamzahlen führen und das kann dann zum Problem werden. Warum, erzähle ich euch in diesem Artikel.

Gina Steiner, Product Owner, intersoft AGGina Steiner, Product Owner, intersoft AG
Teamtotal – eine:r mehr ist doch egal!

Ein Team muss nicht funktionieren, kann aber

Irgendwo müssen natürlich Annahmen getroffen werden und das geschieht nun hier: Ich nehme an, ihr arbeitet in agilen Teams, die selbst entscheiden, wie sie die Dinge tun, die in ihrem Aufgabengebiet liegen. Jetzt nehmen wir weiterhin an, euer Team kriegt alles super hin und liefert zur Zufriedenheit. Dann liegt der Gedanke nahe: Och, da muss ich ja auf nichts mehr achten. Ich lege euch dennoch ans Herz, euch regelmäßig zwei Dinge zu fragen:

  • Führen wir immer noch genug kritische Retrospektiven durch, um auch weiterhin eine Achtsamkeit gegenüber verdeckten Konflikten und schlummernden Ideen/Innovationen zu gewährleisten?
  • Sind wir in einer Wohlfühlzone angekommen? Entwickeln wir uns kaum mehr weiter, sind also auf einer Art Plateau angekommen? Dies kann dazu führen, dass wir glauben, die Situation ohne weitere Probleme nach oben skalieren zu können – eine Art „Größenwahnsinn“.

Wenn ihr euer Team aber trotz Weiterbildung, Teambuilding, Retros, Speedbacks und all den wunderschönen Methoden nachhaltig nicht ans Laufen bekommt, es also nicht zuverlässig liefert, sollten möglichst neutral folgende Fragen beleuchtet werden:

  • Fehlen dem Team nachhaltig schlicht und einfach Fähigkeiten, die nicht durch Teammitglieder erlernt werden können? Wenn ja: Kann das Team durch Hinzufügen eines Teammitglieds in einen störungsfreien Zustand überführt werden?
  • Ist es möglich, dass ein Teammitglied das Team in die Dysfunktionalität führt?

Falls wir uns entscheiden, dass es dem Team (und dem Gesamtorganismus) hilft, das Team zu vergrößern, dann sollten wir uns bewusst sein, dass das gesamte Team die Tuckman-Phase mit dem neuen Teammitglied durchlaufen wird. Das allerdings ohne Garantie, dass Dysfunktionen danach ausgelöst werden und weiterhin wird dies die Komplexität der Kommunikation erhöhen.

Wenn wir das Team um eine Person vergrößern, muss diese Person nicht nur „ins Team passen“ und das Team die Forming – Storming – Norming – Performing Phasen erfolgreich durchlaufen, sondern das neue Teammitglied muss mit allen anderen Teammitgliedern eine Kommunikation aufbauen.

Es wird also kontinuierlich komplexer und dies will ich nun visualisieren. Vielleicht wird es damit möglich sein, eine Richtline zu finden, ab wann wir vorsichtig werden sollten und ab wann es anfängt, wirklich Hürden zu entwicklen. Doch schauen wir uns das einmal an:

Ist 6 eine gute Sache?

Bei 6 Teammitgliedern bedeutet das Hinzugügen einer weiteren Person, dass Kommunikationskanäle zu 6 Personen aufgebaut werden müssen.

Das ist im Fall der Erweiterung eines 6er-Teams auf ein 7er-Team nicht weiter bedenklich. Diese Person muss nur 6 Kommuniaktionskanäle aufbauen. Selbst eine Erweiterung eines 6er-Teams um zwei Personen auf ein 8er-Team hält die Anzahl der Kommunikationskanäle in einem überschaubaren Maß. Hier muss die letzte Person dann allerdings schon 7 Kommunikationskanäle aufbauen.

Generell können wir sagen: 6 (7 und 8) ist eine gute Sache!

Sollten wir ab 8 achtgeben?

Teamtotal – eine:r mehr ist doch egal!

Vereinen wir im Team aber bereits schon 8 Teammitglieder, sieht diese Sache selbst bei der Erweiterung um eine Person schon etwas komplexer aus, denn diese Person muss schon 9 Kommunikationskanäle aufbauen. Wenn wir dies visualisieren und vergleichen, sehen wir, dass es langsam anfängt, unüberschaubar zu werden.

Es sieht also wirklich so aus, als sollten wir ab 8 achtgeben.

Ist 11 eine Schnapszahl oder eine Schnapsidee?

Kommen wir gar auf die Idee ein 8er Team um drei Personen von 8 auf 11 Personen zu erweitern, wächst die Anzahl der Kommunikationskanäle bedrohlich. So sehen die Kommunikationskanäle bei 11 Personen aus:

Wir sollten uns also bewusst sein, dass die Anzahl der zu etablierenden Kommunikationskanäle von der bereits bestehenden Anzahl der Teammitglieder abhängt.

Das 12te Teammitglied müsste z. B. 11 Kommunikationskanäle aufbauen, womit dann 1+2+3+4+5+6+7+8+9+10+11 = 66 Kommunikationskanäle existieren würden. Dies ist ein signifikanter Unterschied zum Zustand von zuvor 55 Kommunikationskanälen bei nur einer Person weniger.

11 ist vermutlich schon eine Schnapsidee, aber ab 11 fängt es wirklich langsam an, eine ausgewachsene Schnapsidee zu werden.

Ein paar Rechenbeispiele

Wir haben in Meetings Kommunikations- und Abstimmungsaufwände. Jedes Team hat diese, denn jedes Team muss Arbeit planen und ihren Stakeholdern Aussagen über Lieferumfänge und Fertigstellungswahrscheinlichkeiten liefern. Das Team muss die Anforderungen verstehen und sich über das WAS und WIE austauschen. Da ich persönlich viel im agilen Umfeld arbeite, will ich an drei Rechenbeispielen veranschaulichen, was verschiedene Teamgrößen im agilen Alltag bedeuten:

Daily

Ein Daily dauert in der Regel 10 Minuten mit einer Gruppe von 6 Devs.
Danach wird dann oft noch ein allgemeiner Austausch dran gehängt, in dem neue Aufträge, Mails, Urlaube, Weiterbildungen o. Ä. besprochen werden. Das kann auch noch einmal 10 Minuten dauern.

Also in der Summe 20 Minuten – nichts was wehtäte.

Bei einer Vergrößerung auf 12 Devs ist das Daily 2,5-mal so lang. Warum 2,5-mal?
Es sind nicht nur doppelt so viele Arbeiten am Board (das würde die Zeit verdoppeln), sondern bei jeder Arbeit können auch noch doppelt so viele Personen Wortbeiträge zusteuern. Der Austausch ist dann wieder eher nur doppelt so lang.

In der Summe also 50 Minuten. Das ist ein signifikanter Zeitfaktor und es nervt, denn es „hält von der Arbeit ab“ und zwar täglich – aber das Daily ist noch gar nicht das Problem.

Planning

Das Planning ist im Vergleich zum Daily schon viel eher ein Problem, denn hier schlagen unsere 66 Kommunikationskanäle zum Teil zu, da es beim Planning auch zu einzelnen Interaktionen kommt.
Wir vergleichen also eher 15 (1+2+3+4+5) Kommunikationskanäle bei 6 Devs mit 66 (1+2+3+4+5+6+7+8+9+10+11) Kommunikationskanälen bei 12 Devs. Dazu kommt die Verdopplung der Arbeit. Ein Planning mit 12 Devs ist eher 3-mal so lang als mit 6 Devs. Da ein Planning schnell mal eine Stunde mit 6 Devs dauert, braucht ein Planning derselben Tiefe mit 12 Devs eher 3 Stunden.

Speedback

Das Speedback ist hier ein Killer, weil die 2-Stunden-Marke im Einzelgespräch erreicht wird.

Bei einem Speedback wir sehr schnell ein sehr dichter Einzelaustausch erzeugt, der eine Wunderwaffe bezüglich Konflikten, Kennenlernen, Respekt, Offenheit und Feedback ist – eine Kultur-Wunderwaffe sozusagen. Doch was passiert da genau?

In Zweiergruppen wird sich 10 Minuten Zeit genommen. 5 Minuten redet die eine Person, die andere hört nur zu, 5 Minuten andersrum. In den 5 Minuten werden bis zu 3 Dingen genannt, die der einen Person an der anderen gefallen und 2 bei denen dieselbe Person Entwicklungspotenzial sieht, dann wie gesagt das Ganze andersherum. Wird ein Speedback alle 4-6 Wochen durchgeführt, wird es bald keine Leichen mehr im Keller geben und jeder weiß ganz genau, wen man vor sich hat und wie die Person tickt – ganz egal, ob man im Arbeitsalltag viel miteinander zu tun hat oder nicht und ganz egal, ob man remote arbeitet oder nicht.

Mit 6 Personen dauert ein Speedback 50 Minuten – alle 4-6 Wochen sind diese 50 Minuten sehr gut investierte Zeit und machen Spaß.

Mit 12 Personen allerdings dauert ein Speedback 110 Minuten, also mit dem Umsortieren der Gruppe 2 Stunden. 2 Stunden in Einzelgesprächen mit 11 Kolleg:innen ist nicht spaßig. Bei dieser Gruppengröße ist man besser beraten, sich ein anderes Format zu überlegen. Ich kenne allerdings keines, was so gute Ergebnisse erzielt.

Summa Summarum

Das waren nur ein paar Beispiele, aber ihr seht, wie sich das durch alle Meetings und Scrum-Artefakte oder Kanban-Kadenzen zieht. Das Team wird dadurch schwerfällig und in Konsequenz wird oft der Sprintzyklus verlängert, was die Reaktionszeit verlangsamt. Eine gute Lösung ist das allerdings nicht.

Ergo ein kleineres Team – aber gibt es eine Leitlinie?

Wie immer gibt es kein Patentrezept, denn ein Team ist einzigartig und die Fähigkeiten, die es mitbringt, sowie die Aufgaben, die es zu erfüllen hat auch. Dennoch gibt es eine Orientierung mit der wir ins Rennen gehen können:

Ein guter Startpunkt kann bei einer Teamgröße von 6 Entwicklern mit PO und Scrummaster also bei 8 liegen, je nachdem welche Fähigkeiten in der Crossfunktionalität abgebildet werden sollen. Ab 11 wird die Kommunikation so komplex, dass Retros nicht mehr einfach zu handeln sind und das Team zusätzlich Gefahr läuft, „Subteams“ zu bilden. Fehlinformation ist nahezu vorprogrammiert. Kurz gesagt:

Je größer, desto Wollknäuel.

Gebt eurem Team also die Chance, gut funktionieren zu können.

Gina Steiner, Product Owner, intersoft AG

Über die Autorin:

Ich heiße Gina, lebe seit 30 Jahren in Hamburg und beschäftige mich mit agilen Arbeitsmethoden und Organisationsentwicklung. Ich bin akkreditierte Kanban-Trainerin der Lean Kanban University und habe im Laufe meiner beruflichen Laufbahn einigen Firmen bei der agilen Transition geholfen. Bei intersoft bin ich seit 1,5 Jahren als PO tätig und wirke dabei während der alltäglichen Arbeit auf die agile Transformation ein.

Während und nach meinem Meteorologie-Studium habe ich am Max-Planck-Institut für Meteorologie gearbeitet, wo ich mit der Open Source Welt in Kontakt kam. Seit 2003 war ich diesbezüglich stark engagiert, Vize Präsident der TYPO3 Association, danach ein Neos-Core-Team-Member und Direktorin der Neos Foundation.

Privat liebe ich es, durch die Welt zu reisen, zu schwimmen und Kajak zu fahren. Ich bin Tauchlehrerin, GUE Höhlentaucherin und segle ab und zu auf einem Traditionsschiff namens Windsbraut.