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.