Читать книгу Agile Transformation - Rini van Solingen - Страница 22

Der Umfang der Transformation wird durch denjenigen bestimmt, der sich für das zugrunde liegende Problem verantwortlich fühlt. Das ist der Transformations-Owner, wie wir bereits am Anfang von Teil B beschrieben haben. Wie ein »Product Owner« der Transformation trifft diese Person die Entscheidungen, und das beginnt bereits mit dem Umfang der Transformation. Natürlich macht diese Person das nicht alleine. Die Beratung mit den Beteiligten und dem Transformationsteam hilft, gute Entscheidungen zu treffen und für Unterstützung zu sorgen. Außerdem hilft es dabei, zu erkennen, wo die größte Herausforderung für die Organisation liegt. Gibt es z. B. eine Abteilung, bei der ein hoher Grad an Wissensverlust erwartet wird? Oder gibt es ein herausforderndes Projekt, das sich über mehrere Abteilungen erstreckt und womit gestartet werden kann? Schlussendlich liegt jedoch die Entscheidung über den Umfang beim Transformations-Owner.

FALLSTUDIE

Zu groß oder doch zu klein?

Eine mittelgroße kommerzielle Organisation stellte 2014 fest, dass die IT-Teams, die mit Scrum arbeiteten, schnell in der Lage waren, Anpassungen vorzunehmen. Das ging mit einer hohen Zufriedenheit des Fachbereichs einher. Der Rest der IT-Abteilung stand jedoch unter Druck. Projekte wurden regelmäßig verschoben und lieferten nicht immer das, was der Kunde erwartet hatte. Der Plan wurde aufgestellt, die komplette Entwicklungsarbeit zukünftig auf agile Weise durchzuführen. Man investierte in Trainings und versuchte lange Zeit, die richtigen Wertschöpfungsketten zusammenzustellen. Wie sehr man sich auch bemühte, es blieben viele Fragen und Unklarheiten bestehen.

Es wurde beschlossen, den Umfang der Transformation zunächst drastisch auf eine einzige Wertschöpfungskette zu verkleinern. Diese Wahl wurde dadurch getrieben, dass einige Stakeholder gerne ein größeres Projekt, das zu dieser Zeit bereits abgesegnet war, auf eine agile Weise durchführen wollten. Der Umfang war nun deutlich übersichtlicher, sodass die ersten Teams drei Wochen später starten konnten.

Die Teams arbeiteten gut zusammen, in einem festen Rhythmus von zwei Wochen. Das Ergebnis war noch nicht direkt für den Fachbereich wertvoll, weil Änderungen noch nicht in die Produktion eingebracht wurden: Der Betrieb war nämlich kaum beteiligt. Das führte täglich zu Problemen. Diese wurden von den Gegnern der Transformation genutzt, um die ganze Initiative anzuzweifeln.

Dennoch gelang es, die operativen Stolpersteine aus dem Weg zu räumen, wodurch sofort spürbarer Wert geliefert werden konnte und das Projekt eine Sogwirkung entwickelte. Verschiedene Initiativen, auf die der Fachbereich wartete, wurden zum Backlog hinzugefügt, weil sie schnell zu echten Ergebnissen führten. Auch die Anzahl der Teams wurde vergrößert. Weniger als ein Jahr nach dem Start wurde eine zweite und dann dritte Wertschöpfungskette gestartet. Der Betrieb wurde dabei von Anfang an mit einbezogen.

Indem man den Umfang verringerte, wurde ausreichend Vertrauen geschaffen, um die Transformation in größerem Umfang fortzusetzen. Diese Transformation von der Mitte nach außen hatte zu Beginn sicherlich unter viel Skepsis zu leiden, manchmal sogar unter bewusster Opposition. Da es anfangs nicht genügend Unterstützung gab, war die einzige Möglichkeit, kleiner zu beginnen und den Umfang im laufenden Prozess zu vergrößern. Es galt zunächst zu zeigen, dass es funktioniert, und dann hochzuskalieren. Aufgrund des starken Antriebs aus dem Fachbereich und der erzielten Ergebnisse hielt die IT keinem Gegenargument stand.

Indem man sich dem unguten Gefühl, nicht in Produktion gehen zu können, bewusst aussetzte und es verstärkte, war es notwendig, weiterzumachen. Wenn man einfach nur am Erstellen von großen Plänen festgehalten hätte, wären die Durchbrüche nie erreicht worden: erfolgreiche Wertschöpfungsketten mit dem Fachbereich am Steuer. Auch Jahresplanungen wurden vollständig überarbeitet und gegen feste Budgets mit stabilen Teams pro Wertschöpfungskette ausgetauscht.