Die wichtigste Frage zur agilen Skalierung
Wir hören aus fast jedem Großunternehmen, mit dem wir zusammenarbeiten: „Wir brauchen ein agiles Skalierungs-Framework.“ Wenn 50 oder mehr Entwickler zusammenarbeiten müssen, ist der Einsatz eines Skalierungsframeworks tatsächlich vorteilhaft. Doch eine Frage bleibt unbeantwortet. Eine unausgesprochene, unangefochtene Annahme schwebt wie ein Schreckgespenst über jedem Skalierungs-Ansatz. Bevor wir jedoch diese Frage stellen, beleuchten wir die Gründe, warum diese Frage beantwortet werden muss.
Ein komplexes Produkt entwickeln
Komplexe Systeme sind – schon allein aufgrund ihrer Definition – komplex. Eine übliche Annahme ist, dass Divide+Conquer (D+C) ein guter Ansatz ist, um komplexe Probleme zu lösen: Wir zerteilen ein großes Problem in viele kleine, verteilen diese und fügen die Lösungen wieder zusammen. Das klingt auch vielversprechend.
Ein Skalierungsframework kann man dann einsetzen, um die Effektivität des D+C zu maximieren.
Beginnen wir mit den Randfragen, um uns der Kernfrage zu nähern:
Wie definiert man das Problem?
Wenn man mit der Entwicklung eines großen Produkts beginnt, hat man zuerst mal einen Bedarf – und man möchte ein Produkt bauen, was den Bedarf stillt. Die Natur der Produktentwicklung ist, dass die bedarfsgerechte Lösung noch nicht existiert.
Ist das Problem überhaupt richtig beschrieben? Ist schon hinreichend klar, wo die Aufwände reinfließen? Ist die Domäne der Herausforderung schon so klar, dass man D+C sinnvoll anwenden kann?
Was ist wirklich das Problem?
Wenn man eine Produktentwicklung organisiert, nimmt man einfach an, dass der Bedarf klar umrissen ist und der Rest „einfach Arbeit“ ist.
Doch: Was passiert, wenn sogar die Frage, aufgrund der geplant wurde, schon falsch war? Was passiert, wenn der Plan fehlschlägt und man die falsche Antwort verfolgt? Hilft es, wenn mehr Leute an den falschen Dingen arbeiten?
Wo ist das Problem wirklich?
Die Grundannahme agiler Skalierung: „Das Hauptproblem ist mehr Arbeit, als wenig Leute tun können.“ Wie auch in einem anderen Artikel beschrieben, ist das Hauptproblem mit viel Arbeit, dass viel Arbeit viel Arbeit verursacht! Dabei geht es um nichtwertschöpfende Arbeit wie Koordination, Task-Switching, Meetings und Ähnliches.
Haben Sie schon darüber nachgedacht, wie groß der Anteil wertschöpfender Arbeit am Produkt gegenüber dem Anteil nichtwertschöpfender Bedienung von Prozessen in Ihrer Organisation ist? Wie viel Zeit benötigen Ihre Entwickler wegen der Komplexität Ihrer Strukturen für Koordination? Liegt Ihr Schwerpunkt auf der Bereitstellung von Produkten oder der Befolgung von Prozessen? Was passiert mit dem Overhead, wenn Sie Ihre Prozesse erweitern? Was passiert mit wertschöpfender Entwicklungszeit?
Ist das Problem wirklich so groß?
Bei der agilen Skalierung nehmen Sie einfach an, dass Sie viele Leute brauchen, um das Produkt zu bauen, was Sie planen. Die nächste Frage ist dann, wie man diese Leute optimal organisiert.
Wussten Sie, dass Google in den ersten Jahren von zwei Leuten entwickelt wurde? Und Facebook von einem?
Ist Ihr Produkt wirklich so groß, dass es Google und Facebook in den Schatten stellt? Werden Sie wirklich Billionen damit verdienen? Ist Ihr Verständnis und Ansatz tatsächlich optimal?
Hilft viel wirklich viel?
Das Buch „The mythical man-month“, vor gut 40 Jahren von Frederick P- Brooks geschrieben, hat die Idee „Je mehr Leute an einem Produkt arbeiten, desto schneller wird es fertig“ längst wiederlegt. Doch bis heute glauben viele Unternehmen, dass „Agile Skalierung“ die Lösung des „Mythischen Mann-Monats“ sei. Wie vorher erwähnt, wurden großartige Produkte von wenigen Leuten entwickelt – und mehr Leute schaffen zwar mehr Arbeit, aber keinen höheren Mehrwert!
Könnte man nicht mit weniger Entwicklern mit weniger Arbeit eine bessere Lösung finden? Wäre es wirklich langsamer, wenn weniger Leute beteiligt wären?
Und so kommen wir nach so vielen Fragen zur kritischen Kernfrage:
Ist „agile Skalierung“ wirklich nötig?
Denken Sie über folgende Punkte nach:
Haben die Entwickler das 100% beste Wissen, um eine Lösung bereitzustellen?
Steht ihnen die 100% bestmögliche Technologie zur Verfügung, um Probleme zu lösen?
Fokussieren sich die Entwickler zu 100% darauf, den maximalen Mehrwert zu liefern?
Ist jede Tätigkeit 100% wertschöpfend?
Ist die getane Arbeit 100% effektiv?
Kommen mehr Leute hinzu, gehen diese Prozentsätze tendenziell nicht hoch. Sie sinken.
Rechnet man diese Prozentsätze zusammen, ist das Ergebnis oft erschreckend. Vielleicht hat man 10 Leute, die nur 20% ihres Potentials nutzen können – so dass 3 Leute, die 80% ihres Potentials entfalten können, schneller voran kämen!
Wenn 100 Entwickler auf 5% ihres Potentials beschränkt sind, wäre vielleicht ein einzelnes Team effektiver als sie alle!
Haben Sie schon alle Möglichkeiten ausgekostet, um mit weniger mehr zu erreichen?
Nur dann, wenn diese Fragen bereits alle mit „Ja“ beantwortet sind – dann ist die Antwort der Kernfrage auch „Ja“. Vorher werden Sie ihre Probleme – und nicht ihre Problemlösung – skalieren!