Praxisbericht

Scrum in SAP-Projekten einsetzen

Teil 2: Projektdurchführung und Ausblick
Im ersten Teil haben Sie erfahren, was es bei der Vorbereitung und Planung von Scrum in SAP-Projekten zu berücksichtigen gilt. In diesem abschließenden zweiten Teil zeigen Claus Kolb und Rüdiger Lühr, auf was das Scrum-Team bei der Projektdurchführung achten sollte. Zudem geben die Autoren einen Ausblick, wie sich der Einsatz von Scrum in SAP-Projekten weiter optimieren lässt.

Im ersten Teil haben Sie erfahren, wie der Scrum-Einsatz in SAP-Projekten aussehen kann und wie sich die Projektinitiierung sowie -planung durchführen lässt. Dieser zweite und abschließende Teil beleuchtet nun den Praxiseinsatz von Scrum während der Durchführungsphase und zeigt darüber hinaus, welche technischen und organisatorischen Strategien den Einsatz von Scrum in SAP-Projekten begünstigen.

Wir sprinten

Nachdem wir uns im Projekt ausführlich aufgewärmt hatten, waren wir bereit, den ersten Sprint zu starten.

Release-Plan des Projekts

Anhand der Betrachtungen im ersten Teil wird klar, dass eine vollständig flexible Änderung und Produktivsetzung nach jedem Sprint von beliebigen Objekten auch bei exklusivem Zugriff auf die Objekte in der beschriebenen SAP-Systemarchitektur nicht möglich ist. Im Projekt haben wir immer mehrere Sprints zu einem Release zusammengefasst. Je höher der Aufwand für die Produktivsetzung, desto weniger oft kann im Projekt ein Release live gestellt werden.

Im Projekt brachten wir insgesamt vier Releases heraus (Bild 1). Nach den ersten vier Sprints setzten wir das erste Release produktiv, wofür wir einen Stabilisierungssprint vorsahen, da wir an denselben Objekten weiterentwickelten. Anschließend vollzogen wir einen Objektwechsel, so dass wir für das Ausbringen des zweiten Releases auf einen Stabilisierungssprint verzichten konnten.

Bild 1: Release-Plan des Beispielprojekts.
Bild vergrößern

Die Änderungen in den Sprints 9 bis 14 waren recht kompliziert, so dass wir danach eine separate Testphase vor dem Release vorsahen. Deswegen verzichteten wir darauf, direkt nach Sprint 14 weiterzuarbeiten und führten stattdessen einen Stabilisierungssprint durch. Den Abschluss des Projekts bildete das Release 4, in welchem wir die Änderungen der Sprints 15 bis 18 produktiv setzten.

Laufende Pflege des Product Backlogs

In der Aufwärmphase hatten wir bereits so viele User Storys fertiggestellt, dass das Development Team für die ersten beiden Sprints genug zu tun hatte. Eine große Herausforderung war, die dafür benötigten Personen in ausreichendem Maße einbinden zu können. Insbesondere die Verfügbarkeit der drei Fachbereichsvertreter war kritisch, da diese auch noch durch andere

Anzeige
Der vollständige Artikel ist für Abonnenten frei zugänglich.
Artikel kaufen (4,50 €)
  • 12 Seiten Praxiswissen
  • PDF-Download
Kostenlos weiterlesen!
  • Diesen Beitrag kostenlos lesen
  • 4 Wochen Online-Zugriff auf alle Artikel, Methoden und das Glossar
Tech Link