Sich häufig wiederholende Muster, die einen agilen Change spannender als notwendig gestalten.

Eine Organisation sieht sich mit mehreren Herausforderungen konfrontiert. Der Begriff Digitalisierung ist überall zu finden, die Medien berichten vom rückständigen Wirtschaftsstandort Deutschland und die Politik hadert mit dem Breitband-Internet.
In diesem gefühlten Chaos der Umbrüche wird der Begriff der Agilität als zentrales und einzig wahres Allheilmittel auserkoren. Durch agiles Arbeiten können schließlich Kosten gespart werden und die Arbeit wird schneller („warum heißt das denn sonst Sprint?“).
Auch wenn die Digitalisierung der eigenen Produkte und Dienstleistungen ohne ein agiles Mindset (was nicht bedeutet, dass Kanban und Design Thinking gemacht werden müssen) kaum denkbar sind, so darf eine agile Transformation nicht als Lösung für alles dargestellt werden. Die Erwartungshaltung der Mitarbeiter steigt in dem Fall so weit an, dass auch der erste Rückschlag zu Zynismus und einer „ich habe es doch gewusst“ Mentalität führen kann.

Der Name des Anti-Patterns ergibt sich aus „Parkinsons law of triviality“ welches sinngemäß übersetzt das Folgende besagt: In Projekten verhält sich die Dauer von Diskussionen zu einer Entscheidung umgekehrt proportional zu ihrer Tragweite. Zum Verständnis führt er dabei das folgende Beispiel an: Bei dem Bau eines Atomkraftwerkes kann es durchaus länger dauern, sich über den Fahrradschuppen der Mitarbeiter einig zu werden, als über den Meiler mit seinen Kühltürmen selbst.

Übertragen auf agile Veränderungsprojekte finden sich viele passende und absolut triviale Diskussionsgründe, welche den Fortschritt unnötig lange hinauszögern:

• Was steht auf den neuen Visitenkarten?
• Welche agile Projektmanagementsoftware setzen wir ein und wer darf sie administrieren?
• Muss das Daily Meeting wirklich jeden Tag stattfinden?
• Wer muss/darf/soll am Review Meeting teilnehmen?
• Ist es sinnvoller, ein Kanban-Board an der Wand zu pflegen oder im Software-Tool? Muss es ggf. sogar redundant sein?

Es finden sich hier noch viele weitere Beispiele, die der Denke folgen, dass solche Dinge zuerst geklärt werden müssen. Dabei sollte Agilität ihrem eigenen Vorbild folgen. Prioritäten in der Umsetzung müssen gesetzt werden und der Fokus des Veränderungsvorhabens darf nur auf diesen liegen. In Fall solcher Trivialentscheidung ist es dabei hilfreich, einfach erst einmal die zweitbeste Lösung zu finden. Agil zu handeln, bedeutet hier auch in kleinen Schritten zu beginnen und continous improvement zu leben.

Das Top-Management lässt sich im Intranet über die neue agile Initiative interviewen. Schließlich fällt der Begriff mehrfach in der frisch präsentierten Unternehmensstrategie. Gegebenenfalls berichten sogar Medien über dieses Leuchtturm-Projekt oder ein eigener Youtube-Film wird produziert.

Im Hause steigt der Verbrauch von Post-It-Zetteln exponentiell an, ehemalige Besprechungsräume werden für agile Experten exklusiv blockiert. Die Anzahl von Wandkalendern verschiedener Beratungsfirmen mit Überschriften wie „Scrum, Kanban oder SAFe“ nehmen zu und Gespräche machen die Runde, wer jetzt alles eine Scrum Master Zertifizierung erhalten hat.

Weiter entfernt vom agilen Leuchtturm zeigt sich aber ein anderes Bild. Der normale Sachbearbeiter versteht nicht, worum es geht. Er informiert sich selber und wird von den Versprechen von Leadership und Selbstorganisation enttäuscht, da sich im Umfeld seiner Führungskräfte nichts verändert. Er weiß auch aus der Erfahrung, dass sich hier nichts verändern wird. Der agile Veränderungsprozess ist in großer Gefahr. Wie in jedem Change-Projekt müssen die Mitarbeiter mitgenommen werden. Nur geht es bei Agilität um eine Veränderung der persönlichen Haltung. Nicht nur um die Einführung einer Software oder um den Wechsel des Inhabers des Unternehmens. Die Haltung, das Mindset, ist geprägt durch das Leben und wird mit Werten und Erfahrungen unterfüttert. Agile Experten sollten hier sehr sensibel handeln.

Ein Pferd zieht seine Kutsche. Dementsprechend ist die Kutsche auch hinter das Pferd gespannt. Anders herum wäre die Reihenfolge falsch. Es kommt aber vor, dass – häufig durch Aktionismus – Entscheidungen in agilen Transformationsvorhaben getroffen werden, die in einer anderen Reihenfolge mehr Sinn gemacht hätten. Falls überhaupt. In dem Fall wird die Kutsche nun mal vor das Pferd gespannt. Unabhängig davon, ob das überhaupt funktionieren kann.

Denn auch wenn es eine schöne Geste ist, alle aktuellen Projektmanager sofort zum Scrum Master zu zertifizieren und dies unabhängig davon, ob sie überhaupt ein Pilotprojekt zum lernen haben, stellt sich die Frage: „Hat das die höchste Priorität?“ Wäre es nicht sinnvoller gewesen, das Management erst einmal zum Thema Leadership abzuholen und Agilität von ihren Werten und Prinzipien her zu initiieren, statt ausgehend von einem Framework?
Wäre es nicht besser gewesen, wenn man sich über die zukünftige Ausprägung von Agilität im Hause Gedanken gemacht hätte und was dies für Führungskräfte bedeuten wird? Das Management müsste sich doch die Fragen stellen, was erreicht werden soll. Was ist das Ziel und was sind Akzeptanzkriterien des Veränderungsvorhabens? Es kann sich dabei durchaus herausstellen, dass Scrum als Framework nicht das Mittel der Wahl sein wird.

(Drei potenzielle Ziele agiler Transformationen beschreibe ich in diesem Artikel: https://www.cassini.de/inspire/drei-ziele-der-agilen-transformation.)