Nicht schon wieder ... Teil 1

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

Im Rahmen einer agilen Veränderung wird in der betroffenen Organisation immer etwas Neues geschaffen. Verhalten und Praktiken verändern sich. Gegebenenfalls wird auch der Organisationsaufbau angepasst, um den agilen Arbeitsweisen besser zu entsprechen. Man findet sich als agiler Coach dabei in jedem Projekt in einem neuen Kontext wieder und genau das macht den Reiz der Aufgabe aus: Es gibt keine Blaupause. Jeder Klient, jeder Unternehmensbereich und jedes Team ist anders. Einfach ein Buch aus der Tasche ziehen und „Scrum machen“ reicht nicht, um agil zu sein.

Dennoch ist es durchaus sinnvoll, das Rad nicht immer neu zu erfinden. Wie auch in anderen Bereichen der Wirtschaft gibt es Muster, welche eine Orientierung geben können. Speziell die Soziologie, die Musik, aber auch das Handwerk der Softwareentwicklung hat sich intensiv mit Mustern auseinandergesetzt. Es hat sich der feststehende Begriff der Softwarepattern entwickelt. Diese sind bewährte Wege, um Softwareprojekte zu managen, Architekturen zu bauen oder den Code selbst zu schreiben. Ein Beispiel für ein solches Pattern ist das mittlerweile in fast jedem sozialen Netzwerk zu findenden „Lazy Loading“. Man kann es daran erkennen, wenn zum Beispiel auf den Pinnwänden von Facebook und Co. die Informationen beim Herunterscrollen sichtbar nachgeladen werden.

Jetzt gibt es aber bei allen positiven Verhaltensmustern auch immer das Gegenteil. Muster, die in einem Projekt nicht in Erscheinung treten sollten. Diese gibt es natürlich in der Softwareentwicklung, aber auch in Projekten, welche den Fokus haben, Agilität zu etablieren. Und da agile Veränderungsprojekte nicht immer reine Erfolgsgeschichten sind, sollen einige von ihnen hier angesprochen werden. Die Beschreibungen der folgenden „agilen Anti-Pattern“ basieren auf jahrelanger Erfahrung. Dementsprechend sind auch die Namen subjektiv und teilweise an Softwarepattern angelehnt.

„Der Goldene Hammer“

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 Fahrrad-Schuppen (the bycicle shed)“

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.

„Der Elfenbein-Leuchtturm“

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.

„Die Kutsche vor das Pferd spannen“

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.)

Artikel von:
Peter Kalvelage, Management Consultant, Cassini Consulting AG
Peter Kalvelage
Management Consultant
Seite teilen
Newsletter Cassini

Newsletteranmeldung

Sie möchten regelmäßig die neuesten Informationen zum Thema Digitalisierung und digitale Transformation erhalten und über spannende neue Jobangebote informiert werden?
Melden Sie sich kostenlos für unseren Newsletter an.


Ja, ich möchte den regelmäßigen Newsletter von Cassini erhalten. Weitere Informationen finden Sie in unseren Datenschutzbestimmungen.

*Pflichtangaben