Diese Frage wurde mir mitt­ler­weile so häufig gestellt, dass ich mir selbst den Gefal­len tun möchte, eine Antwort zu formu­lie­ren, die mir auch in Momen­ten der abso­lu­ten Verwun­de­rung sofort wieder einfällt.

Spoi­ler Alert: Die kurze Antwort ist nein. Die kurze Begrün­dung lautet: Agil zu arbei­ten bedeu­tet, inter­dis­zi­pli­när, itera­tiv und inkre­men­tell Produkte zu entwi­ckeln und konti­nu­ier­li­che Verbes­se­rung für ein Team und die Orga­ni­sa­tion dahin­ter zu ermög­li­chen. Das hat nur Nach­teile, wenn man es sich expli­zit zum Ziel gemacht hat, zu versagen.

Auf der Suche nach dem verdamm­ten Haken

Müsste ich einen Nach­teil an Agili­tät benen­nen, so wäre es, dass die schein­bare Unter­kom­ple­xi­tät agiler Frame­works im Ange­sicht der Komple­xi­tät zu meis­tern­der Heraus­for­de­run­gen falsche Hoff­nun­gen erweckt und dann nicht hinter­fragt wird. Das Resul­tat ist, dass die frischen Scrum Master und Agile Coaches die immer­hin zwei Tage Schu­lung und 80 Multi­ple Choice Fragen größ­ten­teils rich­tig beant­wor­tet hatten, immer wieder versu­chen werden so lange mit dem Scrum Guide auf ein Problem zu hauen, bis ihnen entwe­der die Heft­chen um die Ohren flie­gen, oder die Orga­ni­sa­tio­nen dahin­ter kapi­tu­lie­ren: “Agile haben wir probiert, hat bei uns nicht funktioniert.”

Auch wenn die Bibel des klas­si­schen Projekt­ma­nage­ments ‑der PMBOK Guide — mit seinen 600 Seiten sicher­lich auch über­treibt, kann die Hoff­nung doch nicht sein, dass der Scrum Guide (19 Seiten!) alle Heraus­for­de­run­gen, die der Produkt­ent­wick­lungs­all­tag so mit sich bringt, auf einmal mühe­los erle­digt. Oder doch?

Und nun sind wir wieder an der Stelle ange­langt wo Menschen immer sagen: “Wenn Du nur einen Hammer hast, sieht jedes Problem aus wie ein Nagel.” Die Beto­nung liegt hier in der Regel auf Hammer. Span­nend wird’s, wenn wir die Beto­nung auf einen verla­gern. Der Hammer also nicht nur in Gestalt des Scrum Guides oder des PMBOKs daher­kommt, sondern eine Viel­zahl von Werk­zeu­gen zur Verfü­gung steht, in Form von Metho­den, Erfah­run­gen und Perspektiven.

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

Bei der agilen Produkt- und der dazu­ge­hö­ri­gen Orga­ni­sa­ti­ons­ent­wick­lung geht es nicht darum, User Stories rich­tig zu schrei­ben oder darauf zu achten, dass dass die Retro so viele Stun­den dauert, wie der Sprint Wochen lang war. Diese Hilfs­mit­tel dienen, genau wie der Scrum Guide oder das agile Mani­fest, der Orien­tie­rung am Anfang einer Transition.

Wie bei jedem Werk­zeug kommt es vor allem darauf an, wer es in der Hand hält! Manch­mal muss der Hammer auch falsc(h)rum gehal­ten oder eben ein gänz­lich ande­res Werk­zeug in Betracht gezo­gen werden. Und manch­mal muss man auch den Mut haben zu sagen,“Ich hab leider keine Ahnung wie das geht, lasst uns gemein­sam über­le­gen, wie wir hier weiter­kom­men oder wer uns unter­stüt­zen könnte.” In Helden­kul­tu­ren, wie wir sie sehr häufig vorfin­den, erfor­dert so eine Haltung enorm viel Mut. Und Menschen zu unter­stüt­zen, die solch eine Haltung an den Tag legen erfor­dert eben­falls Mut und ein beson­de­res Verständ­nis von Führung.

Und wo blei­ben jetzt die Nachteile?

Wo stehen wir denn jetzt bezüg­lich der Eingangs­frage nach den Nach­tei­len der Agili­tät? Meine Antwort bleibt die glei­che: es gibt keine. Nur sollte endlich damit aufge­hört werden, mit den Frame­works auch die Kontexte Ihrer Einsatz­ge­biete zu simplifizieren. 

Barack Obama hatte eine Plakette auf seinem Schreib­tisch im Oval Office auf der stand “Hard things are hard”. Diese Form von Demut kann dabei helfen, das Schei­tern agiler Vorha­ben nicht der Agili­tät an sich zuzu­schrei­ben. Es ist sehr wahr­schein­lich, dass anstren­gende Entwick­lungs- und Tran­si­ti­ons­vor­ha­ben auch weiter­hin anstren­gend sind und hoher Konzen­tra­tion und Diszi­plin bedür­fen. Das ist jedoch kein Nach­teil von Agili­tät, sondern schon immer ein Merk­mal quali­ta­tiv hoch­wer­ti­ger Arbeit.

Was mach ich jetzt damit?

Versu­chen Sie doch mal folgende Fragen für sich zu beant­wor­ten: Welche Nach­teile sehen Sie im agilen Arbei­ten? Woran liegt es Ihrer Meinung nach, dass unsere Ansprü­che an agile Entwick­lung offen­bar höher sind als an klas­si­sche Entwick­lung? Stimmt das über­haupt? Ange­nom­men, Sie müss­ten ein Element aus der klas­si­schen Entwick­lung in die agile Entwick­lung “herüber­ret­ten”, welches wäre das und was hat Sie bisher davon abge­hal­ten es zu tun?

Ihre Antwor­ten inter­es­sie­ren mich brennend!