Warum es einfacher ist, einen Sack Flöhe zu hüten, als Scrum in großen Unternehmen zu implementieren

Schon mal versucht, einen Sack Flöhe zu hüten? Gar nicht so einfach. Kaum hat man mal eine Gruppe der Biester unter Kontrolle, machen die anderen wieder, was sie wollen. Die einen hüpfen nach rechts, die anderen nach links, springen mal hoch, mal niedrig, oder in alle Richtungen verstreut. Wieder andere bewegen sich gar nicht und bleiben nur stur am Platz. Moment mal, das erinnert Sie an die Scrum Implementierung in Ihrem Unternehmen? Seltsam, Scrum ist doch ein Framework mit einem definierten Vorgehen, wie kann es dann sein, dass es im Unternehmen offensichtlich so chaotisch läuft? Da muss man sich schon mal die Frage stellen, warum das eigentlich der Fall ist und was da falsch gelaufen ist.

Völlig losgelöst von der Erde…

Mit Sorge beobachte ich derzeit, dass viele Ansätze bei Banken scheitern, Scrum und agile Frameworks einzusetzen. Im Gegensatz zu Major Tom in den 80er Jahren, kommen sich heutzutage Scrum Teams in Banken sehr losgelöst von den strategischen Zielen des Unternehmens vor.

Ich mache das mal an einem Beispiel fest. Gehen wir mal davon aus, Sie arbeiten in einer Bank mit ca. 500 Mitarbeitern in der IT. Bei 10 Mitarbeitern pro Scrum Team wären das in Summe also 50 Scrum Teams und vielleicht 30 Produkte, an denen die Teams arbeiten. Ich weiß, es ist unrealistisch, aber nehmen wir gerne mal an, jedes dieser Produkte hat seine eigene Roadmap und Strategie – ist mir in der Realität zwar noch nicht begegnet, aber wir sind hier hypothetisch unterwegs. Nun bekommt Ihr Unternehmen einen neuen Vorstand, der sich dem Thema Digitalisierung verschrieben hat und proklamiert, dass die Bankprozesse bis 2024 digitalisiert werden sollen. Diese Nachricht kommt natürlich auch bei den 30 Product Ownern an, welche sich pflichtbewusst an die Arbeit machen. So ändert der Product Owner für ein Kreditbearbeitungssystem seine Roadmap dahingehend ab, dass die Unterlagen für einen Kreditantrag in einem Dokumentenmanagementsystem gespeichert werden. Der Product Owner für ein Zahlungsverkehrssystem ergänzt eine KI gestützte AML-Lösung, der Product Owner Wertpapier macht erst einmal nichts, da er eh schon sehr digital unterwegs ist und der Product Owner für das Risikomanagement will endlich sein Data Warehouse umsetzen, um eine einheitliche Datenbasis zu haben. Der Wertzuwachs für das Unternehmen bis 2024 wird eher marginal ausfallen, da jeder ausschließlich an sein eigenes Produkt denkt und der neue Vorstand wird viel beschäftigt sein, seine Strategie im Unternehmen mit den Product Ownern abzustimmen. Oder kurz gesprochen, im Ergebnis müssen Flöhe gehütet werden.

Scrum oder nicht Scrum, das ist (k)eine Frage

Immer wieder werden Stimmen laut, die zurück zum Wasserfallmodell wollen, mit der Begründung, dass das wenigstens mal funktioniert hat. Aber will man ernsthaft dahin zurück, Kunden nur dreimal im Jahr über die Jahresreleases neue Funktionalitäten zur Verfügung zu stellen? Die FinTechs würde es jedenfalls freuen, da viele Kunden nicht mehr dorthin zurückwollen. Aber wie immer steckt da natürlich ein Körnchen Wahrheit drin, denn zu Zeiten des Wasserfallmodells hatte man sinnvolle Steuerungsmechanismen wie ein Portfoliomanagement oder ein Programmmanagement. All das wurde aber mit der Einführung von Scrum, leider meist auf Zutun agiler Coaches und Berater, über Bord geworfen. Schließlich sind diese nicht mehr im Scrum definiert und somit auch nicht mehr erforderlich. Dabei wurde leider vergessen, warum ich diese Instrumente in der „alten Welt“ eingesetzt habe, nämlich um meine Steuerungsprozesse zu skalieren. In einem kleinen Unternehmen kann ich selbstverständlich mittels Nexus über ein Produkt skalieren, Nexus ist allerdings nicht einsetzbar, wenn ich eine Skalierung über mehrere Produkte benötige.

Sehr häufig höre ich in diesem Zusammenhang den Ausdruck „hybride Modelle“, was leider nicht zielführend ist, da es ein Mix aus agiler und nicht-agiler Entwicklung beschreibt. Die Problematik der skalierten Steuerung bleibt auch bei diesen „hybriden Modellen“ bestehen. Andersherum ist eine komplette Agilisierung eines Unternehmens auch nicht sinnvoll. Man nehme nur mein Lieblingsbeispiel eines Minimum Viable Products für den Jahresabschluss.

An dieser Stelle muss man sich einmal auf die eigentlichen Ziele der Agilisierung eines Unternehmens besinnen. Ich als Berater ziehe dann gerne mal die VUCA-Karte (Volatility, Uncertainty, Complexity, Ambiguity), welche die neuen Rahmenbedingungen in der Unternehmensführung beschreibt. Ein agiles Vorgehen ist eine Möglichkeit, darauf zu reagieren – insbesondere auf die Faktoren Volatilität, Unsicherheit und Komplexität. Wieder zurück zum Wasserfall zu gehen bedeutet, einen strategischen Nachteil gegenüber dem Markt in Kauf nehmen zu müssen. Warum also nicht weiter agil arbeiten, die Steuerungsmechanismen der „alten Welt“ aber auf dieser Agilität zu implementieren? Hierbei geht es nicht allein um die Prozesse, sondern auch um das Thema Skalierung der Organisation. Ein durchaus beliebtes Organisationsmodell war und ist das sogenannte Spotify-Modell, welches man eigentlich nicht mehr so nennen dürfte, da Spotify längst anders organisiert ist. Dieses Modell beschreibt zwar, wie eine Organisation mittels Tribes and Squads skalieren kann, aber nicht wie die skalierten Prozesse aussehen. Außerdem hört das Modell oberhalb der Tribes auf, was sicherlich auch daran liegt, dass es eher für kleinere oder mittlere Unternehmen angedacht war. Für größere hierarchische Unternehmen ist es also eher weniger geeignet.

Warum man mit SAFe seine Schäfchen ins Trockene bekommt

Wie aber kann ich nun einen Sack Flöhe hüten? Schauen wir doch mal über den Tellerrand. Was macht denn ein Schäfer, wenn er ein Gewitter aufziehen sieht und seine Schäfchen in den Stall bekommen möchte? Genau! Er verwendet Hirtenhunde, die er permanent so dirigiert – oder sollte ich besser sagen: steuert – bis alle Schäfchen in die richtige Richtung laufen. Er hat also mehrere Helfer, die sofort einschreiten können, sollte er feststellen, dass die Schäfchen falsch laufen.

Was heißt das nun für große Unternehmen? Der Hirtenhund strategischer Umsetzungen sind Frameworks wie SAFe, welche die Möglichkeit bieten, sowohl die Prozesse als auch die Organisation zu skalieren und alte und neue Welt miteinander zu verbinden. Somit hilft SAFe im übertragenen Sinne, seine Schäfchen ins Trockene zu bringen.

SAFe basiert auf einem recht alten Prinzip, das jeder IT-ler kennt, nämlich „Teile und Herrsche“. Es ist auf unterschiedliche Hierarchien ausgelegt und somit für Unternehmen mit unterschiedlichen Größen anwendbar. Strategische Themen wie Digitalisierung werden auf Portfolio-Ebene als Portfolio-Vision entwickelt, welche budgetiert werden und als Epic in dem Portfolio-Backlog priorisiert werden. Auf dieser Ebene wird dann definiert, über welchen sogenannte Value Stream die Umsetzung an welche Teams übergeben wird. Diese Epics werden über einen definierten Prozess auf verschiedene Team-Backlogs zugeteilt. Dort erfolgt dann die eigentliche Aufwandsschätzung und die Planung sowohl für den kommenden Sprint aber auch für die Dauer eines Programminkrements, typischerweise acht bis zwölf Wochen. Wichtig ist hierbei, dass die Inhalte aus den übergreifenden Themen abgeleitet, die Planung aber auf den unteren Ebenen erfolgt. Heißt also, dass die Strategie so lange heruntergebrochen wird, bis diese in verarbeitbaren Paketen von acht bis zwölf Wochen abgeschätzt werden können. Auf dieser Basis erfolgt dann die Definition von Sprint-Zielen. Bildlich gesprochen, teile ich meinen Sack Flöhe in kleinere Flohgruppen auf und sage allen Gruppen, was sie zu tun haben und beobachte über einen längeren Zeitraum, ob sie sich auch in die richtige Richtung bewegen. Nur durch diesen strukturierten Prozess der inhaltlichen Vorgaben, kann sichergestellt werden, dass die strategischen Ziele des Unternehmens auch erreicht werden.

Fazit: Es ist ein Stück weit alter Wein in neuen Schläuchen, aber ich nehme etablierte Prozesse wie Portfolio- und Programmmanagement, ergänze sie um Aspekte einer Enterprise-Architektur und adaptiere sie auf ein agiles Vorgehen. Aus meiner Sicht aber die einzig vernünftige Art und Weise, etablierte und als gut befundene Prozesse und Organisationsformen mit der neuen agilen Welt zu verbinden.