News & Wissen Agiles Arbeiten gemäß SCRUM – und was es mit uns macht: Erfahrungsbericht aus einem SAP Application Lifecycle Management (ALM)-Team

Agilität ist in aller Munde. Agilität ist ein Megatrend. Alle machen jetzt einen auf agil. Mit einem agilen Projektansatz wird sicher alles gut! Doch was konkret bedeutet agiles Management von (SAP-)Projekten? Was konkret agiles Arbeiten gemäß SCRUM? Was macht diese Arbeitsweise mit uns als Menschen? Welchen Einfluss hat sie auf die Qualität von Arbeitsergebnissen?

Lesen Sie im Folgenden die Antworten hierauf aus einem Selbstversuch eines SAP ALM-Teams.

Auch SAP-Projekte können agil gemanagt werden. Womit agiles Arbeiten oftmals gleichgesetzt wird, geht aus einem Konzentrat an Erkenntnissen aus meinem Beratungsalltag hervor:

•  Ad-hoc-Arbeiten
• einem (hippen) Werkzeug/ Tool, das bestehende (oftmals ungeliebte) Tools ablöst
• einer Methode, die Schlupfwinkel bzw. Fluchtmöglichkeiten bietet (z.B. „keine Doku mehr!“)

Somit wird agiles schnell zu fragilem Arbeiten. Final eine nervenaufreibende Irrfahrt ins Ungewisse. Und im Falle eines (vorhersehbaren) Scheiterns oftmals abgelöst durch ein neues, viel besseres Mantra. DevOps ist ein bekanntes Beispiel.

Doch zurück zum Thema: Was bedeutet agiles Arbeiten konkret? Und was agiles Arbeiten nach SCRUM? Im Sinne eines besseren Verständnisses lernen Sie im Folgenden zentrale SCRUM Begrifflichkeiten in der Schnellübersicht kennen:

SCRUM-Rollen:

• Stakeholder (Kunde, Anwender, Management): gibt das Produkt in Auftrag und definiert dessen Anforderungen
• Product Owner: verantwortet das Product Backlog und steht mit dem Stakeholder sowie dem Entwicklungsteam in regelmäßigem Austausch zwecks Fertigstellung des Produkts hinsichtlich Budget, Qualität und Zeit (d.h. er verantwortet das „Was“)
• Entwicklungsteam: realisiert das Produkt und ist für die Qualität des Produkts verantwortlich (d.h. es verantwortet das „Wie“)
• Scrum Master: verantwortet die methodisch korrekte Implementierung sowie Einhaltung der durch SCRUM vorgegebenen Spielregeln

SCRUM-Prozess:

• generell: Der Produktentwicklungsprozess erfolgt iterativ, d.h. in Feedback-Schleifen von wenigen Wochen, den sogenannten Sprints
• Sprint: Entwicklungszeitraum für ein zuvor definiertes Inkrement/ Produkt bzw. dessen Fortschritt/ Zuwachs
• Sprint Backlog: Arbeitsvorrat für die Dauer eines Sprints (Ziel: Stabilität)
• Sprint Planning: Sprint-Planung von Product Owner und Entwicklungsteam auf Basis des durch den Product Owner zuvor priorisierten Product Backlogs
• Product Backlog: priorisierter Arbeitsvorrat für das Entwicklungsteam (Ziel: Dynamik)
• Sprint Review: erfolgt am Sprint-Ende vom Entwicklungsteam in Richtung Product Owner und Stakeholder (Fokus: Produkt bzw. dessen Verbesserung)
• Sprint Retrospektive: erfolgt im Anschluss an das Sprint Review durch das gesamte SCRUM-Team (Fokus: Prozess bzw. dessen Verbesserung)

Fragen Sie sich auch gerade, wie Sie diese Bausteine auf ein SAP-Projekt anwenden sollen? Dann sind Sie in bester Gesellschaft. Denn: SCRUM-Literatur gibt es zu Hauf. Die Herausforderung ist, das SCRUM-Framework – denn mehr ist es nicht – auf das SAP-Projektgeschäft bzw. das Management von SAP-Landschaften anzuwenden.

Um diese – zuweilen leidvolle – Erfahrung (auch) meinen Kollegen zuteil werden zu lassen, habe ich unser Team einem Selbstversuch unterzogen.
Und beim Stichwort Leid(en) sind wir dann auch schon bei einer Autorin angelangt, deren Arbeiten nicht nur Teil meiner mündlichen Abiturprüfung waren, sondern auch fundamentaler Baustein der gesamten Change Management-Literatur ist: Elisabeth Kübler-Ross. Ihr zentrales Werk: Interviews mit Sterbenden (1972), und damit dem Inbegriff von Leid(en) schlechthin. Hier beschreibt die Autorin fünf zentrale Sterbephasen.
Übertragen auf unseren Kontext: fünf Phasen, die jeder durchlebt, der eine unausweichliche Änderung - in unserem Falle ein Wechsel der Arbeitsweise auf agiles Arbeiten nach SCRUM – erfährt/ durchlebt:

1. Nicht-Wahrhaben-Wollen (Leugnen)
2. Zorn
3. Verhandeln
4. Depression
5. Annahme

Betrachtungsgegenstand bzw. Inkrement(e)/ Produkt unseres Selbstversuchs: ein sehr aufwändig zu realisierendes Kunden-Webinar. Dies vor dem Hintergrund, um in einem abgesicherten Umfeld Erfahrungen für (zukünftige) SAP-Projekte zu sammeln.

In Abwandlung an das SCRUM Framework war in unserem Fall der Product Owner Teil des Entwicklungsteams, um redundante Abstimmungen zu vermeiden. Der Product Owner stand in seiner herausgehobenen Rolle dem Entwicklungsteam vor und war zentraler Ansprechpartner für den Stakeholder, in unserem Falle der Webinar-Auftraggeber.

In Summe durchlebte das Team seinen Änderungsprozess wie folgt, die Auswirkungen auf unsere Inkremente bzw. unser finales Produkt inbegriffen:

Woche/ Sprint 1:

• Alles dabei: von Leugnen bis Depression
• gemündet in einem Krisen-Meeting („Uns drückt der Schuh“)
• Motto der Woche: „Findungsphase“

An dieser Stelle war gefühlt auf allen Seiten schon die Luft raus. Absoluter Tiefpunkt. Doch dann …

Woche/ Sprint 2:

• Stimmungswechsel in Richtung Annahme
• unterstützt durch sehr viel Kommunikation und Motivation
• Motto der Woche: „Umdenken“

Woche/ Sprint 3 & 4:

• absolute Annahme
• unterstützt durch sehr viel Kommunikation und Motivation
• Motto der Woche: „Rollenverständnis wächst“, „Das Arbeitsergebnis profitiert vom SCRUM-Vorgehen“

Woche/ Sprint 5 (inkl. Durchführung des Webinars):

• absolute Annahme
• unterstützt durch sehr viel Kommunikation und Motivation
• Mottos der Woche:

„Der Prozess wird innerhalb der Gruppe gelebt und jeder weiß in seiner Rolle, was er zu tun hat“

„Durch die ständige Optimierung des Produkts wurde das Ergebnis am Ende übertroffen“

Wenn Sie sich mit eigenen Augen und Ohren das Produkt bzw. dessen Qualität anschauen möchten. Nur zu! Machen Sie sich Ihr eigenes Bild:

Nur so viel möchte ich verraten: Beindruckend empfinde ich als Webinar-Auftraggeber (Stakeholder) nach wie vor die Geschwindigkeit, mit der das SCRUM-Team in Phase 5 angekommen ist, d.h. die Annahme des neuen Vorgehens vollzogen hat. In Summe eine Woche.

Einhergehend mit einer unglaublichen Dynamik innerhalb der Gruppe: Teambuilding in Reinform!

Und zuletzt die für mich sehr eindrucksvolle Performance der Gruppe sowie die Qualität des abgelieferten Produkts/ Arbeitsergebnisses.

Für mich eindeutig zurückzuführen auf die mittels SCRUM:

1. absolute Fokussierung auf das Produkt bzw. auf das dem Produkt übergeordnete Ziel,
2. kontinuierlich verbessert durch klar definierte Sprints und deren Reviews (Lerneffekte),
3. begleitet durch klar definierte Rollen (klare Verantwortlichkeiten)
4. sowie deren ständiger Kommunikation bzw. Austausch über das Produkt

Fazit:

SCRUM ist anstrengend, bringt einen zuweilen an seine Grenzen. Das Ergebnis ist in unserem Falle überwältigend: ein tolles Webinar mit 2,5-mal so vielen Teilnehmern als geplant.

Stand: 24. April 2020