Leseprobe
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 einen 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 Softwareentwicklung. Durch die agile Herangehensweise und damit einhergehender verbesserter Effektivität entwickelte sich Scrum seither innerhalb der Technologiebranche graduell weitgehend 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 Anforderungen 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 Eignung 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 wissenschaftliche1 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 Lochkarten zu schreiben unterlag keinem wesentlichen methodischen Unterschied. Als die Komplexität der Software sich erhöhte, bediente man sich an den Vorgehensweisen anderer Branchen, wie dem produzierenden Gewerbe und adaptierte diese auf die Anforderungen der Softwareentwicklung. Insbesondere das 1970 von Royce entwickelte Wasserfallmodell erlangte einen großen Einfluss. Weitere Modelle wie das 1979 von Boehm entwickelte V-Modell, sowie das Spiralmodell nach Boehm von 1988 entstanden als Weiterentwicklungen des Wasserfallmodells und berücksichtigten bereits teilweise mit dem Prozess einhergehende Entwicklungsrisiken.2 Durch trennscharfe Entwicklungsschritte, die definiert und modelliert zur Verfügung standen, entwickelten diese Modelle den Eindruck den Entwicklungsprozess unter Kontrolle zu haben.3 Der Fokus klassischen Projektmanagements liegt auf der Effizienz, das Projekt wird so geplant, wie es ideal in der Entwicklung umzusetzen ist. Änderungen während des Projektablaufes sind nicht vorgesehen. 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.4 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.5
Scrum als Begriff des Projektmanagements wurde im Jahre 1986 durch Hirotaka Takeuchi 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 bereits: 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.6
In der folgenden Dekade entwickelt John Sutherland zusammen mit Ken Schwaber das Scrum Konzept weiter, das insbesondere die Rollendefinition und -organisation beinhalten und oftmals konträre Ansichten zu bestehenden Vorgehensweisen aufzeigt.7 Im Agile Manifesto, das 2001 erscheint wird von Sutherland, Schwaber, Beedle und vierzehn weiteren 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.8 In den darauffolgenden Jahren entwickelt sich Scrum vom Werkzeug für die Softwareentwicklung zum Rahmenmodell des Projektmanagements weiter. Insbesondere Ken Schwaber und Mike Cohn widmen sich in ihrer Literatur zunehmend den Möglichkeiten von Scrum als Methode des Projektmanagements und erwecken 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.9 Die Scrum Alliance, eine 2001 gegründete Non-profit Organisation hat zum heutigen Tage weltweit 750.000 Mitglieder zertifi- ziert.10
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 erster 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 Entwicklung mit ein.11 Um dies zu gewährleisten basiert das agile Manifest auf folgenden Grundprinzipien:
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 Methoden wie Scrum hoch priorisiert, ohne jedoch die Prinzipien der rechten Seite vollständig 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. Interaktionen 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 selbstorganisiert 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.12
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 visualisiert.
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 Projektteam nach festgelegten Zielen ein Produktinkrement erschafft, dass dem Kunden ausgeliefert werden kann. Im Bereich der Softwareentwicklung könnte dies beispielsweise die neue Funktionalität einer Software sein.13
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.14 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.15
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 Priorisierung von Aufgaben.16 In bestehenden Unternehmen findet sich jedoch selten eine solche Situation vor. Die Struktur und Organisation eines Unternehmens ist über Jahre gewachsen und zunächst vorgegeben. Die Abteilungen und Teams übersteigen in der Größenordnung ein Scrum Team und Projekte sind oftmals größer, als dass sie sich mit einem zehnköpfigen Scrum Team bewältigen ließen. Ungeachtet dessen genießt Scrum wesentliche Bedeutung in der Mehrheit der Unternehmen im IT-nahen Umfeld.17
[...]
1 Vgl. Sutherland, J., Scrum Revolution, 2015, S. 7f.
2 Vgl. Grechenig, T. et al., Softwaretechnik, 2010, S. 372f.
3 Vgl. Sutherland, J., Scrum Revolution, 2015, S. 7.
4 Vgl. Böhm, J., Agilität, 2019, S. 10ff.
5 Vgl. Gloger, B., Scrum, 2011, S. 19.
6 Vgl. Tekeuchi, H., Nonaka, I., Product development, 1986, S. 137.
7 Vgl. Gloger, B., Scrum, 2011, S. 20f.
8 Vgl. Hazzan, O., Dubinsky, Y, Agile Anywhere, 2014, S. 9.
9 Vgl. Deutsche Gesellschaft für Projektmanagement, Status Quo Agile, 2015, S. 6f.
10 Vgl. Scrum Alliance, Who is Scrum Alliance, 2019, o. S.
11 Vgl. Canty, D., Agile for PM, 2015, S. 1.
12 Vgl. Maigatter, A., Führung und Scrum Teams, 2018, S. 304.
13 Vgl. Schwaber, K., Sutherland, J., Scrum Guide, 2017, S. 6.
14 Vgl. Wirdemann, R., Mainusch, J., Scrum mit User Stories, 2019, S. 30.
15 Vgl. Roock, S., Wolf, H., Scrum, 2018, S. 13ff.
16 Vgl. Rigby, D. et al., Agile innovation, 2015, S. 2.
17 Vgl. Deutsche Gesellschaft für Projektmanagement, Status Quo Agile, 2015, S. 8f.