Die Top 10 der Herausforderungen bei der Einführung eines Agile Programms


Flink, beweglich, schnell – so die wörtliche Bedeutung von Agile. Agile Vorgehensmodelle in der Software-Entwicklung zielen darauf, schnell auf geänderte Rahmenbedingungen zu reagieren und den Entwicklungsprozess schlanker und flexibler zu gestalten. Damit lösen sie sich vom klassischen Wasserfall-Modell und dessen Variationen. Vorteile der agilen Modelle gibt es viele. Aber was sind die versteckten Gefahren, die Sie und ihre Organisation davon abhalten können, von den Vorteilen von Agile zu profitieren?

Bild1Wir haben hier eine „Dev“-Sache am Laufen.
Herausforderung: Jeder denkt, Agile ist eine Sache der Entwickler, die sie nicht betrifft.

Ein Produkt oder einen Service zu entwickeln, kann naiver Weise als Aufgabe der IT-Entwickler angesehen werden. Aber um ein Produkt in der richtigen Art und Weise und zudem effizient zu entwickeln, müssen viele Personen, Ressourcen und die Unterstützung von sämtlichen Seiten zusammengebracht werden. Der Entwicklungs- oder „Dev“-Teil ist dabei tatsächlich nur die Füllung des „Was ist das Beste, das wir unserem Kunden bieten können“- und „Lasst uns das Ding in die Produktion geben“-Sandwichs.

Bild2Hat jemand meinen Job gesehen?
Herausforderung: Die Mitarbeiter haben Angst, dass sich ihre aktuelle Position verändern oder gänzlich verschwinden wird.

Product Owner – abgehakt. Scrum Master – abgehakt. Entwicklerteam – abgehakt. Und was passiert mit allen anderen? Wo ist der Projektmanager, die DBA’s, das Deployment-Team, die UX-Typen, die Architekten – alle, die wir einmal hatten? Hat die Einführung von Agile die Abteilung auf 6 bis 9 Mitarbeiter reduziert? Nein. Aber es hat verändert, wie manche dieser Personen arbeiten und welche Rollen und Verantwortung sie übernehmen. Wo wir bestimmte Arbeiten einst vorgezogen haben und hofften, dass alles schon irgendwie klappt, müssen wir jetzt adaptiver und iterativer vorgehen. Die Leute müssen immer noch den gleichen Job erledigen – aber jetzt üben sie diese Jobs in der Gemeinschaft und vermutlich auch anders aus. Das mag für den ein oder anderen beängstigend sein.

Bild3Stellung beziehen und abliefern
Herausforderung: Projekte müssen frühzeitig, kontinuierlich und regelmäßig einen Nutzen liefern, um „agile“ zu sein.

In den Agile-Prinzipien heißt es: „Funktionierende Software ist das wichtigste Fortschrittsmaß.“ Elementar beim Output eines Sprints ist es, diesen letztendlich zu produzieren, damit Kunden ihn auch nutzen können. Aber sagen Sie das beispielsweise einer Bank und beobachten Sie ihre Reaktion auf die potentiellen Risiken, die Sie suggerieren. Sicherlich ist es besser, alle vier Monate auszuliefern, so dass wir einige Wochen und Monate für das Testing haben – richtig? Falsch. Im digitalen Zeitalter müssen wir so oft wie nur möglich neue Funktionalitäten veröffentlichen, um Märkte, die nicht vier Monate warten wollen, zufrieden zu stellen. Was passiert mit diesen monolithischen Banken, wenn Apple oder Amazon zu Banken werden und zehn Mal am Tag neue Updates, Produkte und Services veröffentlichen? In den 80er-Jahren hätten sie sich in Bars verwandelt. Jetzt werden sie zu den Lagerhallen von Amazon.

Bild4Ich liebe Veränderungen! (bei anderen Leuten…)
Herausforderung: Es wird Veränderungen geben. Veränderungen sind verrückt…

Sprechen Sie mit einem CIO oder CEO über eine Welt voller verbesserter Qualität und schnellerer Lieferung, zu der Agile die Türen öffnen wird, und sie werden Feuer und Flamme sein. Erzählen Sie ihnen, dass sie ihre Gewohnheiten in Bezug auf Prozessmessung, Wertermittlung und Team-Unterstützung ändern müssen und sie werden ein bisschen weniger begeistert sein. Wie bereits erwähnt, müssen die Bemühungen von allen Seiten des Unternehmens ausgehen. Das verlangt von vielen etablierten Positionen, Prozessen und mitunter auch Werten Veränderung ab. Veränderung impliziert, dass das, was man die letzten 20 Jahre getan hat, falsch ist – und das zu hören, kann hart sein.

Bild5Ladet die Waffen
Herausforderung: Die Erwartungen sind hoch, dass Agile die Lösung aller Probleme ist – obwohl das nicht so ist.

„Agile ist großartig – es wird all unsere Probleme lösen!“ Ich kenne einen CIO, dem Agile umgehend nach diesem Zitat verkauft wurde. Stellen Sie sich seine Enttäuschung vor, als sein Agile-Projekt mit allen möglichen Problemen konfrontiert war; das Produkt war nicht das, was das Unternehmen wollte, die Entwicklung würde nicht unter den einst geschätzten Kosten umsetzbar sein, die Qualität war nicht hoch genug, die Hardware nicht darauf ausgelegt und so weiter. Diese Probleme hatte er beim Wasserfall-Modell nicht schon in diesen frühen Phasen! Und genau deswegen, muss er diese frühen Warnungen mehr als Erfolg denn als Niederlage sehen. Durch regelmäßige Feedback-Schleifen hilft Agile einem Projekt dabei, erfolgreich zu sein. Dazu zählen etwa die Überprüfung von Sprints oder Blicke auf die Usability, Suitability, Deliverability – also „ability“ oder Fähigkeit im Allgemeinen. Agile wird nicht all Ihre Probleme eliminieren, aber es wird dazu beitragen, sie früher zu erkennen, wenn es noch einfacher ist, sie zu beheben oder zu bewältigen.

Bild6Und jeden Tag ein kleines Stückchen besser
Herausforderung: Eine halbherzige oder schlecht vollzogene Einführung von Agile wird nicht zum erwarteten Mehrwert führen.

Wie bei so vielen Dingen im Leben – Schach zum Beispiel – ist der Anfang und das „Gar-nicht-mal-so-schlecht-Sein“ relativ einfach. Wirklich gut zu werden, dauert länger und man muss daran arbeiten. Ich habe Teams gesehen, die dieses Gefühl bei der Durchführung von Scrum Zermonien und dem Einsatz von Storys oder JIRA hatten – sie haben den Scrum-Nagel quasi auf den Kopf getroffen. Aber sie haben für keine bessere Qualität oder häufigere Auslieferungen gesorgt, einzig für weniger Planung und Dokumentation.

Ein Agile-Team auf die Beine zu stellen und zum Laufen zu bringen, ist erst der Anfang der Reise. Man muss auch ständig darum bemüht sein, sich zu verbessern. Seien Sie abenteuerlustiger und versuchen sie sich an neuen Herangehensweisen. Wenn es nicht funktioniert, stoppen, kontrollieren, bearbeiten und justieren Sie nach („inspect and adapt“). Wenn Sie es ernst meinen, nehmen Sie sich einen Coach. Und denken Sie immer daran: Was für das eine Team funktioniert, klappt nicht zwangsläufig auch für das andere.

Bild7Raus aus der Komfort-Zone
Herausforderung: Die Leute fühlen sich in ihrer aktuellen Position wohl und wollen sich nicht aus ihr heraus bewegen.

„Gleich und gleich gesellt sich gern“ – genau deswegen sehen wir des Öfteren, das gesamte Testing-Team zusammen sitzen, das gesamte Project-Delivery-Team zusammen sitzen und alle Entwickler zusammen sitzen. Es ist komfortabel, mit Leuten zusammengesetzt zu werden, die ähnliche Fähigkeiten besitzen wie man selbst, aber es wird nicht dazu beitragen, ein Projekt abzuliefern. Es ist außerdem komfortabel, sich auf den Fehlern anderer Disziplinen auszuruhen. Ich habe einmal ein Poster in einem IT-Operations-Raum gesehen mit einem brennenden Haus und verängstigten Menschen, die darum liefen. Darunter der folgende Satz: „In der Entwicklung hat es funktioniert.“ Mitarbeiter im gesamten Unternehmen müssen zusammen arbeiten, nicht nur nebeneinander existieren.

Bild8Nein, ich möchte keine komischen Dinge wie Retrospectives und Scrum Master…
Herausforderung: Agile einzuführen ist kompliziert genug – auch ohne ein völlig neues Wörterbuch.

Manchmal hat es den Anschein, als hätten wir uns mit Agile, Scrum, Lean und deren Terminologien selbst Steine in den Weg gelegt. Manche der Begriffe klingen komisch, peinlich oder einfach lustig. „Scrum Master“ klingt wie etwas, das man auf einem britischen Rugby-Platz findet, „Retrospective“ hört sich an wie Hippie-Slang und „Shu-Ha-Ri“ könnte auch ein haariger Schuh – natürlich rückwärts gesprochen – sein. Mit „Release Train Engineer“ will ich erst gar nicht anfangen…

Wir selbst müssen diese Begriffe verstehen und dürfen nicht davor zurückschrecken, sie auch zu verwenden und damit zu unterstreichen, dass sich die Welt weiterentwickeln muss. Namen zu verändern, hilft dabei, dies zu untermauern. Ein Scrum Master ist kein Projektmanager, eine Retrospective ist kein Post Mortem und ein „Shu-Ha-Ri“ beschreibt kein CMMI.

Bild9Ich weiß, was du denkst
Herausforderung: Mit uns selbst und anderen ehrlich zu sein, gerade was Probleme betrifft, ist hart.

Ehrlichkeit spielt bei Agile eine Schlüsselrolle – und im Besonderen ehrlich mit sich selbst zu sein. Wie wir gesehen haben, untermauern „inspect and adapt“ ¬ und eine kontinuierliche Verbesserung die Agile-Philosophie, der Beste zu sein und „Niederlagen“ als wichtige Lernprozesse anzusehen. Das funktioniert aber nur, wenn man sich nicht selbst vorspielt, einen guten Job zu erledigen. Wenn sich Ihre Qualität nicht verbessert oder Sie Ihre Sprint Commitments verpassen, werfen Sie das nicht anderen vor – seien Sie ehrlich zu sich selbst.

Bild10Neustart für das Denken
Herausforderung: Agile zu handeln ist nicht genug – man muss daran glauben und seine Prinzipien und Werte annehmen.

Das ist der größte Konflikt bei der Einführung von Agile – die eigene Denkweise. Wir müssen unsere Art zu Denken ändern, und vor allem dem Drang widerstehen, in alte Denkmuster zurück zu verfallen.

Ein agiles Denkmuster führt zu einem agilen Verhalten – das schlussendlich im agilen Arbeiten mündet.