Zusammenfassung
Wir gliedern unsere DMS-Projekte in drei Phasen: In Phase A wird das Projekt strukturiert und eine Software beschafft. In Phase B startet eine neue Abteilung in das Projekt. In Phase C wird ein einzelner Prozess im DMS implementiert und produktiv gesetzt. Die Phase C muss agil gestaltet werden, bei Phase A kann dies der Fall sein. Eine agile Vorgehensweise nach Scrum wird vorgestellt und die verschiedenen Elemente von Scrum – Rollen, Steueurungsinstrumente und Ereignisse – überblicksmäßig erläutert.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Notes
- 1.
Der folgende Überblick ist auf keinen Fall ausreichend, um ein Projekt agil aufzusetzen. Wir empfehlen allen Verwaltungen, die ein DMS-Projekt agil organisieren möchten, zumindest den sog. Product Owner und den Scrum Master eine zweitägige Schulung in „Scrum für OE-Projekte“ angedeihen zu lassen. Hinweise auf Seminare findet man unter anderem auf www.agile-verwaltung.org.
- 2.
Die Begründer von Scrum, Sutherland und Schwaber, betonen, dass es sich bei Scrum um ein „Rahmenwerk“ (engl. framework) handele und nicht um ein Projektmanagement. Scrum erläutert nämlich beispielsweise bestimmte Rollen nicht, die aber in Projekten immer besetzt sind (z. B. die des Auftraggebers oder des oder der Projektkunden).
- 3.
Scrum ist keine Abkürzung, sondern bedeutet „Gedränge“ in der englischen Sprache. – Die offiziellen Regeln zu Scrum sind im „Scrum Guide“ [1] zusammengefasst. Diesen können Sie sich kostenlos von der Webseite scrumguides.org herunterladen.
- 4.
Im englischen Original „development team“.
- 5.
Die Qualitätskriterien, die das Team bei der Erarbeitung einer Lösung beachten muss, sind in der sog. „Definition of Done“ niedergelegt. Sie werden von uns hier nicht genauer erläutert. Wir verweisen hier auf den Scrum-Guide in [1].
- 6.
Diese Übersetzung des englischen Worts „Artefacts“ verantworte allein ich als Autor. In der Regel übersetzen deutsche Scrum-Publizisten diesen Begriff mit „Artefakten“ ins Deutsche – eine völlig unübliche und meines Erachtens verwirrende Bezeichnung
- 7.
In der Praxis haben sich für funktionale Anforderungen (im Unterschied zu technischen Aufgaben) sog. User Storys bewährt. Diese werden in einem der folgenden Kapitel erläutert.
- 8.
Englisch „Tasks“.
- 9.
So etwas kann in der Realität natürlich dauernd vorkommen. Nicht erlaubt ist es hingegen, dass der Product Owner während des Sprints dem Team neue Anforderungen überträgt. Er hat nicht das Recht, Druck auszuüben im Sinne von „ach, das könnt ihr doch auch noch machen. Ist eben reingekommen, ganz wichtig!“.
- 10.
Englisch „Sprint Goal“.
- 11.
Vgl. Kap. 13 „Agiler Vertrag“.
- 12.
Mit „potenziell auslieferbar“ ist gemeint: das Sprintergebnis könnte man an die Endanwender ausliefern, muss es aber nicht. Wenn ein Sprint drei Wochen dauert, kann Product Owner sich z. B. überlegen, dass er nur alle neun Wochen jeweils drei Produktinkremente im Bündel ausliefert. Das reduziert Umstellungsaufwand für die Anwender.
- 13.
Eigentlich soll die Sprintlänge nie geändert werden. In der Realität kommt es zu Projektbeginn oft zur Wahl einer längeren Sprintdauer (drei oder vier Wochen). Nach einiger Zeit merkt man dann, dass insbesondere in „Teilzeitprojekten“ kürzere Sprintlängen sinnvoller sind.
- 14.
Der Scrum Guide geht bei einem vierwöchigen Sprint von maximal 8 h aus für das Planungsmeeting aus. Das sind aber Angaben aus Softwareentwicklungsprojekten, bei denen das Team Vollzeit an einem Produkt arbeitet. In unserem Fall haben wir „Teilzeitprojekte“, bei denen nur ein mehr oder weniger großer Teil der Arbeitszeit „nebenbei“ ins Projekt fließt. Daraus ergeben sich absolut gesehen viel kürzere Meetingzeiten. Aber sie sind relativ (als Anteil an den gesamten Projektstunden, die in einem Sprint geleistet werden, höher. Teilzeitprojekte sind immer unproduktiver als Vollzeitprojekte).
- 15.
Manche Projektteams haben die Bezeichnung durch „Weekly Scrum“ ersetzt oder durch „Standup Meeting“. Hier im Buch verwende ich weiter „Daily Scrum“.
- 16.
Literatur
Ken Schwaber, Jeff Sutherland: Der Scrum Guide. Der gültige Leitfaden für Scrum: Die Spielregeln. Entwickelt und kontinuierlich verbessert. Deutsche Ausgabe. Abrufbar unter https://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-DE.pdf
Marc Löffler: Retrospektiven in der Praxis, dpunkt-verlag, Heidelberg, 2014
Judith Andresen: Retrospektiven in agilen Projekten: Ablauf, Regeln und Methodenbausteine, Hansa Fachbuch, 2015
Esther Derby, Diana Larsen: Agile Retrospektives: Making Good Teams Great. 1. Aufl. Dallas, Texas: Pragmatic Programmers, LLC, 2006
Author information
Authors and Affiliations
Corresponding author
Editor information
Editors and Affiliations
Rights and permissions
Copyright information
© 2020 Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature
About this chapter
Cite this chapter
Fischbach, J., Steinbrecher, W. (2020). Agiles Projektmanagement nach Scrum. In: Steinbrecher, W. (eds) Agile Einführung der E-Akte mit Scrum. Springer Gabler, Berlin, Heidelberg. https://doi.org/10.1007/978-3-662-59705-7_6
Download citation
DOI: https://doi.org/10.1007/978-3-662-59705-7_6
Published:
Publisher Name: Springer Gabler, Berlin, Heidelberg
Print ISBN: 978-3-662-59704-0
Online ISBN: 978-3-662-59705-7
eBook Packages: Business and Economics (German Language)