Eignung und Anwendung agiler Methoden nach Scrum im Rahmen des Managements großer Projekte

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einleitung
1.1 Problemstellung
1.2 Gang der Untersuchung
1.3 Zielsetzung

2 Grundlagen agiler Methoden nach Scrum
2.1 Historische Betrachtung
2.2 Prinzipien und Ziele
2.3 Scrum-Flow
2.4 Skalierung von Scrum mittels Scaled Agile Framework

3 Eignung agiler Methoden in Großprojekten
3.1 Herausforderungen und Merkmale großer Projekte der Finanzbranche
3.2 Skalierte Anwendungsmöglichkeiten nach SAFe
3.3 Eignung der Methoden nach SAFe

4 Fazit
4.1 Zusammenfassung der Ergebnisse
4.2 Kritische Würdigung und Ausblick

Anhang

Abbildungsverzeichnis

Abb. 1: Der Ablauf in Scrum

Abb. 2: Large Solution SAFe Framework

Abb. 3: Bewertung ausgewählter FinTechs, Stand 2016

Abb. 4: Portfolio SAFe Framework

Tabellenverzeichnis

Tab. 1: Grundprinzipien des agilen Manifests

Abkürzungsverzeichnis

DevOps Development & Operations

FinTech Financial Services & Technology

OOPSLA Object-Oriented Programming, Systems, Languages and Applications

PI Product-Increment

SAFe Scaled Agile Framework

STE Solution Train Engineer

1. Einleitung

1.1 Problemstellung

Im Jahre 1995 veröffentlichte Ken Schwaber in Zusammenarbeit mit Jeff Sutherland ei­nen ersten Beitrag zu Scrum im Rahmen der wissenschaftlichen Konferenz OOPSLA in Austin, USA. Bis zu dieser Zeit und noch bis etwa zehn Jahre nach der Veröffentlichung des Scrum Beitrages dominierten Wasserfallmodelle die Prozesse der Softwareentwick­lung. Durch die agile Herangehensweise und damit einhergehender verbesserter Effekti­vität entwickelte sich Scrum seither innerhalb der Technologiebranche graduell weitge­hend zur Standardmethode zur konzeptionellen Neuentwicklung von Software. Jedoch auch außerhalb der Softwareentwicklung, nämlich im Projektmanagement erfreuen sich agile Methoden auf Grund ihrer Reaktionsfähigkeit bei Problemen, der Entfesselung von starren Projektablaufplänen sowie der flexiblen Adaption an sich verändernde Anforde­rungen erhöhter Aufmerksamkeit.1 Die Methodik scheint gerade in kleinen Unternehmen, ebenso in kreativen Bereichen in besonderem Maße geeignet zu sein. Doch lassen sich agile Methoden nach Scrum auch auf große Unternehmen skalieren, die scheinbar nicht auf langfristige und detaillierte Planung verzichten können? Welche Methoden bietet Scrum um auch im großen Maßstab und in vermeintlich starren und etablierten Branchen wie dem Finanzsektor Effektivität zu verbessern und Projekte agil zu managen?

1.2 Gang der Untersuchung

Die vorliegende Seminararbeit ist wie folgt aufgebaut: Der Hauptteil der Arbeit ist in zwei Bereiche aufgegliedert. Der erste Teil (Kapitel zwei) beschäftigt sich zunächst mit einer kurzen historischen Betrachtung agiler Methoden nach Scrum, bevor Prinzipien und Ziele eben dieser beleuchtet werden. Im weiteren Verlauf werden die Abläufe sowie Methoden erläutert, die Scrum anbietet um Prozesse agil zu gestalten und zu skalieren. Im zweiten Teil der Arbeit (Kapitel 3) soll aufgezeigt werden, wie Scrum durch das SAFe auf große Projekte skaliert werden kann. Unter Fokussierung auf die Finanzbranche soll aufgezeigt werden in wie fern sich agile Methoden nach Scrum in Großprojekten ebendieser eignen, in dem zunächst auf die Besonderheiten großer Projekte in der Finanzbranche eingegan- gen wird, um darauffolgend die Anwendungsmöglichkeiten zu betrachten und deren Eig­nung zu untersuchen. Im letzten Teil der Arbeit wird abschließend ein Fazit gezogen, sowie ein kurzer Ausblick auf die zukünftige Entwicklung gegeben.

1.3 Zielsetzung

Ziel dieser Seminararbeit soll es sein, herauszufinden, ob und in wie fern die Verwendung agiler Methoden nach Scrum auch außerhalb der Softwareentwicklung im Rahmen des Projektmanagements großer Projekte am Beispiel der Finanzbranche Eignung aufweist und welche Chancen und Risiken sich hieraus insbesondere im Finanzsektor ergeben.

2. Grundlagen agiler Methoden nach Scrum

2.1 Historische Betrachtung

Zu Beginn der Softwareentwicklung lagen nur wenige wissenschaftliche¹ Phasenmodelle vor. In den 1950 Jahren wurde nicht zwischen der Entwicklung von Soft- und Hardware unterschieden. Drähte auf einer Platine zu verlöten oder Befehle für Software auf Loch­karten zu schreiben unterlag keinem wesentlichen methodischen Unterschied. Als die Komplexität der Software sich erhöhte, bediente man sich an den Vorgehensweisen an­derer Branchen, wie dem produzierenden Gewerbe und adaptierte diese auf die Anforde­rungen der Softwareentwicklung. Insbesondere das 1970 von Royce entwickelte Wasser­fallmodell erlangte einen großen Einfluss. Weitere Modelle wie das 1979 von Boehm entwickelte V-Modell, sowie das Spiralmodell nach Boehm von 1988 entstanden als Wei­terentwicklungen des Wasserfallmodells und berücksichtigten bereits teilweise mit dem Prozess einhergehende Entwicklungsrisiken.² Durch trennscharfe Entwicklungsschritte, die definiert und modelliert zur Verfügung standen, entwickelten diese Modelle den Ein­druck den Entwicklungsprozess unter Kontrolle zu haben.³ Der Fokus klassischen Pro­jektmanagements liegt auf der Effizienz, das Projekt wird so geplant, wie es ideal in der Entwicklung umzusetzen ist. Änderungen während des Projektablaufes sind nicht vorge­sehen. Agile Methoden wie Scrum setzen den Fokus auf Effektivität. Der Kundennutzen rückt in den Vordergrund und es bietet eine gute Adaptierbarkeit bei Änderungen.⁴ Scrum trägt der Unvorhersagbarkeit des Entwicklungsprozesses Rechnung. Das Endprodukt ist unter Berücksichtigung der Kosten, der Zeit und der Funktionalität das bestmögliche.⁵

Scrum als Begriff des Projektmanagements wurde im Jahre 1986 durch Hirotaka Takeu­chi und Ikujiro Nonaka erstmalig im Rahmen der Harvard Business Review vorgestellt. Der Begriff selbst liegt dem Rugby Sport zu Grunde, wo er für eine Standardsituation durch das Gedränge und die Anhäufung von Spielern steht. Der Begriff impliziert es be­reits: In ihren Ausführungen machen Takeuchi und Nonaka deutlich, dass sie eine andere Ansicht von Rollen und dem Projektablauf haben. Eine höhere Erfolgsquote in Projekten soll dadurch realisiert werden, dass lernende Teams ohne Organisation von außen oder strenger Führung gebildet werden, die sich in diversen Projektphasen iterativ dem Ziel annähern sollen.⁶

In der folgenden Dekade entwickelt John Sutherland zusammen mit Ken Schwaber das Scrum Konzept weiter, das insbesondere die Rollendefinition und -organisation beinhal­ten und oftmals konträre Ansichten zu bestehenden Vorgehensweisen aufzeigt.⁷ Im Agile Manifesto, das 2001 erscheint wird von Sutherland, Schwaber, Beedle und vierzehn wei­teren Kollegen ein gemeinsames Verständnis von Scrum und agiler Methodik geschaffen. Auch andere Methoden wie Lean, und Extreme Programming bedienen sich fortan dieses Manifests der agilen Methoden.⁸ In den darauffolgenden Jahren entwickelt sich Scrum vom Werkzeug für die Softwareentwicklung zum Rahmenmodell des Projektmanage­ments weiter. Insbesondere Ken Schwaber und Mike Cohn widmen sich in ihrer Literatur zunehmend den Möglichkeiten von Scrum als Methode des Projektmanagements und er­wecken das Interesse der Praxis. Zum heutigen Tage hat sich insbesondere Scrum zur weltweit angewandten Praxis etabliert: IT-Dienstleister wie IBM führen agile Projekte im großen Rahmen basierend auf Scrum durch.⁹ Die Scrum Alliance, eine 2001 gegründete Non-profit Organisation hat zum heutigen Tage weltweit 750.000 Mitglieder zertifi- ziert.¹⁰

2.2 Prinzipien und Ziele

Der Begriff Agilität impliziert Geschwindigkeit. Agile Methoden haben sich jedoch nicht dazu verschrieben lediglich schneller zu liefern. Ziel agiler Methoden soll es zwar auch sein, Deadlines einzuhalten, die Dynamik und Schnelligkeit bezieht sich allerdings in ers­ter Linie auf die schnelle Anpassungsfähigkeit. Partielle Ergebnisse werden in kürzeren Abständen geliefert, validiert und es wird auf Veränderungen reagiert. Anpassungen des Auftraggebers sind im laufenden Prozess jederzeit möglich und fließen in die Entwick­lung mit ein.¹¹ Um dies zu gewährleisten basiert das agile Manifest auf folgenden Grund­prinzipien:

Tabelle 1: Grundprinzipien des agilen Manifests

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Beck, K. et al., Agile Manifesto, 2001, o.S.

Die Prinzipien auf der linken Seite der Tabelle werden bei der Verwendung agiler Me­thoden wie Scrum hoch priorisiert, ohne jedoch die Prinzipien der rechten Seite vollstän­dig außer Acht zu lassen. Der Fokus wird deshalb auf die Prinzipien der linken Seite gelegt, da sie sich als kritische Treiber für den Projekterfolg herausgestellt haben. Inter­aktionen mit dem Kunden, der Fokus auf Individuen und Kollaboration im Team stellen wesentliche Grundpfeiler einer erfolgreichen Projektausführung mit agilen Methoden dar. Anstatt einem starren Plan zu folgen, soll es Ziel sein, dass Scrum Teams selbstorga­nisiert und zielorientiert arbeiten sowie in der Lage sind schnell und effektiv auf sich verändernde Anforderungen einzugehen und diese in das Produkt einfließen zu lassen.¹²

2.3 Scrum-Flow

Der Ablauf in Scrum (Scrum-Flow) ist bewusst einfach gehalten und kann gut vermittelt werden. Zur Veranschaulichung des Prozesses folgt eine Abbildung, die den Prozess vi­sualisiert.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1: Der Ablauf in Scrum

Quelle: Roock, S., Wolf, H., Scrum, 2018, S. 14.

Der Prozess der iterativen Annäherung an ein Ziel in Scrum wird als Sprint bezeichnet. Der Sprint ist ein ein- bis vierwöchiger Prozess in dem das fünf- bis zehnköpfige Projekt­team nach festgelegten Zielen ein Produktinkrement erschafft, dass dem Kunden ausge­liefert werden kann. Im Bereich der Softwareentwicklung könnte dies beispielsweise die neue Funktionalität einer Software sein.¹³

Der Scrum-Flow beginnt mit einer Vision der Eigenschaften des Produktes, sowie den jeweiligen Spezifikationen. Der Product Owner, der für den wirtschaftlichen Erfolg des Produktes verantwortlich ist, organisiert und priorisiert diese im Product Backlog. Die Spezifikationen werden somit zu Backlog Items. Bevor der eigentliche Sprint beginnt, kommen Product Owner, Scrum Master und das Entwicklungsteam zum Sprint Planning zusammen und einigen sich darauf, welche Backlog Items für den kommenden Sprint aus dem Product Backlog in das Sprint Backlog übernommen werden. Unmittelbar darauf beginnt der ein- bis vierwöchige Sprint. Das Entwicklungsteam organisiert sich dabei selbst, der Scrum Master nimmt unterstützende Funktionen ein und unterstützt bspw. bei der Organisation. Während des Sprints werden täglich Daily Scrum Meetings mit dem Scrum Master abgehalten, die zur Abstimmung des Teams dienen.¹⁴ Das Ergebnis des Sprints ist ein auslieferbares Produktinkrement. Im Anschluss an einen Sprint erfolgt das Sprint Review, in dem der Product Owner, die Stakeholder, also bspw. den Auftraggeber über den Entwicklungsfortschritt informiert. Das Feedback aus dem Sprint Review fließt dann wieder in das Product Backlog. Somit lassen sich Änderungen unmittelbar adaptie- ren.¹⁵

2.4 Skalierung von Scrum mittels Scaled Agile Framework

Die im vorangegangenen Kapitel beschriebenen Prinzipien und Methoden erscheinen nachvollziehbar und eingängig, betrachtet man eine Neukonzeption eines kleinen Teams oder Neuausrichtung kleinerer Unternehmen. Scrum minimiert die Time-To-Market (Produkteinführungszeit) und eignet sich besonders hinsichtlich wechselnder Priorisie­rung von Aufgaben.¹⁶ In bestehenden Unternehmen findet sich jedoch selten eine solche Situation vor. Die Struktur und Organisation eines Unternehmens ist über Jahre gewach­sen und zunächst vorgegeben. Die Abteilungen und Teams übersteigen in der Größenord­nung ein Scrum Team und Projekte sind oftmals größer, als dass sie sich mit einem zehn­köpfigen Scrum Team bewältigen ließen. Ungeachtet dessen genießt Scrum wesentliche Bedeutung in der Mehrheit der Unternehmen im IT-nahen Umfeld.¹⁷

[...]

¹ Vgl. Sutherland, J., Scrum Revolution, 2015, S. 7f.

² Vgl. Grechenig, T. et al., Softwaretechnik, 2010, S. 372f.

³ Vgl. Sutherland, J., Scrum Revolution, 2015, S. 7.

⁴ Vgl. Böhm, J., Agilität, 2019, S. 10ff.

⁵ Vgl. Gloger, B., Scrum, 2011, S. 19.

⁶ Vgl. Tekeuchi, H., Nonaka, I., Product development, 1986, S. 137.

⁷ Vgl. Gloger, B., Scrum, 2011, S. 20f.

⁸ Vgl. Hazzan, O., Dubinsky, Y, Agile Anywhere, 2014, S. 9.

⁹ Vgl. Deutsche Gesellschaft für Projektmanagement, Status Quo Agile, 2015, S. 6f.

¹⁰ Vgl. Scrum Alliance, Who is Scrum Alliance, 2019, o. S.

¹¹ Vgl. Canty, D., Agile for PM, 2015, S. 1.

¹² Vgl. Maigatter, A., Führung und Scrum Teams, 2018, S. 304.

¹³ Vgl. Schwaber, K., Sutherland, J., Scrum Guide, 2017, S. 6.

¹⁴ Vgl. Wirdemann, R., Mainusch, J., Scrum mit User Stories, 2019, S. 30.

¹⁵ Vgl. Roock, S., Wolf, H., Scrum, 2018, S. 13ff.

¹⁶ Vgl. Rigby, D. et al., Agile innovation, 2015, S. 2.

¹⁷ Vgl. Deutsche Gesellschaft für Projektmanagement, Status Quo Agile, 2015, S. 8f.