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

Geschrieben von

Moritz Müller Moritz Müller Für Moritz Müller ist Agile das erste Konzept, in dem das Lernen aus Fehlern nicht nur eine leere Worthülse ist, sondern tatsächlich eminenter Bestandteil. Er ist der Ansicht, dass eigentlich alle Menschen nach diesem Ansatz arbeiten sollten – gemeinsam im Team unter Berücksichtigung der individuellen Fähigkeiten, eigenverantwortlich und selbstorganisiert. Seinen Schwerpunkt als Consultant sieht er daher auch im Empowerment der Mitarbeitenden und Kunden. Moritz hat Freude daran, Menschen zu befähigen, sich weiterzuentwickeln. Sein besonderes Interesse gilt dabei der öffentlichen Verwaltung, in der er großes Potenzial für die Einführung von agilen Methoden sieht. Der Veränderung begegnet er selbst zunächst zurückhaltend, weil er sich gerne erst einen Überblick verschafft. Durch diese reflektierte Herangehensweise gelingt es ihm, sich und seine Umgebung auf das vorzubereiten, was kommt.

Team member profile

TEILE DIESEN BEITRAG

Schreibe einen Kommentar

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