Foto: Fractal Pictures - shutterstock.com
Agile ist eigentlich ein alter Hut. Ein sehr alter Hut. Schließlich hat das Manifest für agile Softwareentwicklung schon knapp zwanzig Jahre auf dem Buckel. Im Gegensatz zu Athene, die bereits in voller Blüte und vollständiger Rüstung dem Kopf des Zeus entsprungen sein soll, wurden agile Methoden schon lange vor dem Erscheinen des Manifests praktiziert.
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.
- Produkt- & Projektmanager
Ganz generell schätzen es Entwickler nicht so besonders, wenn ihnen jemand erklären will, wie sie ihren Job zu machen haben. Weil Produkt- und Projektmanager aber oft Entwickler-Teams leiten, passiert genau das. Das kann zu Unstimmigkeiten führen. <br /><br /> Dazu hat auch David Fox von devRant eine Meinung: "Letztendlich ist es in den meisten Fällen so, dass Produkt- und Projektmanager in irgendeiner Art und Weise die 'Besitzer' von Projekten und Prozessen sind, ohne dabei die täglichen Herausforderungen und Probleme der Softwareentwickler zu kennen." - Chefs
Genau wie die Produkt- und Projektmanager sind auch Development oder Engineering Manager dafür zuständig, Teams von Entwicklern zu führen und sicherzustellen, dass Projekte rechtzeitig und unter Budget fertiggestellt werden. <br /><br /> "In einigen Unternehmen können Situationen entstehen, in denen der Chef gleichzeitig Mitglied des Entwicklerteams ist. Insbesondere wenn der Chef vorher selbst Entwickler war und nach einer Beförderung zum Chef wird, ist Konfliktpotenzial gegeben", merkt Fox an. - Recruiter
Softwareentwickler müssen gar nicht selbst aktiv nach einem Job suchen, um von Recruitern und Headhuntern belästigt zu werden - dem Fachkräftemangel sei Dank. Es dürfte sehr schwer sein, einen Developer zu finden, der noch nicht in die Fänge der Recruiter geraten ist. <br /><br /> David Fox sieht insbesondere die Hartnäckigkeit der Recruiter als Problem: "Sie rufen an, sie e-mailen und sie lassen Dich einfach nicht in Ruhe - selbst dann, wenn Du gar keinen Job suchst. Und selbst wenn man eine Anstellung sucht, neigen viele Recruiter dazu, irrelevante Jobangebote zu machen oder Stellen zu empfehlen, deren Profil überhaupt nicht passt - etwa einen Job am anderen Ende des Landes, obwohl man gar nicht bereit ist, umzuziehen." - Dokumentation
Gibt es keine Dokumentation, beschweren sich die Softwareentwickler. Wenn es zuviel ist, beschweren sie sich und wenn sie die Dokumentation selbst erledigen müssen, auch. Sogar über die Art und Weise, wie andere Leute die Dokumentationsaufgabe bewältigen, beschweren sich die Entwickler. <br /><br /> An dieser Stelle seien sich auch endlich einmal alle Entwickler einig, wie Fox betont: "Softwareentwickler wollen eine ausführliche, gut geschriebene und akkurate Dokumentation - aber selber machen wollen sie es nicht." - Meetings
Meetings sind nicht nur für alle anderen ein Problem, sondern auch für Softwareentwickler. Insbesondere dann, wenn es sich um völlig unnötige, zeitraubende und stinklangweilige Zusammenkünfte handelt. Wie Fox erzählt, sind inzwischen auch Devotionalien mit der Aufschrift 'I survived another meeting that should have been an email' erhältlich. - Coworking Spaces
Mit dem Aufstieg der Agilität sind flache Hierarchien, Collaboration und Teamwork zum Alltag in Unternehmen geworden - insbesondere für Software-Development-Teams. Gerade die können ihre Arbeit in einem Großraumbüro aber meist nur schwer oder gar nicht bewältigen - sagen zumindest die Zahlen von devRant. <br /><br /> David Fox erklärt: "Es gibt einfach zuviel Ablenkung: die Kollegen unterhalten sich, Meetings werden verpasst, Telefonanrufe überhört. Es gibt auch eine Vielzahl an Beschwerden über den Kaffee im Büro und andere Annehmlichkeiten - oder eben das Gegenteil davon." - Kollegen
Selbsterklärend: Jeder hat wohl einen Kollegen oder eine Kollegin, den beziehungsweise die er ganz besonders schätzt. Nicht. <br /><br /> Im Fall der Softwareentwickler ist die Abneigung gegenüber Kollegen meist entweder in der mangelnden Qualität ihrer Arbeit oder einem völlig aus dem Leim gegangenen Ego begründet, gibt David Fox preis. - Vorstellungsgespräche
Wenn ein Softwareentwickler auf Jobsuche ist und zum Bewerbungsgespräch geladen wird, gibt es danach meist auch etwas zu meckern: <br /><br /> "Dumme Fragen oder die Lösung von völlig praxisfernen Aufgaben im Bewerbungsgespräch stoßen den Developern ebenso sauer auf, wie ein Gesprächspartner, der überhaupt nicht weiß, was ein Entwickler eigentlich genau macht", so Fox. - Fehler & Bugs
Softwareentwickler haben tagein, tagaus mit Fehlern und Bugs zu tun. Deswegen glaubt devRant-Gründer Fox, dass Entwickler in dieser Sache anders ticken: <br /><br /> "Die meisten anderen Probleme erfahren keine positive Auflösung, aber Bugs und Fehler sind behebbar und das fühlt sich gut an." - Quality Assurance
Die Quality Assurance (QA) - oder Qualitätssicherung - ist ein kritischer Teil der Softwareentwicklung. Dennoch bemängeln Softwareentwickler an QA-Experten häufig dieselben Dinge wie an Produkt- und Projektmanagern, so Fox. <br /><br /> "Die Qualitätssicherung bekommt das Produkt oder Projekt in die Hände, wenn die Entwickler es abgeschlossen haben. Deswegen verstehen sie oft nicht, welche Hürden und Workarounds die Entwickler im Entstehungsprozess bewältigen mussten. Offensichtlich kommt es auch regelmäßig vor, dass QA-Leute die Entwickler bitten, Bereiche nochmals zu überarbeiten, die sie auch selbst bewältigen könnten."
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.