27. Wasserfall oder Agil, oder beides: Hybrid? Ein kleiner Ausflug in die Methodendiskussion

Zusammenfassung: Der Blog-Beitrag „Wasserfall oder Agil, oder beides: Hybrid?“ diskutiert die Vor- und Nachteile der Wasserfall- und Agilen Methoden und wie Unternehmen von einer Kombination aus beiden, also einer Hybrid-Methode, profitieren können. Es wird empfohlen, dass Unternehmen ihre Arbeitsweise an ihre individuellen Bedürfnisse anpassen und flexibel bleiben, um erfolgreich zu sein.

 

Es erstaunt mich, dass ich zurzeit viele Anfragen für S/4HANA Projekte bekomme, in denen die Frage gestellt wird, ob ich SAP Activate „kann“. Aus meiner Sicht ist dies die vollkommen falsche Fragestellung. Richtig wäre es zu Fragen, ob ich genügend Methodenwissen habe, um in einer spezifischen Situation in einem Projekt S/4HANA effizient und sicher und gemäß den Vorgaben der Unternehmensleitung einzuführen.

 

Methoden und Werkzeuge

Hintergrund ist hierbei, dass ich schon zu Anfang meiner Karriere als SAP Berater das Glück hatte, bei meinen ersten Projekten sowohl der falschen als auch der richtigen Anwendung von Methoden und Werkzeugen beiwohnen zu dürfen. Das Learning daraus war: Die unreflektierte strikte Anwendung einer bestimmten Methode in allen Situationen ist ineffizient und führt in der Regel zu keinen guten Ergebnissen, aber vielen Frustrationen. Richtiger ist es vielmehr, aus dem Baukasten der unterschiedlichen Methoden und Werkzeugen den richtigen Mix für die spezifische Projektaufgabe zu bestimmen, klare Regeln aufzustellen und sicherzustellen, dass alles vom Projektteam verstanden, getragen und befolgt wird, weil alle den jeweiligen Sinn verstanden haben. Hierzu bedarf es einerseits einer breiten Kenntnis und Erfahrung mit den unterschiedlichen zur Verfügung stehenden Methoden und Werkzeugen seitens der dafür verantwortlichen Projektleitung und andererseits auch den Mut – stellenweise begründet – neue Wege zu gehen.

Als ich zum Beispiel in der von mir geleiteten S/4HANA Einführung mitgeteilt bekam, dass es der Wunsch der dafür im Unternehmen Verantwortlichen ist, in dem Projekt schwerpunktmäßig agil zu arbeiten, weil diese Form der Arbeitsweise künftig breiter in dem Unternehmen kultiviert werden soll, sind wir in der Projektleitung dem gern nachgekommen. In dem Zusammenhang habe ich mich mit den seinerzeit zur Verfügung stehenden Inhalten von SAP Activate beschäftigt und festgestellt, dass dies zwar als „agile Vorgehensweise“ für die Einführung von S/4HANA durch die SAP lanciert wurde, aber schlussendlich im Wesentlichen „alter Wein in neuen Schläuchen“ mit agilem Anstrich war. Allerdings erschien mir die Gesamtdokumentation weder vollständig, noch war konsequent agiles Vorgehen, so wie es z.B. in SCRUM – der wohl verbreitetsten agilen Methodik – beschrieben ist, klar ausgeprägt. Wir haben dem Wunsch nach einem agilen Vorgehen trotzdem entsprochen, die wesentlichen Projektakteure im Rahmen von Inhouse-Schulungen fit gemacht und das Projekt in den wesentlichen Phasen SCRUM folgend durchgeführt. In den wesentlichen Phasen deshalb, weil wir festgestellt haben, dass agiles Vorgehen nicht in allen Phasen und Aufgabenbereichen die sinnvollste Vorgehensweise ist, um das Projekt insgesamt sicher in trockene Tücher zu bringen. Also schlussendlich scheint ein hybrides Vorgehen das sinnvollste zu sein.

 

Die agile Vorgehensweise – und ich lege hier das Regelwerk von SCRUM und SAFe zugrunde – hat aus meiner Erfahrung in der Scoping und Prototyping-Phase klare Vorteile und dies sind insbesondere, dass:

• das Business durch die Übernahme der Product-Owner und Business-Owner Rollen klar in den Driver-Seat kommt und klar definierte Aufgaben und Verantwortlichkeiten bei der Spezifikation und Abnahme von Artefakten und Inkrementen hat

• in den User-Stories wird nicht nur dokumentiert, welchen Funktionen das Business benötigt, sondern es muss auch angegeben werden, was sie damit bewirken wollen (dies ist für mich vor allem in Greenfield sowie auch in Bluefield-Projekten ein gutes Argument und Vorgehen, um historisch gewachsene Funktionen und Prozesse kritische zu hinterfragen und so zu bereinigen; außerdem kann anhand der bezweckten Wirkung auch geprüft werden, ob diese mit anderen als den offensichtlichen Mitteln im SAP Standard bewirkt werden kann)

• die Ressourcennutzung in den eigenverantwortlichen SCRUM Teams in diesen eher kreativen Phasen deutlich effektiver erfolgen kann

• es in der Verantwortung des Business ist, die einzelnen User-Stories zu priorisieren und somit auch zu entscheiden, was aufgrund von zeitlichen oder Ressourcen-Restriktionen ggfs. auf ein Folgeprojekt vertagt werden muss

• last but not least die Projektleitung deutlich entlastet wird, da sich die SCRUM Teams unter der Führung der SCRUM Master selbst organisieren und managen (bis hin zur Urlaubsplanung etc.)

 

Was sind die Herausforderungen und wie können diese adressiert werden?

• Es muss bei allen Akteuren ein klares Verständnis hinsichtlich der Rollen und Vorgehensweise vorhanden sein -> hierzu empfehle ich eine mehrtägige Inhouse-Schulung, wie sie viele SCRUM-Trainer anbieten; Ferner sollten die ersten SCRUM Review-Sessions von dem SCRUM Trainer begleitet und gecoacht werden

• Man benötigt engagierte, empathische und strukturierte SCRUM Master in allem SCRUM-Teams -> hierfür kann man entweder eigene Mitarbeiter als SCRUM-Master ausbilden und zertifizieren lassen oder auch übergangsweise externe SCRUM-Master engagieren

• Aufgrund der normalerweise sehr großen Funktionsbreite von SAP Projekten wird man in der Regel mehrere SCRUM-Teams mit eigenen Product- und Business-Ownern, Scrum-Mastern und Delivery Teams benötigen; da Integration im SAP ein Kernthema ist, müssen diese übergreifend gesteuert werden -> hierzu bietet es sich an eine agile   Methode, wie z.B. Scaled Agile Framework, kurz SAFe einzusetzen und so die Inhalte der einzelnen Sprints unter Berücksichtigung der integrativen Abhängigkeiten übergreifend zu takten; eine Hilfestellung kann hierbei bieten, wenn man die zu einem Thema gehörenden User-Stories in Kapitel (z.B. EPICS, auch wenn diese gemäß SCRUM nicht genau dafür vorgesehen sind) zusammenbindet und diese im Rahmen von Program-Inkrement Planungsmeetings mit allen SCRUM-Teams übergreifend in der Sprintplanung adressiert. Eine gute Alternative zur Anwendung von SAFe kann in Umgebungen, in denen das Projektteam schon fundierte SCRUM Erfahrungen hat, der Einsatz von NEXUS sein, ein Vorgehen, in dem es dedizierte Integrationsrollen gibt.

• Häufig ist den Product- und Business-Ownern nicht klar, hinter welchen User-Stories sich welche Realisierungs- und Abstimmungsaufwände verbergen können, so sind manche komplex anmutende Punkte in der SAP Konfiguration mit einem Mausklick zu erledigen, während vermeintliche Lappalien einen großen Aufwand nach sich ziehen können -> In dem Kontext ist es wichtig, zum einen die Backlog-Refinement Meetings konsequent und mit genügend zeitlichem Raum durchzuführen und andererseits konsequent eine Bewertung der User-Stories mit Story Points durchzuführen, um dann zum einen die Velocity der einzelnen Sprints ermitteln zu können und zum anderen einen realistischen Blick auf das leistbare im Team zu bekommen. (s. auch S. Burkart: „Warum klein nicht immer richtig ist, als Einstieg in seinen YouTube Kanal: https://youtu.be/BYd7ZuZ_W8c )

• Ein weiteres Problem ist die Vollständigkeit der Anforderungen (s. auch R. Wanner: „Anforderungsmanagement bei agilen Projekten und Scrum erfolgreich anwenden“), da aufgrund des hohen Integrationsgrades es für das Business nicht offensichtlich ist, für welche Themenbereiche User-Stories zu erstellen sind, um ein komplettes Bild zu zeichnen -> hier kann ein Vorgehen nach SCRUM 3.0 (von Boris Gloger) Abhilfe, gemäß dem es zulässig ist, dass sich auch das gesamte Development Team an der Erstellung der User-Stories beteiligt und so die bestehenden Lücken schließt

• Wir haben die Erfahrung gemacht, dass die alleinige Dokumentation der Anforderungen und Lösungen in Produkt- und Sprintbacklog nicht zu einer für alle verständlichen Sicht auf die künftige Lösung führt -> Hier kann die Erstellung eines Business Blueprint, in dem zu Beginn der wesentliche Rahmen (Org.-Einheiten, Kernprozesse, sowie Nutzung wesentlicher Stammdaten und Funktionen) festgehalten werden und dann begleitend zu den Sprints aktualisiert und komplettiert werden, um dann am Ende der Scoping- und Prototyping-Phase mit zur Gesamtabnahme des getesteten Prototypen herangezogen werden zu können.

• Die DOR (Definition of Ready) und DOD (Definiton of Done) müssen den Spezifika einer SAP-Einführung Rechnung tragen -> dazu hier ein Projektbeispiel:

Definition of Ready (DoR)

Definition of Ready für Product-Backlog-Einträge, damit sind in einen Sprint eingeplant werden können

• User Story ist komplett ausformuliert (Representing function X, I need functionality Y in order to achieve benefit Z)

• Der Stakeholder des Backlog Eintrages ist klar

• Es gibt mindestens ein Acceptance Kriterium

• Alle Acceptance Kriterien sind scharf und möglichst messbar formuliert und vom Development Team verstanden

• Das Development Team hat keine weiteren Fragen mehr zur zu liefernden Funktionalität

• Integrative Fragestellungen mit anderen Teams sind identifiziert und abgestimmt

• Das Dev. Team ist in der Lage die Story-Points für den PBL-Eintrag zu schätzen

 

Definition of Done (DoD)

Definition der Elemente, die abgeschlossen/abgehakt sein müssen, damit ein Product-Backlog-Eintrag vom Product Owner auf den Status „Abgeschlossen“ gesetzt wird

• Prozessablauf basierend auf realen Daten ohne Fehler in Unit-Test Mandanten und vollständig dokumentiert im Testskript (s. auch BLOG 19) und im zentralen Verzeichnis abgelegt

• Prozessdurchlauf wurde von Product Owner & Stakeholdern akzeptiert
  • Fehlende Funktionen wurden als Product Backlog Item erfasst

• Alle Bus. Blueprint Deliverables wurden erstellt:
  • Prozesse, Funktionen und Rollen wurden im BPM spezifiziert (z.B: basierend auf den SAP BP BPMN2 uploads), sofern ein e2e Prozess fertiggestellt wurde, respektive ein Teil-Prozessablauf betroffen ist
  • Notwendiger Datenaustausch mit Nicht-S/4HANA Systemen wurde identifiziert und dokumentiert
    • Verbindung und Informationsfluss (auf Objektlevel) zwischen den Systemen wurde in dokumentiert
    • Funktionale Spezifikationen (Informationsaustausch (Inhalt und Trigger-/Zeitpunkt) wurden für in- und outbound Schnittstellen definiert und in SAP PO (früher PI) gespeichert
    • Feldinhalte aller benötigten Masterdatenfelder, die in diesem Prozess notwendig sind, wurden identifiziert und vom MDM-Team bestätigt und dokumentiert gemäss den Regeln, die Master Data Management definiert hat
  • Funktionale Spezifikationen wurden für die Entwicklung von Forms erstellt, im zentralen Verzeichnis abgelegt und mit der Change No in SolMan-CHarM verlinkt
  • Funktionale Spezifikationen wurden für die Entwicklung von Erweiterungen und Add-Ons erstellt, im zentralen Verzeichnis abgelegt und mit der Change No in SolMan-CHarM verlinkt
  • Alle betreffenden Prozessschritte in S/4HANA (jede Zeile des Testskripts) wurden im Autorentool aufgezeichnet und referenzieren auf den entsprechenden Prozess in BPM
  • Alle benötigten organisatorischen Änderungen wurden identifiziert und im Organizational Change Management-Log notiert

• Alle durchgeführten Konfigurationen wurden komplett in Übereinstimmung mit den Guidelines im IMG des Entwicklungsmandanten dokumentiert

• Alle vom SCRUM Team getroffenen Entscheidungen wurden in den Meeting-Minutes (siehe auch https://sapxp.ch/meeting-minutes-xlsx/ ) notiert

• Alle Lücken, die nicht im SAP Standard gelöst werden können, wurden im Hold-Basket notiert und dem SAP-Verantwortlichen zugewiesen

• ACHTUNG: Wenn die fehlenden DoD Deliverables komplett in neuen Product Backlog Einträgen aufgenommen wurden, kann der ausgeführte auf «Completed» gesetzt werden

In einer Brownfield S/4HANA Migration würde ich in der Scoping/Prototyping-Phase nicht agil vorgehen, dort kann agiles Vorgehen meiner Meinung nach nicht sinnvoll angewendet werden, sondern würde vielmehr dazu verleiten, von dem vorgegebenen Ansatz abzuweichen, weil die Kreativität ja in einem agilen Vorgehen gefördert wird. Auch lässt sich das SCRUM Regelwerk nicht oder nur beschwerlich konsequent auf eine 1:1 Übertragung heutiger Prozesse und Funktionen anwenden.

Auch kann ich mir agiles Vorgehen ich in den Phasen Projektvorbereitung, Realisierung und Implementierung nicht wirklich sinnvoll angewendet vorstellen, in der Realisierung und Implementierung geht es ja darum die in der agilen Scoping/Prototyping-Phase erstellten Anforderungen zu komplettieren und fertigzustellen. Hier erscheint mir der klassische Wasserfall-Ansatz, so wie wir ihn aus dem Accelerated SAP (ASAP) kennen, deutlich sinnvoller – Ablaufpläne für die entsprechenden Phase finden Sie zum Beispiel bei uns zum Download https://sapxp.ch/asap-ms-project-plans-digistore24/ .

Für eine Übersicht über die Unterschiede der unterschiedlichen Vorgehensweisen empfehle ich: https://www.theprojectgroup.com/data/Downloads_Content_Upgrades/CU5D_Agile_Klassisch_Hybrid_-_TPG_TheProjectGroup.pdf

 

Fazit

Zusammenfassend würde ich aufgrund meiner bisherigen Erfahrungen nur in Greenfield und Bluefield S/4HANA Implementierung in der Phase Scoping/Prototyping ein agiles Vorgehen zugrunde legen, allerdings begleitend einen Business-Blueprint erstellen und ansonsten Wasserfall-basiert arbeiten, also ein sogenanntes Hybrid Vorgehen anwenden.

In einer Brownfield S/4HANA Migration würde ich ausschließlich ein Wasserfall-basiertes Vorgehen anwenden.