Es gibt mittlerweile einen breiten Konsens, dass agile Vorgehensweisen bei sich schnell ändernden Rahmenbedingungen sehr nützlich sind. Trotzdem tun sich viele Unternehmen nach wie vor schwer diese Vorgehensweisen dann auch zum Erfolg zu führen.
Dieser Beitrag zeigt anhand eines alltäglichen Beispiels was der Unterschied zwischen agilen und klassischen Vorgehensweisen ist und warum eine agile Vorgehensweise nicht für jedes Problem geeignet ist. Außerdem beleuchte ich aus eigener Erfahrung die Fallstricke bei der Umsetzung von agilen Vorgehensweisen.
Der Beitrag basiert auf einen Vortrag von mir beim Alster Business Club, welcher bei Youtube angeschaut werden kann.
Einfach, kompliziert, komplex oder chaotisch: Das Cynefin Framework versucht Klarheit zu schaffen
Würde ich in ein Flugzeug einsteigen, wenn die Flugfähigkeit des Flugzeugs einer komplexen Ursachen- und Wirkungsbeziehung unterliegen? Lieber nicht! Sie ist sicherlich kompliziert, folgt aber einer klaren Ursachen- und Wirkungsbeziehung. Ich muss die Funktionsweise eines Flugzeugs nicht verstehen. Es beruhigt mich aber ungemein, dass es Experten gibt, die dies tun.
Das Cynefin Framework unterteilt Problemstellungen in die vier Bereiche einfach, kompliziert, komplex und chaotisch. Es gibt noch einen fünften Bereich des Nicht-Wissens (Disorder). In diesem befindet man sich, wenn unklar ist in welchem Bereich sich das Problem befindet.
Im einfachen Bereich befinden sich Problemstellungen mit einer einfachen Ursachen-/Wirkungsbeziehung. Wenn die Ampel auf rot springt, wissen Autofahrer, dass der Vordermann mit einer hohen Wahrscheinlichkeit bremsen wird. Dies ist eine einfache Regel, die wir tagtäglich anwenden und wo die wenigsten überlegen müssen. Lösungen in diesem Bereich sind „Beste Praxis“.
Im komplizierten Bereich ist die Beziehung zwischen Ursache und Wirkung zwar klar, aber nur Experten wissen was genau dazwischen abläuft. Egal ob Verbrenner, Hybrid oder Elektro. Wenn ich auf das Gaspedal drücke, dann fährt das Auto los. Wie genau das funktioniert, werden die wenigsten wissen. Lösungen in diesem Bereich sind „Gute Praxis“.
Im komplexen Bereich gibt es viele Ursachen und Wirkungen und es gibt Beziehungen dazwischen, die auch Experten nicht verstehen. Komplexe Umfelder sind meistens die, wo Entscheidungen von Menschen einen großen Einfluss haben. Die Aktienmärkte sind ein Beispiel für Ursachen und Wirkungen, die im Vorhinein nicht prognostiziert werden können. Lösungen in diesem Bereich sind „Entstehende Praxis“
Im chaotischen Bereich gibt es keine Beziehung zwischen Ursachen und Wirkungen. Existenzielle Krisen bewegen sich oft im chaotischen Bereich. Lösungen in diesem Bereich sind „Neue Praxis“
Die bekanntesten IT-Vorgehen können wie folgt den Bereichen zugeordnet werden:
- Wasserfall-Vorgehen: Geeignet für einfache Probleme
- ITIL / Kanban: Geeignet für einfache und komplizierte Probleme
- PRINCE2 / PMP: Geeignet für komplizierte Probleme
- Agil / Scrum: Geeignet für komplexe Probleme
Wohnraum schaffen: Klassisch oder agil?
Die Projektmanager Walter Wasserfall und Sebastian Scrum haben beide die Aufgabe Wohnraum zu schaffen.
Walter Wasserfall entscheidet sich für ein Hochhaus, welches nach klassischem Vorgehen entstehen soll. Sebastian Scrum wählt Einfamilienhäuser, die nach und nach entstehen sollen.
Walter Wasserfall erstellt einen Projektplan. Nach 17 Monaten soll der Wohnraum an Bibo Betrieb übergeben werden. Der Projektplan beinhaltet den Projektinhalt, den Zeitplan und das Budget. Sebastian Scrum erstellt ebenfalls ein Plan. Bei ihm sind der Zeitplan und das Budget festgelegt. Statt eines klar definierten Projektinhalts schreibt er aber das Ziel fest: Innerhalb der nächsten knapp 1,5 Jahre Wohnraum schaffen.
Beide legen los. Walter Wasserfall holt zunächst die Anforderungen ein, lässt daraus eine Spezifikation erstellen. Auf Basis der Spezifikation wird das Vorhaben entwickelt, getestet und zu Abnahme gebracht. Nach der Abnahme sollen die neuen Bewohner einziehen.
Sebastian Scrum erstellt einen ersten Prototyp und lässt dort die ersten Bewohner einziehen. Er sagt klipp und klar, dass der Prototyp nicht das Endergebnis ist. Sein Ziel ist frühes Feedback von den Nutzern zu bekommen, um diese Erkenntnis in den nächsten Schritten einzubeziehen. Da es Sommer ist, ziehen die ersten Bewohner in das Einfamilienhaus, welches keine Fenster und auch keine Heizung hat. Die neuen Bewohner geben Sebastian Scrum frühzeitig wertvolle Informationen. Diese Information nutzt er, um die Häuser mit jedem Schritt besser zu machen.
Nach 6 Monaten sind bei Sebastian bereits sechs Parteien eingezogen. Walters Projekt befindet sich gerade am Start der Entwicklung. Es gibt bei den Anforderungen und bei der Spezifikation Probleme, da die Anforderungen teilweise nicht klar waren und damit die Spezifikation nicht beendet werden konnte.
Nach eineinhalb Jahren sind alle Bewohner bei Sebastian eingezogen. Es gab auf dem Weg dorthin viele Probleme, allerdings konnte Sebastian aufgrund des frühen Feedbacks unmittelbar handeln. Die neuen Bewohner zeigen sich sehr zufrieden, da flexibel auf ihre Bedürfnisse eingegangen werden konnte.
Walter kämpft mit mächtigem Verzug. Die Entwickler beschweren sich über die Spezifikationen und die Tester über die Entwickler. Walter musste in zahllosen Change Advisory Boards (CAB) Änderungen genehmigen lassen. Oft hat sich die Genehmigung über einen langen Zeitraum gestreckt, da nicht alle Entscheider im CAB anwesend waren. Eine erste Begehung der zukünftigen Bewohner hat ergeben, dass das zwar alles ganz schön aussieht, für die Bewohner in der Form aber nicht nutzbar ist.
Dieses zugegeben sehr plakative Beispiel soll den Unterscheid zwischen klassischem und agilem Vorgehen verdeutlichen.
Im nächsten Abschnitt schauen wir uns an was auf dem Weg in die agile Welt alles schief gehen kann.
Nichts Halbes und nichts Ganzes, aber ganz viel Frust
Die Firma „Analoges Geschäftsmodell AG“ hat Schwierigkeiten. Die Konkurrenz ist beweglicher und weiß die zunehmende Digitalisierung zu ihrem Vorteil zu nutzen. Ein Berater von „Freudig & Alt“ hat zu einem Tagessatz von knapp 3.000 € den nahezu revolutionären Tipp gegeben Scrum einzuführen. Das Konzept wurde individuell auf die Situation von „AG AG“ zugeschnitten und soll jetzt eigenständig umgesetzt werden.
Um Scrum einzuführen wurden zunächst die neuen Begriffe etabliert. Releases heißen jetzt Sprints, Anforderungen heißen Epics und Spezifikationen Stories. Die Währung Personentage (PD) wurde durch Story Points ersetzt – haben aber die gleiche Bedeutung. Die Excelliste aus dem CABs heißt jetzt Product Backlog und das CAB wurde durch das Product Owner Gremium ersetzt. Die ehemaligen Abteilungsleiter sind jetzt Product Owner, haben aber weiterhin disziplinarische Verantwortung, da das die Personalabteilung so vorsieht.
Der Teamleiter Charlie Chef wurde aufgrund von mangelnder Alternative zum Product Owner und Scrum Master in Personalunion ernannt. Da alle Entscheidung über Charlie Chef laufen, sieht sein Team auch keine Veranlassung Verantwortung für die Konsequenzen solcher Entscheidungen zu übernehmen.
Nach einem Jahr fragt der Vorstand mal vorsichtig an, warum zwar bzgl. der Umstellung auf Scrum Vollzug gemeldet wurde, das gewünschte Ergebnis der Umstrukturierung aber ausbleibt.
Der Vorstand holt sich noch mal externe Expertise, um die Frage zu beantworten.
Die Analyse hat ergeben, dass sich zwar die Begrifflichkeiten geändert haben, die Arbeitsweise, Verantwortungszuschnitt und die Kultur sind aber dieselben wie vor der Transformation. Das neue Produkt braucht immer noch ein Jahr bevor es ausgerollt werden kann. Die Teams machen zwar jetzt StandUps und sind hervorragend beim Kickern, können aber nicht selbst entscheiden, da sie von zu vielen anderen Beteiligten abhängig sind.
Die Teams haben sprichwörtlich auf den Bau von Einfamilienhäusern umgestellt, allerdings zieht dort keiner ein. Die Häuser bleiben leer und damit profitieren die Teams nicht vom frühen Feedback.
Fazit
Eine agile Transformation ist eine Reise mit vielen Hindernissen. Es reicht nicht Werkzeuge und Prozesse umzustellen. Der Schlüssel zum Erfolg basiert auf eine Änderung der Kultur und des Mindsets als Grundlage für eine anderen Arbeitsweise. Das ist kein Sprint, sondern ein Marathon und braucht seine Zeit.
Der Erfolg sollte daher auch nicht daran gemessen werden, ob agile Prozesse und Werkzeuge eingeführt worden sind, sondern ob es „agile Ergebnisse“ gibt.
Agile Ergebnisse heißt, dass unter unsicheren oder unbekannten Rahmenbedingungen erfolgreich Ergebnisse produziert werden.
Über mich
Seit über 20 Jahren setze ich erfolgreich IT-Vorhaben um. Als IT-Berater, Projektmanager (PMP) und Produktmanager habe ich in verschiedensten Kontexten, Branchen und Unternehmen agil und klassisch IT-Systeme konzipiert, erstellt und betrieben. Als Führungskraft und Changemanager habe ich Teams befähigt und Organisationen erfolgreich transformiert.