Wie skaliert eigentlich Lego?

Lesezeit 5 min
Wie skaliert eigentlich Lego?

Photo by Ryan Quintal on Unsplash

Warum agile Skalierung meist verkehrt gedacht wird

Agile Skalierung ist das Thema der Stunde. Denn, wenn agile Rahmenwerke wie Scrum nur für einzelne Teams gemacht sind, so jedenfalls die verbreitete Meinung, was mache ich dann, wenn ich ein Produkt erstellen möchte, für dessen Erstellung ich sinnvollerweise mehr als neun Personen benötige? Brauche ich dann nicht mehr als Scrum? Brauche ich nicht übergreifende Rollen und Strukturen, die in Scrum nicht vorgesehen sind: einen Chief Product Owner, einen Verantwortlichen für die Gesamtarchitektur oder einen teamübergreifenden Test-Manager? Die Antwort ist jein.

Zunächst ist zu klären, ob Scrum wirklich nur für ein Team gemacht ist? Der Scrum Guide sagt dazu: „Der Kern von Scrum ist ein kleines Team von Menschen. Dieses Team ist sehr flexibel und anpassungsfähig.“ Hier hören die Meisten anscheinend auf zu lesen. Doch es geht weiter: „Diese Stärken wirken weiter zwischen mehreren und vielen Teams und sogar Netzwerken von Teams, die die Arbeit und Ergebnisse von Tausenden von Menschen entwickeln, ausliefern, betreiben und erhalten.“ Scrum ist also für die Arbeit von Tausenden Menschen gedacht! Nun kann man mit Recht kritisieren, dass der Scrum Guide keine weiteren Hinweise darauf liefert, auf welche Weise die Stärken eines einzelnen Teams in Netzwerken von Teams wirken sollen. Er liefert dazu keine Operationalisierung. 

Aber der Scrum Guide beschreibt sehr klar den Grundgedanken aller agilen Ansätze: Man fängt beim einzelnen Team an und versucht den Charakter der Arbeit von kleinen Teams und kleinen Vorhaben auch in größere Teams und Produktentwicklungen zu tragen. Agilität denkt bottom-up. In vielen Ansätzen für agile Skalierungen äußert sich aber die genau entgegengesetzte Denkweise. Wenn ich *ein* Produkt habe, muss ich dann nicht auch jeweils *eine* Person haben, die für die Gesamt-Architektur, für die Test-Strategie oder die UX zuständig ist? Muss ich dann nicht einen Lenkungsausschuss haben und einen Gesamt-Projektleiter? Als offene Frage bleibt in diesem Ansatz nur, wie diese Personen und Gremien mit den jeweiligen Fachverantwortlichen in den Teams zusammenwirken. Das selbstverständliche Installieren von gesamtverantwortlichen Rollen ist aber kein Naturgesetz, sondern eine bewusste Entscheidung. Es ist Ausdruck einer Philosophie, einer Denke, nämlich der Top-Down-Denke – und kollidiert darum oft mit agilen Vorgehensweisen oder verhindert sie sogar.

Wie Agilität skaliert, ist aber gut vergleichbar mit der Frage, wie eigentlich Lego skaliert? Wenn man den Scrum Guide paraphrasiert, könnte man sagen: „Der Kern von Lego ist ein kleiner Baustein aus Plastik. Dieser Baustein ist sehr flexibel und anpassungsfähig. Seine Stärken wirken weiter zwischen mehreren und vielen Bausteinen und sogar Netzwerken von Bausteinen.“ Denn genau so funktioniert Lego ja tatsächlich. Auch das Schloss Neuschwanstein im Legoland oder mannshohe Riesenräder aus Lego Technic bestehen nicht aus größeren Bausteinen als die Ritterburg, die sich ein Fünfjähriger im Kinderzimmer baut. Sie bestehen nicht aus großen, tragenden Strukturen, in die irgendwo die kleinen Legosteine eingehängt werden. Sondern sie entstehen, indem Legostein auf Legostein auf Legostein gesetzt wird. Und wenn man das länger und mit mehr Wissen um Architektur tut als der Fünfjährige im Kinderzimmer, kann man mit denselben Steinen wie er auch einen 1,50 m hohen Big Ben oder ein Fußballstadion bauen. Nur die Speichen des Lego-Technic-Riesenrads sind möglicherweise Sonderanfertigungen, weil sie sich anders durchbiegen würden.

Genau so kann man auch agile Skalierungen angehen: Man baut die Strukturen seines Vorhabens bottom-up auf, geht von der kleinsten Einheit aus, dem Team von nicht mehr als ca. neun Personen, fügt weitere Teams hinzu. Und nur die zusätzlichen Strukturen, die Speichen des Riesenrads, ohne die man wirklich überhaupt nicht auskommt, kommen als „Extra“ hinzu. Vielleicht genügt es ja, wenn drei Teams, die an einem Produkt arbeiten, einen Scrum of Scrums abhalten und regelmäßig die Abhängigkeiten ihrer Backlog-Items visualisieren? Oder vielleicht genügt es, wenn erfahrene IT-Entwickler aus den Teams eine Community of Practice bilden und so sicherstellen, dass die von ihnen entwickelten Module zusammenpassen?

Aber warum macht das nicht jede Firma so? Es klingt ja sogar leichter, nur die wirklich notwendigen teamübergreifenden Strukturen neu einzuführen und nicht ein komplettes Skalierungsframework wie SAFe oder LeSS oder Scrum@Scale. Die Herausforderung ist, dass eine für diesen Ansatz notwendige Kompetenz in vielen Unternehmen nicht weit verbreitet und auch tatsächlich nicht trivial ist: das Zerlegen von Arbeit in kleinere Module oder Arbeitspakete, die untereinander nur die inhaltlich zwingenden Abhängigkeiten aufweisen und so von Teams parallel bearbeitet werden können. Diese Kompetenz zu erlernen kann also der Schlüssel dazu sein, auch große Vorhaben mit agilen Methoden umsetzen zu können, ohne einen unnötig großen Überbau errichten zu müssen.

Dabei ist dieses Vorgehen keineswegs neu, auch nicht dort, wo große architektonische Entwürfe die Regel sind. Das Empire State Building war bei seiner Eröffnung das höchste Gebäude der Welt, eine gigantische Struktur. Weil es aber in sehr kurzer Zeit errichtet werden musste, wurde es extrem modular gebaut. Nach der Erstellung eines Grob-Entwurfs, der in 17 ca. einwöchigen Iterationen finalisiert worden war, wurden die Detailpläne für die Etagen nach und nach erstellt. Also erstellten die Ingenieure die detaillierten Pläne für die 48. bis 50. Etage erst, während die 45. bis 47. Etage gerade gebaut wurden. So gelang es von 1929 bis 1931 ein Gebäude in nur 18 Monaten Bauzeit zu errichten, wie es die Welt noch nicht gesehen hatte: Etage für Etage für Etage, zusammen mit einer lediglich so groben Planung des Gesamtgebäudes, wie man sie in einer Woche erstellen und überarbeiten kann

Bei dieser Erfolgsgeschichte darf man nicht unterschätzen, dass sie hohe Anforderungen an die Arbeitsweise der Beteiligten stellt. Insbesondere konnten existierende Stahlwerke die benötigten Träger nicht mit dem kurzen Vorlauf herstellen, den die Bauweise mit sich brachte. Deshalb wurde für den Bau des Empire State Buildings ein eigenes, geeignetes Stahlwerk gebaut. Aber die Aussicht, so die Bauzeit radikal zu verkürzen, machte selbst diese Investition sinnvoll.

Auch agile Skalierungen, die bottom-up durchgeführt werden, können also viel Arbeit machen und neue, hohe Anforderungen an die Arbeitsweise aller Beteiligten stellen. Aber es ist wichtig, dass die Arbeit dort geleistet wird, wo sie am effektivsten den Mehrwert vergrößert, den agile Arbeitsweisen versprechen, nämlich höhere Flexibilität und die Möglichkeit, an komplexen Produkten unter veränderlichen Umständen zu arbeiten. Und diese Stelle ist die möglichst autonome Arbeitsfähigkeit von kleinen, flexiblen und anpassungsfähigen Teams von Menschen – dem Kern von Scrum.

Wenn Sie Beratung bei der Einführung und Umsetzung von Agilität in Ihren Projekten wünschen bzw. in der Aufbauorganisation von agilen Strukturen, sprechen Sie uns an. Wir beraten Sie auf Augenhöhe individuell passend zu Ihren unternehmerischen Anforderungen – vor dem Hintergrund unserer zahlreichen Erfahrungen aus verschieden komplexen Projekten.

Sie möchten mehr zu diesem Thema erfahren?

Dann nehmen Sie mit uns Kontakt auf und senden Sie eine E-Mail an info@digitaspixelpark.com.