Wege zur agilen Selbstsabotage

Dennoch gibt es immer noch einige furchtlose Gesellen, die es - zahllosen Erfolgsbeispielen zum Trotz - irgendwie geschafft haben, sich dem Trend zur Agilität zu entziehen. Wenn Sie zu dieser Gruppe gehören und sich unter "Agile-Druck" wähnen, ist es jetzt an der Zeit, sich nicht mehr länger wie ein Dinosaurier zu fühlen, der auf den Asteroideinschlag wartet. Gehen Sie lieber in die Offensive: Wir zeigen Ihnen sieben Strategien, die sicherstellen, dass in Ihrer IT-Organisation nichts aus Agile wird - ohne dass Sie eine Reputation als Sand im Unternehmensgetriebe entwickeln.

1. Agile Terminierung

Wenn Sie Ihr nächstes Projekt angehen, bestehen Sie darauf, dass der Projektmanager den "Agile Way" einschlägt. So können alle Beteiligten jeden Morgen aufs Neue überlegen, was sie tun können, um das Projekt in eine Richtung zu treiben, die sie für vorwärts halten.

Was Testing angeht: Immer, wenn das Team dazu bereit ist, lassen Sie den Product Owner wissen, dass Sie morgen Unterstützung vom Business brauchen, um das geplante Feature ordentlich zu penetrieren. Wenn das nicht geht - kein Problem. Das bedeutet dann eben, dass das Feature in den nächsten Sprint rutscht.

Sollte der Product Owner dann auf die Idee kommen, sich über die Abweichung vom Terminplan zu beschweren, kommt der beste Part: Dann dürfen Sie diesem eröffnen, dass agile Projekte keinen Zeitplan haben. Schließlich heißt Agile soviel wie "ohne Plan".

2. Architektur egal

Verschwenden Sie zu Beginn des Projekts keine Zeit damit, die Applikations-Architektur zu definieren. Agiles Arbeiten heißt nämlich, dass die Anforderungen sich stetig weiterentwickeln. Wieso sollte das also nicht auch für die App-Architektur gelten?

Überstrapazieren Sie also nicht die Kreativität Ihrer Entwickler, indem Sie zum Prinzipienreiter werden. Empowerment heißt stattdessen das Stichwort: Lassen Sie die Devs entwickeln, wie sie lustig sind. Module und Interfaces können auch einfach irgendwie strukturiert werden. Wenn die Module unterschiedlicher Entwickler später nicht miteinander kompatibel sind, ist das kein Problem. Wozu gibt es denn Refactoring?

Und wenn die Entwickler in verschiedenen Sprachen coden wollen, geht das auch klar. Dafür gibt es ja Container.

3. Scrum, Beste!

Agile ist keine Methodik, sondern eine Familie von Methoden, von der jede einzelne zu einer spezifischen Projektart passt. Scrum ist die populärste davon - aber nicht, weil sie so "Best Practice" ist, sondern weil es die Methode mit der ausgeprägtesten Struktur ist. So ausgeprägt, dass es schon in Richtung Wasserfall-Komfortzone geht.

Besonders ungeeignet ist Scrum insbesondere für COTS- und SaaS-Implementierungen, die unter den IT-Projekten den Löwenanteil einnehmen. Bessere Alternativen wären die agilen Methoden CRP oder ATTD. Aber wer hat von denen schon jemals etwas gehört? Kritisieren kann Sie jedenfalls niemand dafür, wenn Sie sich für die populärste agile Methode entscheiden.

Wenn ihre Scrum-getriebene COTS-Implementierung ordentlich an die Wand fährt, dann jedenfalls nicht, weil Sie es nicht besser wussten. Also schon, aber Sie können ja sagen, dass das Projekt gescheitert ist, weil Agile von vorneherein keine gute Idee war. Jeder, der etwas anderes behauptet, tut das nur, um sich selbst zu schützen.

4. Aus Wasserfall mach SAFe

Der Charme agiler Methoden liegt in ihrer Schlichtheit. Ihre größte Schwäche hingegen ist, dass sie gar nicht einmal so gut skalieren.

Smarte Unternehmen machen Agile deswegen agil. So sehr, dass nicht nur Software-Implementierungen, sondern jeglicher Change unter die Schirmherrschaft des Agile Manifesto gestellt wird. Aus dieser Perspektive sind großangelegte Strategien untrennbar mit der Wasserfall-Methodik verbunden und scheitern aus demselben Grund wie IT-Projekte, die nach dieser Methodik ablaufen. Der Ablauf ist linear, die Abhängigkeiten- und Hürdendichte hoch. Zudem beruhen solche Projekte auf Annahmen über die Zukunft, die mindestens zweimal über den Haufen geworfen werden, bis die Zukunft da ist.

Aber lassen Sie sich davon nicht beirren. Der Job des CIO ist es nicht, das Business agiler zu machen, sondern die Unternehmensstrategie zu stützen. Egal, ob die funktionieren kann, wie sie ist oder nicht. Weil Agile jedoch nicht auf große Strategien skaliert, muss die IT auf eine Methodik ausweichen, die agil klingt, aber Wasserfall-mäßig skaliert.

Willkommen bei SAFe - dem sogenannten Scaled Agile Framework (woher das kleine E kommt, weiß bis heute niemand). Wo Agile mit Schlichtheit punktet, überwältigt SAFe mit Komplexität und genauso vielen Variablen und potenziellen Fail-Quellen wie die Wasserfall-Methode. Bonus: Kaum jemand kennt sich wirklich damit aus. Nicht falsch verstehen: SAFe ist nicht grundsätzlich schlecht, erfordert aber erfahrene Spezialisten und eine Menge Program Infrastructure.

Wenn SAFe aber das ist, was das Business braucht, hat die IT zu gehorchen und absolviert den Sprung von Wasserfall zum Scaled Agile Framework - allen Risiken zum Trotz. Das Projekt wird dadurch untergehen, aber Ihre Weste bleibt rein. Schließlich haben Sie ja gewarnt, dass Agile nicht skaliert.

5. Agile Partnerschaften

Bestehen Sie unbedingt darauf, dass Ihre Entwicklungspartner ebenfalls agil arbeiten. Das ist nämlich immer besser. Außerdem schulen Sie so jeden Manager aus dem Business, wie agile Zusammenarbeit mit der IT geht.

Darüber hinaus sollten die Angebote der Partner unbedingt mit Fixpreisen versehen sein. Nur so können Sie sicher sein, dass diese auch ehrlich sind und keine Motivation entwickeln, das Projekt-Budget sprengen zu wollen. Sollte einer der Anbieter es wagen, dieses Vorgehen als "anti-agil" in Frage zu stellen, ist das etwas Positives. So haben Sie schon vor Unterzeichnung des Statement of Work herausgefunden, wie schwierig sich die Zusammenarbeit mit diesem Partner gestalten würde.

6. Offshore Agile

In der Theorie setzen Business Planner Ziele für Umsatz, Kosten, Risiken und Zielerreichung. In der Praxis - zumindest in den meisten Unternehmen - werden mit den Projekten, die abgesegnet werden, Kosten eingespart. Und wo könnte man besser die Schere ansetzen als bei den Entwicklergehältern?

Deshalb sollten Sie bei der Wahl Ihres Partners unbedingt darauf achten, dass dessen Team elf Zeitzonen entfernt lebt und arbeitet. Mindestens. Das sechste Prinzip des agilen Manifests betont zwar die Bedeutung der Face-to-Face-Kommunikation, aber ignorieren Sie das einfach - schließlich ist das nur graue Theorie. Wenn man die Wahl hat, entweder Geld zu sparen oder sich an abstrakte Prinzipien zu halten, sollte man immer den Business-Magnaten raushängen lassen und nur die Zahlen unter dem Strich fokussieren - genau solche Leute braucht heute jedes Unternehmen.

Wenn das agile "Team" am Ende Module liefert, die zwar ins Schwarze treffen, aber eben auf der falschen Zielscheibe, ist das auch okay. Hat schließlich auch weniger gekostet. Die IT hingegen kann sich immer darauf berufen, dass das Business die Anforderungen nicht klar genug kommuniziert hat. Dass das so gekommen ist, weil keine ordentliche Kommunikation stattgefunden hat, merkt schon niemand.

7. Prozesse über alles!

Wir wissen alle, dass das Agile Manifesto Individuen und Interaktionen über Prozesse und Tools stellt. Aber wenn das Management eine Sache aus den vergangenen Dekaden gelernt hat, dann, dass Business-Erfolg von gut definierten, wiederholbaren Prozessen abhängt. Nicht von guten Beziehungen oder Kollaboration, sondern von Mitarbeitern, die den Prozessen Schritt für Schritt folgen, genau so, wie es das Swimlane-Diagramm vorgibt.

Und wie jeder gute Prozess-Designer weiß, überlässt ein guter Prozess nichts dem Zufall. Es liegt also an Ihnen, sicherzustellen, dass jeder Prozess so kleinteilig und exakt wie möglich aufgedröselt wird. Sie brauchen für Ihren Agile-Prozess nur genug Komplexität, damit die IT zum verlängerten Arm der EPMO-Projektmanagement-Prozess-Polizei wird und ein wachsames Auge auf Ihre Agile Coaches werfen kann - so wie zuvor auf die Wasserfall-Projektmanager.

Alternatives Heilmittel

Wenn diese sieben Strategien nicht Ihren Geschmack treffen, haben wir noch eine Alternative für Sie auf Lager: Stellen Sie sich dem Unausweichlichen. Gestehen Sie sich ein, dass agile Methoden dem Wasserfall-Modell tatsächlich einiges voraushaben und lassen Sie es auf einen ernsthaften Versuch ankommen.

Das wird wehtun, ist aber vergleichbar mit einer Hüftprothesen-OP: Auf lange Sicht machen Vermeidungsstrategien alles nur schlimmer. (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation CIO.com.