Wie Microservices und die Two-Pizza-Rule das Entwicklungsteam optimal unterstützen

Im agilen Coaching wird der Fokus häufig auf die Rollen des Product Owners und des ScrumMasters gelegt und weniger auf die Rolle des Entwicklungsteams. Dabei ist auch diese Rolle klar definiert: Das Team hat die Aufgabe zu liefern. Ich habe die Erfahrung gemacht, dass es bei der Beratung von Entwicklungsteams zwei Ansätze gibt, die die Rolle eines Mitglieds des Entwicklungsteams optimal unterstützen. Das sind zum einen Microservices und zum anderen die Two-Pizza Rule.

Microservices

Microservices beruhen im Wesentlichen auf der UNIX-Philosophie „Do one thing and do it well“. Das heißt, dass Microservices immer genau eine Funktion, einen Zweck abbilden. Das kann der Produktkatalog eines Online-Portals sein, die Geschwindigkeitsmessung einer Verkehrskamera oder der Bilder-Upload bei einem Service wie Facebook. Ein Microservice soll so klein wie möglich, aber so groß wie nötig sein, damit ein Team in der Lage ist, den vollen Funktionsumfang abzudecken und die Funktionalität unter Kontrolle zu halten. Sobald ein Team dies nicht mehr gewährleisten kann, muss ein zweites Team gebildet werden, das weitere Funktionen herstellt (Gloger 2017: 48).Zugegeben, die Verwendung einer Microservices-Architektur erhöht die Komplexität des Gesamtsystems, da unterschiedliche Programmiersprachen und Entwicklungswerkzeuge verwendet werden können. Demgegenüber steht aber, dass Teams unabhängig voneinander arbeiten können und sich keine ungewollten Abhängigkeiten einschleichen, da aufgrund architektonischer Vorgaben Schnittstellen nur über API eingerichtet werden können. Dies führt wiederum dazu, dass der Koordinations- bzw. Steuerungsaufwand kleiner wird und gleichzeitig die einzelnen Teams schneller liefern können. Dem Entwicklungsteam hilft das insofern, als dass es sich voll und ganz auf eine Funktionalität und damit auf die Lieferung fokussieren kann. Schließlich ist das die Hauptaufgabe des Entwicklungsteams.

Two-Pizza-Rule

Wie groß soll so ein Team also idealerweise sein, damit diese Voraussetzungen gewährleistet sind? Bei dieser Frage verhält es sich vermutlich wie bei vielen anderen Fragen auch: Frage zwei Leute und du bekommst drei Meinungen. Allerdings gibt es eine Teamgröße, die sich in der Praxis als ideal erwiesen hat: die Two-Pizza-Rule. Dieser Begriff wurde von Jeff Bezos, CEO von Amazon, geprägt, der gesagt hat: „Laden Sie nie mehr Teilnehmer zu einem Meeting ein, als von zwei Pizzen satt werden.“ Zwar hat er diesen Hinweis zunächst für die ideale Größe eines Arbeitsmeetings gegeben, doch lässt sich das auch auf Teams übertragen. Folgt man dem Hinweis von Jeff Bezos und nimmt eine Pizza von 40 cm Durchmesser, so ergibt sich eine Anzahl von fünf bis acht Teammitgliedern oder Teilnehmern.Dabei war es nicht das Ziel von Jeff Bezos die Kosten zu senken, sondern den Fokus auf zwei Dinge zu richten: Effizienz und Skalierbarkeit. Das hat folgenden Grund: Kleinere Teams müssen nicht so viel Zeit darauf verwenden, sich gegenseitig auf den neuesten Stand zu bringen, da der Kommunikationsaufwand geringer ist. Die gesparte Zeit können sie für Dinge verwenden, die wichtig sind. Außerdem steigt die Wahrscheinlichkeit von Konflikten, je größer eine Gruppe wird, und es wird wahrscheinlicher, dass Gruppenmitglieder keine Verantwortung übernehmen, weil sie sich leichter „verstecken“ können.Eine Gefahr bei zu großen Teams heißt HiPPO. Dies steht für „Highest Paid Person‘s Opinion“ und beschreibt die Tendenz, dass niedrigrangigere Mitarbeiter dem HiPPO nachgeben – damit lässt sich Innovation fantastisch verhindern. In einem „Pizza-Team“ hat keiner das Sagen, sondern es entscheidet immer die Gruppe. Um es noch einmal deutlich zu machen: Die Effizienz eines Teams sinkt mit seiner Größe.Das lässt sich auch mit der folgenden Gleichung deutlich machen:

Diese Gleichung sagt nichts anderes aus, als dass ein Team mit 7 Mitgliedern 21 Verbindungen managen muss. Bei 12 Mitgliedern sind es schon 66 Verbindungen. Wenn das Team 60 Mitglieder hat, müssen 1770 Verbindungen berücksichtigt werden. Bei einem Unternehmen mit 6000 Vollzeitkräften sind es 17997000 Verbindungen.Eingangs habe ich die Frage aufgeworfen, wie das Entwicklungsteam optimal unterstützt werden kann. Nun, das Team soll liefern. Und das am besten schnell. Die anderen Akteure sollen den Rahmen dafür schaffen. Zwei dieser Rahmenbedingungen sind die klare Abgrenzung dessen, was das Team liefern soll und die Größe des Teams. Wir haben gesehen, dass das Team am besten liefern kann, wenn es sich genau um eine Funktionalität kümmert und dabei aus fünf bis acht Personen besteht. Diese beiden Rahmenbedingungen sind also notwendig, damit Scrum funktioniert und das Team schnell liefern kann.Foto: Pixabay License, igorovsyannykov

Agile Toolbox
Scrum
Rollen
Team
Moritz Müller
July 17, 2019

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

ScrumMaster vs. Product Owner? Oder beides?
BG

ScrumMaster vs. Product Owner? Oder beides?

Die Wiederkehr der 80er – Nostalgie als politische Strategie?
BG

Die Wiederkehr der 80er – Nostalgie als politische Strategie?

Remote-First vs. Präsenztrainings – was ist besser?
BG

Remote-First vs. Präsenztrainings – was ist besser?

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst
BG

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst

Wer die Zukunft voraussagen will, muss sie gestalten
BG

Wer die Zukunft voraussagen will, muss sie gestalten

Die etwas andere agile Bücherliste.
BG

Die etwas andere agile Bücherliste.

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!
BG

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!

Scrum organisiert am Produkt entlang
BG

Scrum organisiert am Produkt entlang

Trainings verändern - oder sie sind wertlos!
BG

Trainings verändern - oder sie sind wertlos!

Zertifizierung – Das ist hier die Frage
BG

Zertifizierung – Das ist hier die Frage

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind
BG

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind

Organisationsentwicklung am Produkt entlang
BG

Organisationsentwicklung am Produkt entlang