Nach dem Thema «Netzwerke statt Hierarchien», den ich im letzten Teil meiner Blogreihe zum Thema Digitalisierung (Teil 1, Teil 2, Teil 3, Teil 4, Teil 5) beleuchtet habe, möchte ich heute das Thema "Kürzere Markeinführungszyklen" anschauen.
Kürzere Markteinführungszyklen: Alles wird agil.
Agile hat sich in den letzten Jahren zu einem der meistmissbrauchten Schlagworte entwickelt. Alles scheint agil zu werden und jeder behauptet, agil zu sein. Haben Sie schon einmal jemanden sagen hören: "Nein, wir sind nicht agil"? Aber was meinen wir eigentlich, wenn wir von Agilität sprechen?
Der Wikipedia-Artikel über agile Softwareentwicklung (Agile) definiert agile Praktiken wie folgt: "Agile Softwareentwicklung bezeichnet Ansätze im Softwareentwicklungsprozess, die die Transparenz und Veränderungsgeschwindigkeit erhöhen und zu einem schnelleren Einsatz des entwickelten Systems führen sollen, um so Risiken und Fehlentwicklungen im Entwicklungsprozess zu minimieren. Dazu wird versucht, die Entwurfsphase auf ein Mindestmass zu reduzieren und im Entwicklungsprozess so früh wie möglich zu ausführbarer Software zu gelangen. Diese wird in regelmässigen, kurzen Abständen mit dem Kunden abgestimmt. So soll es möglich sein, flexibel auf Kundenwünsche einzugehen, um so die Kundenzufriedenheit insgesamt zu erhöhen. Agile Softwareentwicklung zeichnet sich durch selbstorganisierende Teams sowie eine iterative und inkrementelle Vorgehensweise aus."
Sie wurde durch das "Manifest für agile Softwareentwicklung" populär gemacht. Die Werte und Prinzipien, für die dieses Manifest eintritt, wurden von einer Vielzahl von Softwareentwicklungs-Frameworks abgeleitet, einschliesslich Scrum und Kanban." Die zugrunde liegenden Prinzipien der agilen Softwareentwicklung wurden bereits im Jahr 2001 im Rahmen des "Manifesto for Agile Software Development" veröffentlicht. Es ist ein iterativer Ansatz für das Projektmanagement und die Softwareentwicklung, der den Teams hilft, ihren Kunden schneller und mit weniger Kopfschmerzen einen Mehrwert zu liefern. Anstatt alles auf einen "Big Bang"-Launch zu setzen, liefert ein agiles Team die Arbeitsresultate in kleinen, aber konsumierbaren Schritten. Anforderungen, Pläne und Ergebnisse werden kontinuierlich evaluiert, so dass die Teams über einen natürlichen Mechanismus verfügen, um schnell auf Änderungen reagieren zu können. Kurze, iterative Zyklen (Sprints) und die Reduktion von Overhead und Bürokratie auf ein Minimum und damit die schnelle Lieferung kleiner Teile von nutzbarem Code mit echtem Mehrwert für das Geschäft ist die Essenz von Agile.
Geschwindigkeit (speed to market) ist das A und O, um in der heutigen Geschäftswelt wettbewerbsfähig zu sein, und das ist einer der Hauptgründe, warum agile Methoden so beliebt geworden sind. Oft wird Agile jedoch von Business Managern missverstanden und meist als reines "IT-Ding" gesehen. Sie glauben, dass mit der Einführung agiler Methoden durch ihre IT-Teams Projekte bei gleichem Umfang einfach schneller und kostengünstiger durchgeführt werden. Dies ist jedoch eine Illusion.
Meine persönliche Erfahrung, die ich als CIO bei einer agilen Transformation gemacht habe, hat mich gelehrt, dass das gesamte Unternehmen agil werden muss, um die wahren Vorteile agiler Methoden nutzen zu können - und das erfordert weit mehr als nur die Transformation der IT. Es reicht nicht aus, Scrum in der IT zu implementieren, ein paar Projekte nach dem agilen Ansatz durchzuführen und zu glauben, dass das Unternehmen dadurch schneller am Markt ist.
Nachdem wir jahrelang Rapid-Prototyping-Methoden eingesetzt und unsere IT-Teams mit den Fachbereichen physisch zusammengelegt hatten (colocation), begannen wir 2013 mit der Einführung agiler Methoden. Wir haben sehr schnell Vorteile erzielen können; indem wir in der Lage waren, kleinere Teile gebrauchsfertiger Software viel schneller zu liefern als bei der Anwendung des traditionellen Wasserfallmodells. Als wir jedoch den Code in Produktion setzen wollten, blieben wir bei unseren eigenen IT-internen, ITIL-basierten Prozessen stecken. Unsere IT-Operations-Kollegen, die zu Recht den Auftrag haben, den "heiligen Gral" des stabilen und sicheren Betriebs zu bewachen, erlaubten nur zu vordefinierten Zeitpunkten, dass SW-Code auf der Grundlage strenger Prozesse und Abnahmekriterien in die Produktion freigegeben wurde. Zum Beispiel wenn die monatlichen oder manchmal auch vierteljährlichen Release-Zyklen fällig waren. Uns war klar, dass wir diesen Engpass nur überwinden können, wenn wir die Mitarbeitenden des IT-Betriebs in die agilen Teams (Squads) integrieren und sie und ihre Prozesse zum Teil der agilen Transformation machen. Dies war der Beginn von DevOps in der Organisation.
Obwohl ich sehe, dass viele Unternehmen ihre agile Transformation in diesem Stadium stoppen, weil sie agil als eine IT-Methode betrachten, wollten wir weitergehen. Wir stellten fest, dass uns einige andere Bereiche des Unternehmens immer noch ausbremsten und daran hinderten, die wahren Vorteile der agilen Methoden voll zum Nutzen des Unternehmens umzusetzen.
Lassen Sie mich ein paar Beispiele für solche "Agile-Hemmer" in traditionellen, hierarchisch organisierten Unternehmen nennen. Jede Ähnlichkeit mit tatsächlichen Personen oder Organisationseinheiten eines Unternehmens, für das ich gearbeitet habe, ist rein zufällig:
- Die Marketingabteilung weigert sich, dass die neuen Funktionalitäten der mobilen App ausgerollt werden, weil eine Marketingkampagne zur Bewerbung einer Reihe neuer App-Funktionen erst in ein paar Monaten stattfinden soll.
- Die Finanzabteilung weigert sich, weitere Mittel freizugeben, weil das Budget für das Jahr bereits aufgebraucht ist. Und sie bestehen darauf, dass wir alles auf Eis legen, bis im Rahmen des regulären jährlichen Budgetierungsprozesses neue Mittel genehmigt würden.
- Die Personalabteilung weigert sich, dem Team nach einem wichtigen, erfolgreichen Sprint eine Auszeichnung für die hervorragende Arbeit zukommen zu lassen. Dies, weil der reguläre jährliche Nominierungsprozess für den "Chairman’s Award" des Unternehmens erst vor zwei Monaten abgeschlossen wurde und das Team daher für den Zyklus des nächsten Jahres nominiert werden sollte.
Ich könnte wahrscheinlich mit solchen Beispielen von Einheiten und Funktionen innerhalb der traditionellen hierarchischen Silos weitermachen, aber ich denke, Sie haben den Punkt jetzt verstanden: Sie können Agile nicht auf die IT beschränken, wenn Sie tatsächlich von der erhöhten Geschwindigkeit profitieren wollen, die agile Arbeitsweisen bieten. Stattdessen müssen Sie die Transformation durch das gesamte Unternehmen vorantreiben.
Traditionelle Planungs- und Projektmanagement-Methoden haben uns in der Vergangenheit gute Dienste erwiesen, sind aber heute ebenso Altlasten, wie die hierarchischen Strukturen, sowie deren bürokratischen Prozesse, die oft nur dem Selbstzweck von Konzernfunktionen und Overhead-Strukturen von vielen Unternehmen dienen. Diese hierarchischen Strukturen mit ihren starren Planungs-, Kontroll- und Finanzprozessen, die aus dem Industriezeitalter des letzten Jahrhunderts stammen (Taylorismus), sind für das neue agile Paradigma nicht geeignet - und auch nicht damit kompatibel.
Ich habe beobachtet, dass in traditionell geführten Projekten (Wasserfallmethode) die Teams viel Zeit damit verbringen, auf andere zu warten. In vielen Projekt-Reviews lautete eine häufige Erklärung auf die Frage, warum das Projekt hinter dem Zeitplan zurücklag: "Wir warten darauf, dass Einheit A X liefert". Dies kann daran liegen, dass die Geschäftsbereiche Spezifikationen oder Testfälle absegnen oder Abnahmetests durchführen müssen usw. Oder es liegt an der IT-internen Bürokratie, wie z. B. Enterprise-Architecture, um die Lösungsarchitektur freizugeben, Cybersecurity, um die Risiken abzuzeichnen, IT-Betrieb, um Server bereitzustellen, usw. Oder aber aufgrund externer Faktoren, wie z. B. wenn ein Lieferant einer outgesourcten Komponente nicht pünktlich liefert.
Warum verbringen wir so viel Zeit damit, auf andere Projektbeteiligte zu warten? Einfach gesagt, wegen der strikten Aufgaben- und Rollentrennung des Industrialisierungsansatzes, die zu mehrfachen Übergaben (Hand-over) und zu Overhead führt. Ein CIO-Kollege einer europäischen Bank und einer der starken Befürworter agiler Arbeitsweisen sagte mir vor ein paar Jahren: "Bei Agile geht es darum, Hand-overs abzuschaffen. Hand-overs verlangsamen Prozesse und sind die Quelle von Fehlern."
Im Roman "The Phoenix Project" wird agil treffend beschrieben, dass es um die Fokussierung auf Einfachheit geht -- die Kunst, die Menge nicht getaner Arbeit zu maximieren --, also alles Unnötige zu entfernen. Ähnlich wie bei Lean-Methoden in der Fertigung geht es um die Minimierung von "work in progress" und die Vermeidung von Engpässen.
In seinem Buch "The Delicate Art of Bureaucracy" beschreibt Mark Schwartz schön, wie wichtig es ist, unnötige Bürokratie abzubauen, um die Agilität zu erhöhen.
Meiner Meinung nach geht es bei agilem Vorgehen weniger darum, noch eine weitere Methodik (Scrum, Kanban, SAFe, Holokratie, etc.) minutiös zu befolgen und damit wieder Bürokratie einzuführen. Sondern um eine Denkweise, die sich auf einige wenige Prinzipien im gesamten Unternehmen und nicht nur in der IT konzentriert:
- Reduzierung von Hand-overs, Hierarchien und Bürokratie -> Fokus auf integrierte und selbstorganisierende Teams, die mit sehr schlanker Governance eigenständig entscheiden können
- Positive Einstellung gegenüber Menschen -> Vertrauen gegenüber den Mitarbeitenden, dass sie die Arbeit erledigen. Gehen Sie aus dem Weg. Kein Mikromanagement oder übermässige Kontrolle und Prozesse
- Reduzieren der Grösse von Arbeitspaketen und "work in progress" und damit die Zykluszeit
- Konstante und kontinuierliche Verbesserungen anstelle von klar definierten Projekten und iterative Anpassungen anstelle von langen, komplizierten Plänen
Da agile Methoden in der IT bereits eine gewisse Tradition haben, ist der CIO gut dafür positioniert, die agile Transformation im gesamten Unternehmen voranzutreiben. CIOs sollten die Business-Kollegen dabei unterstützen, ebenfalls agil zu werden, indem sie diese Prinzipien übernehmen und ihnen helfen, den Mind-Set innerhalb ihrer Organisationen zu ändern. Dies ist ein wichtiger Teil der Rolle des modernen CIOs, der für sein Unternehmen einen echten Mehrwert schaffen und einen positiven Einfluss im Unternehmen ausüben möchte. Von den CIOs von heute wird erwartet, dass sie aus dem Backoffice herauskommen, die traditionelle Rolle der IT als Support-Einheit verändern und aktiv die agile Transformation des gesamten Unternehmens vorantreiben.
