Scrum
Artikel Methoden und Techniken
| Bezeichnung der Methode / Technik | Scrum |
| Kategorie (Zweck) | |
| Anwendungsbereiche | Für Vorhaben mit konkretem (Projekt-)Auftrag und höherer Komplexität (schwach strukturierte Prozesse, auch über die Anwendung von IT-Projekten hinaus). |
| Kurzbeschreibung | Scrum als eine Form des agilen Projektmanagements ist durch die iterativ-inkrementelle Arbeitsweise besonders für unsichere und schwer planbare Umgebungen geeignet. Die Methode ist ein effektiver Ansatz zur Bearbeitung komplexer Vorhaben/Produkte. Dabei stellt Scrum ein minimales „Rahmenwerk“ dar, das verschiedene Rollen und Ereignisse umfasst und auch Raum für die Anwendung anderer Techniken/Methoden bietet. Scrum kann daher in die eigenen und etablierten Entwicklungspraktiken eingebettet werden. |
| Voraussetzungen / Rahmenbedingungen / Grundlagen |
|
| Grobe Einschätzung des Zeit- und Personalaufwandes | Teamrollen und -größe:
Zeitaufwand:
|
| Vorteile/Stärken der Methode |
|
| Risiken, Stolperfallen, „darauf sollten Sie achten“ |
|
| Arbeitshilfen | Scrum Guide – Der gültige Leitfaden für Scrum: die Spielregeln: Microsoft Word - 2020-Scrum-Guide-German-v2.0.docx (scrumguides.org) Moderne Methoden und Arbeitsweisen – Impulse zu agilen Methoden und Formaten, Canvas-Vorlagen: |
| Weiterführende Medien und Quellen | CityLAB Berlin Innovationslabor für die Stadt der Zukunft (2020): Öffentliches Gestalten. Handbuch für innovatives Arbeiten in der Verwaltung: Öffentliches Gestalten | CityLAB (citylab-berlin.org) Bartonitz, Martin; Lévesque, Veronika; Michl, Thomas; Steinbrecher, Wolf; Vonhof, Cornelia; Wagner, Ludger (Hg.) (2018): Agile Verwaltung. Wie der Öffentliche Dienst aus der Gegenwart die Zukunft entwickeln kann. Berlin, Heidelberg: Springer Berlin Heidelberg. Agiles Projektmanagement mit SCRUM erklärt (2018): https://www.youtube.com/watch?v=CQPffJMb1hE |
Grundlagen
"Scrum" ist ein Begriff aus dem Rugby und bedeutet „Gedränge“. Bei einem Rugbyspiel stehen sich am Anfang eines Spielzuges fünf bis acht Spieler in einer dichten Ansammlung gegenüber und versuchen aus diesem Gedränge heraus, den Ball in ihrem Sinne in das Spiel zu bringen. Das Team muss hierzu eng zusammenarbeiten, spontan reagieren und in dieselbe Richtung arbeiten, um Erfolg zu haben. Dieser Gedanke wird bei der Scrum-Methode für das Projektmanagement aufgegriffen und in ein klares, aber dennoch leichtgewichtiges Rahmenwerk übersetzt.[1]
Scrum basiert auf dem „Agilen Manifest“ (original "Manifesto for Agile Software Development" bzw. “Agile Manifesto”), das 2001 von einer Gruppe von 17 renommierten Softwareentwicklern formuliert wurde, darunter z. B. Jeff Sutherland und Ken Schwaber, die Begründer des Scrum Frameworks.[2] Das "Agile Manifest" legt folgende Werte fest:
- Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
- Eine funktionierende Software ist wichtiger als umfassende Dokumentation.
- Die Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.
- Das Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans.
Ursprünglich war Scrum für die Softwareentwicklung gedacht, wird jedoch mittlerweile auch in anderen Bereichen angewendet.
Die Scrum-Methode basiert auf klaren Regeln, die drei Rollen, fünf Events und drei Artefakte beschreiben.[3]
Eine detaillierte Beschreibung ist im Scrum Guide zu finden: https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-German.pdf
Rollen bzw. Scrum-Team
Das Scrum-Team, ein kleines interdisziplinäres Team von üblicherweise zehn oder weniger Personen, ist der zentrale Bestandteil von Scrum. Es besteht aus
| einer/einem Scrum Masterin/Scrum Master | ist verantwortlich für die Einhaltung der Praktiken und Regeln der Scrum-Methode[4] im Team und als Teil des Teams mit verantwortlich für die Schaffung eines nutzbaren Increments. |
| einer/einem Product Ownerin/Product Owner | verantwortet Ergebnis und Product Backlog (Liste der Dinge, die durch das Scrum-Team erledigt werden), |
| Developerinnen und Developern | haben sich der Aufgabe verschrieben, jeden Sprint und jeden Aspekt eines nutzbaren Increments (konkreter Schritt in Richtung des Produkt‐Ziels) zu schaffen.[5] |
Das Team agiert als geschlossene Einheit und konzentriert sich auf das Produkt-Ziel. Teilteams und Hierarchien existieren innerhalb dieser sich selbstführenden Einheit nicht. [6]
Abbildung 1: Rollen in Scrum [7]
Artefakte
Die Scrum-Artefakte dienen dem Scrum-Team als Übersicht über alle Tasks, Anforderungen und fertiggestellten (Teil-)Produkte.[8] Sie sind dafür ausgelegt, Ergebnisse für die Verantwortlichen transparent zu machen und ein gemeinsames Verständnis zu schaffen.[9] Alle Mitglieder des Scrum-Teams, die sie überprüfen, haben so die gleiche Grundlage für Anpassungen der Produkte.[10]
Im Gegensatz zu anderen Projektmanagementsystemen benennt Scrum explizit nur die drei folgenden am Leistungsumfang orientierten Produkte des Projektmanagements:
| Product Backlog | emergente, geordnete Liste der Dinge, die zur Produktverbesserung benötigt werden; die einzige Quelle von Arbeit, die durch das Scrum-Team erledigt wird,[11] |
| Sprint Backlog | besteht aus dem Sprint‐Ziel (Wofür), den für den Sprint ausgewählten Product‐Backlog‐Einträgen (Was) sowie einem umsetzbaren Plan für die Lieferung des Increments (Wie),[12] |
| Increment | konkreter Schritt in Richtung des Produkt‐Ziels; jedes Increment ist additiv zu allen vorherigen Increments und gründlich geprüft, um sicherzustellen, dass sie alle zusammen funktionieren; muss verwendbar sein, um einen Mehrwert zu erzielen.[13] |
Unterlagen, die meist in klassischen Projekten verwendet werden, wie z. B. einen Ablauf- oder Kostenplan, gibt es bei der Scrum-Methode i. d. R. nicht.
Die Definition of Done zählt nicht zu den offiziellen Scrum Artefakten, ist jedoch von zentraler Bedeutung für die Beurteilung eines Increments[14] , denn sie kann als eine Art Arbeitsvereinbarung gesehen werden, mit der das Scrum-Team ein einheitliches Verständnis darüber erlangt, was es als „erledigt“ ansieht.[15]
Scrum-Events
Jedes der Scrum-Events innerhalb eines Sprints bietet die Gelegenheit, Artefakte zu überprüfen und anzupassen. Sie sind darauf ausgelegt, die erforderliche Transparenz zu ermöglichen. Darüber hinaus ist es Ziel der Events, Regelmäßigkeit zu schaffen sowie die Notwendigkeit von klassischen Meetings, wie sie in Scrum nicht definiert sind, zu minimieren. Es ist empfehlenswert, alle Events immer zur selben Zeit am selben Ort durchzuführen, um Komplexität zu reduzieren. Folgende fünf Events sind nach Scrum definiert:
| Sprint | kurzer Arbeitszyklus von maximal 30 Tagen; hat eine feste Länge, um Konsistenz zu schaffen; die übrigen nach Scrum definierten Events finden innerhalb eines jeden Sprints statt,[16] |
| Sprintplanung | Dauer von vier bis acht Stunden je nach Sprintlänge; initiiert den Sprint, indem es die für den Sprint auszuführenden Arbeiten darlegt; der daraus resultierende Plan wird durch die gemeinschaftliche Arbeit des gesamten Scrum-Teams erstellt;[17] |
| Daily Scrum | tägliches, maximal 15-minütiges Event für die Developerinnen/Developer des Scrum-Teams mit dem Zweck, den Fortschritt in Richtung des Sprint-Ziels zu überprüfen und das Sprint Backlog bei Bedarf anzupassen, um die bevorstehende geplante Arbeit zu justieren, |
| Sprint Review | maximal vierstündiges Event am Ende eines Sprints, um das Ergebnis zu überprüfen und künftige Anpassungen festzulegen; das Scrum-Team stellt die Ergebnisse seiner Arbeit den wichtigsten Stakeholderinnen und Stakeholdern vor; die Fortschritte in Richtung des Produkt‐Ziels werden diskutiert,[18] |
| Sprint Retrospective | maximal dreistündiges Event am Ende eines Sprints; bei dem das Scrum-Team seine bisherige Arbeitsweise überprüft, um in Zukunft effizienter und effektiver arbeiten zu können.[19] |
Quelle: eigene Darstellung (Vergrößerung öffnet sich im neuen Fenster)
Abbildung 2: Scrum Prozess [20]
Notwendigkeit für die öffentliche Verwaltung und Anwendung der Methode
Die Welt verändert sich immer schneller, wird zunehmend komplexer und lässt sich entsprechend weniger gut berechnen. Ursache und Wirkungen verschwimmen und es gibt keine eindeutigen Lösungen mehr. Die daraus entstehende VUKA-Welt (VUKA = Akronym für Volatilität, Unsicherheit, Komplexität, Ambiguität; s. auch Abbildung 3) beeinflusst auch die öffentliche Verwaltung. Sie muss sich auf die steigende Digitalisierung vorbereiten und gleichzeitig auf verschiedene Krisen reagieren (z. B. Flüchtlings- oder Corona-Krise).[21]
Abbildung 3: VUKA
Agile Arbeitsweisen und Methoden unterstützen dabei, sich in diesem Umfeld zurecht zu finden. Dabei ist Agilität definiert als "die Gewandtheit, Wendigkeit oder Beweglichkeit von Organisationen und Personen bzw. in Strukturen und Prozessen. Man reagiert flexibel auf unvorhergesehene Ereignisse und neue Anforderungen und handelt, etwa in Bezug auf Veränderungen, nicht nur reaktiv, sondern auch proaktiv." [22]
Scrum ist eine der agilen Methoden und eignet sich besonders zur Organisation der Arbeit von einem oder mehreren Projektteams in komplexen Umgebungen. Diese komplexen Umgebungen sind durch viele Variablen gekennzeichnet, die in gegenseitiger Wechselwirkung stehen. Zu Beginn eines Projekts ist es unmöglich, vorherzusagen, was genau passiert. Es können also nur Annahmen getroffen, durch ständiges Ausprobieren gelernt und schließlich Muster erkannt werden.[23]
Um den Einstieg in die Arbeit mit einer agilen Projektmanagementmethode wie Scrum zu erleichtern, kann es sinnvoll sein, zunächst einzelne Elemente von Scrum, wie z. B. die Besprechungsformate, mit traditionellen Projektmanagementelementen in Form eines hybriden Projektmanagements zu kombinieren. Im weiteren Verlauf oder in anderen Projekten können zusätzliche Scrum-Elemente hinzugenommen werden. Diese Vorgehensweise ermöglicht es dem Team, sich Schritt für Schritt mit der Methode vertraut zu machen und sich auf die neue Arbeitsweise einzustellen (s. auch Abbildung 4).
Quelle: eigene Darstellung (Vergrößerung öffnet sich im neuen Fenster)
Abbildung 4: Mehrwert von Agilität
Weitere Impulse zu agilen Methoden und Formaten finden Sie unter folgendem Link: https://www.bva.bund.de/...
Grenzen der Methode (für den öffentlichen Sektor)
Scrum basiert auf den drei Säulen Empirie, Empowerment und Ownership. Das Scrum-Team soll gemeinsam durch Experimente und Beobachtungen (Empirie) während seiner Arbeit lernen und dadurch sowohl die Zusammenarbeit als auch das Produkt kontinuierlich verbessern. Um dieses Lernen zu ermöglichen, müssen die Beteiligten selbstbestimmt als Team agieren können (Empowerment). Ownership im Sinne der Zugehörigkeit zu einem Team und der gemeinsamen Verantwortung für ein Produkt ist somit wichtiger als Expertentum. Expertenwissen wird dennoch benötigt, nämlich dort, wo es zur Entwicklung angewendet wird.[24]
Um ein selbstbestimmtes Arbeiten im Team zu ermöglichen, müssen zunächst bestehende, traditionelle Denk- und Arbeitsweisen sowie organisatorische Strukturen aufgebrochen werden. Dieser Wandel verläuft meist nicht ohne Widerstände und kann gerade in den bürokratischen und hierarchischen Strukturen der Verwaltung zur Herausforderung werden. Dieser Wandel und das damit verbundene Umdenken erfordert Ausdauer und bedeutet einen nicht unerheblichen finanziellen und zeitlichen Aufwand.
Hierbei ist zu beachten, dass mit dem Einsatz von Scrum auch ein erhöhter Kommunikationsaufwand einhergeht, um mit Auftraggebenden sowie innerhalb des Teams zu kommunizieren. Dies soll eine bessere Nutzerzentrierung und ein zielgerichtetes Arbeiten ermöglichen sowie Mehraufwand durch Planungen vermeiden, die unerwartet wieder verworfen werden müssen, wie es z. B. bei klassischen Wasserfallprojekten möglich sein kann. Das bedeutet aber auch, dass Scrum nicht flächendeckend für jedes Projekt eingesetzt werden kann und sich insbesondere nicht für Projekte eignet, die ein klar vorgegebenes Ziel haben und die unter relativ konstanten Bedingungen durchgeführt werden. Es muss also sorgfältig abgewägt werden, für welche Projekte bzw. in welchen Bereichen, der Einsatz der Methode und der damit verbundene Aufwand angemessen ist.[25]
Literaturverzeichnis
| Bendel, O. (2019): Agilität [online] https://wirtschaftslexikon.gabler.de/definition/agilitaet-99882/version-368852 [abgerufen am 09.06.2022]. |
| Diehl, A. (2020): Das Agile Manifest – Leitsätze und Werte agiler Teams [online] https://digitaleneuordnung.de/blog/agiles-manifest/ [abgerufen am 18.05.2022]. |
| Diehl, A. (2021): Stacey Matrix – Wann der Einsatz agiler Methoden notwendig und wirksam ist [online] https://digitaleneuordnung.de/blog/stacey-matrix/ [abgerufen am 09.06.2022]. |
| Grätsch, S./Knebel, K. (2018): Der Scrum Guide: Was ist Scrum und wie funktioniert es? [online] https://www.berlinerteam.de/magazin/scrum-guide/ [abgerufen am 18.05.2022]. |
| projektmagazin (2019): Scrum Artefakte [online] https://www.projektmagazin.de/glossarterm/scrum-artefakte [abgerufen am 18.05.2022]. |
| Raitner, M. (2021): Die drei Säulen der Agilität: Empirie, Empowerment und Ownership [online] https://fuehrung-erfahren.de/.../ [abgerufen am 14.06.2022]. |
| Salimi, Sohrab (2022): Definition of Done [online] https://www.agile-academy.com/de/scrum-master/definition-of-done/ [abgerufen am 04.07.2022]. |
| Schwaber, K./Sutherland, J. (2020): Der Scrum Guide [online] https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-German.pdf [abgerufen am 01.07.2022] |
| Theobald, S./Guckenbiehl, P. (2021): Agilität in der Verwaltung – eine Einführung [online] https://www.iese.fraunhofer.de/blog/agilitaet-in-der-verwaltung/ [abgerufen am 14.06.2022]. |
| Trepper, T. (2012): Agil-systemisches Softwareprojektmanagement, Wiesbaden: Springer-Gabler (Research). |
| Zweimüller, Annika (2020): Die Scrum Artefakte [online] https://www.agile-heroes.de/magazine/scrum-artefakte/ |
Fußnoten
[1] Vgl. Grätsch et al., 2018
[2] Vgl. Diehl, 2009
[3] Vgl. Schwaber et al., 2020
[4] Vgl. Schwaber et al., 2020, S. 7
[5] Vgl. Schwaber et al., 2020, S. 6
[6] Vgl. Schwaber et al., 2020, S. 5
[7]
[8] Vgl. Zweimüller: 2020
[9] Vgl. Trepper: 2012, S. 105 – 106
[10] Vgl. Schwaber et al.: 2020, S. 11
[11] Vgl. Schwaber et al.: 2020, S. 11
[12] Vgl. Schwaber et al.: 2020, S. 12
[13] Vgl. Schwaber et al.: 2020, S. 13
[14] Vgl. projektmagazin: 2019
[15] Vgl. Salimi: 2022
[16] Vgl. Schwaber et al.: 2020, S. 8
[17] Vgl. Schwaber et al.: 2020, S. 9
[18] Vgl. Schwaber et al.: 2020, S. 10
[19] Vgl. Schwaber et al.: 2020, S. 0 - 11
[20] Vgl. Trepper: 2012, S. 105 - 106
[21] Vgl. Theobald et al., 2021
[22] Vgl. Bendel, 2019
[23] Vgl. Diehl, 2021
[24] Vgl. Raitner, 2021
[25] Vgl. Theobald et al., 2022
