Chef versteht agil nicht: Von falschen Erfolgsmetriken und der Meeting-Hölle

Inhaltsverzeichnis

Na, hatten Sie heute schon Ihr Daily Standup, Ihre Retro, Ihr Stakeholder-Meeting oder Ihre Project Refinement Session? Dann gehören Sie wahrscheinlich zu jenen, die man im Betrieb mit einer "agilen Transformation" beglückt hat. Das ist, so möchte man meinen, heutzutage ja kaum noch der Rede wert, denn agil sind oder werden seit Jahren schließlich alle Unternehmen so irgendwie.

Ein Kommentar von Martin Gerhard Loschwitz

Martin Gerhard Loschwitz ist freier Journalist und beackert regelmäßig Themen wie OpenStack, Kubernetes und Ceph.

In jenem "irgendwie" versteckt sich allerdings ein gewaltiger Haken – denn vielerorts werden agile Transformationen schnell zu einem Martyrium, durchgezogen ohne Sinn und Verstand, dafür aber mit aller Gewalt, und ohne sinnvolle Ergebnisse. Übrig bleibt von der einst hehren Idee dann meist nur noch ein schier endloser Meeting-Marathon, der effizientes und zielgerichtetes Arbeiten praktisch unmöglich macht.

Die agilen Prinzipien sind gut

Damit das klar ist: Das Problem sind keineswegs die Prinzipien agilen Arbeitens, wie die Verantwortlichen nach manchem gescheiterten Einführungsversuch gern behaupten. Grundlegende Ideen agilen Arbeitens, wie sie etwa im Agilen Manifest kodifiziert sind, sind nach aktuellem Stand der Wissenschaft effizient und hochgradig nützlich. Aktuelle Erkenntnisse der Soziologie belegen beispielsweise, dass sie hervorragend geeignet sind, die Zusammenarbeit in Teams kundenorientiert zu gestalten.

Und es ist ja auch nicht so, als hätten etwa die Autoren des Agilen Manifests sich ihre Erkenntnisse aus den Fingern gesogen. Vielmehr waren ähnliche Ansätze in vielen Firmen bereits im Einsatz, als es die IT in ihrer heutigen Form noch gar nicht gab. Der global erfolgreiche Autobauer Toyota ist hierfür ein hervorragendes Beispiel.

Die Umsetzung ist furchtbar

Verantwortlich für das Scheitern agiler Methoden sind stattdessen in der absoluten Mehrzahl der Fälle die Unternehmen selbst und ihr Vorgehen. Nach den Gründen für kapitale Fehlschläge braucht man meist nicht lange suchen: Los geht es oft schon damit, dass die Firmenleitung die Einführung eines bestimmten agilen Modells über die Köpfe der Belegschaft hinweg beschließt, sodass deren "Buy-In" fehlt.

Unvergessen ist etwa das zu zweifelhafter Berühmtheit gelangte Spotify-Video über Tribes und Chapters und pipapo, das poppig aufgemacht und mit markigen Worten ein bestimmtes Arbeitsmodell propagierte. Landauf und landab quälten Chefs ihre Leute mit ebendiesem Video, bis Spotify selbst sich zur Klarstellung veranlasst sah, es habe sich lediglich um eine Idee gehandelt. Bei Spotify sei diese aber wegen konzeptioneller Probleme gar nicht erst umgesetzt worden. Bis heute gibt es keine belastbaren Erhebungen darüber, wie viele Unternehmen sich noch immer mit diesem Modell herumschlagen, das nicht mal sein eigener Erfinder für praxistauglich hielt.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmmung wird hier eine Vimeo-Video (Vimeo LLC) geladen.

Vimeo-Video immer laden Vimeo-Video jetzt laden

Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Vimeo LLC) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.

Für sich selbst definieren die Chefitäten dabei nicht selten Ausnahmen noch und nöcher: Während man die unteren Ebenen der Firma ins Chaos stürzt, funktioniert im C-Level gefälligst alles weiter wie bisher. Das fängt bei der GF-Bordüre am Planungsbrett an und reicht bis hin zur völligen Verweigerung von Erkenntnissen, zu denen agile Arbeitsgruppen hinsichtlich des C-Levels eines Unternehmens gelangen. Die Hölle, das sind schließlich die anderen!

Woanders scheitert die Einführung agiler Arbeitsmethoden schon am Fehlen guter und erfahrener Trainer für Scrum, Kanban und die diversen Mischformen. In einem Hauruck-Verfahren werden dann meist Menschen, die sich freiwillig gemeldet haben, in entsprechende Kurse gesteckt, mit Wissen druckbetankt und sollen anschließend im Unternehmen die agile Transformation vorantreiben.

Selbst wenn aus diesen Menschen in kurzer Zeit hervorragende Trainerinnen und Trainer werden, kämpfen sie meist doch auf verlorenem Posten. Denn einerseits braucht es Zeit, die agilen Grundlagen und die der ausgewählten Methode zu verstehen und auch zu vermitteln. Das gilt umso mehr, wenn Teil des "Vermittelns" auch ein "Überzeugen" ist, weil die Betroffenen sich in die Einführung eines agilen Konzepts komplett nicht eingebunden fühlen. Und andererseits erwarten regelmäßig dieselben Manager, die agile Arbeitsweisen fordern, deutlich positive Ergebnisse unmittelbar nach dem Start eines agilen Piloten. Werden diese nicht in wenigen Wochen oder Monaten sichtbar, bricht eine merkliche Nervosität aus, die oft dazu führt, dass der gesamte agile Ansatz letztlich eingestampft wird. Plötzlich gilt dann doch wieder "Wasserfall" zusammen mit "außer Spesen nichts gewesen".

Besonders skurril ist dabei, dass das Management vielerorts gar nicht realisiert, dass agile Projekte andere Erfolgsmetriken haben können, als der Wasserfall-Ansatz – und andere Voraussetzungen benötigen, um erfolgreich zu sein. Wer über Bill und Unbill von agiler Transformation mit den KPIs von Stab, Linie und Wasserfall richtet, ist blödestensfalls a priori gar nicht in der Lage, erreichte Erfolge zu erkennen und zu bewerten. Trotzdem gelten solche Projekte dann flugs als "low performing", womöglich gar als gescheitert.

Es ist zum Davonlaufen: Holte man bei einem Segelboot die Segel ein und griffe stattdessen auf den kleinen Dieselmotor zurück – es käme kein vernünftiger Mensch je auf die Idee, den abnehmenden Diesel-Bestand im Tank als Beweis dafür zu verwenden, dass Segeln ja gar nicht funktionieren könne. Genau das passiert bei der Bewertung der Ergebnisse agiler Transformationen in vielen Firmen jedoch ohne Unterlass.

Meeting-Wahnsinn

Die gefährlichsten Auswirkungen haben zweifelsohne jedoch jene agilen Projekte, die auf halbem Wege verenden, ohne dass es jemandem auffällt. Das hat viele Gründe: Unternehmen gehen beispielsweise regelmäßig nicht sorgfältig genug dabei vor, die eigenen Teams auszuwählen, auf die klassische agile Entwicklungsmethoden wie Scrum oder Kanban sich überhaupt anwenden lassen. Infrastruktur beispielsweise lässt sich agil nur ausgesprochen schwierig betreiben. Ein Switch, der nicht im Rack hängt, kann nicht mit einer Konfiguration betankt werden, so sehr der Sprintplan das auch vorsieht. Hier liefert der klassische Wasserfall oft sogar bessere Ergebnisse.

Ein anderer Grund für halbtote Agiltransformationen sind banale Schlampereien beim Anwenden der Werkzeuge der gewählten agilen Methode. Eigentlich sinnvolle Werkzeuge wie Retros etwa werden gern zum allgemeinen Debattierclub, weil niemand auf die Einhaltung gesetzter zeitlicher Limits achtet. Das Standup-Meeting in Scrum, das eigentlich dazu dient, die Aufgaben des jeweiligen Tages sinnvoll aufeinander abzustimmen, wird stattdessen zur Rekapitulation der am vergangenen Tag durchgeführten Arbeiten. Und oft genug ebenfalls zum Debattierclub, weil die eigentlich geltenden Regeln niemand erzwingt. Werkzeuge wie Scrum- oder Kanban-Boards enden als De-Facto-Papierkorb, weil den einzelnen Zetteln darauf irgendwann schlicht keine praktische Relevanz mehr zukommt und auch keine Ordnung mehr zu erkennen ist.

Übrig bleibt dann ein absurder Meeting-Wahnsinn aus Dailys und Retros und Stakeholder-Meetings und etlichen anderen Meeting-Formen, die für produktive Arbeit kaum noch Zeit lassen. Aber letztlich, und das ist das Problem, auch nicht zu besseren Ergebnissen führen als das vorherige Modell.

Ganz oder gar nicht

Wer sich in einem oder mehreren der beschriebenen Situationen wiederfindet, muss jetzt innehalten und sich die Frage stellen, wie das Problem in den Griff zu kriegen ist. Unternehmen müssen lernen, dass agile Transformation Zeit benötigt, statt hyperaktiv agile Projekte abzuschießen, weil diese nach wenigen Wochen nicht zur gewünschten Effektivitätsverdoppelung geführt haben. Wer agile Methoden einsetzt, tut gut daran, sich an deren Regeln zu halten. So verlockend es aus Sicht von Engineers auch sein mag: Tiefgreifende technische Diskussionen gehören nicht ins Daily, sondern in hierfür angesetzte Einzeltermine. Hier sind auch die Unternehmen wieder gefordert, denn agile Coaches können von Projekten erst abgezogen werden, wenn die gegebenen Regeln dort verinnerlicht sind. Bis dahin ist ihre Führung wertvoll und essenziell für den Erfolg des Unterfangens.

Ferner ist es auch keine Schande, Scrum, Kanban & Co. wieder aus einem Unternehmen zu verbannen, falls sich ihre Einführung schlicht als nicht sinnvoll erweist. Hierzu ist es aber nötig, laufende Verfahren zu überwachen und falls nötig einzugreifen. Und wenn, dann aber bitte gleich richtig: Niemandem ist mit zahllosen Meetings geholfen, die weder Erkenntnis- noch Effizienzgewinne ermöglichen und die genauso gut eine E-Mail oder eine gut ausgearbeitete Wiki-Seite hätten sein können. Agil? Ja, gerne! Aber: mit Sinn, mit Verstand, und vor allem mit einem guten Plan.

(fo)