42 WISSEN projektManagementaktuell | AUSGABE 4.2018 „Wir wollen agiler werden“ - das proklamieren derzeit viele Unternehmen. Frameworks für die agile Entwicklung wie Scrum haben längst gezeigt, dass sie zu einem deutlichen Effektivitätsanstieg führen können. Per definition sind diese jedoch für kleine Teams ausgelegt. Dies stellt für Unternehmen mit zunehmender Unternehmensgröße oft ein Hindernis dar. Aus dem Bedarf an agilen Vorgehensmodellen für große und komplexe Unternehmungen heraus sind in den vergangenen Jahren verschiedenste Skalierungsansätze wie SAFe, LeSS, Nexus u. a. entstanden. Für Anwender ist die Auswahl der Skalierungsmethode ein wichtiger Erfolgsfaktor. Dabei sollten die bekannten Frameworks eher als Inspiration, denn als Blaupause verstanden werden. 1 Herausforderung Immer mehr etablierte Organisationen versuchen durch agile Vorgehensweisen an Flexibilität und Innovationskraft zu gewinnen. Allerdings sind viele agile Methoden wie beispielsweise Scrum nur für den Einsatz in Teams mit drei bis neun Personen ausgelegt [1, S. 7]. Es ergibt sich somit die Fragestellung, wie agile Strukturen auch in größeren Kontexten etabliert werden können. Eine Aufgabenstellung, die nochmals herausfordernder ist als die Nutzung agiler Prinzipien auf Teamebene. Gilt es doch, eine deutlich größere Zahl von Abhängigkeiten und Personen zu koordinieren. Dies bedeutet zugleich eine deutliche Steigerung des Grades der Komplexität wie auch eine erschwerte Nutzbarkeit der sonst auf Teamebene genutzten Prinzipien wie etwa der direkten Kommunikation, der einfachen Visualisierung oder der schnellen Nutzung entwickelter Inkremente im Realbetrieb. Inzwischen existieren verschiedene Frameworks und Praktiken für die agile Skalierung. Trotz einiger Gemeinsamkeiten greifen diese den Skalierungsgedanken auf unterschiedliche Art und Weise auf. Im folgenden Artikel soll eine vergleichende Gegenüberstellung der fünf viel diskutierten Skalierungsansätze SAFe, LeSS, Nexus, Scrum@Scale und Scaling Agile @ Spotify erfolgen. Dazu werden die genannten Ansätze kurz dargestellt und ihre Anwendungsgebiete sowie Eigenschaften verglichen. Des Weiteren wird anhand einzelner Beispiele verdeutlicht, welche Impulse diese Frameworks auch im klassischen Projekt- und Projektportfoliomanagement geben können. 2 Skalierungsframeworks - SAFe, LeSS, Nexus und Scrum@Scale 2.1 SAFe Das Scaled Agile Framework (SAFe) ist ein von Dean Leffingwell im Jahr 2011 entwickeltes Rahmenwerk für die Realisierung von Agilität im Unternehmensumfeld. SAFe beruht auf drei Grundpfeilern: agile Entwicklung, Lean-Produktentwicklung sowie Systemdenken und beinhaltet eine Anleitung zur Skalierung der Entwicklungsarbeit auf allen Ebenen des Unternehmens. SAFe stellt ein „Big Picture“ zur Verfügung, welches eine detaillierte Darstellung über die verschiedenen Ebenen mit den dazugehörigen Rollen, Artefakten und Abhängigkeiten beinhaltet. SAFe kann mit zwei, drei oder vier organisatorischen Ebenen konfiguriert werden. Bei der dreistufigen Ansicht erfolgt eine Unterscheidung Potenziale für das Projektmanagement und das Projektportfoliomanagement Skalierung als Herausforderung - agile Skalierungsansätze und Frameworks nutzen Autoren: Ayelt Komus, Lea Bell >> Für eilige Leser Die derzeit meist diskutierten Skalierungsframeworks sind SAFe, LeSS, Nexus, Scrum@Scale und Scaling Agile @ Spotify. Neben einigen Gemeinsamkeiten verfügt jedes Framework über bestimmte Spezifika mit Stärken und Schwächen. Agile Methoden adressieren komplexe Aufgabenstellungen, bei denen es keine „Good Practices“ oder gar „Best Practices“ gibt. Daher sollten die bekannten Skalierungsansätze nicht einfach als Blaupause in die eigene Organisation übernommen werden. Gleichwohl liefern sie wertvolle Impulse. Viele Ideen und Konzepte aus dem agilen Umfeld können auch als Impulse für das klassische bzw. hybride Projekt-, Programm- und Projektportfoliomanagement dienen. Zu diesen Impulsen gehören neben vielen anderen das „Big Room Planning“, der „Heartbeat“ und das aktive Management der Architektur. WISSEN 43 projektManagementaktuell | AUSGABE 4.2018 zwischen der Teamebene, der Programmebene und der Portfolioebene. Zur Unterstützung von Organisationen mit in der Regel mehr als Tausenden von Praktikern stellt SAFe eine vierstufige Ansicht zur Implementierung zur Verfügung. Hierbei kommt die Large-solution-Ebene hinzu. Sie unterstützt insbesondere die Entwicklung von großen und komplexen Lösungen. SAFe ist sehr präskriptiv und detailliert beschrieben. Mit seinem Big Picture stellt es eine Art Starter-Kit dar und bietet eine gute Starthilfe für Organisationen mit wenig bis keiner Erfahrung im agilen Umfeld. Studien wie „Status Quo Agile“, aber auch „State of Agile“ weisen SAFe als die meistgenutzte agile Skalierungsmethode aus [2, S. 12; 3, S. 25]. Kennzeichnend für die SAFe-Methode ist ein sehr ausgefeiltes Konzept von Rollen, Prozessen und Artefakten, wie es auch unter www.scaledagileframework.com verfügbar ist. Abbildung 1 zeigt die Struktur von SAFe in der Variante „Full SAFe“ mit vier Ebenen. Abb. 1: Scaled Agile Framework mit vier Ebenen [4] Abb. 2: Large Scale Scrum [5]; Grafik: http: / / less.works, BY-ND 44 WISSEN projektManagementaktuell | AUSGABE 4.2018 2.2 LeSS LeSS („Large Scale Scrum“) ist Scrum, angewandt auf viele Teams, die gemeinsam an einem Produkt arbeiten. Das Ziel der beiden LeSS- Begründer Craig Larman und Bas Vodde war es nicht, Scrum zu verbessern, vielmehr geht es bei LeSS um die Anwendung der Prinzipien und Elemente von Scrum in einem skalierten Umfeld. Das Rahmenwerk LeSS, welches 2005 begründet wurde, setzt sich aus vier Elementen zusammen - Prinzipien, Regeln, Wegweiser und Experimente. Die Regeln von LeSS bilden das Fundament und definieren die Kernelemente des Frameworks zur Unterstützung der empirischen Prozesskontrolle und des ganzheitlichen Produktfokus. Wegweiser enthalten Empfehlungen für eine effektive Einführung von Regeln, die Durchführung von Experimenten und eine kontinuierliche Verbesserung. LeSS setzt auf die Denkweise „Probieren geht über Studieren“, sodass Experimente ein fundamentales Element des Frameworks darstellen. Praktiken sind situativ und abhängig vom spezifischen Kontext. LeSS warnt davor, dass sogenannte Best Practices die Kultur des Lernens sowie den kontinuierlichen Verbesserungsprozess töten. LeSS gibt umfangreiche Hinweise in Bezug auf die Rollen, Prozesse, Regeln und Prinzipien auf, lässt an einigen Stellen doch bewusst Freiräume für Experimente und situatives Lernen. Large- Scale Scrum beinhaltet zwei Frameworks. Das kleinere „LeSS-Framework“ ist für einen Product Owner, der die Verantwortung für das Produkt und die Verwaltung des Product Backlogs trägt, ausgelegt. Dabei arbeiten zwei bis acht crossfunktionale, komponentenübergreifende Teams in gemeinsamen Sprints zusammen. Ein Scrum Master betreut ein bis drei Teams. Neben diesem dargestellten Framework gibt es außerdem „LeSS Huge“ als Framework für größere und komplexere Organisationen mit mehr als acht Teams. Abbildung 2 zeigt die Strukturen des „LeSS-Framework“. 2.3 Nexus Nexus ist ein vom Scrum-Mitbegründer Ken Schwaber und Scrum.org veröffentlichtes Rahmenwerk für die Entwicklung und den Erhalt von skalierten Produkt- und Softwareentwicklungsinitiativen. Nexus ist konsistent zu Scrum, basiert auf seinen Rollen, Events und Artefakten und setzt sich aus einem Nexus Integration, Team sowie etwa drei bis neun Scrum-Teams zusammen. Das Nexus Integration-Team kommt als neue Rolle im Nexus Framework hinzu. Es ist ein Scrum-Team und setzt sich aus dem Product Owner, einem Scrum Master und einem oder mehrerer Nexus Integration-Teammitgliedern zusammen. Sämtliche Integrationsprobleme sowie das Aufzeigen von Abhängigkeiten und Tätigkeiten wie Coaching und Beratung fallen in die Zuständigkeit des Nexus Integration-Teams. Darüber hinaus verantwortet es im Rahmen des Nexus die erfolgreiche Integration der Arbeit aller Scrum-Teams. Das Nexus Integration-Team trägt die Ergebnisverantwortung, dass mindestens in jedem Sprint ein gemeinsam, fertiggestelltes Produkt, ein sogenanntes integriertes Inkrement, erstellt wird. Wie auch im Scrum- Framework beschrieben, verantwortet das Scrum-Team die Entwicklung potenziell releasefähiger Inkremente. Nexus baut unmittelbar auf Scrum auf und erweitert nur die Elemente, die in einem skalierten Umfeld in unveränderter Form nicht mehr funktionieren würden. Nexus ist an vielen Stellen sehr abstrakt beschrieben und lässt Organisationen genauso wie LeSS viele Freiräume. Eine weitergehende Beschreibung der Nexus-Methode findet sich im Nexus-Guide, welcher unter www.scrum.org/ verfügbar ist. Abbildung 3 zeigt Nexus im Überblick. 2.4 Scrum@Scale Scrum@Scale ist ein Skalierungs-Framework, welches von Jeff Sutherland und Alex Brown auf der „Agile 2014“ zum ersten Mal vorgestellt Abb. 3: Nexus TM Framework [6] 17x11 in WISSEN 45 projektManagementaktuell | AUSGABE 4.2018 wurde. Seit Februar 2018 steht ein offizieller Scrum@Scale Guide zur Verfügung. Scrum@ Scale ist ein Framework, innerhalb dessen Netzwerke von Scrum-Teams, die konsistent mit dem Scrum Guide arbeiten, komplexe adaptive Probleme adressieren und gleichzeitig Produkte mit dem höchstmöglichen Wert liefern. Das Framework dient der Skalierung von Scrum und enthält zwei Zyklen: den Scrum Master Cycle (das „Wie“) und den Product Owner Cycle (das „Was“) sowie Prinzipien bezüglich Metriken und Transparenz. Die Koordination der Scrum-Teams erfolgt über Scrum of Scrums (SoS). Dabei handelt es sich um ein Scaled-Daily-Scrum-Event mit einem Vertreter jedes Teams. Jedes Scrumof-Scrum-Team verfügt wiederum über einen Scrum of Scrums Master. Abhängig von der Größe der Organisation ist ein SoS unendlich skalierbar. Jedes Scrum of Scrum of Scrums (SoSoS) sollte wiederum einen Scrum of Scrum of Scrums Master (SoSoSM) haben. Das SoS für die gesamte Organisation wird als Executive Action Team (EAT) bezeichnet und verantwortet die Erstellung und Durchführung des Backlogs. Für jedes SoS gibt es ein Meta-Scrum, eine Gruppe von Product Ownern (PO), die ein gemeinsames, übergeordnetes Backlog mit allen Aktivitäten koordinieren müssen. Die Person, die für die Koordination des Gesamt-Product-Backlogs für alle Teams verantwortlich ist, wird zum Chief Product Owner ernannt. So wie SoS zu SoSoSs werden können, können Meta-Scrums auch durch denselben Mechanismus erweitert werden. Das Framework ist modular aufgebaut und besteht aus zehn Modulen. Die Modularität bietet Scrum@Scale eine große Vielseitigkeit und schreibt weder konkrete Einsatzgebiete noch eine maximale Größe der Entwicklungsorganisation vor. Scrum@Scale ist an vielen Stellen sehr abstrakt gehalten und setzt den Schwerpunkt auf die Koordination der Scrum-Teams. Eine weitergehende Beschreibung der Methode findet sich im Scrum@Scale Guide, welcher unter www.scrumatscale.com verfügbar ist. Abbildung 4 zeigt die Strukturen von Scrum@Scale. 2.5 Scaling Agile @ Spotify Scaling Agile @ Spotify, auch oft als Spotify- Modell bezeichnet, beschreibt die agile Arbeitsweise, die beim Musik-Streaming-Anbieter Spotify entwickelt wurde. Das Framework wurde nicht explizit „erfunden“ und stellt nach eigenen Angaben auch kein „finales“ Konzept dar, denn Spotify entwickelt sich fortlaufend weiter und sucht nach weiteren Verbesserungen im Prozess. Aufgrund des interessanten Ansatzes für die Skalierung agiler Teams, welchen Spotify verfolgt, wurde Scaling Agile @ Spotify erstmalig von Henrik Kniberg und Anders Ivarsson im Jahr 2012 beschrieben und findet seither weitreichende Beachtung. Spotify unterscheidet in seinem Framework zwischen Squads, Tribes und Chapters. Squads stellen die bekannten agilen Teams dar, wobei kein spezifisches Vorgehen vorgeschrieben wird. Koordiniert werden die Arbeiten durch einen Product Owner. Für die Einhaltung der Regeln sorgt wiederum der Agile Coach. Ein Squad verantwortet vollständig einen Teil des Produktes und implementiert selbstständig neue Features. Mehrere Squads, die im gleichen Kontext arbeiten, werden in „Tribes“ zusammengefasst, wobei eine maximale Anzahl von 100 Mitgliedern nicht überschritten wird. Die Sicherstellung eines optimalen Arbeitsumfeldes innerhalb eines Tribes verantwortet der Tribe Leader. Zum Informationsaustausch und zur übergreifenden Planung finden auf Tribe-Ebene regelmäßige Mee- Abb. 4: Scrum@Scale [7] 46 WISSEN projektManagementaktuell | AUSGABE 4.2018 SAFe Begründer Dean Leffingwell Hintergrund/ Idee Ausarbeitung einer sehr detaillierten, strukturgebenden Darstellung in Form eines Starter-Kits Adressierte Größe der Entwicklungsorganisation 100 bei zwei Ebenen, bis zu 10.000 Ausarbeitung des Konzepts im Detail • Sehr präskriptive und detaillierte Beschreibung der Rollen, Prozesse, Artefakte und Zeremonien Schwerpunkt/ Zielsetzung • Strukturgebende Anleitung, als eine Art Starter-Kit • Organisation und Synchronisation der Teams nach einem gemeinsamen „Heartbeat“ Spezifische Eigenschaften • Integration mehrerer Teams mit gleichen oder unterschiedlichen Sprintlängen • Integration von Scrum und Methoden aus der Lean- und Kanban-Welt • Konfigurierbar mit zwei, drei oder vier Ebenen entsprechend der Unternehmensgröße • Instanz auf jeder Ebene zum Managen der übergreifenden Architektur LeSS Begründer Craig Larman, Bas Vodde Hintergrund/ Idee Ansatz zur Skalierung von Scrum Adressierte Größe der Entwicklungsorganisation • LeSS: zwei bis acht Teams • LeSS Huge: mehr als acht Teams Ausarbeitung des Konzepts im Detail • Weitreichende Ausarbeitungen zu Rollen, Prozessen, Artefakten und Zeremonien basierend auf Scrum, dennoch mit Freiheitsgraden Schwerpunkt/ Zielsetzung • Minimalistische Essenz, die zur Skalierung von Scrum erforderlich ist • Durchführung von Experimenten Spezifische Eigenschaften • Keine zusätzlichen Rollen, Artefakte und Prozesse • Schlanke und überschaubare Vorgehensweise • Einfacher Ansatz für Scrum-erfahrene Agilisten Abb. 5: Scaling Agile @ Spotify Framework [8] WISSEN 47 projektManagementaktuell | AUSGABE 4.2018 tings statt. Zum Austausch über grundlegende Themen und zur Weiterentwicklung prozessneutraler fachlicher Fähigkeit treffen sich Personen mit ähnlichen Fähigkeiten aus gleichen Tribes in sogenannten Chaptern. Über die Grenzen von einzelnen Tribes hinaus bildet sich eine sogenannte Guild, um Wissen bezüglich der Werkzeuge und Herangehensweisen weiterzuentwickeln und zu synchronisieren. Das Framework definiert die Aufbauorganisation, lässt aber viele prozessuale Aspekte offen und eröffnet somit viele Freiheiten. Der agile Wert „Transparenz“ spielt eine bedeutende Rolle. Unterstützung leistet dabei unter anderem der regelmäßig ermittelte „Happyness-Index“. Strickt vermieden wird die Nutzung etablierter Begrifflichkeiten. Auch grundlegende Konzepte werden durch die Spotify-eigene Terminologie ersetzt. Entscheidungen finden primär auf Squad-Ebene statt. Den Fokus legt Scaling Agile @ Spotify stark auf die Koordination und den teamübergreifenden Informations- und Wissenstransfer. Eine weitergehende Beschreibung der Methode steht auf https: / / blog.crisp.se/ wpcontent/ uploads/ 2012/ 11/ SpotifyScaling.pdf zur Verfügung. Abbildung 5 zeigt die Grundstruktur des Spotify-Frameworks. Nexus Begründer Scrum-Begründer Ken Schwaber Hintergrund/ Idee Ansatz zur Skalierung von Scrum Adressierte Größe der Entwicklungsorganisation • Nexus: drei bis neun Teams • Nexus +: mehr als 10 Teams (Weiterentwicklung von Nexus, aktuell aber noch in der Ausarbeitung) Ausarbeitung des Konzeptes im Detail • Konsequent minimalistischer Ansatz • Erweiterung der Elemente, die in skalierter Umgebung nicht mehr funktionieren würden Schwerpunkt/ Zielsetzung • Minimalistische Essenz, die zur Skalierung von Scrum erforderlich ist • Koordination und Synchronisation der Teams Spezifische Eigenschaften • Sehr abstrakt mit wenig Beschreibungen • Keine zusätzlichen Strukturen Scrum@Scale Begründer Scrum-Begründer Jeff Sutherland, Alex Brown Hintergrund/ Idee Ansatz zur Skalierung von Scrum Adressierte Größe der Entwicklungsorganisation Unbegrenzter Gesamtumfang Ausarbeitung des Konzepts im Detail • Detaillierte Ausarbeitung in Bezug auf die Koordination der Teams • Ansonsten sehr viele Freiheitsgrade, wenig Vorgaben Schwerpunkt/ Zielsetzung • Koordination und Synchronisation der Teams • Modularer Aufbau Spezifische Eigenschaften • Hohe Flexibilität bei der Einführung aufgrund der modularen Struktur • Koordination der Teams Scaling Agile @ Spotify Begründer Henrik Kniberg und Anders Ivarsson Hintergrund/ Idee Entwicklung eines eigenen Frameworks für das Unternehmen Spotify Adressierte Größe der Entwicklungsorganisation Unbegrenzter Gesamtumfang Ausarbeitung des Konzepts im Detail Definierte Aufbauorganisation Viele prozessuale Aspekte werden offengelassen Schwerpunkt • Kulturelle Aspekte • Koordination und teamübergreifender Informationsaustausch und Wissenstransfer Spezifische Eigenschaften • Hohe Transparenz • Spotify-eigene Terminologie Tab. 1: Vergleichende Gegenüberstellung der Skalierungsansätze 48 WISSEN projektManagementaktuell | AUSGABE 4.2018 3 Vergleichende Gegenüberstellung der Skalierungsansätze Betrachtet man das Scaled Agile Framework, Large Scale Scrum, Nexus, Scrum@Scale und Scaling Agile @ Spotify im direkten Vergleich, fällt auf, dass es neben den Gemeinsamkeiten bestimmte Spezifika gibt. Auch nicht jedes Skalierungsframework ist für jeden Bedarf gleich gut geeignet. Tabelle 1 stellt die aufgeführten Skalierungs-Frameworks vergleichend gegenüber. 4 Ideen und Ansätze für die Weiterentwicklung von Projektmanagement und Projektportfoliomanagement Eine Skalierung agiler Methoden ist angezeigt, wenn die adressierten Aufgabenstellungen als komplex, nicht als kompliziert einzuordnen sind. Im Komplexen gibt es keine sinnvollen „Good Practices“ oder gar „Best Practices“ im Sinne des Cynefin-Konzeptes. Entsprechend sollte nach Einschätzung der Verfasser auch keiner der vorgestellten Skalierungsansätze eins zu eins in die eigene Organisation übernommen werden. Vielmehr ist es sinnvoll, sich an Aspekten der Frameworks zu orientieren und diese an die eigene Organisation anzupassen. Experimente und situatives Lernen müssen in Organisationen die Basis zur Entwicklung eines eigenen Ansatzes zur Unterstützung eines sinnvollen, agilen Vorgehens der Zusammenarbeit in größeren Aufgabenstellungen sein. Folgend soll an drei ausgewählten Beispielen kurz gezeigt werden, welcher Reichtum an Ideen und Konzepten in den skalierten agilen Rahmenwerken zu finden ist und wie diese Impulse auch im klassischen Projekt-, Programm- und Projektportfoliomanagement aufgenommen werden können. Die drei Beispiele sind das „Big Room Planning“, der „Heartbeat“ und das aktive Management der Architektur. Beim „Big Room Planning“, wie es etwa u. a. im SAFe vorkommt, kommen Teams, die an zusammenhängenden Inkrementen arbeiten, zusammen, um im räumlichen und zeitlichen engen Kontext gemeinsam Review, Retrospektive und Planning durchzuführen. Viele Organisationen haben inzwischen verstanden, wie wichtig es ist, bei Review, Retrospektiven und Planning in agiler Weise das Team einzubinden und mithilfe von die Architekturorientierung. Skalierungsansätze wie SAFe sehen spezifische Rollen für das aktive Architekturmanagement vor. Bei SAFe bildet diese Instanz der Enterprise Architect auf Portfolioebene ab bzw. der Solution Architect auf Programmebene. Eine ähnliche Instanz findet man auch bei Nexus in Form des Nexus Integration-Teams. Diese Rollen bieten eine technische Führung für die sich entwickelnden architektonischen Fähigkeiten der gesamten Lösung. Gefordert wird eine enge Zusammenarbeit mit Stakeholdern, Teams, Kunden und Lieferanten bei der Definition der Technologieinfrastruktur, der Zerlegung in Komponenten und Subsysteme und der Definition von Schnittstellen. Die systematische Berücksichtigung der Architekturaspekte - unabhängig davon, ob es sich um IT- Entwicklungsaktivitäten oder andere Themen handelt - ist ein wichtiger Impuls, der in keinem Portfoliobzw. Programmmanagement fehlen sollte. Die Implikationen reichen dabei über die aktive inhaltsgetriebene Priorisierung und Budgetierung bis hin zur Überführung weiterer Teile des Projektportfolios in ein Programmportfolio. Dieser Themenblock adressiert in der Praxis weitreichende Herausforderungen des gelebten Portfoliomanagements, sei es eine zu formale Vorgehensweise der Priorisierung bis hin zum nicht sinnvollen Management von Aktivitäten in Projekten, wo eigentlich Produktentwicklungsaktivitäten angezeigt sind. 5 Fazit und Ausblick Mit weiterhin sehr komplexen und volatilen Umfeldbedingungen bleibt das Thema der guten agilen Zusammenarbeit weiterhin ein Schlüsselthema des erfolgreichen (Projekt-)Managements. Nachdem agile Methoden wie Scrum auf Teamebene zunehmend besser verstanden werden, gewinnt nun in vielen Organisationen das Thema der agilen Skalierung an Bedeutung. Verschiedene Skalierungsframeworks zeigen mögliche Gestaltungsansätze auf. Eine pauschale Aussage, welches das beste Skalierungs- Framework ist, lässt sich nicht treffen. Vielmehr sollte der spezifische Unternehmenskontext als entscheidend erkannt werden und der individuellen Ausgestaltung und Weiterentwicklung hohe Bedeutung eingeräumt werden. Die fünf vorgestellten Frameworks greifen den Skalierungsgedanken auf unterschiedliche Art auf. LeSS und Nexus weisen eine hohe Ähnlichkeit im Aufbau sowie in der Vorgehensweise auf. Visualisierung, Planning Poker u. Ä. gemeinsam Dinge zu entwickeln. Ein Big Room Planning schafft außerdem Zusammenhalt, ein gemeinsames Verständnis und fördert die Netzwerkbildung, um bei der notwendigen Abstimmung schnell und flexibel, die richtigen Ansprechpartner zu kennen und unkompliziert ansprechen zu können. Nicht nur innerhalb des eignen Teams kann ein Austausch erfolgen, sondern auch ein teamübergreifender Wissenstransfer wird ermöglicht. Neben der taktischen Planung empfehlen sich auch taktische Reviews und Retrospektiven sowohl auf Teamebene als auch auf höheren Ebenen mit den jeweiligen Vertretern der Teams. Absurderweise gibt es inzwischen viele Organisationen, die die Vorteile eines gemeinsamen erlebten Prozesses auf Teamebene nutzen, auf den höher skalierten Ebenen aber nach wie vor auf Einzelpersonen oder formale Abstimmungsprozesse ohne erhöhte Teaminteraktion setzen, wenn es bspw. um die Programmplanung oder das Portfoliomanagement geht. Diese Organisationen verzichten damit auf die Chance, die Potenziale agiler Interaktion zu nutzen, gerade wenn es über die Ebene einzelner Teams hinausgeht; und dies, obwohl die Komplexität der zu koordinierenden Aktivitäten mit zunehmender Größe deutlich steigt. Ein weiteres Beispiel für die Weiterentwicklung des Projektmanagements oder Projektportfoliomanagements ist der sogenannte „Heartbeat“. Der Heartbeat adressiert eines der häufigsten Probleme der traditionellen agilen Entwicklung: Teams, die an derselben Lösung arbeiten, arbeiten unabhängig und asynchron. Das macht es schwierig, das Gesamtprodukt routinemäßig zu integrieren. Synchronisation stellt sicher, dass der Fokus stets auf der Entwicklung und objektiven Bewertung des Gesamtprodukts liegt und nicht auf seinen einzelnen Elementen. Erforderlich sind feste Synchronisations-Meetings, die es ermöglichen, Anforderungen in definierten Zyklen fertigzustellen. Sprints werden auf verschiedenen Ebenen angesiedelt, die in einem gemeinsamen Heartbeat münden, der den Rhythmus aller Teams vorgibt. Neben einem Product Owner für das Anforderungsmanagement auf Teamebene empfiehlt sich ein gemeinsamer Product Owner, der die Anforderungen aller Teams koordiniert und den Heartbeat verantwortet. Ein dritter Aspekt, der interessante Impulse für das Projektportfoliomanagement beinhaltet, ist WISSEN 49 projektManagementaktuell | AUSGABE 4.2018 Beide Ansätze nehmen nur minimalistische Erweiterungen zu Scrum vor, die in unveränderter Form im skalierten Umfeld nicht mehr funktionieren würden. Auch bei Scrum@Scale steckt die Idee in der Skalierung von Scrum. Alle drei Ansätze verfügen über einen Guide, der eine deskriptive, detaillierte Beschreibung liefert, wie man Scrum skalierte. Dennoch lassen alle drei Ansätze in vielen Aspekten Freiheitsgrade bei der Interpretation und Umsetzung. Scrum@ Scale ist ein sehr abstrakter Ansatz und setzt den Schwerpunkt auf die teamübergreifende Synchronisation und Koordination der Teams. Dennoch lassen sich aufgrund der Durchführung von Experimenten Analogien zu LeSS erkennen. Einen deutlichen Kontrast zu LeSS, Nexus und Scrum@Scale stellen SAFe und Scaling Agile @ Spotify dar. Das von Dean Leffingwell entwickelte Framework SAFe unterscheidet sich in seinem Aufbau und Vorgehen deutlich von den drei genannten Skalierungsmethoden. Auch Scaling Agile @ Spotify verwendet in seinem Framework eine Spotify-eigene Terminologie. Zum gegenwärtigen Zeitpunkt kann über die zukünftige Entwicklung und gelebte Umsetzung der thematisierten Skalierungsansätze nur spekuliert werden. Nach der Einschätzung der Autoren werden SAFe und LeSS weiterhin dominierende Rollen einnehmen. Beide Ansätze weisen eine etablierte Anhängerschaft und detaillierte Beschreibungen auf. Zudem kommt die hohe Verbreitung dieser Ansätze dem Erfahrungsaustausch innerhalb einer agilen Community zugute. Des Weiteren ist zu beobachten, dass immer mehr Organisationen ihr eigenes agiles Framework, oftmals in Anlehnung an einen der genannten Ansätze, entwickeln. Das wohl bekannteste Beispiel ist hier „Scaling Agile @ Spotify“ oder einfach das „Spotify-Modell“. Infolge einer individuellen Entwicklung können die spezifischen Herausforderungen einer Organisation optimal adressiert werden. Da es sich bei der Skalierung agiler Methoden um eine komplexe Aufgabe handelt, ist es nur folgerichtig, dass eine Lösungsfindung individuell auf Basis einer gezielten Lernkurve stattfindet, da Best oder Good Practices allgemein im Komplexen nicht funktionieren. Es steht zu erwarten, dass Organisationen sich an Skalierungsansätzen und -praktiken orientieren und darauf basierend ein eigenes agiles Framework entwickeln. Impulse aus dem agilen Umfeld wie das „Big Room Planning“, der „Heartbeat“ und das aktive Management der Architektur sind Beispiele dafür, wie wertvoll Ansätze aus den agilen Skalierungsansätzen auch im klassischen oder hybriden Multiprojektmanagement sein können.  Literatur [1] Schwaber, K./ Sutherland, J.: Der Scrum Guide. Der gültige Leitfaden für Scrum: Die Spielregeln. 2016, www.scrum.org [2] VersionOne Inc.: The 12 th State of Agile Report. 2018, www.versionone.com [3] Komus, A./ Kuberg, M.: Status Quo Agile: Studie zu Verbreitung und Nutzen agiler Methoden. 2017, www.gpm-ipma.de [4] Leffingwell, D./ Scaled Agile Inc.: SAFe 4.0 Indroduction. Overview of the Scaled Agile Framework for Lean Software and Systems Engineering. 2016, www.scaledagileframe work.com [5] Vodde, B./ Larman, C./ Yin, T./ Atlas, A./ Quah, B./ Dittlau, F.: LeSS. More with LeSS. 2017, less.works/ de, BY-ND [6] Schwaber, K.: Nexus Guide. Der gültige Leitfaden für Nexus: Das Exoskelett für eine skalierte Entwicklung mit Scrum. 2015, www.scrum.org [7] Sutherland, J./ Scrum. Inc.: The Scrum@ Scale Guide: The Definitive Guide to Scrum@ Scale: Scaling that Works. 2018, www. scrumatscale.com [8] Kniberg, H./ Ivarsson, A.: Scaling Agile @ Spotify with tribes squads chapters and guilds. 2012, labs.spotify.com Schlagwörter agile Methoden, Lean, Multiprojektmanagement, Programmmanagement, Projektportfoliomanagement, Skalierung Kompetenzelemente der ICB 4.0 3.04 Ablauf und Termine, 3.10 Planung und Steuerung Autoren Prof. Dr. Ayelt Komus ist Keynote Speaker, Management-Coach und Professor für Organisation und Wirtschaftsinformatik an der Hochschule Koblenz. Er beschäftigt sich mit den Implikationen der digitalen Transformation sowie der hybriden und skalierten Nutzung agiler Methoden im Projekt- und Portfoliomanagement. Sein besonderer Schwerpunkt liegt in der Nutzung agiler Methodenelemente in klassisch geprägten Strukturen und Branchen sowie den Implikationen für PMOs, Einkauf und andere Unterstützungsbereiche. Weitere aktuelle Informationen und Studienberichte unter: www.process-and-project.net, www.komus.de Lea Bell hat den Master- Studiengang Business Management an der Hochschule Koblenz im Jahr 2017 abgeschlossen. Ihre Masterthesis schrieb sie zum Thema „Skalierung agiler Methoden“. Zurzeit ist sie als Beraterin im Geschäftsprozessmanagement in einer großen deutschen Versicherung tätig. Anschrift der Autoren: Prof. Dr. Ayelt Komus, Hochschule Koblenz, Konrad-Zuse-Straße 1, 56075 Koblenz, Tel.: 0172/ 6 86 86 97, E-Mail: Komus@hs-koblenz.de Der Benchmark für Ressourcenplanung Projektportfolio-Management Ressourcenplanung Zeit-/ Aufwanderfassung Kostenmanagement Projektplanung Die Testumgebung in der Cloud steht für Sie bereit Scheuring AG CH-4313 Möhlin � +41 61 853 01 54 www.scheuring.ch � info@scheuring.ch www.ressolution.ch Anzeige