Agiles Pilotprojekt oder gleich "der große Wurf"?

Question

Hat jemand Erfahrungen, welcher Weg der agilen Transformation besser funktioniert: Zuerst in einem Teilbereich des Unternehmens mit einem agilen Pilotprojekt starten oder lieber gleich alle Ebenen/Abteilungen in die Transformation einbinden? Es geht um ein Unternehmen mit rund 200 Mitarbeitern.

Aus unserer Sicht hat beides Vor- und Nachteile. Ein Pilotprojekt bindet im ersten Schritt nicht so viele Ressourcen und einmal gemachte Learnings könnten gut auf andere Abteilungen übertragen werden. Andererseits erscheint es inkonsequent, dass nur ein kleiner Teil der Belegschaft agil wird, wenn doch eine grundsätzliche Veränderung der Unternehmenskultur Voraussetzung ist. Trennt ein Pilotprojekt die Belegschaft nicht in 2 Lager?

Freue mich auf Erfahrungen aus der Praxis.

Answer 1

Ich würde so etwas immer mit einem Pilotteam/Pilotbereich angehen. Das hat verschiedene Gründe.

Zum einen kostet eine solche Umstellung immer Zeit, da man sich an die neuen Arbeitsweisen gewöhnen muss und an vielen stellen neu einigen wie zusammen gearbeitet werden soll. Wenn ich das im ganzen Unternehmen gleichzeitig mache kann es im schlimmsten Fall dazu führen dass man das ganze Unternehmen lahmlege.

Zum Anderen, und was ich viel wichtiger finde, kann ich das was ich in einem Pilotteam lerne auf andere Teams übertragen. Und lernen wird man hier am Anfang immer sehr viel.

Gerade weil es vieles neu auszuhandeln und vielleicht auszuhalten gibt, hilft es wenn das Pilotteam auch komplett hinter der Umstellung steht und bereit ist die ersten Hürden zu nehmen sowie die ersten Fehler zu machen. Wenn ich stattdessen, kann ich alle gleichzeitig umstelle, dann ist der Effekt des "von einandern Lernens" deutlich geringer und viele Fehler werden mehrfach gemacht. Aushalten auch vor allem deshalb, da wenn ein Team agil arbeitet oft Dinge anders macht, als sie im Unternehmen bisher gemacht werden.

Von den Erfahrungen und Erfolgen, kann das Pilotteam dann ja auch regelmäßig berichten, so dass alle im Unternehmen wissen was passiert. Dann kann auch jedes andere Team bzw. jeder andere Bereich damit starten, sobald sie sich dazu bereit fühlen. da es nicht hilft, wenn ich Agilität verordne.

Abgesehen davon ist es auch im Sinne der Agilität, hier Schritt für Schritt vorzugehen und aus jedem Schritt etwas für die nächsten Schritte zu lernen.

Ich bin jetzt nur auf die Vorteile eingegangen, wenn es einen Pilotbereich gibt, weil ich davon abraten möchte, da ich es für zu gefährlich halte, dass man sich damit zu viel auf einmal vornimmt.

Ich hoffe, ich konnte dir die Frage dennoch etwas beantworten.

Answer 2

Wie die Frage und die erste Antwort bereits beinhalten, so gibt es für beide Optionen Vor- und Nachteile.

Ich möchte hier eine Lanze brechen für den Beginn im Großen und erläutere Gefahren, welche ich schon in mehreren Unternehmen genau so beobachten konnte:

---

Zielerreichung

Falls es konkrete Ziele der Transformation gibt (was leider zu selten der Fall ist), dann stellt sich die Frage, ob diese erreicht werden können, wenn man nur einen Teil transformiert.

Beispiel: Wir wollen die Feedbackzyklen mit den Anwendern vergleichen. Wir fangen eine Transformation im Kleinen an und nehmen nur die Softwareentwickler mit. Dann haben wir einen Großteil der Länge eines Feedbackzyklus, welche wir mit dieser Transformation gar nicht verändern können. Anforderungsstellung, Konzeption, nachgelagerter Test und Auslieferung sind dann weiterhin möglich sehr langwierig, auf wenige Termine im Jahr festgelegt und ob sich im Inneren des Unternehmens die Entwicklung anders aufstellt, hat für den Endkunden und den Feedbackzyklus mit Anwendern keine spürbare Bedeutung.

Eine fehlende Zielerreichung in Kombination mit Kosten und Schmerzen bei der Transformation können dafür Sorgen, dass Zweifel an der Sinnhaftigkeit der Transformation wachsen und diese gestoppt wird, noch bevor sie richtig gestartet ist.

---

Abhängigkeiten

Ein Kernelement einer agilen Transformation sind cross-funktionale Teams, welche Mehrwert für den Kunden/Anwender in kurzen Abständen liefern können. Was kann hier alles schief gehen, wenn man nur einen Teil des Unternehmens transformiert? Möglicherweise ist die Software mit so vielen Abhängigkeiten/Schnittstellen versehen, dass Änderungen nur in Kombination mit Änderungen in durch Schnittstellen versehenen Produkten ausgeliefert werden können. Die Verkürzung vom Lieferzyklus ist also durch diese Abhängigkeit möglicherweise stark begrenzt. Besprechungen in Retrospektiven, welche die Probleme aufdecken, können zu Frustrationen führen wenn es immer nur heißt, dass man da nichts machen könne (weil die anderen Bereiche eben noch nicht verändert werden sollen). Zusätzlich werden die potentiellen Verbesserungen nicht sichtbar, da die internen Veränderungen nicht bei den Anwendern/Kunden wahrnehmbar sind.

---

Karrieremodell

In vielen Organisationen gibt es wenig Aufstiegschancen für die Entwickler, so dass sie gezwungen werden, die Rolle zu wechseln, um weiter aufzusteigen. Das verändert je nach Unternehmen die Zusammensetzung eines Teams sehr häufig, so dass es schwer ist, stabile Teams zu bekommen. Gleichzeitig werden diese ehemaligen, erfahrenen Entwickler dann in andere Rollen gesteckt, wie z.B. Scrum Master oder Product Owner, welche sich dann einmischen in die Art der Umsetzungen, da hier ihre eigentliche Leidenschaft und ihre Erfahrung liegt, so dass sie es dem Team erschweren sich selbst zu organisieren und sich selbst erschweren, ihre eigentliche Rolle zu fokussieren.

In vielen Organisationen müssen außerdem Mitarbeiter darstellen, welches ihr Anteil an bestimmten Erfolgen ist, um damit Beförderungen oder Gehaltserhöhungen zu begründen. Dies sind individuelle Ziele, welche Teammitglieder zu Kontrahenten machen, was hinderlich ist, ein Team zu sein. Werden hier dann diejenigen Mitarbeiter belohnt, welche sich nach dem alten Modell richten (jeder denkt an sich, stellt seine Erfolge heraus, schiebt Probleme auf andere und ignoriert Priorisierungen, wenn es dem eigenen Erfolg im Wege steht), kann das in Kombination mit der Demotivation der anderen Mitarbeiter die Transformation massiv erschweren.

---

Dies nur als 3 Beispiele, was passieren kann, wenn man zu klein anfängt. Ich plädiere trotzdem aus meiner Erfahrung dafür, möglichst klein anzufangen, aber: Die Größe sollte so gewählt sein, dass Ziele auch erreichbar sind und das auftretende Probleme und Lösungen nicht auf eine Zeit in 3 Jahren geschoben werden, wenn auch andere Bereiche transformiert werden sollen, sondern möglichst schnell ernst genommen und angegangen werden, so dass bei Bedarf der Bereich der Transformation auch kurz- bis mittelfristig ausgeweitet und nicht an einem festen Plan der Transformation festgehalten wird.