Scrum, XP & Co. – warum keiner mehr agil arbeiten will
Die Hochphase agiler Methoden wie Scrum und Extreme Programming scheint vorbei zu sein – ja, es scheint sogar einen Gegentrend zu geben. Wie kommt das?
(Bild: LanKS/Shutterstock.com)
- Golo Roden
Ich bin mir nicht sicher, ob es derzeit ein allgemeines Thema ist oder ob es gerade einfach nur verstärkt in meiner eigenen Bubble auftaucht, aber ich habe immer mehr den Eindruck, dass Agilität zunehmend infrage gestellt wird. Sei es durch die dotnetpro, die in ihrer August-Ausgabe einen Leitartikel mit dem Titel "Ist Agilität tot?" veröffentlicht hat. Sei es durch eine Studie aus dem Juni, die behauptet, dass agile Softwareprojekte mit einer um 268 Prozent höheren Wahrscheinlichkeit scheitern würden, oder durch YouTube-Videos mit Titeln wie "It’s time to move on from Agile Software Development (it’s not working)".
Egal, wohin man blickt: Agilität scheint auf einmal nicht mehr en vogue zu sein, sie hat offenbar ihren Zenit überschritten. Doch woran liegt das? Warum ist eine Methodik, die einst angetreten ist, alles besser zu machen und die über Jahre hinweg sehr beliebt war, plötzlich so verpönt?
Agile Methoden – ein Entwicklungsprozess von 1957?!
Vielleicht sollte man zunächst die Frage stellen: Was bedeutet agil überhaupt? Was steckt hinter diesem Begriff, woher kommt er, und wie lautet seine Definition? Beschäftigt man sich damit, stellt man als erstes (und vielleicht auch etwas überrascht) fest, dass vieles von dem, was heutzutage typischerweise mit Agilität assoziiert wird, gar nicht so neu ist, wie man zunächst meint. Tatsächlich reicht nämlich beispielsweise die wichtige Erkenntnis, dass Software eher iterativ und inkrementell entwickelt werden sollte, bis ins Jahr 1957 zurück, als IBM erkannte, dass dies der richtige Ansatz ist. In den 1970er-Jahren entstanden dann ergänzend dazu noch das sogenannte "evolutionäre Projektmanagement" und die "adaptive Software-Entwicklung" – beides also ebenfalls schon recht früh.
Empfohlener redaktioneller Inhalt
Mit Ihrer Zustimmmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.
Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.
Formalisiert wurde das Ganze dann schließlich im Februar 2001 unter dem Schlagwort der Agilität im Rahmen des Agilen Manifests. Damals trafen sich zahlreiche Größen der Softwareentwicklung in Utah, um gemeinsam einige Erkenntnisse als Leitsätze für die Zukunft festzuhalten. Mit dabei waren unter anderem die bekannten Entwickler Kent Beck und Ron Jeffries, Ken Schwaber und Jeff Sutherland (bekannt von Scrum), Dave Thomas und Andrew Hunt (bekannt für Ihr Buch "The Pragmatic Programmer"), sowie Martin Fowler und Robert C. Martin. Insgesamt also eine ganze Reihe bedeutender Persönlichkeiten.
Die vier Leitsätze des Agilen Manifests
Sie formulierten vier Leitsätze, die beschreiben, was sie im Laufe der Zeit und in zahlreichen Projekten schätzen gelernt haben. Der erste Punkt besagt, dass Prozesse und Werkzeuge die Menschen und die Interaktion zwischen ihnen fördern sollen und dass sich die Prozesse und Werkzeuge daher an die Bedürfnisse der Menschen anzupassen haben, nicht umgekehrt. Der zweite Punkt betont, dass es wichtiger ist, am Ende des Tages eine funktionierende Software zu haben, die ein reales Problem löst, als eine umfassende Dokumentation zu erstellen.
Der dritte Punkt fordert, in enger Abstimmung mit dem Kunden zu arbeiten, statt jede Kleinigkeit im Vorfeld auszuhandeln und vertraglich festzulegen. Der vierte und letzte Punkt hebt hervor, dass es wichtiger ist, sich auf Veränderungen einzulassen und das Vorgehen entsprechend anzupassen, statt strikt einem Plan zu folgen. Wichtig ist, dass die weniger relevanten Punkte dabei nicht unwichtig sind – sie sind nur nicht so wichtig wie die anderen. Es ist also schon durchaus sinnvoll, einen Plan zu haben, aber man sollte nicht stur an ihm festhalten, wenn sich die äußeren Bedingungen geändert haben, sondern flexibel auf diese reagieren und den Plan adaptieren.
Das ist, kurz zusammengefasst, im Wesentlichen das Agile Manifest.
Was bedeutet das nun?
Das erste Problem tritt auf, wenn man einem Team sagt:
"Wir ersetzen jetzt das V-Modell durch agiles Arbeiten."
Zunächst finden das alle toll, aber letztlich weiß niemand, was sich nun konkret ändern soll, weil niemand genau weiß, was agil denn nun konkret überhaupt bedeutet. Denn selbst wenn man das Agile Manifest zur Hand nimmt, bleibt vieles vage. Was genau bedeutet der erste Punkt, "Individuals and Interactions over Processes and Tools", denn nun für die tagtägliche Praxis?
Es gibt zahlreiche Interpretationsmöglichkeiten, und welche davon die richtige ist, lässt sich schwer beantworten. Deshalb sind im Lauf der Zeit verschiedene Interpretationen entstanden, die dessen vier Grundregeln unterschiedlich auslegen. Um diese Interpretationen auseinanderhalten zu können, haben sie jeweils eigene Namen erhalten. Inhaltlich unterscheiden sie sich in ihren Ansätzen deutlich.
Extreme Programming (XP) richtet sich zum Beispiel an Entwicklerinnen und Entwickler und deren Alltag. Um diesen Alltag agiler zu gestalten, führt XP Praktiken wie Test-Driven Development, einen Build-Server. Code-Reviews und Pair-Programming ein. Also alles sehr konkret auf die tatsächliche Entwicklung bezogen. Im Gegensatz dazu bewegt sich Scrum eher auf einer organisatorischen Meta-Ebene, die sich mit Prozessen und Koordination befasst, während der konkrete Entwicklungsalltag kaum eine Rolle spielt. Trotzdem lässt sich nicht sagen, dass Scrum an sich besser oder schlechter sei als XP.
Der Aufstieg der agilen Methoden
Natürlich gibt es neben diesen beiden agilen Methoden auch noch andere, wie Feature-Driven Development (FDD) oder Kanban, und am Ende des Tages ist keine dieser Methoden die einzig wahre. Sie unterscheiden sich eben in ihren Absichten und damit auch in ihrer Interpretation. Viele Teams haben im Laufe der Zeit verschiedene agile Methoden kombiniert, wie zum Beispiel Scrum und Kanban zu Scrumban oder Scrum und XP, auch wenn es dafür bis heute keinen schicken Namen gibt. Es gibt Praktiken, die sich bewährt haben und für bestimmte Arten von Projekten passen, und andere, für die das weniger gilt. Doch das hängt letztlich immer stark davon ab, was man erreichen möchte.
Und bis hierhin ist die Geschichte auch ein großer Erfolg: Die agilen Methoden, allen voran Scrum, haben praktisch die Welt erobert. Ich weiß nicht, wie viele Unternehmen ihren Teams Scrum oder eine andere agile Methode verordnet haben, aber man kann sagen, dass agile Methoden im Verlauf von zwei Jahrzehnten das V-Modell und so ziemlich jeden anderen Softwareentwicklungsansatz abgelöst haben. Wenn ein Team heutzutage bewusst auf eine agile Methode verzichtet, wirkt das oft (zumindest auf den ersten Blick) seltsam und veraltet.
Zumindest war das bis vor Kurzem so. Aber, wie ich eingangs erwähnte, scheint in den letzten Jahren etwas schiefgelaufen zu sein. Immer weniger Unternehmen scheinen noch Interesse an agilen Methoden zu haben, und immer häufiger wird die Agilität als Ganzes infrage gestellt. Da frage ich mich: Wie konnte das passieren? Was ist schiefgelaufen? Aus meiner Sicht gibt es im Wesentlichen drei Punkte, an denen Agilität scheitert und die immer wieder kritisiert werden.
Agilität als Cargo-Kult
Punkt Nummer eins ist, dass agile Methoden, welche auch immer verwendet werden, angeblich nicht die versprochene Verbesserung gebracht hätten. Das ist tatsächlich etwas, was ich schon oft gesehen habe: Ein Unternehmen führt zum Beispiel Scrum ein, aber es funktioniert nicht richtig. Wenn man jedoch genauer hinschaut, stellt man häufig fest, dass das, was da gemacht wird, gar kein echtes Scrum ist. Stattdessen wird etwas praktiziert, das zwar pro forma so aussieht wie Scrum, aber völlig am Ziel vorbeigeht.
Formal werden also alle Anforderungen erfüllt, und dennoch ist das Team so weit weg von einem agilen Prozess, wie man sich das nur vorstellen kann. Leider ist das tatsächlich nicht selten. Da werden dann Sprints geplant, bei denen der Product Owner den konkreten Inhalt vorgibt, und das Entwicklungsteam darf diesen Umfang nur abnicken – egal wie unrealistisch die Vorgabe auch sein mag. Sprints dauern dann drei Monate. Retrospektiven behandeln alles, nur nicht, wie es den Teammitgliedern geht. Und das Daily dauert anderthalb Stunden, weil es zu einem klassischen Statusmeeting verkommt. Geht man die Liste der Scrum-Kriterien oberflächlich durch, wird man alle Elemente wiederfinden – aber jeder einzelne Punkt wird nicht so umgesetzt, wie es für den erfolgreichen Einsatz von Scrum erforderlich wäre.
In einem solchen Szenario ist es natürlich kein Wunder, dass das Ganze am Ende nicht das hält, was ursprünglich versprochen wurde. Die Frage ist: Warum passiert so etwas? Wohlwollend könnte man sagen, das jeweilige Team wusste es vielleicht nicht besser und ist eventuell über kurz oder lang wieder in alte Verhaltensmuster zurückgefallen. Vielleicht hatte das Team auch keine gute Anleitung und Unterstützung, aber es hat sich zumindest nach bestem Wissen und Gewissen bemüht.
Für dieses pseudo-agile Vorgehen gibt es sogar einen Begriff: Man nennt das Ganze Fake-Agile. Ich persönlich würde es vielleicht auch als Cargo-Kult bezeichnen, aber im Grunde meinen beide Begriffe dasselbe: Nur weil man etwas tut, das wie die richtige Umsetzung aussieht, bedeutet das noch lange nicht, dass man auch tatsächlich das Richtige macht.
Agilität als Deckmantel einer Hidden-Agenda
Punkt Nummer zwei ist zumindest in weiten Teilen praktisch dasselbe wie Punkt Nummer eins, nur mit einem anderen Hintergrund. Während ich bei Fake-Agile den meisten Teams unterstelle, dass sie es einfach nicht besser hinbekommen haben, gibt es auch jene Teams, in denen Agilität bewusst falsch praktiziert wird. Das ist dann nicht mehr Fake-Agile, sondern wird als Dark-Agile bezeichnet. Hier wird unter dem Deckmantel von Scrum, XP & Co. eine bewusst nicht-agile Vorgehensweise angewendet, meistens, um eine andere Agenda durchzusetzen, also eine irgendwie geartete Hidden-Agenda.
Das kann bedeuten, die Kontrolle über die Mitarbeiterinnen und Mitarbeiter erhöhen zu wollen, oder ein Team bewusst gegen die Wand laufen zu lassen, um dann zu sagen, dass die Methode nicht gut oder das Team ungeeignet sei, oder Ähnliches. In jedem Fall wird das Team als Bauernopfer für ein ganz anderes Vorhaben benutzt, das mit Agilität nichts zu tun hat. Das ist aus naheliegenden Gründen der viel schlimmere Fall, weil hier mit Menschen gespielt wird, mit deren Hoffnungen, Erwartungen und Engagement. Dark-Agile ist daher als sehr negativ zu bewerten.
Egal, ob es sich um Fake- oder Dark-Agile handelt: Beides trägt natürlich nicht dazu bei, das Vertrauen in agile Vorgehensweisen zu stärken. Im Gegenteil, das Vertrauen sinkt eher, und es ist am Ende leicht zu sagen:
"Tja, das habe ich euch ja gleich gesagt. Ich schlage vor, wir machen es jetzt mal anders."
Wer also eine Veränderung weg von der Agilität will, der oder dem spielen Fake- und Dark-Agile ideal in die Hände. Im einen Fall lässt man dem Schicksal seinen Lauf und greift nicht rettend ein, im anderen Fall fördert man das Ganze sogar noch. Das Ergebnis ist letztlich dasselbe: Die Agilität steht schlecht da.
Der agil-industrielle Komplex
Hinzu kommt noch ein weiterer Aspekt, der agile Methoden aus einer ganz anderen Richtung diskreditiert: Der, wie ich ihn in Anlehnung an die Rüstungsindustrie gerne nenne, agil-industrielle Komplex. Gemeint ist die extreme Kommerzialisierung der Agilität, was vor allem Scrum betrifft. Das Problem ist, dass Organisationen wie Scrum.org oder die Scrum Alliance damit begonnen haben, Zertifikate auszustellen, Workshops zu veranstalten und Train-the-Trainer-Konzepte zu entwickeln – alles nur mit dem Ziel, eine komplette Business-Maschinerie rund um eine agile Methode aufzubauen.
Und ganz ehrlich: Den ganzen Kram braucht niemand, um agil arbeiten zu können, am allerwenigsten Zertifikate. Allerdings benötigt diese Erkenntnis Zeit, und in der Zwischenzeit wurde sich bereits an zahllosen Entwicklerinnen, Entwicklern, Managerinnen und Managern eine goldene Nase verdient. Und natürlich möchte ich hier nicht alle Agile-Coaches oder Beratungsunternehmen über einen Kamm scheren, aber gerade in diesem Bereich gibt es auffallend viele schwarze Schafe.
Damit sind wir dann auch schnell bei Agilität als vermeintlichem Allheilmittel, als angepriesenem Wundermittel, als Schlangenöl. Egal, was Sie vorhaben: Mit Scrum (oder einer anderen agilen Methode) wird es auf jeden Fall besser. Und natürlich zeigt Ihnen gegen viel Geld auch sehr gerne jemand, wie das funktioniert. Wenn es dann nicht funktioniert, haben Sie sich einfach nicht ausreichend bemüht. Vielleicht brauchen Sie noch einen weiteren Workshop oder ein weiteres Zertifikat. Und so entsteht nach und nach ein Geschäftsmodell, das sich selbst befeuert: Wenn Sie Ihr Zertifikat bestehen, ist das super, aber leider läuft es nach ein paar Jahren ab, und Sie müssen es erneuern. Es hat sich zwar inhaltlich nichts geändert, aber Sie sind auf der sicheren Seite, wenn Ihr Zertifikat aktuell bleibt. Dass Sie dafür wieder Geld bezahlen müssen, das kann man ja unter den Tisch fallen lassen. Aber hey, Sie haben wieder ein Zertifikat, das Sie an die Wand hängen können! Ist das nicht toll?
Was bedeutet das nun zusammengenommen?
Was ist nun das Fazit? Ich glaube ehrlich gesagt, dass Scrum seine Hochzeit tatsächlich hinter sich hat. Und ich glaube auch, dass Scrum, wenn man mal ehrlich ist, gar nicht so gut und so übermäßig gelungen ist, wie oft angenommen oder dargestellt. Damit sage ich nicht, dass Scrum per se schlecht sei oder dass es keine Projekte gäbe, die sich für Scrum eignen würden, aber ich bin der festen Überzeugung, dass Scrum deutlich überbewertet ist.
Dass Scrum und Agilität heute oft gleichgesetzt werden, ist problematisch. Denn XP zum Beispiel halte ich nach wie vor für eine fantastische Arbeitsweise. Ja, vielleicht muss man das eine oder andere modernisieren, immerhin ist XP auch schon über 20 Jahre alt, aber XP halte ich persönlich für wesentlich gelungener als Scrum. Auch Kanban finde ich wesentlich gelungener als Scrum. Tatsächlich bin ich ein großer Freund von Kanban in der Verbindung mit XP, wobei ich auch dort ein paar Anpassungen vornehmen würde. Deshalb haben wir bei meinem Unternehmen, the native web, eine eigene Entwicklungsmethode entworfen, die zwar an Kanban und XP angelehnt ist, aber doch ein bisschen anders funktioniert.
Und ich weiß, dass jetzt viele sagen werden:
„Ja, aber damit machst du doch genau das, was du bei Scrum kritisiert hast: Du machst Kanban und XP auch nicht mehr wie im Lehrbuch.“
Und das stimmt. Aber ich habe vorhin auch nicht gesagt, dass man agile Methoden nicht adaptieren dürfe, sondern nur, dass man ein anderes Ergebnis erzielt, wenn man die Vorgehensweise ändert. Solange die Veränderung das Ergebnis verbessert, ist sie legitim. Das Problem ist nur, dass dreimonatige Sprints, fehlende Reviews und Pro-Forma-Retrospektiven das Ergebnis eher verschlechtern. Und dann war die Anpassung eben eine eher schlechte Idee. Man sollte also mit einem gewissen Augenmerk auf das Ergebnis an die Anpassung des Prozesses herangehen. Wenn man das kann, funktioniert es auch. Wenn nicht, sollte man es lieber lassen.
Ist Agilität tot?
Langer Rede, kurzer Sinn: Ich glaube nicht, dass Agilität tot ist. Ich glaube auch nicht, dass Projekte, die einem agilen Prozess folgen, mit einer 268 Prozent höheren Wahrscheinlichkeit scheitern. Und ich glaube vor allem auch nicht, dass es Zeit ist, sich von agiler Entwicklung an sich zu verabschieden.
Ich glaube aber, dass man, wenn man agil arbeiten möchte, es dann auch richtig tun sollte. Dafür braucht man nicht zwingend Scrum, die Scrum Alliance, Scrum.org, einen zertifizierten Coach oder Ähnliches. Was man braucht, ist das Agile Manifest und jemanden, die oder der einen agilen Prozess auf dieser Basis aufbauen und betreuen kann, und die oder der wirklich versteht, was Agilität im Kern bedeutet. (who)
