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.

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.