Zu groß zum Skalieren – Leitfaden zur optimalen Scrum-Teamgröße

Veröffentlicht: 2022-03-11

Hören Sie sich die Audioversion dieses Artikels an

Ob Sie in einem kleinen Startup oder in einem großen Unternehmen an einem neuen Produkt arbeiten, Sie kommen wahrscheinlich an einen Punkt, an dem Sie zu viele Leute in einem Team haben. Das frühzeitige Erkennen der Anzeichen bewahrt Sie davor, die ineffizienteste Phase des Teams zu erreichen.

Jedes Produkt ist anders und die Teams, die daran arbeiten, sind es auch. Wenn Sie also ein Team aufteilen, müssen Sie auch einige Entscheidungen treffen, die Ihre Umstände widerspiegeln. Einige Dinge zu beachten sind:

  • So bewahren Sie die Integrität des Know-hows, wenn Teamkollegen nicht mehr zusammenarbeiten
  • Sollten Sie Funktionen aufteilen (z. B. Front-End- und Back-End-Teams)?
  • Sollten die neuen Teams separate Backlogs haben?
  • Soll das Produktmanagement-Team entsprechend wachsen?

Wann sollten Sie mit der Erstellung eines zweiten Teams beginnen?

Der offensichtlichste Hinweis, über eine Teamaufteilung oder das Hinzufügen eines neuen Teams nachzudenken, ist, wenn Ihr Budget steigt. Dies kann eine neue Investitionsrunde in einem Startup oder neue Ziele für Ihr Produkt in einem Unternehmen sein. Wenn die Budgeterhöhung so erheblich ist, dass Ihr Team um das Dreifache oder mehr wächst, ist es ein Kinderspiel, dass Sie Ihr aktuelles Team aufteilen müssen, um Know-how zu verteilen. Die Entscheidungen werden jedoch nicht so eindeutig, wenn die Budgeterhöhung schrittweise erfolgt und Sie am Ende ein paar neue Leute in die Liste aufnehmen. Wenn Sie beispielsweise vorhaben, Ihr Team von 7 auf 11 Personen zu vergrößern, ist dann eine Aufteilung erforderlich? Agile fördert kleine Teams, aber auch Einzelpersonen und Interaktionen über Prozesse und Tools. Zwei oder mehr Teams zu haben, schafft unweigerlich mehr Prozesse, um synchron arbeiten zu können.

Was sagen die Experten?

Jeff Bezos, der Gründer von Amazon, wendet die Zwei-Pizza-Regel sowohl für Meetings als auch für Teams an. Das bedeutet, dass jeder nur so viele Leute haben sollte, wie zwei Pizzen über das Mittagessen versorgen können.

Zwei-Pizza-Regel für Scrum-Teams

Der Scrum Guide schlägt vor, zwischen drei und neun Teammitglieder zu haben, die das Sprint Backlog tatsächlich ausführen. Das bedeutet, dass Sie den Product Owner oder Scrum Master nicht in die Gesamtzahl einbeziehen würden, es sei denn, einer von ihnen implementiert die Sprint-Backlog-Elemente.

Diese Zahlen scheinen intuitiv Sinn zu machen, aber es steckt auch etwas Mathematik dahinter. Wenn Sie an ein Team denken, ist jede Person wie ein Knoten und sie verbindet sich mit anderen Knoten. Dies sind die zwischenmenschlichen Beziehungen zwischen Teamkollegen. Sie können freundlich, konkurrenzfähig, boshaft oder fürsorglich sein. Was auch immer die Beziehung zwischen zwei Menschen ist, es ist immer noch eine Verbindung, die von jeder Person eine gewisse geistige Leistungsfähigkeit erfordert. Wenn ein Team wächst, wächst diese Anzahl dieser Links nicht linear. Die Formel für Verbindungen zwischen Knoten ist \(n(n-1)/2\). Hier ist das Linkwachstumsdiagramm:

Anzahl der Verbindungen zwischen Teammitgliedern

Das Diagramm veranschaulicht aus mathematischer Sicht deutlich, warum Teams am effizientesten arbeiten, wenn sie nicht zu groß sind. Wenn wir die vom Scrum Guide vorgeschlagenen 3 bis 9 Teammitglieder nehmen, kommen wir auf 3 bis 36 Links. Wenn wir auf 15 Leute anwachsen würden, hätten wir über 100 Links. Ein solches Team konnte nur dann effizient arbeiten, wenn seine Aufgaben sehr genau definiert waren und sich selten überschnitten oder wenn es einige inoffizielle Untergruppen gab. Beides ist beim Arbeiten nach agilen Prinzipien nicht der Fall oder erwünscht.

Anzeichen dafür, dass das Team zu groß wird

Tägliches Scrum

Manchmal auch als Daily Standup bezeichnet, ist das Daily Scrum ein Treffen des gesamten Teams, um Fortschritte und Hindernisse des Sprints zu besprechen. Der Scrum Guide schlägt vor, diese auf 15 Minuten zu timen, und das ist ein guter Lackmustest für die Teamgröße. Wenn Sie feststellen, dass Ihr Team die 15-Minuten-Leiste überschreitet, kann dies auf eines von zwei Dingen hindeuten:

  • Die Daily Scrums sind nicht effizient. Die Leute gehen zu sehr ins Detail. Oder es gibt keine klare Sprechreihenfolge und es braucht Zeit, bis sich Teamkollegen zu Wort melden. Vielleicht nutzt der Product Owner oder Scrum Master das Daily Scrum als Gelegenheit, verschiedene Updates bereitzustellen, die nichts mit dem Sprint zu tun haben.
  • Das Team ist zu groß. Wenn die Daily Scrums effizient sind, Sie aber immer noch die 15 Minuten überschreiten, dann haben Sie vielleicht einfach zu viele Leute im Team. Sie sollten auch bemerken, dass die Leute das Interesse verlieren, weil es eine Grenze gibt, wie viele Informationen eine Person aufnehmen kann. Wenn zu viele Leute Updates bereitstellen, wird es schwierig, den Fortschritt aller zu verfolgen und den Status des Teams zu verstehen . Dies führt dazu, dass sich die Menschen nach innen wenden und nur über ihre Fortschritte nachdenken, anstatt nach Möglichkeiten Ausschau zu halten, anderen zu helfen.

Grooming und Sprintplanung

Sowohl Grooming als auch Sprint Planning sind Aktivitäten, die sich auf das Aufschlüsseln von User Stories und das Abschätzen ihrer Lieferzeit oder -größe beziehen. Mehr Leute können dem Team helfen, bessere Entscheidungen zu treffen, aber zu viele Leute könnten das Team in eine Sackgasse führen. Es gibt immer verschiedene Wege, um dieselbe Aufgabe zu lösen, und die Anzahl der Argumente auf jeder Seite steigt mit der Anzahl der Personen im Team.

Wie beim Daily Scrum sollten Sie eine ineffiziente Planungssitzung nicht mit einem zu großen Team verwechseln. Letztendlich ist es die Aufgabe des Scrum Masters, die Scrum-Zeremonien effizient und effektiv zu gestalten.

Retrospektive

Während einer Retrospektive können die Teammitglieder etwaige Streitigkeiten oder Konflikte lösen und Wege finden, ihren Arbeitsprozess zu verbessern. Retrospektiven lehren uns die Kunst des Kompromisses, da sie uns dazu bringt, Gemeinsamkeiten zwischen verschiedenen Parteien zu suchen. Ein Team ist so mächtig, wie seine Mitglieder bereit sind, bei ihren Differenzen Kompromisse einzugehen.

Aber wie bei der Sprintplanung schaffen zu viele Teammitglieder zu viele Verbindungen, die alle potenzielle Konfliktpunkte darstellen. Fangen Sie an zu bemerken, wenn Sie während Retrospektiven immer weniger Gemeinsamkeiten finden. Es kann ein Zeichen dafür sein, dass das Team zu groß ist und von einer Aufteilung profitieren würde.

So teilen Sie das Team auf

Auf den ersten Blick ist die Aufteilung des Teams eine relativ einfache Aufgabe. Teilen Sie die Teammitglieder in zwei Gruppen auf, stellen Sie sicher, dass jeder über ähnlich erfahrene Mitarbeiter verfügt, und definieren Sie die Ziele für die neuen Teams. Allerdings gibt es einige Dinge zu beachten, die einen großen Einfluss auf den zukünftigen Erfolg der neuen Teams haben könnten.

Überlegungen bei der Aufteilung eines Teams

Team-Moral

Wahrscheinlich ist eines der wichtigsten Dinge, die man im Auge behalten sollte, die Teammoral. Am Ende sind es die Leute im Team, die in der neuen Zusammensetzung arbeiten müssen. Wenn das Team in Bezug auf agile Prinzipien ausgereift ist, sollte es in der Lage sein, die Aufteilung selbst vorzunehmen. Dies ist das wünschenswerteste Ergebnis, da die Teammitglieder ihre internen Beziehungen am besten kennen – wer mit wem am besten zusammenarbeitet und wer von getrennten Teams profitieren könnte.

Funktionsübergreifende Teams

Scrum fördert funktionsübergreifende Teams „mit allen Fähigkeiten als Team, die notwendig sind, um ein Produktinkrement zu erstellen“. Dies gilt für die Skalierung auf zwei oder mehr Teams. Für viele Entwickler, besonders wenn sie neu in Agile sind, besteht die natürliche Tendenz, neben technischen Linien zu denken. Beispielsweise möchten Teams häufig in Back-End- und Front-End-Teams aufgeteilt werden. Dies mag in einigen seltenen Fällen sinnvoll sein, aber als Produktmanager sollten Sie meistens davon abraten. Ein Team voller Frontender ist nicht in der Lage, ein Produktinkrement alleine zu liefern und wird natürlich anfangen, mehr über die technische Kapazität nachzudenken, die sie eint. Stattdessen sollten sie sich auf den Kunden und die Befriedigung seiner Bedürfnisse konzentrieren.

Eine weitere interessante Überlegung sind die Nicht-Entwicklungsrollen im Team. In verschiedenen Situationen kann ein Team einen Designer, Geschäftsanalysten oder einen QA-Spezialisten umfassen. Sobald Sie ein Team aufgeteilt haben, insbesondere wenn Sie nicht zu viele neue Mitarbeiter einstellen, entsteht ein Dilemma, was mit diesen Rollen zu tun ist. Sollten sie ihre Zeit unter den Teams aufteilen? Sollten Sie neue Leute einstellen, die sich nur einem Team widmen würden? Sollen sie mit den Entwicklungsteams zusammenarbeiten oder Teil des Produktteams sein?

Dafür gibt es wirklich keinen einzigen guten Rat, da jedes Produkt so unterschiedlich ist. Diese Entscheidungen werden am besten zusammen mit dem Team getroffen, wobei zu berücksichtigen ist, dass Sie unterwegs möglicherweise Kurskorrekturen vornehmen müssen.

Sollten die Teams getrennte Backlogs haben?

Wenn ein Team aufgeteilt ist, stellt sich natürlich die Frage, ob sie denselben Rückstand abarbeiten oder getrennte haben sollten. Als Orientierungshilfe können wir das Scaled Agile Framework heranziehen.

Scrum@Scale

Scrum@Scale ist eine Methodik, die vom Schöpfer des Scrum Guide entwickelt wurde. Scrum@Scale ist nicht sehr präskriptiv und beschreibt nicht speziell, wie mit Product Backlogs umzugehen ist. Er weist jedoch auf zwei Punkte hin:

  • Der Prozess auf Teamebene ist derselbe wie im Scrum Guide beschrieben.
  • Product Owner bilden ein Product Owner Team, in dem sie ein einziges einheitliches Backlog erstellen. Dies geschieht, um Doppelarbeit zu vermeiden und Sichtbarkeit im Unternehmen zu schaffen. Gleichzeitig haben Teams ihre separaten Backlogs, die Elemente aus dem einheitlichen Backlog speisen.

Im Wesentlichen stellt Scrum@Scale also die neuen Teams mit ihren eigenen jeweiligen POs und Backlogs dar. Es fügt lediglich einige zusätzliche Strukturen hinzu, um die Arbeit zwischen den Teams zu koordinieren. Scrum@Scale funktioniert am besten mit mehreren, Dutzenden oder Hunderten von Teams, aber es kann einige wertvolle Erkenntnisse liefern, selbst wenn Sie mit zwei Teams arbeiten.

Groß angelegtes Scrum (LeSS)

LeSS fördert einen interessanten Ansatz für das Product Backlog. Bei LeSS arbeitet ein Product Owner mit zwei bis acht Teams. Es mag unmöglich erscheinen, dass ein PO mit so vielen Teams zusammenarbeitet. Die LeSS-Philosophie ist, dass der PO auf einer abstrakten Ebene arbeitet und die Verantwortlichkeiten für die Verfeinerung der Product Backlog Items an die Teams delegiert. In diesem Fall sollten funktionsübergreifende Entwicklungsteams auch Fachkenntnisse einbeziehen, um ein Produktinkrement liefern zu können. In LeSS gibt es nur einen Rückstand.

So bleiben Sie auf dem Laufenden

Für einen Produktmanager bedeuten mehrere Teams mehr Arbeit, um den Fortschritt zu verfolgen und auf Anfragen zu reagieren.

Bleiben Sie auf dem Laufenden, nachdem Sie ein Team aufgeteilt haben

Priorisieren Sie Besprechungen

Wenn Sie an den Daily Scrums eines einzelnen Teams teilgenommen haben, wird es höchstwahrscheinlich unproduktiv sein, diese Gewohnheit fortzusetzen. Betrachten Sie tägliche Scrums als eine Gelegenheit, vorbeizuschauen, um einen Puls der Teams zu bekommen, und erinnern Sie sie daran, dass Sie für Diskussionen zur Verfügung stehen.

Ihre Teilnahme an Sprint-Planungssitzungen hängt von der Reife der Teams ab. Wenn die Teams viele frische Gesichter enthalten oder sie schon lange nicht mehr mit Agile arbeiten, ist eine Anleitung von Ihrer Seite erforderlich. Auch wenn Sie sich sicher fühlen, das Team ohne Ihre Anwesenheit planen zu lassen, stellen Sie sicher, dass Sie während der Planung für einen Besuch oder Voice-Chat mit dem Team verfügbar sind, falls Fragen auftreten.

Sprint Reviews müssen Ihre oberste Priorität bleiben und alle sollten besucht werden. Sprint-Reviews sind eine Gelegenheit, Feedback aus erster Hand von allen anwesenden Stakeholdern und dem Team selbst zu erhalten. Es ist eine Zeit, in der Annahmen validiert werden und die nicht verpasst werden sollte.

Engagieren Sie sich mehr mit Scrum Mastern

Während Sie Ihr Engagement bei einigen der Scrum-Zeremonien möglicherweise reduzieren, sollten Sie Ihre Partnerschaft mit dem Scrum Master verdoppeln. Nach der Trennung des Teams könnte es jetzt mehr als einen geben, in diesem Fall müssten Sie eng mit allen zusammenarbeiten.

Stellen Sie sicher, dass Sie darauf vertrauen können, dass sie einen ehrlichen Überblick über den Fortschritt des Teams und alle Probleme geben, die während der Sprints auftreten. Durch diese Beziehungen bleiben Sie auf dem Laufenden, ohne an allen Scrum-Zeremonien teilnehmen zu müssen.

Führen Sie Scrum of Scrums ein

Ein Scrum of Scrums wird manchmal als Meta-Scrum bezeichnet und ist eine neue Zeremonie, die typischerweise eingeführt wird, wenn Scrum-Prozesse skalieren. Es ist eine Nachbildung des Daily Scrum auf höherem Niveau. Jedes Team ernennt einen Botschafter, die sich jeden Tag beim Scrum of Scrum treffen, um Fortschritte und Hindernisse zu besprechen. Diese Zeremonie wird auch verwendet, um alle teamübergreifenden technischen Probleme hervorzuheben, die möglicherweise gelöst werden müssen.

Erwägen Sie die Erweiterung des Produktteams

Wenn Ihr Scrum-Setup erfordert, dass der Produktmanager aktiv mit dem Team zusammenarbeitet, sollten Sie erwägen, mehr Leute auf der Produktseite hinzuzufügen. Es gibt einige Möglichkeiten, dies anzugehen.

Junior Produktmanager. Ein Weg besteht darin, eine strategischere Rolle für sich selbst zu übernehmen und gleichzeitig Junior-Produktmanager einzustellen, die einige der täglichen Aufgaben erledigen. Sie könnten einige Aufgaben wie die Qualitätssicherung (QA), das Schreiben von Spezifikationen für User Stories oder das Erstellen von Modellen auf hoher Ebene für neue Funktionen übernehmen.

Business-Analysten. Eine andere Möglichkeit besteht darin, einen oder mehrere Business-Analysten in oder neben den Teams arbeiten zu lassen. Der Produktmanager kann mit Geschäftsanalysten zusammenarbeiten, um Produktannahmen zu identifizieren, und diese dann Wege finden lassen, um sie entweder durch Recherchen oder neue Funktionen zu validieren.

Fazit

Wenn Ihr Team wächst, werden Sie wahrscheinlich einige Anzeichen dafür bemerken, dass es zu groß wird, insbesondere in:

  • Tägliches Gedränge. Wenn Sie bei Daily Scrums den 15-Minuten-Zeitrahmen überschreiten und feststellen, dass die Leute anfangen, das Interesse zu verlieren.
  • Sprintplanung. Wenn du beim Sprint Planning immer öfter in Deadlocks gerätst.
  • Retrospektive. Wenn Sie merken, dass es bei Retrospektiven immer schwieriger wird, Kompromisse einzugehen.

All dies deutet darauf hin, dass Sie möglicherweise das Team aufteilen müssen. Ein Team aufzuteilen ist scheinbar eine einfache Aufgabe, hat aber auch nachhaltige Folgen und jeder Produktmanager muss dabei einige Dinge beachten:

  • Moral der Mannschaft. Idealerweise sollten Sie das Team entscheiden lassen, wie es es aufteilen möchte, um die Anzahl der verschrotteten guten Arbeitsbeziehungen zu minimieren.
  • Funktionsübergreifende Teams. Teams sollten über alle erforderlichen Fähigkeiten verfügen, um ein Produktinkrement zu erstellen.
  • Produktrückstand. Entscheiden Sie, ob Ihre Teams ein separates oder ein einheitliches Backlog haben werden.

Um zwei oder mehr Teams im Auge zu behalten, müssen Sie Prioritäten setzen. Ein effektiver Produktmanager sollte planen, wie er mit den neuen Teams auf dem Laufenden bleibt:

  • Priorisieren Sie Besprechungen. Überlegen Sie, welche Agile-Zeremonien Ihre Zeit wert sind und welche ignoriert werden können.
  • Arbeiten Sie mit Scrum Mastern zusammen. Verwenden Sie Scrum Master als Ihre Team-Stellvertreter und sammeln Sie Informationen von ihnen.
  • Erweitern Sie das Produktteam. Fügen Sie Personen hinzu, die mit Ihnen zusammenarbeiten und entweder bei sich täglich wiederholenden Aufgaben helfen oder Benutzerforschung und Marktanalysen durchführen.

Wenn Sie diese Vorschläge nutzen, sollten Sie in der Lage sein, eine saubere Teamaufteilung zu erreichen. Wenn Ihre Teams weiter wachsen und Sie in Zukunft noch mehr Teams hinzufügen werden, sollten Sie etwas über Scaled Agile Framework lesen, das Struktur- und Prozessvorschläge für Agile in großem Maßstab bietet.