Migration eines Artikelstamms nach SAP-Retail

Ein Erfahrungsbericht von Martin Künkele 

Die Ausgangssituation

Für einen Großhandelskonzern sollte der Artikelstamm aus einem Legacy-System nach SAP-Retail überführt werden, unter Einsatz agiler Methoden. Für die Migration wurden SAP-Entwickler engagiert und auf drei Development Teams mit je sieben Mitgliedern aufgeteilt. Für zwei Scrum Teams war ich als Scrum Master verantwortlich, das dritte Team wurde von Michael, einem fest angestellten Scrum Master, geführt.

Den ersten Kontakt mit den Teammitgliedern hatte ich während der Retrospektive für den Sprint 8. Dieser war der letzte Sprint in alter Besetzung. Bis dahin hatte Michael das bisherige Team, bestehend aus sechs Mitgliedern, geführt.

Von den neu hinzugekommenen Entwicklern hatte noch keiner agil gearbeitet. Von Scrum hatte der eine oder andere schon mal etwas gehört, aber noch nie praktisch damit zu tun gehabt.

Meine wichtigste Aufgabe zu Beginn war deshalb, Scrum einzuführen. Ich erläuterte zunächst die tragenden Säulen von Scrum: Transparenz, Selbst-Organisation, Reflexion und ständige Verbesserung (Inspect and Adapt).

Scrum in der Praxis

Die drei Teams führten nun gemeinsam das nächste Sprint Planning durch. Michael demonstrierte, wie die Kapazität der Teams ermittelt wurde, unter Berücksichtigung der Urlaubsplanung der einzelnen Teammitglieder und der Zeiten für Support und sogenannte Spikes. Diese dienen dazu, neue Erkenntnisse zu gewinnen. Die dafür eingeplante Zeit wird vom Team genutzt, um das erforderliche Know-how aufzubauen, z. B. wie ein bestimmtes Software-Werkzeug verwendet werden kann. Die Spikes wurden in Personentagen taxiert, wohingegen die Bearbeitungszeit für die User Stories auf der Grundlage von Storypoints eingeplant wurde.

Mit der Vergabe von Storypoints wird der Aufwand zur Bearbeitung einer User Story geschätzt: Man geht von ihrer Komplexität aus, und zwar im relativen Vergleich zu den anderen User Stories, und berücksichtigt dabei die vorhandenen Ressourcen des Teams. Das Ergebnis ist wird als Zahl (= Storypoints) festgehalten und jeder User Story angehängt.

In diesen Sprint Plannings ging es sehr lebhaft zu, weil es große Unterschiede gab im Hinblick auf die Beurteilung der Leistungsfähigkeit der Teammitglieder und der Erwartung an die einzelnen Teams.

Die Bedeutung der Transparenz

Der Grund für die auftretenden Differenzen lag in der Aufgabenstellung für die beiden Product Owner von Team 1 und Team 2. Sie waren klassisch geschulte Projektleiter, die sich auf ein Problem fokussierten, und deren einziges Ziel die schnellstmögliche Lösung dieses Problems war. Es ging vornehmlich um die Verteilung der User Stories auf die einzelnen Teams. Die Projektleiter schätzten die Leistungsfähigkeit der Teams nicht nach ihren Besonderheiten ein: die unterschiedlichen Skills und die zuvor gesammelte Erfahrung.

Zu Beginn des Projektes fanden noch Refinement I Meetings statt, in denen die Verteilung der User Stories auf die einzelnen Teams diskutiert und durchgeführt wurde. Diese Treffen wurden leider von den Projektleitern als überflüssig angesehen und nach und nach eingestellt. Das Ergebnis: Zwei Teams begannen sich mehr und mehr zu spezialisieren, die dritte Mannschaft bekam folglich nur noch die User Stories zugeteilt, die nicht von den anderen Scrum Teams bearbeitet werden sollten. Als Scrum Master muss ich im Rückblick sagen, dass ich hier frühzeitig hätte intervenieren müssen.

Gleich im Anschluss an das Refinement Meeting wurde das Sprint Planning I durchgeführt. Zentral bei diesem Treffen ist immer das sogenannte Commitment des Teams: Die Mitglieder geben an, was sie konkret während des anstehenden Sprints leisten werden. Sie benennen möglichst exakt Inhalt und Umfang ihrer Arbeit. Dies ist der Scope des Sprints. Wichtig dabei ist, dass sie realistisch einschätzen, was sie leisten können.

Danach führten die Teams selbst-organisiert das Planning II durch, jedes Team für sich. Während dieser Meetings wurden die User Stories in Tasks aufgeteilt. Für jeden Task wurde ein Post-it an das Task Board in die Spalte 'To Do' gepinnt. Die Tasks durchliefen verschiedene Status, beginnend mit der 'Analyse', über 'Implementierung', 'Test', 'Dokumentation' und 'Review'. Nachdem alle Tasks in der Spalte 'Review' angelangt waren, wurde die User Story in die Spalte 'abgenommen' gehängt.

Mit dieser Vorgehensweise konnte jedem Mitglied transparent vermittelt werden, an welcher User Story im aktuellen Sprint gearbeitet wurde.

Die einzelnen Tasks in den jeweiligen Spalten wurden aufaddiert und die Werte in das Burndown Chart eingetragen. Das schaffte zusätzliche Transparenz über den Fortschritt der Implementierung der User Stories.

Während der Retrospektive am Ende eines jeden Sprints wurde darüber gesprochen, was während der letzten zwei Wochen als verbesserungswürdig erkannt wurde.

Aufgrund der Transparenz der Task Boards für alle Stakeholder war es auch für die Projektleitung einfach, sich zu jedem Zeitpunkt einen Überblick über den Fortschritt zu verschaffen.

Zum erfolgreichen Abschluss des Projektes wurden die Teams vom Vorstand des Konzerns eingeladen. Es gab ja schließlich etwas zu feiern!