Ein agiles Produktentwicklungsprojekt aus dem Automotive-Umfeld mit 35 Teams Grundprinzipien der Skalierung im agilen Kontext

Grundprinzipien der Skalierung im agilen Kontext

Wenn einzelne Projekte zu groß werden und Teams erweitert werden müssen, steht man oft vor der Herausforderung einer Skalierung. Wie Sie Skalierungsvorhaben erfolgreich unter Beachtung einiger Lösungsprinzipien umsetzen, zeigt Ihnen Dominik Maximini. Damit schaffen Sie es, ohne Reibungsverluste und größere Probleme, Projekte und Teams zu skalieren.

Management Summary

Ein agiles Produktentwicklungsprojekt aus dem Automotive-Umfeld mit 35 Teams Grundprinzipien der Skalierung im agilen Kontext

Grundprinzipien der Skalierung im agilen Kontext

Wenn einzelne Projekte zu groß werden und Teams erweitert werden müssen, steht man oft vor der Herausforderung einer Skalierung. Wie Sie Skalierungsvorhaben erfolgreich unter Beachtung einiger Lösungsprinzipien umsetzen, zeigt Ihnen Dominik Maximini. Damit schaffen Sie es, ohne Reibungsverluste und größere Probleme, Projekte und Teams zu skalieren.

Management Summary

Immer mehr Organisationen realisieren, dass der anfallende Arbeitsaufwand im Projekt nicht von einem einzelnen Team bewältigt werden kann. Daher setzen sie Projekte und Programme auf, die von einer Vielzahl von Teams umgesetzt werden. Das gilt gleichermaßen für agile und klassische Vorhaben. In der agilen Welt spricht man hier von "Skalierung", also der Arbeit vieler Teams am selben Produkt. Zwar gibt es mehrere Skalierungsframeworks, die für sich in Anspruch nehmen, das Problem der Skalierung zu lösen. Jedoch helfen diese in der Praxis nur bedingt. Es gibt leider nur wenige große agile Projekte, die reibungslos funktionieren: Meist bleiben die Ergebnisse quantitativ und qualitativ weit hinter den Erwartungen zurück, weil die Projektbeteiligten sich in scheinbar endlosen Diskussionen mit sich selbst beschäftigen. Dieser Artikel stellt die Grundprinzipien der Skalierung im agilen Kontext aus einer undogmatischen Praxissicht vor. Diese Prinzipien helfen Ihnen, häufige Fehler bei der Skalierung zu vermeiden und bessere Ergebnisse zu erzielen. Als Beispiel verwenden wir hierbei ein Projekt aus dem Automotive-Bereich, in dem ein Steuergerät samt zugehöriger App mit 35 Teams entwickelt wurde. Im Verlauf des Projekts begannen wir mit drei Teams und skalierten dann sehr schnell auf 35, was zu diversen Problemen und Erkenntnissen führte. Wenn Sie in einem skalierten Umfeld arbeiten, oder vor haben zu skalieren, gibt dieser Artikel Ihnen wertvolle Hinweise, wie Sie Ihr eigenes Projekt-Setup optimieren können.

Komplexität durch Kommunikation und Abhängigkeiten

Manchmal möchte die Geschäftsführung ein Projektergebnis schneller erzielen, als es die aktuellen Vorhersagen erlauben. Dann werden häufig zusätzliche Teams aufgebaut. Wenn Sie aber eine Aufgabe mit vielen Menschen zu lösen versuchen, die zuvor durch wenige Menschen bearbeitet wurde, dann steigt die Anzahl der Kommunikationspfade exponentiell. Die Formel hierzu lautet n * (n - 1) / 2 und wurde von Frederick Brooks [1] publik gemacht (s. Bild 1). Fünf Personen haben also zehn Kommunikationspfade zueinander, während zehn Personen schon mit 45 Kanälen klarkommen müssen.

Exponentielle Zunahme der Kommunikationspfade
Bild 1: Exponentielle Zunahme der Kommunikationspfade

Genutzt werden diese Pfade mit allen Kommunikationsmitteln, die zur Verfügung stehen, also mit persönlichen Gesprächen, Emails, Telefonaten, etc. In den meisten größeren Projekten, die ich begleite, treffe ich eher 200 Menschen an, was schon 19.900 Kommunikationspfaden entspricht. Jeder Kommunikationspfad stellt eine (unterschiedlich starke) Abhängigkeit zu einer anderen Person dar, zum Beispiel weil Informationen weitergegeben werden müssen oder Arbeit gemeinsam erledigt werden soll. Je mehr Menschen involviert sind, desto schwieriger wird es also, die Abhängigkeiten zu minimieren. Zusätzliche Rollen und Meetings werden gegebenenfalls notwendig, z.B. wird das Gesamtvorhaben in Teilprojekte zerlegt und ein Programmmanagement eingeführt. Es gibt auch mehr Dokumentationsbedarf, um alle Beteiligten stets informiert zu halten. Zudem wollen mehr Personen mitentscheiden. Je komplexer das Projekt ist, desto schwieriger wird es, Entscheidungsbefugnisse vorab festzulegen, weil erst im Entscheidungsprozess klar wird, wer über das nötige Wissen verfügt, um bei der Entscheidung sinnvoll eingebunden zu werden. Sie werden also mehr Personen in mehr Meetings involvieren, idealerweise mit jeweils spezifischem Fokus. Das Festhalten am Fokusthema wiederum erfordert ein hohes Maß an Disziplin. Ihr Team, das zuvor klein war, ist noch die Prozesse aus dieser Zeit vor der Skalierung gewöhnt und muss die neuen Prozesse erst erlernen.

Dies bedeutet, dass schon durch die Skalierung an sich die Komplexität in Ihrem Projekt zunimmt. Die Zielerreichung wird nicht einfacher, nur weil jetzt mehr Teams daran arbeiten und auch die Produktivität pro Team sinkt zunächst kräftig, da mehr Menschen miteinander kommunizieren und neue Prozesse einüben müssen. In unserem Beispielprojekt arbeiteten zunächst knapp zehn Personen an der Hardwarekomponente und zehn Personen an der Produktsoftware. Hier wurde einfaches Scrum eingesetzt und Abstimmungen liefen sehr direkt und einfach ab. Nach der Skalierung auf 35 Teams arbeiteten mehr als 250 Personen miteinander. Es gab eine dreistufige Meeting- und Entscheidungskaskade (Team – Hardware-/Softwareebene – Gesamtprodukt) und es dauerte regelmäßig mehrere Tage oder Wochen, um zu Entscheidungen zu gelangen oder Informationen zu verteilen.

Lösungsprinzip 1: Minimieren Sie Abhängigkeiten

Das Grundproblem in jedem skalierten Kontext ist die Minimierung von Abhängigkeiten. Je mehr Abhängigkeiten es gibt, desto mehr muss organisiert, verwaltet und kommuniziert werden und desto länger dauern Abstimmungs- und Entscheidungsprozesse. Abhängigkeiten treten vor allem in den Dimensionen "Anforderungen", "technische Umsetzung" und "involvierte Personen" auf. Oft erlebe ich in der Praxis, dass die Definition der Anforderung in Team A von der Umsetzung einer anderen Anforderung in Team B abhängt. Beispielsweise hingen in unserem Automotive-Projekt häufig die Anforderungen an die Software von der genauen Ausgestaltung der Hardware ab. Aber auch innerhalb der Software-Applikation traten regelmäßig Abhängigkeiten der Anforderungen auf. So mussten beispielsweise manche Features umdefiniert werden, nachdem das Mandantenkonzept umgesetzt war.

Im Bereich der technischen Umsetzung fehlten oft wichtige Zulieferungen aus dem Nachbarteam für die eigene Implementierung. Schnittstellen wurden zu spät definiert, was Mehrarbeit verursachte. Auch die Wahl von grundlegenden Technologien und Architekturen war in hohem Grad von diversen Faktoren abhängig.

Manche dieser…

Download PDFDownload PDF

Bewertungen und Kommentare

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung.
2 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 2
Kommentare 2

Das könnte Sie auch interessieren

Alle Kommentare (2)

Rainer
Lingmann

Danke für den hervorragenden Artikel, den ich komplett unterschreiben kann. Nur eine Anmerkung zum Begriff der "Agilen Skalierung" selbst: Er ist verführerisch. Denn Strukturen größer zu machen, also sie zu skalieren, das haben alle Organisationen in ihrer Vergangenheit getan, die sich der Notwendigkeit der Agilen Skalierung gegenüber sehen. Die Kunst der Agilen Skalierung ist es aber gerade nicht, Strukturen größer zu machen - sondern erst mal Arbeit kleiner. Natürlich meint das nicht unbedingt den Gesamtumfang des Vorhabens, aber die Länge der einzelnen Projektschritte und die Größe der einzelnen Arbeitspakete. Das sagt auch im Wesentlichen das erste Lösungsprinzip des Artikels aus, denn fachliche Abhängigkeiten zu lösen oder jedenfalls zu lockern hilft schon stark dabei, dass Arbeitspakete auf einmal in Teile zerfallen, die verschiedene Teams weitgehend unabhängig bearbeiten können. Und je mehr Energie ich in dieses Ziel stecke, desto weniger muss ich überhaupt skalieren, sondern kann locker gekoppele Teams nebeneinander stellen, was viel einfacher ist, als übergreifende Strukturen welcher Art auch immer zu etablieren.

Hallo Rainer,

Danke für dein Feedback!
Du hast mit deinem Hinweis zur Verkleinerung der Arbeit Recht. Man könnte auch sagen "scale down before you scale up" oder "skaliere dein Team, bevor du deine Organisation skalierst". Da kommen wir aus meiner Sicht in den Bereich spezifischer Taktiken, deren Umsetzung in einem komplexen Umfeld von sehr vielen Faktoren abhängt. Vielleicht wird das Stoff für einen künftigen Artikel.

Beste Grüße

Dominik