Wissen Sie, was der größte Zeitkiller ist? Wenn man den Wert der idealen Teamgröße unterschätzt und den dadurch gefährlich steigenden Kommunikationsaufwand bei zu großen Teams.
Die magische Zahl 7
In der Folge 165 seines Podcasts berichtet Bernd Geropp über die ideale Führungsspanne, also die Anzahl der Menschen, die sinnvoll von einer Führungskraft geführt werden kann. Die Erkenntnisse lassen sich dabei nicht nur auf Führungskräfte anwenden, sondern auch und besonders bei sich selbst führenden agilen Teams.
Er erwähnt einen Artikel von Prof. Dr. Wolfgang Grunwald, seines Zeichens Arbeits- und Betriebspsychologe. Dort wird gezeigt, dass Gruppen in der Kulturgeschichte immer aus ca. 7 Menschen bestehen und größere Gruppen unausweichlich in kleinere Gruppen dieser Größe zerfallen. (Für nähere Hintergründe empfehle ich den Podcast oder eine Google-Suche nach dem Artikel „Psychologische Gesetzmäßigkeiten der Gruppenarbeit“.)
Ich fand Artikel und Podcast deshalb so interessant, da er mehr als 20 Jahre alt ist, aber Dinge aufgreift, die ich zuerst in agilen Teams und in der UX kennengelernt habe:
Hick’sches Gesetz und die magische 7
In der UX sprechen wir häufig von Hicks Gesetz. Dieses beschreibt den Zusammenhang zwischen Reaktionszeit und Anzahl der Wahlmöglichkeiten. Kurz gesagt: Mir der Anzahl von Optionen steigt unsere Reaktionszeit. Bei ca. 7 Wahlmöglichkeiten liegt die Reaktionszeit bei über einer Sekunde. Nur durch Training kann man diese Zeit verringern.
Bei UX- und Webdesignern hat sich die Faustregel etabliert, niemals mehr als 7 Optionen z.B. im Hauptmenü anzubieten oder gleichzeitig anzuzeigen.
Brooks’s Law und die Kommunikationspfade
Brook’s Law vom Amerikanischen Computer-Pionier Fred Brooks besagt, dass das hinzufügen weiterer Personen zu einem verzögerten Softwareprojekt die Umsetzungszeit verlängert, nicht verringert.
Adding human resources to a late software project makes it later
Fred Brooks (The Mythical Man-Month, 1975)
Dies liegt neben der schwierigen Einarbeitung und der komplexen Spezialaufgaben bei der Softwareentwicklung auch am höheren Kommunikationsaufwand innerhalb des Teams
Das nicht lineare Wachstum von Kommunikationspfaden nach Teamgröße
Warum ist das so? Warum zerfallen große Gruppen fast automatisch in kleinere, effektivere Gruppen?
Neben der Formel, die sich hinter Hick’s Gesetzt verbirgt ist eine weitere Formel interessant. Diese beschreibt die möglichen Kommunikationslinien von Personen, wenn jeder sich mit jedem abstimmen müsste:
n × (n-1) / 2
Die Kommunikation steigt nicht linear mit der Anzahl der Personen:
- Bei 2 Personen ist es 1 Verbindung
- Bei 3 Personen sind es 3 Verbindungen
- Bei 4 Personen sind es 6 Verbindungen
- Bei 10 Personen sind es bereits 45 Verbindungen!
(Sehr eindrucksvoll in diesem Zusammenhang auch diese Grafik von Stackoverflow.)
Wenn wir nun unsere Faustregel der Überforderung nehmen, haben wir irgendwo bei 5-7 Personen ein handhabbares Maß an Kommunikationslinien, je nachdem wieviele aktive/extrovertierte Teilnehmer es sind.
Kleine Anekdote: Ich habe vor Kurzem an einem Workshop teilgenommen, mit etwa 35 Teilnehmern. Was schätzt ihr, wieviele mögliche Kommunikationswege das gewesen wären? Ich sag’s euch: 595.
Agile Teams und Methoden der Kommunikationsvermeidung
Kommunikationsvermeidung klingt erstmal widersinnig. Wir sind ein agiles Team, wir machen Dailys, haben Product Owner, die Stakeholder managen, haben ausgiebige Retrospektiven. Wir sollen Kommunikation vermeiden?
Ja! Wir tun es bereits!
Im Wikipedia-Artikel zu Brook’s Law gibt es ein paar Einschränkungen: Sein Gesetz stammt aus dem Jahre 1975. Heutzutage gibt es viele Dinge, die aktiv Kommunikation vermeiden, da sie Konvention sind:
- Scrum Meetings mit fester Timebox
- Design Patterns und Coding Guidelines, die bestimmte Formalien bei der Arbeit festlegen
- Moderne Praktiken wie Continuous Integration oder Iterative development machen einen großen Teil der Abstimmung zwischen Entwicklern überflüssig oder reduziert sie stark.
5 Regeln zur effektiven Vermeidung Kommunikation
Auf Basis dessen kann man 5 einfache Regeln zusammenfassen, wie auch du auch außerhalb von agilen Teams deine Kommunikation verringerst und dabei mehr erreichst:
- Schafft Standards und Regeln
Standard Meetings wie im Scrum, E-Mail Regeln wie: „Antworte nicht, wenn du im CC stehst“ oder „Allen antworten nur im Notfall“. - Zerteilt Meetings
Holt die Teilnehmer einzeln oder in Kleinstgruppen ab. Widersteht der Versuchung in einem großen, klärenden Gespräch alles abzustimmen. In der Summe und im Ergebnis sind Meetings mit unter 7 Personen deutlich erfolgreicher. - Spart euch E-Mail Empfänger
Überlegt, wer wirklich die Info aus der Mail erhalten muss und wer nur aus Prinzip in der Save-My-Ass-Hauptsache-du-bist-informiert-CC-Spalte. - Gebt nicht zu viele Optionen
Muss eine Entscheidung her, bietet 2 oder 3 Optionen aus. Je mehr Optionen, desto mehr Überforderung und Abstimmungsbedarf - Reduziert die Kommunikationskanäle
Das ist vielleicht Thema für einen eigenen Blogeintrag: Vermeidet ständige Erreichbarkeit und eine große Anzahl an Kommunikationsmöglichkeiten
Wie groß sollte ein Team denn nun sein?
Nach all dem vielen Text habe ich die initiale Frage noch gar nicht ganz exakt beantwortet. Wissenschaft hin oder her, am einfachsten verhaltet ihr euch so wie Jeff Bezos mit seiner Zwei-Pizza-Regel:
Never have a meeting where two pizzas couldn’t feed the whole group.
Jeff Bezos