Der GoLive ist vorbei. Der Knall der Sektkorken ist verhallt. Der Alltag ist zurück.
Und Sie befinden sich in der Betriebshölle!
Mit dem neuen Alltag kommen auch neue Herausforderungen:
- Warum wird mein Team immer langsamer?
- Wo kommen all die Brandherde her?
- Wie sollen wir mit der neuen, unbekannten Situation umgehen?
Über allem steht die Frage: Wie entkommen Sie dieser Betriebhölle?
Die Antwort ist bestechend einfach. Lassen Sie sich überraschen.
Warum der Meilenstein GoLive so besonders ist
Bis zum GoLive konnte Ihr Team unter optimalen Bedingungen arbeiten:
- Der Sprint war geschützt.
- Es gab ein gemeinsames Ziel.
- Das Backlog war die einzige Quelle der Arbeit.
Scrum halt.
Der GoLive war perfekt vorbereitet. Jeder wusste, was zu tun ist. Die Automatisierung zeigte ihren Wert.
Und dann? – Die Betriebshölle nach dem GoLive
Nach dem GoLive findet sich das Team in der Betriebshölle wieder.
Nicht das wir uns falsch verstehen: Bei manchen Teams tritt sie schleichend auf, bei anderen bricht das Chaos über Nacht herein. Aber sie tritt mit hoher Wahrscheinlichkeit ein.
Die Symptome:
- Bugs und Incidents treten vermehrt auf.
- Endbenutzer melden immer neue Probleme.
- Features sind augenscheinlich nicht so ausgereift wie erwartet.
- Viele wichtige Anforderungen haben es nicht mehr in Version 1.0 geschafft und müssen nun nachträglich angegangen werden.
- Unbekannte Probleme treten im System auf, seit echte Menschen damit arbeiten.
Von den paradisischen Scrum-Verhältnissen ist nicht mehr viel geblieben.
Die meisten Scrum Master und agile Coaches reagieren darauf – natürlich, das ist ihr Job.
Mit drei „Pseudo-Lösungen“ in den Teufelskreis
Drei Lösungen sind dabei besonders beliebt:
- Viele setzen nun auf Scrumban statt Scrum. Sie nehmen den geschützten Sprint weg, um schneller zu reagieren. So lassen sich Betriebsaufgaben schnell und einfach in den Prozess hineinpriorisieren. Das Problem: Commitments können nicht mehr gegeben werden. Von Planung fehlt jede Spur.
- Besonders Mutige wechseln den kompletten Arbeitsmodus von Scrum nach Kanban – und ergeben sich damit den äußeren Rahmenbedingungen. Kanban kennt nur ein Commitment – was oben steht wird zuerst bearbeitet.
- Weniger Mutige lassen alles wie es ist. Allerdings opfern sie jetzt den geschützte Sprint und das Commitment, damit sie auf äußere Einflüsse reagieren können.
Auf dem Papier sind alle drei Lösungen bestechend einfach. Und sie sind auch vom Ansatz her nicht per se falsch. Aber jeder, der diesen Schritt gewagt hat, berichtet von folgenden Erkenntnissen:
- Das Produkt wird kaum noch weiterentwickelt, weil die Priorität im Team die ganze Zeit auf Support und Betrieb liegt. Fremdbestimmung par excellence.
- Der Platform Owner kämpft als fachliche Führung gegen Windmühlen – jeder, der laut genug schreit hat die gleiche Macht, wie der PO – geordnete Planung und Priorisierung gehören der Vergangenheit an.
- Das Team hat einen neuen Anreiz – Es muss Betriebs- und Supporttickets schneller abarbeiten. Wie im Hamsterrad.
Ein Teufelskreis!
Das scheint kein guter Ansatz zu sein, um der Betriebshölle zu entkommen. Aber welche Alternative haben Sie sonst?
Das Experiment: „Und wenn wir Scrum ernst nehmen?“
Diese Frage haben mein Geschäftspartner und Scrum Master Stephen Mittag und ich mit einem Experiment ausprobiert – mit durchschlagendem Erfolg.
Die zentrale Frage lautet: Was, wenn wir Scrum auch nach dem GoLive noch ernst nehmen?
Geschützter Sprint. Commitment-Treue. Ein vom PO priorisiertes Backlog als einzige Quelle der Arbeit.
Um es kurz zu fassen. Wir waren erfolgreich.
- Mit jedem einzelnen Sprint liefert das Team, was es verspricht.
- Den Support und Betrieb regelt das Team nebenher.
- Unsere Entwicklerplattform entwickelt sich Schritt für Schritt genau in die vorgesehene richtige Richtung.
Ich als Interim Platform Owner weiß immer genau, wo die Aufwände meines Teams hingehen und kann bei Bedarf steuernd eingreifen.
Und dafür mussten wir gar nicht so viel ändern. Nachdem wir Scrum ernst genommen haben, führte unser Kaizen uns von einer kleinen Korrektur zur nächsten. Wir erlebten die Macht der kleinen Schritte.
Der Entwicklungsprozess steht unverrückbar im Zentrum, der Betrieb, die Planung und die Kontinuierliche Verbesserung unterstützen ihn.
Damit sind wir wieder da, wovon sich die meisten Teams beim GoLive verabschieden – in paradisische Verhältnisse.
„Das geht bei uns nicht.“
Der häufigste Einwand, den wir hören ist: „Das geht bei uns nicht.“. Aber ist das so?
Unser Kunde, bei dem wir es jetzt erfolgreich eingeführt haben, hatte ähnliche Argumente und viele Bedenken. Auch unsere Platform Engineers waren alles andere als überzeugt. Sie alle haben Mut bewiesen und sind uns gefolgt.
Nicht die Maßnahmen, sondern die Reihenfolge ist entscheidend
Rückblickend haben wir festgestellt, dass das Team bereits vorher all die Maßnahmen ausprobiert hat. Wir haben herausgefunden, dass wir drei Dinge anders gemacht haben als zuvor:
- Arbeitsfähigkeit sicherstellen: Wir müssen dafür sorgen, dass das Team zu jedem Arbeitsfähig bleibt. Gerne auch die „unagile“ Arbeitsweise. Dafür müssen wir die aktuellen Fähigkeiten des Teams respektieren.
- Vision: Scrum-Guide ist der erstrebenswerte Zielzustand, nicht der Startpunkt. Wir müssen einen Schritt nach dem anderen gehen, um das Ziel zu erreichen.
- Reframing: Wir haben vom geschützten Entwicklungsprozess her gedacht. Damit haben wir einen unverrückbaren Rahmen gesetzt.
- Teile und Hersche: Wir haben Prozesse geschaffen und Vereinbarungen getroffen, um diesen Entwicklungsprozess vor äußeren Störungen zu schützen.
- Dranbleiben: Wir sind dran geblieben und haben jeder einzelnen Maßnahme den Raum gegeben, sich zu entfalten.
Gerade der letzte Punkt sorgt dafür, dass eine Strategie nicht nur auf dem Papier gut aussieht, sondern sich auch im operativen Geschäft verankert. Und das ist genau der Punkt, an dem die meisten Transformationen scheitern.
Möchten Sie das auch?
Dann sprechen Sie mich gerne darauf an. Mein Geschäftspartner und ich erklären Ihnen gerne das Konzept und arbeiten einen Plan aus, wie sie der Betriebshölle entfliehen und in den geordneten Arbeitsmodus zurückkehren können.