Agilität in der Kritik: Warum agile Methoden ins Wanken geraten

Agile Methoden wie Scrum und XP, einst gefeierte Innovationen in der Softwareentwicklung, geraten zunehmend in die Kritik. Was sind die Gründe für das wachsende Misstrauen gegenüber diesen Praktiken, und warum scheitern sie in der Praxis so häufig? Der Artikel beleuchtet die Schattenseiten der Agilität und zeigt auf, wie eine einst revolutionäre Idee ins Wanken geraten ist.

Scrum, XP & Co. – warum keiner mehr agil arbeiten will

Die Agilität galt einst als der Heilsbringer in der Softwareentwicklung. Mit Methoden wie Scrum und Extreme Programming (XP) sollte alles besser, schneller und effizienter werden. Doch in letzter Zeit ist ein zunehmender Gegenwind zu spüren. Eine Studie von 2023 behauptet, dass agile Projekte eine um 268 Prozent höhere Wahrscheinlichkeit haben zu scheitern. Gleichzeitig mehren sich kritische Stimmen in Blogs, Artikeln und Videos, die fragen: Ist es Zeit, sich von agilen Methoden zu verabschieden?

Agile Methoden – eine lange Entwicklungsgeschichte

Die Wurzeln der Agilität reichen weiter zurück, als viele denken. Schon 1957 erkannte IBM, dass Softwareentwicklung iterativ und inkrementell erfolgen sollte. Diese frühe Erkenntnis führte in den 1970er-Jahren zur Entstehung von Konzepten wie evolutionärem Projektmanagement und adaptiver Softwareentwicklung. Doch es dauerte bis 2001, bis diese Ideen im “Agile Manifesto” zusammengeführt wurden. 17 führende Softwareentwickler, darunter Ken Schwaber, Jeff Sutherland und Kent Beck, trafen sich in Utah, um eine neue Art der Softwareentwicklung zu definieren, die den Fokus auf Flexibilität, Zusammenarbeit und die Fähigkeit zur Anpassung an Veränderungen legt.

Die vier Leitsätze des Agilen Manifests

Das Agile Manifest, das im Jahr 2001 von einer Gruppe von Softwareentwicklern verfasst wurde, markiert einen bedeutenden Wendepunkt in der Geschichte der Softwareentwicklung. Es definiert vier zentrale Leitsätze, die als Grundlage für alle agilen Methoden dienen und eine klare Abkehr von den traditionellen, starren Entwicklungsmethoden darstellen. Diese Leitsätze sind:

Individuen und Interaktionen stehen über Prozessen und Werkzeugen:
Der erste Leitsatz betont die Bedeutung von Menschen und deren Zusammenarbeit im Entwicklungsprozess. Anstatt sich auf festgelegte Prozesse und Werkzeuge zu verlassen, wird der Wert auf direkte Kommunikation und das Einbringen der individuellen Fähigkeiten und Kreativität jedes Teammitglieds gelegt. Dies bedeutet, dass flexibles, anpassungsfähiges Arbeiten gefördert wird, indem die Interaktion zwischen den Teammitgliedern und mit dem Kunden im Vordergrund steht. Die Prozesse und Werkzeuge sind zwar wichtig, sollten jedoch nicht die menschlichen Aspekte der Zusammenarbeit überschatten.
Funktionierende Software ist wichtiger als umfassende Dokumentation:
Der zweite Leitsatz stellt die Auslieferung funktionierender Software in den Mittelpunkt. Anstatt umfangreiche Dokumentationen zu erstellen, die oftmals ungenutzt bleiben oder schnell veralten, wird die Priorität auf die Entwicklung und Bereitstellung von Software gelegt, die tatsächlich funktioniert und den Anforderungen des Kunden entspricht. Dies bedeutet nicht, dass Dokumentation völlig vernachlässigt wird, sondern dass sie in einem agilen Kontext pragmatisch und zielgerichtet eingesetzt wird, um den Entwicklungsprozess zu unterstützen, anstatt ihn zu dominieren.
Zusammenarbeit mit dem Kunden hat Vorrang vor Vertragsverhandlungen:
Dieser Leitsatz unterstreicht die Bedeutung der kontinuierlichen Zusammenarbeit mit dem Kunden während des gesamten Entwicklungsprozesses. Anstelle eines starren Vertrags, der alle Anforderungen im Voraus festlegt und oft wenig Raum für Veränderungen lässt, wird der Kunde als aktiver Partner in den Entwicklungsprozess einbezogen. Dies ermöglicht es, flexibel auf sich ändernde Anforderungen zu reagieren und sicherzustellen, dass das Endprodukt den tatsächlichen Bedürfnissen des Kunden entspricht. Die Zusammenarbeit mit dem Kunden wird so zum Schlüsselfaktor für den Projekterfolg.
Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans:
Der vierte Leitsatz reflektiert die Unvorhersehbarkeit und Dynamik moderner Entwicklungsprojekte. Anstatt starr an einem vorab erstellten Plan festzuhalten, wird die Fähigkeit, auf Veränderungen zu reagieren und den Plan entsprechend anzupassen, als wesentlich wichtiger erachtet. Dies bedeutet, dass das Team jederzeit bereit sein muss, auf neue Erkenntnisse, veränderte Marktbedingungen oder geänderte Kundenanforderungen flexibel zu reagieren. Die Bereitschaft zur Veränderung und Anpassung ist daher ein zentrales Element agiler Methoden.

Diese vier Leitsätze des Agilen Manifests waren damals ein revolutionärer Bruch mit den traditionellen, wasserfallartigen Entwicklungsmethoden, die oft durch starre Phasen und detaillierte Pläne geprägt waren. In der Praxis zeigt sich jedoch, dass die Umsetzung dieser Prinzipien nicht immer einfach ist. Viele Organisationen kämpfen mit der Herausforderung, die Balance zwischen Flexibilität und Struktur zu finden, und es erfordert oft eine tiefgreifende Veränderung in der Unternehmenskultur, um die Prinzipien des Agilen Manifests erfolgreich zu integrieren. Die Umsetzung dieser Leitsätze erfordert ein hohes Maß an Vertrauen, Offenheit und die Bereitschaft, kontinuierlich zu lernen und sich anzupassen.

Was bedeutet das in der Praxis?

Die Umsetzung agiler Prinzipien in der Praxis ist oft mit erheblichen Herausforderungen verbunden. Extreme Programming (XP), das Praktiken wie Test-Driven Development (TDD), Continuous Integration (CI) und Pair Programming propagiert, setzt eine hohe Disziplin voraus. TDD zum Beispiel verlangt, dass Entwickler ihre Tests vor dem eigentlichen Code schreiben. Das klingt einfach, ist aber in der Praxis schwer durchzuhalten, insbesondere unter dem Druck enger Deadlines. Viele Teams neigen dazu, TDD zu vernachlässigen, weil sie glauben, es koste zu viel Zeit. Doch die Folge ist oft ein Rückgang der Codequalität und eine erhöhte Fehleranfälligkeit.

Continuous Integration (CI), eine weitere zentrale Praxis in XP, erfordert, dass Entwickler ihren Code regelmäßig, oft mehrmals täglich, in ein zentrales Repository einpflegen, wo er automatisch getestet und integriert wird. In der Theorie soll CI dazu beitragen, Integrationsprobleme frühzeitig zu erkennen und zu beheben. In der Praxis scheitert CI jedoch oft an unzureichender Testabdeckung oder instabilen Build-Prozessen. Ein fehlerhafter Build kann das gesamte Team lahmlegen und führt nicht selten zu Frustration.

Scrum hingegen fokussiert sich stärker auf den organisatorischen Aspekt der agilen Entwicklung. Es bietet eine klare Struktur mit definierten Rollen (Scrum Master, Product Owner, Entwicklungsteam) und festgelegten Prozessen (Sprints, Dailys, Retrospektiven). Doch auch hier gibt es in der Praxis häufig Probleme. Viele Teams setzen Scrum ein, ohne wirklich zu verstehen, was es bedeutet, agil zu sein. So werden Sprints geplant und Dailys abgehalten, doch die eigentliche Flexibilität und Anpassungsfähigkeit, die Agilität ausmacht, bleiben auf der Strecke. Der Sprint-Backlog wird oft als in Stein gemeißelt angesehen, was dazu führt, dass Teams stur Aufgaben abarbeiten, ohne auf Änderungen einzugehen.

Der Aufstieg und die Tücken agiler Methoden

Agile Methoden erlebten in den 2000er-Jahren einen beispiellosen Aufstieg. Viele Unternehmen sahen in Scrum und XP die Lösung für ihre Probleme in der Softwareentwicklung. Die Methode versprach schnellere Lieferzeiten, bessere Produktqualität und eine höhere Kundenzufriedenheit. Diese Versprechen führten dazu, dass Scrum weltweit implementiert wurde, oft ohne die zugrunde liegenden Prinzipien vollständig zu verstehen.

Das Problem liegt oft in der oberflächlichen Implementierung. Unternehmen führten Scrum ein, weil es als Best Practice galt, ohne jedoch die notwendigen kulturellen und strukturellen Veränderungen vorzunehmen, die für eine erfolgreiche agile Transformation erforderlich sind. Dies führte dazu, dass viele Teams zwar formell nach Scrum arbeiteten, in Wirklichkeit jedoch weiterhin in traditionellen, hierarchischen Strukturen gefangen waren. Die Folge war Frustration bei den Entwicklern und ein Gefühl der Entfremdung, da sie das Gefühl hatten, in einem Prozess gefangen zu sein, der wenig mit echter Agilität zu tun hatte.

Agilität als Cargo-Kult: Wenn der Schein trügt

Ein häufiges Phänomen, das in agilen Teams beobachtet wird, ist das sogenannte Fake-Agile. Hierbei handelt es sich um eine oberflächliche Anwendung agiler Methoden, bei der die Rituale und Praktiken zwar durchgeführt werden, aber die eigentlichen Prinzipien dahinter ignoriert werden. Ein typisches Beispiel ist die Durchführung von Sprints, die über Wochen oder sogar Monate gehen, anstatt die Arbeit in kurze, überschaubare Iterationen zu unterteilen. Auch Dailys, die eigentlich als kurze Abstimmungsmeetings gedacht sind, werden oft zu langen Statusmeetings, bei denen der Fokus auf der Berichterstattung liegt und nicht auf der Problemlösung.

Ein reales Beispiel aus meiner eigenen Erfahrung: In einem großen Unternehmen wurde Scrum eingeführt, um die Entwicklungsprozesse zu verbessern. Doch anstatt das Team in die Planung des Sprint-Backlogs einzubeziehen, diktierte der Product Owner die Aufgaben, die erledigt werden mussten. Die Entwickler fühlten sich nicht nur übergangen, sondern auch überfordert, da die Vorgaben oft unrealistisch waren. Das Resultat war eine sinkende Produktivität und ein zunehmendes Misstrauen gegenüber der Methode. Am Ende wurde Scrum für das Scheitern verantwortlich gemacht, obwohl es in Wirklichkeit nie richtig angewendet wurde.

Agilität als Deckmantel einer Hidden-Agenda

Noch problematischer ist das Phänomen des Dark-Agile – der bewussten Fehlanwendung agiler Prinzipien, um andere, oft fragwürdige Ziele zu erreichen. Unter dem Deckmantel von Scrum oder XP wird eine vermeintlich agile Vorgehensweise praktiziert, die in Wahrheit darauf abzielt, Kontrolle über die Mitarbeiter zu erhöhen oder politische Ziele im Unternehmen zu verfolgen. In diesen Fällen wird Agilität als Vorwand genutzt, um Projekte zu manipulieren oder Teams bewusst scheitern zu lassen, um etwa Machtkämpfe zu gewinnen oder Budgetkürzungen durchzusetzen.

Ein Beispiel für Dark-Agile: Ein Unternehmen führte Scrum ein, um die Eigenverantwortung der Teams zu stärken. Gleichzeitig wurde jedoch ein Überwachungstool installiert, das die Produktivität der Mitarbeiter minutiös überwachte. Die Entwickler fühlten sich überwacht und demotiviert, da sie das Gefühl hatten, ständig unter Beobachtung zu stehen. Die vermeintliche Agilität entpuppte sich als Deckmantel für ein striktes Kontrollregime, das die Motivation und Kreativität der Entwickler erstickte.

Der agil-industrielle Komplex: Wenn Geld wichtiger wird als Qualität

Ein weiteres Problem, das agile Methoden in Verruf bringt, ist ihre zunehmende Kommerzialisierung – der agil-industrielle Komplex. Organisationen wie Scrum.org und die Scrum Alliance haben ein lukratives Geschäft mit Zertifikaten, Schulungen und Workshops aufgebaut. Diese Entwicklung hat dazu geführt, dass Agilität zunehmend als Produkt vermarktet wird, das man kaufen kann, anstatt als eine Methodik, die man verstehen und anwenden muss. Viele Unternehmen investieren in teure Zertifizierungen für ihre Mitarbeiter, oft ohne sicherzustellen, dass diese Schulungen tatsächlich zu einer besseren Arbeitsweise führen.

Ich erinnere mich an einen Kollegen, der nach einer teuren Scrum-Zertifizierung noch immer unsicher war, wie er die Methoden in seinem Team sinnvoll anwenden sollte. Die Schulung hatte ihm zwar das Zertifikat gebracht, aber keine wirkliche Klarheit über die Herausforderungen in der Praxis. Am Ende musste er sich das meiste Wissen durch eigene Erfahrungen und durch die Unterstützung erfahrener Kollegen aneignen. Dies zeigt, dass Zertifikate oft mehr über die Fähigkeit aussagen, einen Test zu bestehen, als über die tatsächliche Kompetenz, agile Methoden in der Praxis erfolgreich anzuwenden.

Gibt es Alternativen?

Wenn Agilität, wie sie oft praktiziert wird, nicht die erhofften Ergebnisse bringt, was sind dann die Alternativen? Eine Möglichkeit ist, sich auf die ursprünglichen Prinzipien des Agilen Manifests zu besinnen und diese unabhängig von kommerzialisierten Methoden anzuwenden. Statt sich in teuren Schulungen und Zertifikaten zu verlieren, könnten Teams in gezieltes Coaching investieren, das auf ihre spezifischen Bedürfnisse zugeschnitten ist.

weniger formalisierte Alternative zu Scrum. Es ermöglicht eine kontinuierliche Auslieferung und eine Visualisierung des Arbeitsflusses, ohne die starren Strukturen, die Scrum manchmal auferlegt. Kanban eignet sich besonders gut für Projekte, bei denen Anforderungen häufig wechseln oder in denen die Priorisierung dynamisch angepasst werden muss.

Lean-Prinzipien sind eine weitere Alternative, die den Fokus auf kontinuierliche Verbesserung und die Vermeidung von Verschwendung legen. Lean hilft Teams, ihre Prozesse pragmatisch zu gestalten und sich auf das Wesentliche zu konzentrieren, ohne unnötigen Ballast. Diese Prinzipien können dazu beitragen, agile Methoden effektiver und zielgerichteter umzusetzen, ohne in die Fallen des „agil-industriellen Komplexes“ zu tappen.

Ein Beispiel für eine erfolgreiche Kombination aus Kanban und Lean: Ein Softwareunternehmen entschied sich, Scrum zu verlassen und stattdessen Kanban in Verbindung mit Lean-Prinzipien anzuwenden. Durch die Visualisierung des Arbeitsflusses auf einem Kanban-Board und die konsequente Fokussierung auf die Beseitigung von Engpässen konnte das Team die Durchlaufzeit ihrer Aufgaben erheblich verkürzen. Gleichzeitig wurde die Zusammenarbeit im Team verbessert, da jeder jederzeit den Status der Arbeit nachvollziehen konnte. Der Fokus auf kontinuierliche Verbesserung führte dazu, dass das Team seine Prozesse regelmäßig überprüfte und optimierte, was zu einer nachhaltigen Steigerung der Produktivität führte.

Aufruf zur Diskussion

Agile Methoden wie Scrum und XP sind seit Jahren fest in der Softwareentwicklung verankert, aber sind sie wirklich noch zeitgemäß? Haben Sie in Ihrem Unternehmen ähnliche Erfahrungen gemacht? Welche alternativen Methoden haben Sie ausprobiert? Diskutieren Sie mit und teilen Sie Ihre Meinung. Lassen Sie uns gemeinsam herausfinden, ob es an der Zeit ist, Agilität neu zu definieren.