23 Jul

Story Splitting Techniken für Enterprise SAP Projekte

Monopoly Geld ist unser Value – Domain Vertreter kaufen Backlog Elemente

In unserem aktuellen agile Transition Team gehen wir auf die verschiedenen Business Divisions zu und binden diese in unsere agile Entwicklung ein. Die Vertreter der Division stoßen zu unserem Product Team als Domain Experten. Die Domains sind Distribution, Ordering, Pricing, Finance, Invoicing und 3 Produkt-Domains die jeweils durch einen Domain PO’s vertreten sind.

Oft haben die Vertreter aus den Business Divisions früher Anforderungen in großen Dokumenten beschrieben, welche sehr lang bearbeitet wurden und dann auch noch in lange Freigabeprozesse weitergereicht wurden. Diese großen Enterprise Prozesse betreffen mehrere Domains und müssen landesspezifisch auch rechtskonform sein.

#Priorisierung funktioniert auf dem Level dieser großen Anforderungen schlecht.

So haben sich Verhaltensweisen eingeschliffen: Wir müssen mit dem Prozess beginnen, welcher zuerst fertig spezifiziert ist und auch freigegeben wurde. Wenn kurz darauf eine andere große Anforderung freigegeben wird, muss das Team auch sofort mit der Umsetzung dieser beginnen. Es dauert ja sowieso schon so lange – also beginnt gleich.

Ergebnis – Das Team hat alles in Bearbeitung, aber es wird nichts fertig.

Mit der hohen Komplexität der Enterprise-Prozesse die in SAP abgebildet oder verändert werden ist dann auch verbunden:

#Story-Splitting hilft die kleinen wertschöpfenden Elemente aus den großen Prozessen zu finden und diese dann auch wirksam zu priorisieren. Dazu müssen diese großen Elemente aber wirksam zerteilt werden und dennoch in jedem Stück ein Kundennutzen erhalten bleiben. Die Skepsis bei den Stakeholdern dazu ist groß.

Unser Ansatz besteht zuerst einmal darin diese Bedenken ernst zu nehmen.

Über viele Jahre wurde das Verhalten geübt und belohnt. Wenn Deine Anforderungen größer, komplexer und teurer sind, diese aber dennoch umgesetzt werden hast Du mehr Macht.

Auch die Optimierung nach Effizienz hat das Verhalten begünstigt. Die Dienstleister sollte alles kostengünstig umsetzen. Also auch alle Systemkomponenten, Schnittstellen, Skripte nur einmal anfassen. Es sollte ja auch nur einmal der Aufwand für das Testen entstehen. Alles wurde in die Anforderungen hineingepackt – man wollte ja nichts vergessen und dann sollte das alles auch gleich mit gemacht werden.  

Praktisch nutzen wir die vorhandenen großen Anforderungsdokumente als Ausgangspunkt und gehen als Coaches mit den Domain Product Ownern und den SMEs (Special Matter Experts) aus den Ländergesellschaften in einen fachlichen Dialog. Wir hinterfragen den Sinn, arbeiten den Nutzen heraus und trennen die Anforderung (WAS) von der Vorgabe der technischen Realisierung (WIE).

So werden klarere, kleinere und wertschöpfende Dinge sichtbar. Dann sind es auch schon mehrere wertschöpfende Dinge. Statt alles „vom Prozess“ zu sehen fragen wir nach dem Nutzen. Wer hat durch die Umsetzung wann wieviel Nutzen?

Tooling halten wir von den Gesprächspartnern fern. Wir nutzen kleine formlose Word-Dokumente ohne Struktur, Karten, Flipcharts, Bilder und ähnliches. Die wertvolle Zeit mit den wirklichen fachlichen Experten stecken wir in die Gespräche (personal interactions) statt in Arbeitsabläufe oder Tool-Diskussionen.

Fragetechniken für das Splitting

  • Für wen entsteht Nutzen?
    • Gibt es unterschiedliche Nutzer? Oder Nutzergruppen?
    • Machen alle das gleiche?
    • Gibt es Experten-/ Profi Nutzer und Gelegenheits-Nutzer?
    • Gibt es Länder oder Regionen welche die Funktion nicht benötigen?
  • Gibt es „Brot und Butter“ Fälle und Sonderfälle?
    • Was ist der Standard-Fall des Prozesses?
    • Welche unterschiedlichen Sonderfälle gibt es?
    • Wie oft kommen diese in welchen Ländern vor?
    • Kann die Performance für Sonderfälle erstmal schlechter sein?
  • Auf welchen Endgeräten entsteht der Nutzen?
    • Am Arbeitsplatz-PC?
    • Tablet/ Mobile Geräte im Außendienst?
    • Kunden-Terminals oder Point of Sales?
  • Werden für einen Prozess-Ablauf alle Daten und Systeme benötigt?
    • Gibt es Varianten wo nur bestimmte Daten benötigt werden?
    • Gibt es Prozesse-Varianten bei denen andere System nicht eingebunden sind?
    • Können bestimmte Teile (erstmal) manuell gemacht werden?
  • Gibt es bestimmte Risiken in einem Bereich?
    • Haben einige Schritte im Prozess einen hohen Einfluss auf Kosten-Risiken?
    • Gibt es technische Schritte, welche wir das erste Mal machen müssen?
    • Gibt es Schritte, bei denen wir kein fachliches Wissen haben?
    • Heben uns manche Schritte vom Wettbewerb ab? (Differentiators)
  • Rechtliche oder Finanzielle Compliance
    • Welche Schritte sind für sich Compliance relevant?
    • Welche Ergebnisse/ Dokumente oä. sind es?
    • Wer prüft diese Compliance wann?
    • Was sind die Kosten der Verletzung?  

Diese Fragen setzen wir aber nicht strikt nach Kochrezept oder gar in einer Reihenfolge ein, sondern fragen situativ und skizzieren dabei die Teile des Ganzen visuell für alle sichtbar mit. Nach einigen praktischen Übungen kommen die Ideen zum Teilen von den Teilnehmern selbst.

Im Ergebnis haben wir aus einem komplexen zusammenhängenden Lastenheft viele für sich nutzbringende Teile gemacht. Diese bringen wir auf Karten.

Jetzt bekommt jeder Domain Product Owner im Verhältnis des Budgets einen Stapel Monopoly Geld. Mit diesem Budget können jetzt Karten gekauft werden. Das Geld wird mit Büro-Klammern an die Karte geklammert. Das repräsentiert den Wert der Karte. Ein hoher Wert bringt die Karte „nach vorn“. Da Monopoly Geld verschiedene Farben hat können die Teilnehmer die Werte im Anschluss auch noch korrigieren, wenn jeder weiß was „sein“ Geld war.

Die Teilnehmer sehen, dass eine Verteilung des Budgets auf viele Elemente nicht zum gewünschten Erfolg führt. Sie entscheiden sich daher zunehmend für das „Pushen“ einiger weniger Karten. Wir bekommen unseren Backlog.

Im Anschluss bringen wir Moderatoren die Karten in’s Jira und das Geld wird zu Value Einheiten und der Value schiebt die Elemente auf „Ihre“ Positionen auf dem Board. Ohne Schulungen in Anforderungsmanagement für alle kommen wir so schnell und zuverlässig zu kleinen werthaltigen Elementen und können #DevOps machen. Wir treiben die #Transformation ohne groß über den Prozess oder die Methodik zu sprechen.

Sources and references

Eine Übersicht von Splitting Techniken und Fragestellungen gibt es bei Agile For All als PDF zum download. Dort gibt es auch einen einen englisch sprachigen Blog Artikel aus dem Jahr 2012 von Richard Lawrence “How to Split a User Story

Leave A Reply

Your email address will not be published. Required fields are marked *