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.
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 Projekte und vom Tagesgeschäft in Anspruch genommen wurden.

Darüber hinaus waren wir von diesen Fachbereichsvertretern auch räumlich getrennt, da wir in verschiedenen Gebäuden auf dem Firmengelände untergebracht waren. Scrum sieht idealtypisch eine enge räumliche Nähe der Projektbeteiligten vor, die bei uns nur beim Scrum Team (Entwickler, Product Owner, Scrum Master) gegeben war.

Fachbereichsvertreter "reservieren"

Um die Anforderungen aufzunehmen und zu dokumentieren, arbeitete der Product Owner mit jeweils einem zentralen Fachbereichsvertreter pro Fachbereich zusammen (s. auch Teil 1, Projektorganisation). Meist waren pro User Story mehrere dieser Fachbereichsvertreter zu involvieren. Zusätzlich mussten die Fachbereichsvertreter die Anforderungen innerhalb ihres Fachbereichs klären. Der Product Owner aggregierte dann die Informationen in Form von Epics und User Storys.

Verglichen mit dem Wasserfallmodell wird in Scrum das Lastenheft während der Projektarbeit "just-in-time" generiert. Vor Beginn jedes Sprints müssen ausreichend User Storys vorliegen, die bereit sind für die Implementierung – mindestens jedoch für einen Sprint. Anzustreben ist ein Vorrat für zwei bis drei Sprints. Die Arbeit mit User Storys verlangte sowohl bei der Konzeption als auch bei der Realisierung kurzfristiges Feedback von den Fachbereichsvertretern.

Um der o.g. Herausforderung der knappen Verfügbarkeit der Fachbereichsvertreter zu begegnen, haben wir diese für zwei Vormittage pro Woche für das Projekt reserviert. Insbesondere wegen der fehlenden räumlichen Nähe und der hohen Auslastung der Fachbereichsvertreter haben wir eine Reihe von Meetings mit festen geblockten Serienterminen (s. Bild 2) vorgesehen. Natürlich waren darüber hinaus auch jederzeit Telefonate oder kurzfristig anberaumte Treffen möglich.

Bild 2: Pflege des Product Backlogs mit Hilfe von Meetings.
Bild vergrößern

Bewertungen und Kommentare

(nur angemeldete Benutzer)

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
Gesamt
Bewertungen 1

Fortsetzungen des Fachartikels

Teil 1:
Projektinitiierung und Planung
Für IT-Projekte bringt die Scrum-Methodik viele Vorteile, der Einsatz in SAP-Entwicklungsprojekten scheint daher naheliegend. Doch in der Praxis bestehen hier einige Herausforderungen. So birgt z.B. die Arbeit an SAP-Objekten gewisse Tücken, die …
Alle anzeigen