Content also available in:

Zugegeben, der zweite Halbsatz „warum wir weniger kommunizieren sollten“ ist in der modernen Arbeitswelt provokant, aber zutreffend. Aber dazu später mehr …

Durch den sehr hörenswerten Podcast „Führung auf den Punkt gebracht“ von Führungstrainer und Geschäftsführer-Coach Bernd Geropp ist mir ein Thema in den Sinn gekommen, über das ich schon lange einmal Bloggen wollte: Die ideale Teamgröße und der gefährlich ansteigende Kommunikationsaufwand bei zu großen Teams.

Die magische Zahl 7

In der Folge 165 des 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
Zitat twittern

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:

Habe nie ein Meeting, bei dem zwei Pizzen nicht die ganze Gruppe ernähren könnten.

Jeff Bezos
Zitat twittern
Andreas Poschen ist ein Spezialist für Konzeption, E-Commerce, UX und Digital Marketing aus Aachen. Er arbeitet als Product Owner Smart Home für Web, iOS und Android bei einem IT-Mittelständler und schreibt in diesem Blog über seine Arbeit als PO und seine Gedanken. Folgt ihm gerne auf:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.