Scrum Skalierung: Herausforderungen & Lösungen

Der Scrum Guide [SS11] empfiehlt eine Teamgröße von 6 ± 3 Entwicklern für optimale Ergebnisse. Ken Schwaber und Jeff Sutherland argumentieren, dass diese Größe die direkte Kommunikation und den problemlosen Austausch innerhalb des Teams gewährleistet, da alle Mitglieder im selben Raum arbeiten können. Diese Empfehlung wird durch die Forschungsergebnisse von Doug Putnam [Put11] zur Team-Produktivität in Abhängigkeit von der Größe und die Miller-Regel [Mil56] gestützt. Putnam's Studie und die detailliertere Erläuterung der Miller-Regel in Kapitel 8.3 belegen die Effizienzsteigerung in Teams dieser Größenordnung. Eine optimale Kommunikation ist ein entscheidender Faktor für den Erfolg von Scrum, insbesondere bei der Bewältigung von Herausforderungen und der Entscheidungsfindung. Die direkte, persönliche Interaktion ermöglicht es, Probleme effizient zu lösen und ein gemeinsames Verständnis zu entwickeln. Abweichungen von dieser Idealgröße erfordern spezielle Maßnahmen zur Kompensation, um die Kommunikation aufrechtzuerhalten und die Produktivität zu sichern. Die Arbeit untersucht die Implikationen, die eine Abweichung von dieser optimalen Teamgröße hat, und analysiert die damit verbundenen Herausforderungen beim Skalieren von Scrum.

Die Verwendung unterschiedlicher Sprintziele in mehreren Teams führt zu Abhängigkeiten zwischen den Aufgaben verschiedener Teams. Die Auswahl von Product Backlog Items wird komplexer, da Aufgaben auf andere Teams verweisen können, deren Sprintziele andere Prioritäten setzen. Dies verlangsamt den Fortschritt und erfordert eine sorgfältige Synchronisierung, Abstimmung oder Aufteilung der Sprints und ihrer Ziele, um Abhängigkeiten zu minimieren und einen reibungslosen Workflow zu gewährleisten. Die Koordination mehrerer Teams und die gemeinsame Planung von Sprints sind essentiell für eine effiziente Arbeit und die Einhaltung der Zeitpläne. Die Arbeit untersucht Strategien, um diese Abhängigkeiten zu managen und eine effektive Zusammenarbeit zwischen den Teams zu ermöglichen. Der Fokus liegt dabei auf der Optimierung des Prozesses und der Vermeidung von Verzögerungen, die durch die Abhängigkeiten entstehen können. Eine gemeinsame Vision und ein gemeinsames Sprintziel sind wichtige Faktoren, um die Zusammenarbeit zu vereinfachen und die Produktivität zu steigern.

Das Entwicklungsteam ist für die Umsetzung der Product Backlog Items verantwortlich. Gemäß der Miller-Regel [Mil56], die auch im Scrum Guide [SS11] reflektiert wird, sollte ein Entwicklungsteam nicht mehr als neun Entwickler umfassen, um die Effizienz zu maximieren. Doug Putnams Studie [Put11] unterstützt diese Aussage und zeigt, dass Teams mit 3-9 (7 ± 2) Mitgliedern am produktivsten sind. Ein größeres Entwicklungsteam würde die Kommunikation und den Informationsaustausch erschweren, was zu Ineffizienzen und Fehlern führen könnte. Die Arbeit analysiert die Konsequenzen größerer Teams und untersucht die Auswirkungen auf die Selbstorganisation und die Entscheidungsfindung im Team. Die Eignung verschiedener Skalierungsstrategien für die Entwicklungsteamgröße wird geprüft und bewertet, um die optimale Teamstruktur für große Scrum-Projekte zu definieren. Das Ziel ist, den positiven Einfluss der Miller-Regel auf die Teameffektivität zu erhalten, auch bei skalierten Scrum Projekten.

Die Skalierung von Scrum-Artefakten wie dem Product Backlog stellt im Kontext großer Projekte besondere Herausforderungen dar. Ein einzelner Product Backlog, der für alle Teams gültig ist, erfordert eine präzise Priorisierung und die vollständige Ausarbeitung vieler hochpriorer Product Backlog Items, bevor ein Sprint beginnt. Die strikte Timebox eines Sprints erhöht das Risiko, dass weniger wichtige Items vorgezogen werden müssen, falls hochpriore Items den Zeitrahmen sprengen. Bei einer hohen Anzahl von Teams steigt dieser Koordinationsaufwand erheblich, und die Product Owner müssen deutlich mehr Items ausformulieren. Die Arbeit identifiziert dieses Problem und skizziert Lösungsansätze. Die mangelnde Transparenz und die Koordination der Arbeiten in einem größeren Product Backlog stellt eine große Herausforderung dar. Die Arbeit exploriert die Problematik der Skalierung des Product Backlogs und identifiziert potenzielle Lösungen, um die Effizienz und die Transparenz im Projekt auch bei einer hohen Anzahl von Teams aufrechtzuerhalten. Insbesondere die Herausforderungen beim Priorisieren und der Ausarbeitung von Product Backlog Items in einem großen, skalierten Scrum-Projekt werden detailliert untersucht.

Die Skalierung von Scrum-Rollen, insbesondere die des Product Owners, ist eine weitere Herausforderung. Während in kleinen Scrum-Teams ein einzelner Product Owner für den gesamten Product Backlog verantwortlich ist, wird diese Aufgabe in großen Projekten zu komplex. Die Arbeit beschreibt das Konzept eines kaskadierten Product Owners oder eines "Super Product Owners", der mehrere Product Owner koordiniert. Diese Hierarchie ermöglicht eine klare Verantwortlichkeit, aber auch der Verlust an Transparenz und die mögliche Kommunikationsprobleme zwischen den einzelnen Ebenen werden angesprochen. Die Skalierung der Product Owner Rolle birgt Herausforderungen hinsichtlich der Kommunikation, der Verantwortlichkeit und der Entscheidungsfindung in größeren Scrum-Projekten. Die Arbeit analysiert diese Herausforderungen und untersucht verschiedene Ansätze, um die Effizienz und die Transparenz im Management des Product Backlogs aufrechtzuerhalten. Das "Teile und Herrsche" Prinzip, welches in der Informatik etabliert ist, wird diskutiert, um große Probleme in kleinere, überschaubare Aufgaben zu zerlegen und damit besser zu managen.

Die Skalierung von Scrum-Meetings, insbesondere des Sprint Planning und Sprint Review, erfordert ebenfalls besondere Maßnahmen. In großen Projekten, die mehrere Teams umfassen, müssen die Meetings entsprechend angepasst werden. Ein gemeinsames Sprintziel kann die Koordination vereinfachen, aber unterschiedliche Ziele führen zu Abhängigkeiten zwischen den Teams. Die Arbeit diskutiert Lösungsansätze wie die Synchronisation von Sprints und Sprint Review Messen. Bei der Sprint Review Messe präsentieren alle Teams ihre Ergebnisse in einem gemeinsamen Meeting, um Feedback von allen Stakeholdern zu erhalten. Salesforce.com wird als Beispiel für die erfolgreiche Implementierung von Release-Kickoffs und Release-Open-Spaces genannt. Zusätzlich wird eine gestaffelte Definition of Done (DoD) als Möglichkeit zur Sicherung der Produktqualität bei mehreren Teams vorgeschlagen. Die Arbeit untersucht die Effizienz verschiedener Methoden, um die Meetings anzupassen und die Kommunikation zwischen den Teams und den Stakeholdern zu optimieren. Die Herausforderung besteht darin, die Transparenz und die Effizienz der Scrum-Meetings auch bei einer größeren Anzahl von Teams und Stakeholdern zu gewährleisten.

Die effektive Kommunikation stellt eine zentrale Herausforderung bei der Skalierung von Scrum dar, insbesondere in großen und verteilten Teams. Der Text betont die Bedeutung der Kommunikation und verweist auf eine Studie des Systems and Software Consortium (SSCI) [ND05], die die Kommunikation als eines der Top-Probleme bei der verteilten Softwareentwicklung identifiziert. Jutta Eckstein [Eck09] unterstreicht diese Problematik ebenfalls. Das "Virtual Distance Model" von Lojeski und Reilly wird als Hilfsmittel vorgestellt, um die verschiedenen Dimensionen der Distanz zwischen Teammitgliedern zu verstehen und zu managen. Diese Dimensionen umfassen die räumliche Distanz, die zeitliche Distanz (unterschiedliche Zeitzonen) und die soziale und kognitive Distanz. Länger anhaltende Probleme ("Readiness Distance") können dazu führen, dass Teammitglieder sich vom Projekt distanzieren. Ein dedizierter Scrum Master spielt eine wichtige Rolle bei der Bewältigung von Kommunikationsproblemen und der Sicherstellung eines reibungslosen Informationsflusses. Die unterschiedliche Erwartungshaltung an die Kommunikationsgeschwindigkeit (z.B. Antwortzeiten von E-Mails) muss ebenfalls berücksichtigt werden. Die Arbeit analysiert die verschiedenen Aspekte der Kommunikation in verteilten Teams und bietet Strategien zur Verbesserung des Informationsaustauschs und der Zusammenarbeit.

Die Softwarearchitektur spielt eine entscheidende Rolle bei der Skalierung von Scrum. Das Ziel einer guten Softwarearchitektur ist die Minimierung der Gesamtkosten und die Berücksichtigung der Interessen aller Stakeholder über den gesamten Produktlebenszyklus [Fri10]. Architekturentscheidungen definieren den Handlungsspielraum für Entwickler und unterliegen technischen und organisatorischen Randbedingungen (einschließlich des Budgets). Die Strukturierung der Softwarearchitektur ist besonders in großen Projekten wichtig, da sie die Komplexität reduziert und die Übersichtlichkeit für Entwickler verbessert. Dies erleichtert das Verständnis der Zusammenhänge zwischen einzelnen Komponenten und ermöglicht effizientere Änderungen. Die Konsistenz der Architektur und die Einhaltung von Konventionen sind essenziell für die Zusammenarbeit mehrerer Teams. Die Arbeit argumentiert für die Bedeutung einer durchdachten Softwarearchitektur in großen, agilen Projekten und diskutiert, wie diese im Kontext von Scrum umgesetzt werden kann. Die Autoren betonen den Zusammenhang zwischen technischer Exzellenz und Agilität, wobei ein Architekt für Projekte mit langfristigem Horizont, hoher Komplexität und vielen Risikofaktoren empfohlen wird [SS12, Appendix 3].

Die Unternehmenskultur ist ein wichtiger Faktor für den Erfolg der Scrum-Skalierung. Eine Umfrage aus dem Jahr 2010 [Spa10] zeigt, dass eine Kultur der Zusammenarbeit als ideal für agile Unternehmen angesehen wird. Jedoch fehlen Unternehmen, die diese Kultur leben, manchmal Aspekte wie eine klare Vision, die Verbundenheit mit Zielen und den Mut, Dinge sich entwickeln zu lassen [Max12]. Im Gegensatz dazu wird eine "command and control" -Kultur als ungeeignet für agile Teams betrachtet [Amb09b]. Die Arbeit diskutiert verschiedene Unternehmenskulturen, darunter "Cultivation" [Sch99], die auf Hingabe, Werten und Kreativität basiert, und die "Kontrollkultur", die sich durch Hierarchien und Einzelleistungen auszeichnet. Eine Anpassung der Unternehmenskultur ist oft notwendig, um eine erfolgreiche Scrum-Implementierung zu gewährleisten. Der Text betont, dass eine Kulturveränderung, wenn nötig, auf der bestehenden Kultur aufbauen sollte [Dru92]. Die Arbeit vergleicht die verschiedenen Kulturtypen und deren Einfluss auf die Effizienz von agilen Teams. Insbesondere wird die "Contingency Theory" [Don96] erwähnt, die die Anpassung der Unternehmensstruktur an den Grad der Unvorhersehbarkeit betont.

Neben der Unternehmenskultur beeinflussen auch das Projekt- und Prozessmanagement sowie die Unternehmensstruktur die Skalierung von Scrum. In großen Projekten ist oft ein hohes Maß an Bürokratie vorhanden, was sich z.B. in der Zeiterfassung und der Zuordnung von Arbeiten zu verschiedenen Kostenstellen niederschlägt. Die hohe Komplexität führt häufig zu einer hohen Spezialisierung der einzelnen Bereiche, was die Bildung funktionsübergreifender Teams erschwert. Der Aufwand für die Verwaltung von Change Requests, Bugs und Hotfixes steigt ebenfalls deutlich. Die Arbeit betont, dass die Wahl der Unternehmensstruktur einen Kompromiss zwischen Effizienz und Flexibilität darstellt [Don96]. Eine zentrale Steuerung ist wünschenswert, aber gleichzeitig soll die Entscheidungsfähigkeit vor Ort erhalten bleiben. Die Arbeit zeigt auf, dass der Aufbau einer geeigneten Infrastruktur und die Wahl der richtigen Tools für alle Teams essenziell ist, um eine einheitliche und effiziente Arbeitsweise zu ermöglichen. Ein Beispiel hierfür ist die Bereitstellung von Servern und Backup-Strategien durch die IT-Abteilung. Die Herausforderungen eines heterogenen IT-Umfeldes und die erhöhte Einarbeitungszeit bei Mitarbeiterwechseln werden ebenso diskutiert. Die erfolgreiche Implementierung und Skalierung von Scrum erfordert daher eine durchdachte Organisation und eine effektive Prozessgestaltung.

Für Produkte mit langen Entwicklungszeiten und vielen Anforderungen, die nicht sofort vollständig spezifiziert werden können, wird die Verwendung eines zusätzlichen Epic Backlogs vorgeschlagen. Dieser Backlog enthält langfristige Ideen, Wünsche und Anforderungen (Epics), die zu einem späteren Zeitpunkt detailliert ausgearbeitet werden. Dies ermöglicht eine flexible Planung und vermeidet den hohen Aufwand, alle Anforderungen bereits zu Projektbeginn vollständig zu spezifizieren. Die Arbeit argumentiert, dass es für Anforderungen, die erst in einem Jahr bearbeitet werden, keinen Sinn macht, bereits zu Projektbeginn alle User Stories und Abnahmekriterien vollständig auszuarbeiten. Die Verwendung eines Epic Backlogs ermöglicht eine schrittweise Detaillierung und passt sich an die sich entwickelnden Anforderungen an. Die Arbeit beschreibt den Vorteil dieser flexiblen Vorgehensweise bei der Bewältigung großer und komplexer Projekte. Dies ermöglicht eine effizientere Ressourcennutzung und eine Anpassung an sich ändernde Anforderungen während des Projektverlaufs.

Die Arbeit beschreibt "Merge Sprints" als eine Möglichkeit, die Produktinkremente verschiedener Teams zusammenzuführen. Anstatt einer kontinuierlichen, iterativen Integration erfolgen die Integrationen erst gegen Ende des Projekts in dedizierten Sprints. Dies bietet den Vorteil, dass sich jedes Team zunächst auf seine eigenen Features und Komponenten konzentrieren kann, ohne sich ständig mit anderen Teams abstimmen zu müssen. Die Geschwindigkeit der Entwicklung ist bis zum Beginn der Merge Sprints höher als bei anderen Integrationsmethoden. Die vollständige Integration muss jedoch nicht Teil der Definition of Done sein, um ein Product Backlog Item als "erledigt" zu markieren. Die Arbeit bewertet die Vor- und Nachteile dieser Methode und diskutiert die Auswirkungen auf die Entwicklungsprozesse und die Definition of Done für jedes einzelne Team. Die Wahl zwischen kontinuierlicher und zeitversetzter Integration hängt von den spezifischen Anforderungen des Projektes ab.

Als Beispiel für die Skalierung von Scrum wird der Ansatz von Salesforce.com mit Release-Kickoffs und Release-Open-Spaces vorgestellt. Die Entwicklungsteams erstellen zunächst einen groben Plan für die nächsten drei bis vier Monate. Im Release-Kickoff präsentieren die Product Owner diesen Plan den anderen Teams. Im anschließenden Release-Open-Space diskutieren die Teams wichtige Themen und Abhängigkeiten und bilden temporäre Gruppen zur Bearbeitung dieser Punkte. Diese Methode fördert die Kommunikation und den Informationsaustausch zwischen den Teams und ermöglicht die frühzeitige Identifizierung und Lösung von Problemen. Die Arbeit beschreibt, wie die Methodik der Release-Kickoffs und Release-Open-Spaces die Transparenz und die Abstimmung zwischen verschiedenen Teams und Stakeholdern verbessert. Salesforce.com dient als Beispiel für ein Unternehmen, welches diese Methode erfolgreich in der Praxis einsetzt. Die Arbeit bewertet die Eignung des Ansatzes für verschiedene Projektgrößen und Komplexitäten.

Um eine einheitliche und hohe Produktqualität sicherzustellen, wird eine gestaffelte Definition of Done (DoD) vorgeschlagen. Diese sieht für verschiedene Release-Stufen (z.B. internes Release, Release in die Produktion) eigene DoD-Kriterien vor. Dies ermöglicht eine schrittweise Verbesserung der Qualität und berücksichtigt die unterschiedlichen Anforderungen an die einzelnen Release-Stufen. Die Arbeit beschreibt, wie eine gestaffelte DoD zu einer höheren Produktqualität führt, da die Anforderungen an die einzelnen Release-Stufen präziser definiert werden können. Eine höhere Qualität kann durch eine klar definierte und abgestimmte Definition of Done über alle Teams hinweg erreicht werden. Die Arbeit beschreibt die Vorteile und den Aufwand einer gestaffelten Definition of Done und analysiert, wie diese die Produktqualität und die Zusammenarbeit zwischen den Teams verbessert.

Für die Bewältigung großer Product Backlogs wird das Konzept der kaskadierten Product Owner vorgestellt. Ein Super Product Owner (oder Chief Product Owner) trägt die finale Verantwortung, wird aber von weiteren Product Ownern unterstützt, um die Anforderungen und Wünsche aller Stakeholder zu erfassen und zu priorisieren. Diese Hierarchie vereinfacht die Organisation, leidet aber unter dem möglichen Verlust an Transparenz, da Product Owner auf niedrigeren Ebenen nicht immer vollständigen Einblick in die Backlogs anderer Bereiche haben. Die Arbeit diskutiert die Vor- und Nachteile dieses Ansatzes, der auf dem Prinzip "Teile und Herrsche" basiert. Die Arbeit bewertet die Eignung dieser Methode, um die Komplexität großer Product Backlogs zu bewältigen, und analysiert die Auswirkungen auf die Transparenz und die Kommunikation im Projekt.

Die Arbeit beschreibt verschiedene Strategien zur Teamaufteilung: horizontale Aufteilung in Layer- oder Komponententeams (jedes Team ist für eine bestimmte Schicht der Anwendung verantwortlich), vertikale Aufteilung in Featureteams (jedes Team arbeitet an einem kompletten Feature), und gemischte Ansätze, die Komponententeams und Featureteams kombinieren. Die Arbeit bewertet die Vorteile und Nachteile der verschiedenen Ansätze. Horizontale Teams bieten klare Verantwortlichkeiten und ermöglichen Spezialisierung, vertikale Teams fördern ganzheitliches Denken und reduzieren Abhängigkeiten. Gemischte Ansätze können die Vorteile beider Modelle kombinieren und sind besonders nützlich, wenn bestimmte Komponenten von mehreren Teams benötigt werden. Die Arbeit betont, dass die optimale Teamaufteilung vom Projektkontext abhängt und keine allgemeingültige Lösung existiert. Die Entscheidung für einen bestimmten Ansatz muss auf die spezifischen Anforderungen des Projekts abgestimmt sein.

Die Arbeit stellt verschiedene Ansätze für den Einsatz von Integrationsteams vor. Feste Integrationsteams, die sich über die gesamte Projektlaufzeit um die Integration kümmern, werden für Projekte mit mehr als 12 Teams empfohlen [Coh10]. Alternativ können virtuelle Integrationsteams eingesetzt werden, die aus Teilzeitmitgliedern bestehen, die zusätzlich zu ihren Aufgaben in den Entwicklungsteams arbeiten. Eine Mischform aus beiden Ansätzen ist ebenfalls möglich, wobei das Integrationsteam zu Beginn des Projekts eine wichtige Rolle bei der Einrichtung der Infrastruktur und Tools spielt und später in ein virtuelles Team umgewandelt wird. Die Arbeit untersucht verschiedene Modelle für Integrationsteams und analysiert den Aufwand und die Effizienz der verschiedenen Ansätze. Die Wahl des richtigen Modells hängt von der Projektgröße und der Komplexität ab.

Die Arbeit beschreibt das "lange Scrum of Scrums" mit einer 15-minütigen Timebox für die Beantwortung von Fragen und einem zweiten Teil zur Besprechung der identifizierten Probleme. Das Weglassen von Namen in der ersten Phase soll die Redezeit verkürzen [Cohn]. Als alternative Methode für das Sprint Review wird die "Sprint Review Messe" vorgeschlagen, bei der alle Teams und Stakeholder an Messeständen ihre Ergebnisse präsentieren und Feedback erhalten. Diese Methode ermöglicht einen effizienten Informationsaustausch und die Einholung von Feedback von vielen Stakeholdern gleichzeitig. Die Arbeit analysiert den Vorteil dieser Methode, um die Effizienz und die Transparenz von Scrum-Meetings in größeren Projekten zu verbessern. Die Arbeit bewertet die Eignung dieser Ansätze für die verschiedenen Projektgrößen und Komplexitäten.

Adobe Systems Inc. entwickelte Adobe Premiere ursprünglich mit traditionellen Wasserfall-Methoden. Nach der Einstellung der Mac-Entwicklung im Jahr 1998 (mit dem Release von Final Cut Pro für Mac OS X) entschied sich das Team 2005, den Mac OS X Markt zurückzuerobern. Die Entwicklung von Adobe Premiere CS3 erfolgte erneut mit einem Wasserfall-ähnlichen Ansatz, was zu einer qualitativ schlechten Software führte. 25% der zweijährigen Entwicklungszeit wurden für die Fehlerbehebung aufgewendet [Gre12], was zu Überstunden, schlechten Kundenbewertungen und Burnout bei Mitarbeitern führte. Die Einführung von Scrum erfolgte als Reaktion auf diese Probleme. Die Herausforderungen umfassten die Kommunikation mit verteilten Teams (teilweise Homeoffice, unterschiedliche Standorte, Videokonferenzen mit Ungleichgewichten im Kommunikationsmittel), die Umstellung von horizontaler zu vertikaler Zerlegung von Product Backlog Items (um den ganzheitlichen Scrum Ansatz umzusetzen), und die Zusammenarbeit mit nicht-agilen Teams innerhalb der Adobe Creative Suite. Die Integration der Komponenten nicht-agiler Teams erfolgte erst in den letzten zwei Sprints der Entwicklung.

Bei Primavera führte ein problematischer Release 3.5 im Jahr 2002 (drei Wochen Verzögerung, unvollständig, keine Bonuszahlungen, schlechte Team-Moral) zum Umstieg auf Scrum. Der Vice President of Development, Bob Schatz, erkannte die Ineffizienz des bisherigen Wasserfall-Modells mit detaillierten Anforderungsdokumenten und der Zuweisung von Aufgaben per "Command-and-Control". Nach der Einführung von Scrum durch Ken Schwaber wurde Release 4.0 erfolgreich entwickelt. Das Whitepaper [OM04] von Primavera und Object Mentor Inc. beschreibt die Erfolgsfaktoren, darunter die Synchronisierung der Sprints und die Durchführung einer "Sprint Review Messe", bei der jedes Team seine Ergebnisse an einem eigenen Messestand in einem großen Raum präsentiert. Die Stakeholder haben jeweils 15 Minuten Zeit, um jedes Team zu besuchen und Feedback zu geben. Bei zehn Teams dauert dieses Sprint Review Meeting insgesamt 2,5 Stunden – weniger als ein reguläres Sprint Review Meeting. Die Erfolgsgeschichte von Primavera verdeutlicht die Vorteile von Scrum, insbesondere im Vergleich zu traditionellen Wasserfall-Methoden und zeigt die Effizienz einer gut organisierten Sprint Review Messe.

Die Arbeit kommt zu dem Schluss, dass Scrum zwar ein geeignetes Framework für die Entwicklung komplexer Produkte ist, es aber keine allgemeingültige Lösung für die Skalierung im Unternehmensumfeld gibt. Jedes Unternehmen muss seinen eigenen Weg finden, Scrum an seine spezifischen Gegebenheiten anzupassen, und das Prinzip "Inspect & Adapt" konsequent anwenden. Die wichtigsten Faktoren, die bei der Skalierung zu beachten sind, wurden in Teil III der Arbeit evaluiert. Es wird jedoch darauf hingewiesen, dass es weitere, kontextabhängige Faktoren geben kann, die ebenfalls eine Rolle spielen. Die Arbeit liefert ein Muster-Framework für die Skalierung von Scrum, betont aber die Notwendigkeit individueller Anpassungen an den jeweiligen Kontext. Der erfolgreiche Einsatz von Scrum in Unternehmen wie Google, IBM, Yahoo und Toyota unterstreicht die Praxistauglichkeit des Frameworks auch in großen Unternehmen. Die Arbeit verdeutlicht die Notwendigkeit einer flexiblen und iterativen Anpassung des Scrum-Frameworks an die spezifischen Bedürfnisse des jeweiligen Unternehmens.

Der Ausblick der Arbeit fokussiert sich auf die "querschnittlichen Faktoren", die über die Skalierung der Scrum-Artefakte, Rollen und Meetings hinausgehen. Diese Faktoren umfassen die Kommunikation, die Softwarearchitektur, die Unternehmenskultur, das Projekt- und Prozessmanagement sowie die Unternehmensstruktur. Die Lösung der Herausforderungen in diesen Bereichen ist sehr individuell und komplex und geht über den Rahmen der Arbeit hinaus. Es wird auf eine parallel entstandene Masterarbeit zum Thema Softwarearchitektur in skalierten Scrum-Entwicklungen [Ros13] verwiesen. Die Arbeit regt weitere Forschung zu den verbleibenden querschnittlichen Faktoren an, um ein umfassenderes Verständnis der Herausforderungen und Lösungsansätze für die Skalierung von Scrum in großen Projekten zu entwickeln. Insbesondere die Interaktion zwischen den verschiedenen querschnittlichen Faktoren und deren Einfluss auf den Erfolg der Scrum-Skalierung stellen ein wichtiges Forschungsfeld für zukünftige Arbeiten dar.