Scope Management sollte möglichst frühes Feedback ermöglichen. Heute will ich das am Beispiel der Einführung eines Warenwirtschafts-Systems erläutern. Wir betrachten die Filialversorgung, genauer das Replenishment (d.h. der Nachschub für die verkauften Artikel) aus dem Zentrallager. Statt in einem Big Bang alles auf das neue System umzustellen (und dann im Panik-Modus die neuen Probleme zu beheben), schlagen wir folgende Salamitaktik vor:

Wir schaffen die Möglichkeit, für die Vertriebs-Organisation auf allen untergeordneten Ebenen(!) festzulegen, ob mit dem alten oder mit dem neuen System bearbeitet werden soll. Konkret bedeutet es in unserem Beispiel, dass innerhalb einer Vertriebsorganisation erst einzelne Filialen, dann Regionen und zuletzt Länder nacheinander auf das neue System aufgeschaltet werden.

Auf der IT-Seite heißt das: wir starten mit dem alten Warenwirtschafts-System als “Master”, d.h. es enthält “die Wahrheit” über alle Filialen auf der Welt. Das neue System macht seine eigenen Operationen und schreibt parallel dazu in das alte System. Damit kann jeweils eine Filiale im neuen System bearbeitet werden, ohne dass andere Systeme darauf Rücksicht nehmen müssen.

Auf der physikalischen Seite heißt das: Ein gelber Aufkleber (o.ä.) zeigt an, dass dieser Filialnachschub aus dem neuen System generiert wurde. Dann können die MitarbeiterInnen diesen Filialnachschub gesondert behandeln, oder noch einmal überprüfen, ob alles OK ist.

Wie gesagt: Wir können das für jede einzelne Filiale entscheiden und diese Entscheidung auch wieder korrigieren. Jetzt strukturieren wir den Scope so, dass wir möglichst früh eine einzelne Filiale durch das neue System schicken können.

Das heisst, am Anfang wird das neue System nur den einfachsten Fall verarbeiten können: Filiale im Inland, einheitlicher Umsatzsteuersatz, Standardware (kein Cross-Docking oder Direktanlieferung), normale Lieferzeit, ein Versand-Dienstleister.

Weil es nur eine Filiale ist, können wir den Filialnachschub “per Hand” verfolgen und verifizieren, ob alles korrekt gelaufen ist. Wir können auch vergleichen: steht im neuen System das gleiche wie im alten? Oder haben wir was vergessen? Wenn es Probleme gibt: macht nichts, man kann sie leicht manuell beheben, weil nur eine oder wenige Filialen betroffen sind.

Falls es ernsthafte Probleme mit der neuen Software gibt: der Betrieb kann unterdessen mit dem alten System einfach weiterlaufen. Wir vergeben eine Zeit lang einfach keine gelben Aufkleber, und sobald der Showstopper behoben ist, leiten wir wieder Filialen auf das neue System.

So können wir das neue System schrittweise ausdehnen. Die Kriterien bleiben erstmal gleich (also nur die einfachsten Fälle), aber wir erhöhen die Anzahl an Filialen:

• jetzt nehmen wir 10 weitere Filialen dazu
• dann eine ganze Region,
• dann ein ganzes Land

Erfahrungsgemäß werden sich neue Probleme oder Sonderfälle zeigen, wenn mehr Filialen verarbeitet werden. Sobald ein Problem auftaucht, stoppen wir die Vergabe von neuen gelben Aufklebern. Das Problem wird sofort behoben, dafür darf auch gern ein oder sogar mehrere Entwickler im stand-by sein. Beheben heißt hier nicht, einen Hotfix einspielen, sondern solide arbeiten: einen automatischen Test schreiben, ggf. Unit Tests anpassen usw.

Wenn wir eine Zeit lang alle “einfachen” Filialnachschübe für die Filialen erfolgreich bearbeitet haben, erweitern wir die Funktionalität. Vielleicht nehmen wir Express-Sendungen als nächstes, oder einen weiteren Versanddienstleister oder Direktanlieferungen.

Es gibt mit dieser Strategie keinen “Big Bang” mehr, denn wir haben jederzeit die Möglichkeit, auf das alte System zurückzufallen. Erst wenn wir das neue System zum Mastersystem machen, haben wir einen “Point of No Return”. Und auch das könnten wir noch zerlegen: ab 1.6. ist das Neue das Mastersystem für alle Filialen einer einfachen Auslandstochter, der meist deutlich größere Anteil der Inlandsfilialen läuft noch über das alte. Bis dahin können wir jeden Fehler abfangen, indem wir auf das alte System zurückfallen.

Diese Vorgehensweise hat zahlreiche Vorteile:

• Wir müssen nicht mehr alles zu Anfang spezifizieren. Testfälle, Code usw. muss zunächst nur für den einfachen Fall gemacht werden.
• Kleinere Stapel (weniger WIP): wir machen diese Sorte Filialen erstmal ganz fertig, so dass sie im Produktivbetrieb reibungslos funktioniert.
• Feedback wird viel schneller (die allgemeine Folge von kleineren Stapeln), falsche Grundannahmen u.ä. Probleme werden frühzeitig entdeckt.
• Es gibt echtes Feedback, nicht “der Testfall 73 funktioniert”, sondern: diese 20 Filialen sind ohne Probleme abgearbeitet worden. Aus den echten Sendungen lernen wir, welche Sonderfälle wir vergessen haben.
• Entwicklung und Fachabteilung können sich besser fokussieren: es geht im Moment nur darum, die nächste Art von Filialen bearbeiten zu können. Für alles andere machen wir Spezifikationen, Testfälle usw. später – just in time.
• Fachabteilung und Entwicklung kommen nicht umhin, enger zusammen zu arbeiten
• Fortschritt lässt sich leicht messen: Wieviel Prozent der Filialen werden über das neue System bearbeitet?
• Prognose bzw. Zielvorgabe lässt sich einfach machen. Beispielsweise: “Jeden Monat soll sich der Anteil Filialen, die mit dem Altsystem gemacht werden müssen, halbieren.” Nach 6 Monaten sind es nur noch 1/64, also ca. zwei Prozent. Damit sind wir vielleicht schon in dem Bereich, wo Sonderfälle sowieso händisch bearbeitet werden.
• Der Verbrauch an Ressourcen für das Projekt läuft einigermaßen parallel(?) zum Nutzen: Wir sammeln den größten Nutzen zuerst ein, indem wir häufige Fälle zuerst behandeln. Vielleicht wollen wir auch erstmal die leichtesten 1% der Filialnachschübe bearbeiten, um überhaupt ein End-to-end funktionierendes System zu haben.
• Wir geraten nicht mehr in die Falle: das alte System ist abgeschaltet, das neue hat schwerwiegende Fehler, jetzt sind wir wochenlang im Feuerlöschmodus, um das einigermaßen zu stabilisieren.

Wir haben gewissermaßen den Rollout in kleine Salamischeiben geschnitten, und diese Scheiben sind auch noch leicht rückgängig zu machen. Eigentlich ist es sogar die gesamte Entwicklung, die abgestuft nach Pipeline-Prinzip abläuft.

Das heißt natürlich nicht, dass man keine Spezifikationen oder Testfälle mehr schreiben sollte.

Ja, dieses Vorgehen läuft der normalen gewohnten “Optimierung” in der Softwareentwicklung zuwider: Wir machen uns zunächst mehr Arbeit, um die Nachschubabwicklung für einzelne Filialen umstellbar zu machen, um in’s Altsystem zu schreiben usw. Das ist Arbeit, die wir im fertigen System nicht mehr brauchen werden. Aber bedenke: das Empire State Building hatte in der Bauphase doppelt so viele Fahrstühle wie nach der Fertigstellung. Die zusätzlichen Fahrstühle wurden zur Unterstützung des Baus benutzt: um Material und Bauleute zu transportieren.

Matthias Berth