Scrum hat eine weite Verbreitung in Java- oder .NET-Projekten gefunden. Aber funktioniert Scrum auch in SAP-Entwicklungsprojekten? Was ist anders, wenn man in SAP-Projekten nach Scrum entwickelt? Welche Herausforderungen stellen sich? Und warum ist bisher so wenig über konkrete SAP-Entwicklungsprojekte publiziert worden, die nach der Scrum-Methode durchgeführt wurden? Diese und weitere Fragen stellten sich dem Projektteam, als wir ein SAP-Entwicklungsprojekt nach Scrum in einem internationalen Konzern durchgeführt haben.

In diesem Projekt sind wir auf technische und organisatorische Herausforderungen gestoßen und haben daraufhin verschiedene Anpassungen an der Vorgehensweise vorgenommen. Insbesondere bei der Sprint- und Release-Planung waren die Besonderheiten des SAP-Systems und des Konzernumfelds zu berücksichtigen. Schlussendlich haben wir das Projekt erfolgreich beendet und die mit ihm verknüpften Ziele auch im Hinblick auf den Einsatz von Scrum erreicht.

Diese Erfahrungen schildert dieser zweiteilige Beitrag. Neben den konkreten Herausforderungen und unseren Lösungsstrategien beschreiben wir zudem, welche veränderten technischen, prozessualen und organisatorischen Rahmenbedingungen den Einsatz von Scrum in SAP-Entwicklungsprojekten vereinfachen. Der erste Teil zeigt, wie der Einsatz von Scrum die Initiierung und Planung des SAP-Praxisprojekts beeinflusste und welche Rolle die SAP-Systemlandschaft dabei spielte. Der zweite Teil widmet sich der Projektdurchführung und enthält über das konkrete Projekt hinaus weitergehende Überlegungen, wie sich der Einsatz von Scrum in SAP-Projekten weiter optimieren lässt.

Das Projekt

Das hier beschriebene Projekt wurde in einer Abteilung eines internationalen Konzerns durchgeführt, der insgesamt ca. 10.000 Mitarbeiter beschäftigt. Wir arbeiteten in einer Multiprojektumgebung mit parallel ca. 35 anderen Projekten im SAP-Umfeld.

Unser Projekt hatte zum Ziel, Prozesse für Kostenvoranschläge und Reparaturen weiterzuentwickeln und zu optimieren. Insbesondere sollte die Anzahl der in den eigenen Werkstätten erstellten Kostenvoranschläge reduziert werden, um Kosten zu sparen. Dazu wurde die auf Basis des SAP-Systems eigenentwickelte Prozessunterstützung erweitert bzw. modifiziert. Ich war dabei von Dienstleisterseite als Scrum Master Teil eines externen Teams tätig. Der Product Owner und die Vertreter des Fachbereichs waren fest beim Kunden angestellt.

Im Gegensatz zum im SAP-Bereich ansonsten üblichen Vorgehen nach Wasserfall wurde dieses Projekt nach der Scrum-Methode durchgeführt und war damit ein Pilotprojekt im Konzern. Der wichtigste Grund für den Einsatz von Scrum war, möglichst früh produktiv einsetzbare Ergebnisse zu erzeugen. Mit dem Vorgehen nach Wasserfall hätten wir erst nach ca. einem Jahr das erste Mal Ergebnisse ins Produktionssystem transportiert.

Darüber hinaus waren die folgenden Ziele mit dem Einsatz von Scrum verbunden:

• Verteilung eines begrenzten Budgets auf die Funktionen bzw. Optimierungen mit dem meisten Nutzen
• Sammeln von Erfahrungen mit Scrum in der SAP-Entwicklung
• Reduktion der Komplexität im Requirements Engineering durch Zerlegen der Anforderungen in User Storys

Warm-up: der Anfang

Scrum-Einführung und Projektinitiierung

Am Anfang des Projekts lag bereits ein Grobkonzept vor, auf dessen Basis die Beauftragung des Dienstleisters erfolgt war. Das Projektteam wurde für dieses Projekt neu zusammengestellt. Bevor wir allerdings damit beginnen konnten, die Software in Sprints zu entwickeln, schalteten wir eine ca. 8-wöchige Phase für die Projektinitiierung vor (s. Bild 1), auch Sprint 0 genannt. Denn da weder das Projektteam noch das organisatorische Umfeld über Erfahrung mit Scrum verfügten, musste die Scrum-Methode im Projektteam und in der Organisation zunächst eingeführt werden.

Bild 1: Vorgehensweise bei der Projektinitiierung.

Die Scrum-Einführung nahmen wir ebenfalls mit der Scrum-Methode vor (s. hierzu auch "Scrum mit Scrum im Unternehmen einführen", Projekt Magazin 16/2013). Dazu arbeiteten wir mit einem Kernteam in einwöchigen Sprints. Das Kernteam bestand aus einem Entwickler, dem Product Owner und mir als Scrum Master. Weitere Stakeholder, z.B. aus dem IT-Betrieb und dem Fachbereich, zogen wir bei Bedarf hinzu.