Im ersten Teil dieser Blog-Serie wurden die organisatorischen Aspekte auf dem Weg zur Agilität sowie der Irrglaube, dass im agilen Umfeld alles innerhalb agiler Teams stattfindet, betrachtet.
In diesem Teil werden nun die Gründe für eine agile Transformation sowie der durch die Umstellung verursachte Change-Prozess unter die Lupe genommen. Denn leider sehen wir nur zu häufig, dass Agilität aus den falschen Gründen oder aufgrund falscher Annahmen eingeführt wird. Auch dies kann zum Scheitern des Change-Prozesses führen, genau wie eine zu geringe Gewichtung des Change-Prozesses an sich.
Richtige und falsche Gründe für die agile Transformation
Ein häufiger Grund für die Einführung eines agilen Vorgehens ist die Erwartung des Managements, dass eine schnellere Realisierung und Kostenersparnisse erzielt werden. Deshalb wird häufig bei klassischen Projekten, welche aufgrund von Zeit oder Kosten zu scheitern drohen, auf Agilität gesetzt.
Ein klassisches Projekt, welches in Schieflage geraten ist, sollte jedoch keinesfalls blind einer agilen Transformation unterzogen werden.
Agilität verspricht auf dem ersten Blick eine schnellere Realisierung und eine kürzere «Time to Market». Die Einführung agiler Frameworks selbst rettet jedoch nicht einen gefährdeten Liefertermin eines bisher klassischen Projektes. Eine agile Transformation durchzuführen, um ein kritisches Projekt ohne Veränderung der Rahmenbedingungen zu retten, ist ebenso zum Scheitern verurteilt wie das Projekt, welches man mit Agilität zu retten versucht.
Bei der Umstellung auf ein agiles Vorgehen muss daher zwingend die Scope-Dimension flexibel werden, da nur durch einen variablen Scope ein agiles Vorgehen überhaupt erst möglich wird. Darüber hinaus sollte beim agilen Vorgehen ein grosser Wert auf stabile Teams gelegt werden. Da das Budget oft zum grossen Teil durch den Ressourcen-Bedarf definiert wird, führen stabile Teams letztlich auch zu einem stabilen Budget für einen definierten Zeitraum.
Bei Agilität geht es zuallererst darum, sich schnell an veränderte Bedingungen anpassen zu können. Hierzu gehört auch regelmässiges Feedback von Stakeholdern, woraufhin ggf. bestehende Funktionen nochmals angepasst werden und Backlog-Items neu priorisiert, ergänzt oder fallengelassen werden müssen.
In diesem Sinne gilt es, die "richtigen" Gründe für eine agile Transformation hervorzuheben und diese auch transparent zu kommunizieren. Hierzu zählen zum Beispiel:
- Eine höhere Kundenzufriedenheit
(Durch ein iteratives Vorgehen und kurze Feedback-Zyklen wird der Kunde enger involviert und dadurch sichergestellt, dass die Bedürfnisse des Kunden letztlich auch zu dessen Zufriedenheit erfüllt wird) - Eine Verkürzung der "Time to Market"
- eine Steigerung der Mitarbeiterzufriedenheit (unter anderem dadurch, dass den Mitarbeitern mehr Verantwortung übertragen wird und diese auch Gehör finden)
Zudem sollte man sich immer bewusst sein, dass auch eine Umstellung auf ein agiles Vorgehen mit einer gewissen Lernkurve verbunden ist. Hierbei verschlechtert sich zumindest kurzfristig die Effizienz eines Teams, bevor eine Verbesserung erreicht wird und das Team tatsächlich effizienter das Richtige liefern können. Erreicht wird die Steigerung der Effizienz und Effektivität der Teams letztlich vor allem durch eine Verringerung von Fehlentwicklungen und Missverständnissen aufgrund der regelmässigen Feedback-Zyklen.
Tipps
- Agilität heisst Änderungen willkommen zu heissen. Dies gilt besonders beim Scope. Schaffen Sie die notwendige Flexibilität, um die Vorteile eines agilen Vorgehens zu ermöglichen.
- Prüfen Sie vor der Umstellung auf ein agiles Vorgehen die Gründe für eine Änderung des Vorgehens gründlich.
- Machen Sie sich und allen Beteiligten bewusst, welche Ziele Sie mit der agilen Transformation verfolgen, und kommunizieren Sie diese transparent.
Change-Prozess nicht unterbewerten
Ein häufiges Hindernis bei der agilen Transformation ist gleichzeitig ein Missverständnis darüber, was Agilität überhaupt bedeutet. Agilität ist mehr als nur die Anwendung eines agilen Frameworks wie SCRUM, sondern betrifft insbesondere die Organisation und Kultur eines Unternehmens.
Vielmehr geht es darum die agilen Prinzipien und Werte zu leben und den Sinn der agilen Praktiken zu verstehen. Nur dadurch kann nachhaltig eine Veränderung in der Organisation entstehen und die agile Transformation verkommt nicht zum Selbstzweck.
Dieser Aspekt wird bei der Einführung von Agilität häufig vernachlässigt. So wird der Transformationsprozess häufig bereits mit der Einführung eines agilen Frameworks wie SCRUM oder SAFe als beendet erklärt. Das Ergebnis dieser nicht vollständig durchgeführten Transformation führt zu einem häufig in der Praxis anzutreffenden Effekt von «Doing Agile» (agile Methoden und Frameworks anwenden) anstatt «Being Agile» (agil sein und das agile Mindset leben).
In diesem Stadium der Agilität werden zwar agile Methoden wie z. B. SCRUM oder SAFe angewendet. Aufgrund der nicht angepassten, übergeordneten Prozesse und einer unveränderten Unternehmenskultur mit bestehenden Hierarchien wird jedoch weiterhin ein iterativer Wasserfall gelebt. Im Extremfall kann dies dazu führen, dass zwar nach SCRUM in Sprints gearbeitet wird, jedoch im Hintergrund weiterhin die klassischen Phasen aus dem Wasserfall angewendet werden. So wird zunächst über mehrere Sprints spezifiziert und damit kein eigentlicher Wert in Form eines potentiell lieferbaren Produktinkrements produziert.
Im Anschluss an die Spezifikationssprints folgt dann die Umsetzung, welche zwar ebenfalls in Sprints gegliedert wird, jedoch nicht um die Vorteile des iterativen Vorgehens mit kurzen Feedback-Zyklen auszunutzen. Stattdessen geht es lediglich darum, die «Regeln» des Frameworks (in diesem Fall als Prozess missverstanden) zu erfüllen. Im schlimmsten Fall wird also trotz «agilem» Vorgehen erst am Ende des Projektes sichtbar, ob die Erwartungen der Stakeholder erfüllt sind. Regelmässige Feedback-Zyklen auf Basis eines abgeschlossenen Inkrements fehlen und so kann das Feedback der Stakeholder nicht in die weitere Entwicklung einfliessen. Letztendlich werden die eigentlichen Probleme des klassischen Vorgehens also nicht gelöst.
Dieses Problem verdeutlicht auch der aktuelle Trends- und Benchmark-Report. Auch hier scheint bei über zwei Drittel der Befragten die Einführung agiler Prozesse und Methoden der wichtigste Aspekt der agilen Transformation zu sein.
Tipps:
- Agile Transformation endet nicht mit der Einführung agiler Frameworks. Dies kann lediglich ein erster Schritt auf dem Weg zur Agilität sein.
- Agile Transformation als Change-Prozess verstehen und entsprechend umsetzen. Es handelt sich dabei um eine organisatorische Veränderung, welche längerfristig betrachtet werden muss.
- Agile Praktiken wie «Inspect & Adapt» und regelmässige Feedbackzyklen auch auf die Transformation anwenden.
- Agile Transformation als Lean Change aufsetzen. Das heisst auch im Change-Prozess nicht einfach einem vorgegebenen Plan zu folgen, sondern mit Hilfe des "Build-Measure-Learn"-Zyklus flexibel auf Änderungen zu reagieren. Hierbei ist wichtig Änderungen anhand von Hypothesen auf deren Erfolg zu validieren und daraus geeignete Rückschlüsse für weitere Änderungen zu ziehen.
- Betroffene zu Beteiligten machen – die Betroffenen (Team-Mitglieder sowie interne und externe Stakeholder) frühzeitig in den Change-Prozess einbeziehen. Dies erhöht die Motivation der Beteiligten und trägt dadurch erheblich zum Erfolg bei.
Fazit
Letztlich kann eine agile Transformation mit dem Besteigen eines Berges verglichen werden. Anfangs ist der Weg noch gut ausgebaut und flach und man kommt gut voran. Bei der agilen Transformation kann dieser Wegabschnitt mit der Einführung eines Frameworks wie SCRUM verglichen werden.
Genauso wie mit den ersten leichten Anstiegen der Gipfel noch nicht erklommen ist, ist die Einführung z. B. von SCRUM als Framework (häufig als Prozess missverstanden) ein zunächst einfacher Schritt in der agilen Transformation. Diese ist jedoch damit noch nicht beendet.
Es ist erst der erste Schritt auf dem Weg von «Doing Agile» zu «Being Agile». Das Ziel bei der agilen Transformation kann schnell aus den Augen verloren werden, ähnlich dem Gipfel eines Berges, wenn auf halbem Weg eine dicke Wolkenschicht den Blick zum Ziel behindert. Es lohnt sich jedoch den Fokus immer wieder neu auf das Ziel auszurichten und auch in der agilen Transformation so flexibel zu bleiben wie in der agilen Entwicklung eines Produktes.
