Get in touch
Bei der Diskussion über die optimale Teamgröße stößt man irgendwann unweigerlich auf die „Zwei-Pizza Regel“ von Jeff Bezos, dem CEO von Amazon. Diese Regel besagt, dass Ihr Team nie so groß skaliert werden sollte, dass es sich nicht von zwei Pizzas ernähren könnte. Bezos zufolge beträgt diese Zahl zwischen sechs und sieben Personen (solange Sie nicht mit extrem hungrigen Leuten zusammenarbeiten).
Die Begründung: Mit zunehmender Teamgröße nimmt auch die Anzahl der Verbindungen (Links) zwischen den Team-Mitgliedern zu. Was noch schlimmer ist, die Anzahl der Verbindungen zwischen Team-Mitgliedern steigt überproportional zur Teamgröße; dies kann mit der folgenden Formel dargestellt werden:
n(n-1)/2
In der Praxis sieht das dann so aus: Wenn Ihr Team aus fünf Personen besteht, gibt es insgesamt zehn Verbindungen zwischen diesen Personen (d. h., es müssen zehn Gespräche stattfinden, um sicherzustellen, dass jeder mit jedem gesprochen hat). Sowie Sie jedoch die Teamgröße verdoppeln, gibt es plötzlich 45 Links zwischen allen Personen. In anderen Worte, bei doppelter Teamgröße wird die Anzahl der Verbindungen aller Team-Mitglieder mehr als vervierfacht.
Dies ist mehr als nur eine mathematische Übung. Bei zunehmender Anzahl der Links sinkt die Produktivität des Teams – etwas, das auf den ersten Blick nicht viel Sinn zu ergeben scheint. Aber bedenken Sie nur, wie viele Menschen nun Informationen erhalten müssen. Anders ausgedrückt: Mit wie vielen Leuten müssen Sie sprechen, um alle möglichen Meinungen einzuholen? Wie lange dauern Meetings jetzt?
Das Scrum-Framework nimmt sich dieses Umstandes an und besagt, dass Scrum am besten mit Teams von fünf bis neun Personen funktioniert. Leider benötigen einige komplexe Projekte schlicht und ergreifend wesentlich mehr Kompetenz, Know-how und Arbeitskräfte, als neun Personen in ausreichender Tiefe zur Verfügung stellen könnten.
Das Team, in dem ich arbeite, ist ein solches Team. Das Team besteht derzeit aus acht Entwicklern (einer davon ist unser Scrum Master), zwei Software-Testern, einem UX Architekten, einem Designer sowie zwei Proxy Product Ownern (PPO). Zwei Pizzas wären definitiv nicht genug, um uns satt zu bekommen.
Naheliegend war der erste Gedanke, das Team in zwei getrennte Teams aufzuteilen. Fast jedes Scrum Skalierungs-Framework (wie beispielsweise SAFe oder LeSS) wird Ihnen dazu raten. Aber keines dieser Ansätze hat in unserem Fall funktioniert. Wir konnten das Team nicht horizontal aufteilen (d. h. nach architektonischen Ebenen), da wir in jedem Sprint an einem ganz spezifischen Teil der Funktionalität arbeiten (in diesem Fall müssten beiden Teams ständig miteinander kommunizieren, damit die Anwendung am Sprint-Ende auch funktioniert). Diese zusätzliche Komplexität in der Kommunikation und Koordination – so glauben wir – würde den Prozess nur noch weiter aufblähen, anstatt ihn zu vereinfachen.
Ein anderer weit verbreitete Ansatz ist es, die Teams nach Feature (also vertikal) aufzuteilen, so dass jedes Team an einer bestimmten Gruppe von User Stories arbeitet. Viele Unternehmen verfahren nach diesem Muster (was technologisch auch teilweise widergespiegelt wird, indem die einzelnen Teile der Software als Microservices gebaut werden). Für unser Team hätte ein solcher Ansatz jedoch keinen Sinn ergeben, da die Teile der Anwendung, an denen wir arbeiten, so sehr miteinander verwoben sind, dass es unmöglich wäre, eine Linie zu ziehen, um sie sauber zu trennen.
Wie haben wir es also geschafft, ein hoch motiviertes und produktives Team aufzubauen, ohne es aufzuteilen? Nun, eigentlich haben wir beides gemacht – wir haben das Team sowohl horizontal als auch vertikal aufgeteilt. Wir haben es aber bewerkstelligt, ohne das Team aufzuteilen.
Lassen Sie mich erklären.
Zuallererst möchten wir als Team natürlich so funktionsübergreifend („cross-functional“) wie möglich arbeiten. Die Komplexität des Stacks, mit dem wir arbeiten, ermöglicht dies aber nicht immer. Daher gibt es bei uns zwei „imaginäre“ Sub-Teams innerhalb der Entwickler: Es gibt Backend- und Frontend-Spezialisten. Das vereinfacht allen das Leben, indem die Möglichkeiten eingegrenzt werden, wen es bei spezifischen technischen Herausforderungen zu fragen gilt – was die gemeinsame Lösungsfindung wiederum stark vereinfacht.
Wir haben zusätzlich auch etwas eingeführt, was wir als „Storypaten“ bezeichnen.
Wenn eine User Story auf unserem Sprint-Board als „in Progress“ wandert, nehmen sich ein Frontend- und ein Backend-Entwickler der Story als „Storypaten“ an. An diesem Punkt übernehmen sie die Verantwortung für alle technologischen und funktionalen Fragen im Rahmen der User Story - und sind darüber hinaus dafür verantwortlich, dass die Story im Sprint fertiggestellt wird.
Natürlich ist das gesamte Team nach wie vor dafür verantwortlich, dass das Sprintziel erreicht wird. Trotzdem konnten wir beobachten, dass wir den Einsatz sowie das Engagement für das Projekt durch die Verpflichtung, kleine Teile des Ganzen zu vollenden, erhöhen konnten. Es ist nicht länger möglich, in einer homogenen Masse von Entwicklern zu verschwinden, stattdessen muss sich jeder Einzelne gegenüber „seinen“ User Stories verpflichten.
Ein weiterer Nebeneffekt: Die Anzahl der Schnittstellen-Bugs (d. h. all die Dinge, die nur auftauchten, weil wir Datenformate, APIs etc. nicht von Anfang an diskutierten) konnte ebenfalls verringert werden.
Da das Produkt zunehmend komplexer wurde, beschloss das Team, die Rolle des „Architekten“ einzuführen. Diese Rolle ist etwas anders als die, an die Sie vielleicht denken würden, wenn Sie den Begriff „Software-Architekt“ hören. Unsere Architekten (es gibt zwei – jeweils einen für Front- und Backend) sind hauptsächlich dafür zuständig, auf Unstimmigkeiten und unmittelbar bevorstehenden technische Schuld zu achten, diese Themen zu identifizieren und die Proxy Product Owner darauf aufmerksam zu machen; diese wiederum können dann daraus User Stories erzeugen.
Das half uns dabei, die Vogelperspektive auf die Technologie hinter dem Produkt beizubehalten und darüber hinaus einen Prozess zu formalisieren, damit diese Dinge auch in den Sprint aufgenommen werden konnten.
Ein Problem bei der Skalierung wurde dadurch aber immer noch nicht gelöst: endlose Diskussionen – besonders in unseren Refinement Meetings.
Was wir tun, tun wir mit Leidenschaft. Manchmal führt das zu langen, detailversessenen Diskussionen. Und, obwohl wir diese Details schätzen, so mussten wir trotzdem einen Weg finden, aus unseren Meetings mit dem angestrebten Ergebnis rauszugehen.
Deshalb haben wir (größtenteils) Planning Poker in unseren Refinement Meetings aufgegeben. Ersetzt haben wir es durch etwas, was sich „Team Estimation Game“ nennt. Ich gehe hier nicht ins Detail (da dies den Post überproportional aufblähen würde), aber die Grundidee ist wie folgt: Team-Mitglieder stellen den PPOs abwechselnd Fragen zu einer User Story. Da man nur Fragen zu einer User Story stellen kann, fokussieren sich alle auf die wichtigen Fragen und überflüssige Einzelheiten werden aus der Diskussion herausgehalten.
Natürlich bedeutet der Begriff „Agile“ auch, dass sich alles ständig verändert, so dass die beschriebenen Feinjustierungen gegebenenfalls nur vorübergehend sind; eventuell müssen wir das Team doch aufteilen oder andere Lösungen für neue Herausforderungen finden. Aber für den Augenblick, denke ich, dass wir mithilfe des Scrum-Frameworks das Beste aus dem Team herausholen und dabei ein hervorragendes Produkt entwickeln, ohne dabei Prozesse unnötig aufzublähen. Im Moment funktioniert das erstaunlich gut für uns. Ich hoffe, dass Sie in diesem Beitrag vielleicht auch einige Anregungen für Ihr wachsendes Team finden.
Der einzige Nachteil ist: Wir müssen immer noch eine Menge Pizza bestellen.
