Die drei Wege ins Glück, oder besser gesagt ins Unglück, sind, wie ein Unternehmen garantiert nicht agil wird. Wenn Sie keine schnellere Time-to-Market wünschen, nicht auf Ihre Kunden eingehen wollen, aber dennoch den Anschein erwecken möchten, agil zu sein und bemüht zu transformieren, folgen Sie einem der drei Wege – oder am besten folgen Sie allen dreien, nur um sicherzugehen.
Die letzten Jahre haben gezeigt: Wer auf dem Markt erfolgreich sein will, kommt um neue Formen der Unternehmensführung und Strukturierung nicht herum. In einer Zeit, in der die Märkte weniger vernetzt waren, Kunden nicht miteinander in Austausch gehen, also Erfahrungen zu Produkten teilen konnten, war es für die meisten Unternehmen einfacher. Auch konnten Methoden, die in einem anderen Unternehmen funktioniert haben, einfach auf das eigene übertragen werden. Nicht umsonst sind heute die meisten Unternehmen nach dem gleichen Muster aufgebaut, unterteilt nach Einheiten mit dem Ziel, möglichst effizient zu arbeiten. Und mit Effizienz ist in diesem Fall gemeint, effizient bzgl. der eigenen Aufgaben, nicht Richtung Kunde.
Dieses Verhalten, die Übernahme von Methoden, teilweise Best Practices genannt, lässt sich auch heute noch gut beobachten. Erfolgreiche Unternehmen kopieren einfach stumpf eine Idee und implementieren sie im eigenen Unternehmen, mit der Annahme, die gleichen Effekte wie im beobachteten Unternehmen zu erzielen. Die Implementierung einer Methode wird zum Selbstzweck. Manche Unternehmen gehen oberflächlich noch weiter und wählen einen der drei Wege ins Unglück.
- Weg 1 – „Wir planen die Transformation“: Natürlich muss es gut durchdacht und von A bis Z geplant sein. Wir können keine Transformation angehen, ohne diese geplant zu haben, wir müssen ja wissen, wann es losgeht, wann es beendet ist, also wann wir endlich agil sind und natürlich auch, was es kostet.
- Weg 2 – „Wir brauchen ein eigenes Framework“: Ist mal ein Plan gemacht (oder auch keiner), deutet sich in einem Unternehmen nur der Wille an, kommen sofort Bedenken und Bedenkenträger. Wie, wir wollen Scrum einführen? Das ist doch nur für Teams, wir sind hier ein Konzern und überhaupt geht das bei uns nicht, wir sind anders, wir müssen unser eigenes Framework entwickeln, das zu unseren Rahmenbedingungen passt.
- Weg 3 – „Change-Team, mit Plan und Soll-Ist-Vergleich“: Plan und eigenes Framework, natürlich muss der Plan auch kontrolliert werden und ein Soll-Ist-Vergleich stattfinden, dafür brauchen wir ein Change-Team, das sich dieser Thematik annimmt. Bitte das Change-Team auch damit beauftragen, ein Framework und einen Plan zu entwickeln. Und ganz wichtig: Das muss geheim bleiben, mit niemandem reden, das würde nur für Verunsicherung sorgen (es werden vielleicht Menschen entlassen oder Ähnliches). Wir müssen das erst gut durchdenken und dann alle mitnehmen, damit es auch klappt.
Ich glaube, die meisten von uns kennen solche Szenarien nur zu gut und haben erlebt, wie gut oder eher schlecht sie funktionieren.
Die ReG AG stand vor einigen Jahren vor einer ähnlichen Herausforderung (Abb. 1). Die Messe lief deutlich schlechter als erhofft, die Kunden waren überhaupt nicht begeistert vom vorgestellten Produkt. Der Vorstand hat zwei Maßnahmen ergriffen: Einen neuen Vertriebsvorstand geholt und Richard und seine designierte CTO, Silke, damit beauftragt, das Unternehmen zu transformieren. Richard kannte das laut eigener Aussage bereits, für ihn war Agilität etwas für Hippies, die sich nicht an Zahlen messen lassen wollten. Daher forderte er vehement ein, dass die Transformation gründlich geplant wird.
Abb. 1: Die ReG AG steht vor der Herausforderung
Der erste Weg
Richard schlug folgenden Transformationsplan vor: Wir haben ein Kick-off-Meeting, zu dem alle kommen müssen. Im Kick-off bestimmen wir, welche Teams (falls sie schon existieren) jetzt nach Scrum oder anderen Frameworks arbeiten. Ganz wichtig: Wir überlassen es nicht den Teams, ihre Methode selbst zu wählen. Wir bestimmen, wer der Product Owner sein wird und wer der Scrum Master. Da die ReG AG hier keine Erfahrung hat, kaufen wir uns einen ein, oder schicken schnell jemanden auf die zweitägige Scrum-Master-Schulung, die reicht dann schon, um als Scrum Master im Unternehmen tätig zu sein. Wer wird der Product Owner? Nehmen wir am einfachsten den Projektleiter des Teams, der hat das jetzt auch schon gut gemacht. Schulung für ihn sparen wir uns, dass kann dann der Scrum Master richten, so anders ist Scrum nun auch wieder nicht.
Dann richten wir uns einige Meilensteine ein, um zu schauen, wie das Team oder die Teams nach Scrum arbeiten, in die ersten Reviews werden die Chefs eingeladen, die dann absegnen, dass die Arbeit gut, also richtig gemacht wurde. Die Vorschläge vom Scrum Master, auch Kunden einzuladen, wischen wir mit dem Kommentar vom Tisch, dass das bei uns nicht geht, wir sind die Experten, nicht die Kunden.
Der zweite Weg
Nachdem wir nun über den ersten Weg gesprochen haben, schauen wir uns den zweiten Weg zum (Un-)Glück an: Wir entwickeln unser eigenes Framework. Warum? Nun, Scrum kommt aus der Softwareindus-trie und wir sind kein Softwareunternehmen, und selbst wenn wir eins sind, ging das vielleicht in Amerika, aber in Deutschland geht das nicht, schon allein wegen unserer Qualitätsansprüche; wir müssen schließlich am Ende genau wissen, was rauskommt. Also bilden wir ein Team aus Experten, kaufen Expertise hinzu, lesen viele Bücher.
Wir nehmen uns den Scrum Guide und schauen, was bei uns funktionieren könnte und was nicht. Wir ignorieren mal die Frage, ob es dann überhaupt noch eine Transformation gibt oder ob wir nur versuchen, Scrum in unsere Prozesse zu pressen (es sollte doch eher umgekehrt sein, die Prozesse und aktuellen Verhalten hinterfragen, um an dieser Stelle besser zu werden). Nein, wir schauen uns Scrum an und ändern es ab, und da Scrum nur für Teams ist, brauchen wir mehr. Wir nehmen z. B. SAFe. SAFe hat viele Ebenen, Rollen, Artefakte etc., aber auch diese passen den wenigsten Unternehmen.Scrum hätte ein kleines Team binnen Tagen oder Stunden anpassen (natürlich verschlimmbessern) können, bei SAFe braucht es schon länger. Nehmen wir uns wieder den Plan von Weg 1 vor und verschieben den Kick-off um mindestens sechs Monate. In diesen sechs Monaten erarbeiten wir ein neues Framework, das genau auf uns zugeschnitten ist, was wir dann stolz beim Kick-off vorstellen.
Der dritte Weg
In den dritten Weg kann Weg 1 und 2 einfließen – der ultimative Weg zum Glück. Ein Change-Team oder Transformationsteam wird ins Leben gerufen und damit beauftragt, die Transformation zu planen, durchzuführen und zu kontrollieren. Dazu werden Weg 1 und Weg 2 angegangen, wenn möglich aber im Geheimen, um niemanden im Unternehmen mit halbgaren Ansätzen zu verunsichern. Ganz nach dem Ansatz von Taylor, das Denken (in dem Fall das Planen) und das Ausführen zu trennen. Es müssen für jeden Transformationsschritt KPIs festgelegt werden, etwa wie viele Scrum Master nach sechs Monaten existieren müssen, wie viele Teams, die nach Scrum arbeiten und so weiter. Die Teams müssen regelmäßig Folien zum Fortschritt der Implementationsmaßnahmen erstellen.
Fazit
Warum schafft es ein Unternehmen nicht, mit diesen drei Wegen agil zu werden? Weg 1 ist der Versuch einer deterministischen Planung, die im komplizierten Umfeld funktionieren mag, da hier Ursache und Wirkungsbeziehungen durch schlichtes Nachdenken (in diesem Fall durch Planen) erhoben werden können. Eine Transformation findet, da hier Menschen beteiligt sind und Menschen nicht planbar sind, im komplexen Umfeld statt, daher ist jeder Plan zum Scheitern verurteilt. Du kannst nicht mit einem Wasserfallplan agil werden.
Weg 2 impliziert etwas Ähnliches, Planbarkeit, und verwechselt Wissen mit Erfahrung. Um ein Framework anzupassen, benötige ich Erfahrung und nicht nur Wissen. Die meisten Menschen lernen gleich, nehmen wir als Beispiel das Kochen. Wenn ich kochen lerne, und das erste Mal ein Rezept ausprobiere, koche ich es strikt nach Rezept. Über die Zeit nehme ich Anpassungen vor, ich habe Erfahrungen mit dem Rezept gesammelt und würze es vielleicht anders, je nach dem, was ich bevorzuge. Nach vielen weiteren Erfahrungen bin ich dann fähig, eigene Rezepte zu entwickeln. Kaum jemand würde auf die Idee kommen, bei ersten Kochversuch das Kochbuch zu lesen und Änderungen am Rezept zu machen. Was beim Kochen nicht funktioniert, funktioniert auch beim Entwickeln von Methoden für eine Transformation nicht. Folge und verstehe Shu Ha Ri!
Und der dritte Weg glaubt weiterhin daran, dass eine Trennung von Denken und Ausführen sinnvoll ist und verwechselt Output mit Outcome. Auch die ReG AG hat erkannt, dass ein Transformationsplan oder ein eigenes Framework nicht dabei helfen werden, das Unternehmen agil auszustellen. Wie entscheiden Sie sich?
René Schröder ist seit 2001 erfolgreich als Agile Coach und Trainer in unterschiedlichen Branchen unterwegs. Seine Erfahrungen teilt er gerne in diversen Kolumnen. Seit 2020 veröffentlicht er außerdem die Panda Story (http://regsus.de/panda_story/), eine Geschichte, in der Ray, Howard und Britta eine agile Transformation bei der ReG AG erleben.
