Diese Frage wurde mir mittlerweile so häufig gestellt, dass ich mir selbst den Gefallen tun möchte, eine Antwort zu formulieren, die mir auch in Momenten der absoluten Verwunderung sofort wieder einfällt.

Spoiler Alert: Die kurze Antwort ist nein. Die kurze Begründung lautet: Agil zu arbeiten bedeutet, interdisziplinär, iterativ und inkrementell Produkte zu entwickeln und kontinuierliche Verbesserung für ein Team und die Organisation dahinter zu ermöglichen. Das hat nur Nachteile, wenn man es sich explizit zum Ziel gemacht hat, zu versagen.

Auf der Suche nach dem verdammten Haken

Müsste ich einen Nachteil an Agilität benennen, so wäre es, dass die scheinbare Unterkomplexität agiler Frameworks im Angesicht der Komplexität zu meisternder Herausforderungen falsche Hoffnungen erweckt und dann nicht hinterfragt wird. Das Resultat ist, dass die frischen Scrum Master und Agile Coaches die immerhin zwei Tage Schulung und 80 Multiple Choice Fragen größtenteils richtig beantwortet hatten, immer wieder versuchen werden so lange mit dem Scrum Guide auf ein Problem zu hauen, bis ihnen entweder die Heftchen um die Ohren fliegen, oder die Organisationen dahinter kapitulieren: "Agile haben wir probiert, hat bei uns nicht funktioniert."

Auch wenn die Bibel des klassischen Projektmanagements -der PMBOK Guide - mit seinen 600 Seiten sicherlich auch übertreibt, kann die Hoffnung doch nicht sein, dass der Scrum Guide (19 Seiten!) alle Herausforderungen, die der Produktentwicklungsalltag so mit sich bringt, auf einmal mühelos erledigt. Oder doch?

Und nun sind wir wieder an der Stelle angelangt wo Menschen immer sagen: "Wenn Du nur einen Hammer hast, sieht jedes Problem aus wie ein Nagel." Die Betonung liegt hier in der Regel auf Hammer. Spannend wird's, wenn wir die Betonung auf einen verlagern. Der Hammer also nicht nur in Gestalt des Scrum Guides oder des PMBOKs daherkommt, sondern eine Vielzahl von Werkzeugen zur Verfügung steht, in Form von Methoden, Erfahrungen und Perspektiven.

No matter what they tell you, it's a people problem!

Bei der agilen Produkt- und der dazugehörigen Organisationsentwicklung geht es nicht darum, User Stories richtig zu schreiben oder darauf zu achten, dass dass die Retro so viele Stunden dauert, wie der Sprint Wochen lang war. Diese Hilfsmittel dienen, genau wie der Scrum Guide oder das agile Manifest, der Orientierung am Anfang einer Transition.

Wie bei jedem Werkzeug kommt es vor allem darauf an, wer es in der Hand hält! Manchmal muss der Hammer auch falsc(h)rum gehalten oder eben ein gänzlich anderes Werkzeug in Betracht gezogen werden. Und manchmal muss man auch den Mut haben zu sagen,"Ich hab leider keine Ahnung wie das geht, lasst uns gemeinsam überlegen, wie wir hier weiterkommen oder wer uns unterstützen könnte." In Heldenkulturen, wie wir sie sehr häufig vorfinden, erfordert so eine Haltung enorm viel Mut. Und Menschen zu unterstützen, die solch eine Haltung an den Tag legen erfordert ebenfalls Mut und ein besonderes Verständnis von Führung.

Und wo bleiben jetzt die Nachteile?

Wo stehen wir denn jetzt bezüglich der Eingangsfrage nach den Nachteilen der Agilität? Meine Antwort bleibt die gleiche: es gibt keine. Nur sollte endlich damit aufgehört werden, mit den Frameworks auch die Kontexte Ihrer Einsatzgebiete zu simplifizieren. 

Barack Obama hatte eine Plakette auf seinem Schreibtisch im Oval Office auf der stand "Hard things are hard". Diese Form von Demut kann dabei helfen, das Scheitern agiler Vorhaben nicht der Agilität an sich zuzuschreiben. Es ist sehr wahrscheinlich, dass anstrengende Entwicklungs- und Transitionsvorhaben auch weiterhin anstrengend sind und hoher Konzentration und Disziplin bedürfen. Das ist jedoch kein Nachteil von Agilität, sondern schon immer ein Merkmal qualitativ hochwertiger Arbeit.

Was mach ich jetzt damit?

Versuchen Sie doch mal folgende Fragen für sich zu beantworten: Welche Nachteile sehen Sie im agilen Arbeiten? Woran liegt es Ihrer Meinung nach, dass unsere Ansprüche an agile Entwicklung offenbar höher sind als an klassische Entwicklung? Stimmt das überhaupt? Angenommen, Sie müssten ein Element aus der klassischen Entwicklung in die agile Entwicklung "herüberretten", welches wäre das und was hat Sie bisher davon abgehalten es zu tun?

Ihre Antworten interessieren mich brennend!