Woran liegt es, wenn agiles Arbeiten scheitert?

Gibt es bei der Einführung agiler »Tools« Probleme, liegt der Grund für ein Scheitern meist nicht in den Praktiken selbst. Aber woran liegt es dann, dass agile Vorgehensweisen so häufig nicht die gewünschte Wirkung entfalten?

Scrum, Design Thinking & Co. stellen Teams und Führungskräften einen wirksamen und bewährten Rahmen zur Verfügung, in dem agiles Arbeiten möglich wird. Aber es gibt einige typische Hürden und Stolpersteine, die es auszuräumen gilt.

Die 11 Stolpersteine, die am häufigsten zum Fallen führen, habe ich dir hier aufgelistet. 

Meine Empfehlung: Identifiziere im 1. Schritt, welcher bei euch die größte Rolle spielt, gleiche das mit der Einschätzung des Teams ab und dann: macht ihr das Gegenteil davon:-)

11 Wirkungs-Killer

Wenn es nicht funktioniert, liegt das daran,

01.  dass Agilität angeordnet wird, statt auf das Prinzip Freiwilligkeit zu setzen und mit denen zu starten, die hoch motiviert sind und dafür brennen, dabei zu sein.

Die gibt es in jedem Unternehmen. Wenn auch nicht immer in der Mehrzahl ...

02.  dass die für den erfolgreichen Einsatz erforderlichen Fähigkeiten und die entsprechende Denkweise bei einer oft nur zwei Tage dauernden Schulung zum Erlernen einer agilen Methodik nicht trainiert werden können.

Denn eine agile Methode allein zeigt keinem Mitarbeiter, wie er selbst agil werden, Agilität bei Teammitgliedern anregen und ein agiles Mindset entwickeln kann.

 (Wie das geht, erfährst du in meinem kostenlosen Workbook "Agiles Mindset" mit Test "Wie agil bist du". Kannst du dir hier gleich holen:-) 

Es ist deshalb zu kurz gedacht, das Thema »Wir werden jetzt agil« allein über eine Schulung von Tools abzuhandeln, die dann auch noch nur in Bruchstücken und bis zur Unkenntlichkeit verzerrt eingeführt werden. Das ist zum Scheitern verurteilt.

03.  dass sich gerade in großen Organisationen die Strukturen zäh gegen Neuerung stemmen und betonharte Silos mit hohem Beharrungsvermögen nicht aufgebrochen werden können.

04.  dass agiles Arbeiten Hindernisse aufdeckt und Probleme sichtbar macht, die von den Teams nicht alleine überwunden oder gelöst werden können. Statt Rückhalt und Unterstützung vom Management und aus der Organisation wird dann häufig die Methode verteufelt und »zurückgerudert«.

05. dass sich Veränderungen selten sofort positiv auswirken und das Durchhaltevermögen und die Zuversicht nicht ausreichen.

06.  dass nur die »Rosinen« herausgepickt werden – also die Aspekte, die leicht umzusetzen sind und nah am gewohnten Arbeiten sind –, die notwendigen sonstigen Veränderungen aber auf die lange Bank geschoben und die alten Muster oft unbemerkt einfach weitergelebt werden.

07. dass sich die Kultur eines Unternehmens weder direkt beeinflussen noch mal eben schnell ändern lässt und häufig (noch) nicht zu der agilen Herangehensweise passt.

08.  dass relevante an der Transformation Beteiligte wie Kunden, das Management, die Geschäftsführung oder noch traditionell arbeitende Bereiche eine agile Zusammenarbeit nicht kennen oder sogar ablehnen.

09.  dass es in der Organisation keine klare Vorstellung davon gibt, was es bedeutet, agil zu arbeiten bzw. darauf umzustellen, und dass die Notwendigkeit unterschätzt wird, sich mit agilen Werten und Prinzipien auseinanderzusetzen. Oft wird den Teams genau dafür keine Zeit zugebilligt.

10.  dass Verantwortlichkeiten nicht geklärt sind und daraus resultierend Spannungsfelder zwischen den agilen Organisationsbereichen und der klassischen Linienorganisation existieren.

Um sie abzubauen, muss geklärt werden, wer welche Themen und Projekte verantwortet, wer die Mitarbeiter führt und welchen Grad an Autonomie man den Mitarbeitern zubilligt.

Dies muss allen Beteiligten transparent kommuniziert werden.

11.  dass es oft zu wenige »agile Vorreiter« aus der oberen Führungsebene gibt, die bereit sind, agile Strukturen und Haltungen zuzulassen, um diese in der Organisation zu fördern und zu verankern.

Viele Organisationen versuchen agiler zu werden, indem sie agile Praktiken einfach an die bestehenden Gewohnheiten anpassen. Ian Mitchell, ein Experte für agile Transformation, nennt den Wunsch dahinter treffend: 

»Bring us an agile way-of-working that matches what we already do.« Denn alles andere wird häufig als nicht effizient angesehen.

Immer wieder beobachte ich dieses Verhalten, das mich an den »Cargo Cult« erinnert: Man versteht darunter den Versuch, positive Effekte herbeizuführen, indem man das imitiert, von dem man glaubt, es führe zum Erfolg – ohne verstanden zu haben, was diesen tatsächlich ausmacht.

Ursprünglich stammt dieser Begriff aus der Beobachtung von Bewohnern der melanesischen Inseln, die während des Zweiten Weltkriegs mit vom Flugzeug aus abgeworfenem Frachtgut (englisch cargo) wie Kleidung, Konservennahrung und anderen begehrten westlichen Gütern nur so zugeschüttet wurden.

Als mit dem Kriegsende kein weiteres »Cargo« mehr abgeworfen wurde, imitierten die Inselbewohner in der Hoffnung, so die Flugzeuge wieder herbeizaubern zu können, die Praxis, die sie bei den Fliegern gesehen hatten:

Sie bauten beispielsweise Flugzeugmodelle in Originalgröße aus Stroh, schufen Anlagen, die den militärischen Landebahnen nachempfunden waren, schnitzten Kopfhörer aus Holz und trugen sie, als würden sie im Flughafentower sitzen, positionierten sich auf den Landebahnen und imitierten die wellenartigen Landungssignale.

Gerade im Scrum-Umfeld erlebe ich oft, dass durch die Verwendung von Scrum-Begriffen für ansonsten weitgehend unverändertes Vorgehen Agilität ebenfalls »herbeigezaubert« werden soll: 

Traditionelle Führungskräfte nennen sich »Chief Product Owner«, die Teamleiter darunter werden jetzt als »Product Owner« bezeichnet, müssen sich aber gegenüber dem »Chief« und diversen kreativ neu benannten Gremien aus alten Zeiten nicht nur verantworten, sondern sich auch Entscheidungen wie in einer herkömmlichen hierarchischen Unternehmensstruktur genehmigen lassen.

Aufgabenlisten heißen jetzt »Product Backlog«, bisherige Projektleiter »Scrum Master«. Allerdings soll dieser wie zuvor dafür sorgen, dass die Teams tun, was die Führungskräfte anweisen, und er wird schnell abgesetzt, wenn er Probleme im Team nicht beseitigt.

Klassische Teammeetings heißen nun »Retrospektive«, allerdings geben anstelle der Teammitglieder der Product Owner und der Scrum Master vor, was zu ändern ist.

Sehr beliebt ist auch, die Rollen Product Owner und Scrum Master in einer Person zu vereinen, nach dem Motto: Hauptsache, es gibt sie. Mit Scrum hat das alles rein gar nichts zu tun – und agil ist das auch nicht!

Bei diesem Vorgehen zeigt sich deutlich, dass weder der Sinn noch die Funktionsweise oder das Zusammenspiel in Scrum verstanden werden.

Das Verhalten ist ganz ähnlich dem der Melanesier, die nicht wussten, wozu ein Kopfhörer dient, und deren rein äußerliche Nachbildungen genauso wenig zum erhofften Ergebnis geführt haben, wie es in Unternehmen heute nicht gelingen kann, wenn nur zusammenhangslose Begriffe verwendet werden, deren Sinn nicht begriffen wird.

Es wird dann ganz im Gegenteil nicht lange dauern, bis man feststellt, dass Scrum weder besser noch schneller funktioniert als die davor verwendeten Methoden.

Und dann hält man es für logisch, dass es an Scrum liegen muss.

Nicht wenige kommen dann auf die scheinbar folgerichtige Idee, Scrum würde eben nicht zum Unternehmen passen und müsse entsprechend verbessert und angepasst werden.

Das wird ziemlich sicher in die Hose gehen, denn Scrum scheint zwar einfach, wirkt aber eben nur dann, wenn alle Bestandteile zusammenwirken und seine Prinzipien verstanden und gelebt werden.

Und dann? Dann wird eben eine andere Methode gewählt ...

Das traurige Ergebnis: Unternehmen, die diesen Weg zu lange gehen, zerstören die Motivation ihrer Mitarbeiter, bei der agilen Entwicklung mitzuwirken. Denn die dadurch entstehende negative Belegung der Begriffe »Scrum« oder »agil« ist kaum noch korrigierbar.

Organisationen müssen also verstehen und akzeptieren, dass eine agile Transformation eine umfassende Veränderung zahlreicher bisheriger Herangehensweisen bedeutet, dass diese Veränderungen agilen Prinzipien folgen sollten, Sinn haben und erfolgsentscheidend sind und dass es nicht möglich ist, sich nur die Rosinen – also all das, was gewohnt und einfach ist – herauszupicken.

Video: Agiles Arbeiten funktioniert am besten Achtsam