Agile Transformation in Unternehmen

Agile Transformation (dt.) oder Agil Transition (eng.) bezeichnet den Übergang von einem klassischen Unternehmen, hin zu einem agilen Unternehmen. Im Rahmen des Führungskreis IT hatte ich die Gelegenheit mich mit diesem Thema zu beschäftigen und für euch die zentrale Fragen der Teilnehmer aufzubereiten.

Warum Agile Transformation?

Ein typisches Problem im IT-Umfeld sind sogenannte Change Requests oder Änderungsanträge. Das heißt der Fachbereich ist mit einer ausgelieferten Funktionalität noch nicht zufrieden und wünscht eine Änderung.  Häufig gibt es von diesem Change Request viel zu viele, alle scheinen gleich wichtig zu sein und sollten sofort umgesetzt werden. Natürlich bei konstanten IT-Ressourcen. 

In diesem Kontext kommt gerne der Ruf nach agilen Methoden. Schließlich verspricht Jeff Sutherland mit seinem genialen Buchtitel: „Scrum: The Art of Doing Twice the Work in Half the Time„. An diesem Punkt lohnt es sich das erste Mal skeptisch zu sein. Die doppelte Arbeit in der halben Zeit ist absoluter Bullshit. Dennoch lohnt sich ein vertiefter Blick auf SCRUM & Co, da diese Methoden für ein Umfeld mit hoher Änderungsrate konzipiert wurden. Agile Entwicklung macht Sinn, wenn sich min. 30% der definierten Anforderungen pro Monat ändern.

Wie gelingt Agile Transformation?

OK, wir haben Bereiche bei uns identifiziert die mit einer hohen Änderungsrate kämpfen. Jetzt wollen wir agil werden! Wie gehen wir es an? Wie sieht die Roadmap für eine agile Transformation aus? Leider gibt es hier kein Patentrezept.

Stattdessen hat sich in der Szene der Grundsatz durchgesetzt, die Transformation als ein agiles Projekt durchzuführen. Learning SCRUM by doing SCRUM. Dazu wird zunächst ein Transition-Team gegründet, das die Rolle des ScrumMaster der Organisation übernimmt. Zur Erinnerung, der SCRUM Master kümmert sich u.a. darum das SCRUM-Teams produktiv arbeiten können.

Das Transition-Team beauftragt SCRUM-Teams Produkte zu entwickeln. Diese SCRUM-Teams melden an das Transition-Team zurück, welche Probleme bei der agilen Entwicklung auftreten. Diese Prinzip kennen wir bereits aus der klassischen Organisationsentwicklung. Die Steuerungsgruppe setzt Projekt-Teams auf, um die strategischen Zielsetzungen zur Veränderung des Unternehmens zu erreichen. Mehr zum Transition-Team von Boris Gloger:

Bei der Veränderung hin zu einer agileren Organisation gibt es im Kern drei Ansatzpunkte oder Handlungsfelder.

1. Input

Wie erwähnt, kämpfen viele IT-Abteilungen mit zu vielen Change Requests die alle scheinbar gleich wichtig sind. Egal mit welcher Methode ich arbeite, es lohnt sich den Input ins System zu drosseln. Je länger die Warteschlange, desto träger wird das System. Der Fachbegriff im IT-Umfeld dazu lautet Demand Management. Nachfrage-Management trifft es aus meiner Sicht recht gut. Es geht darum den Input ins System besser zu koordinieren und priorisieren.

SCRUM bringt in diesem Zusammenhang zwei schöne Grundgedanken mit. Zum einen sagt nicht der Umsetzer (=IT-Abteilung) was umgesetzt wird, sondern der Kunde (=Fachabteilung). Das heißt die Fachabteilungen müssen vor dem Hintergrund einer begrenzten Umsetzungskapazität entscheiden, was in den Tunnel gelassen wird und in welcher Reihenfolge. Zum anderen gilt es diese Arbeit mit einem SCRUM-Board zu visualisieren. Siehe dazu auch den Beitrag „Agiles Qualitätsmanagement„.

2. Organisation

In den Bereichen wo es Sinn macht, also die Änderungsrate über 30% pro Monat liegt, lohnt es sich auf agilen Methoden wie SCRUM, Kanban oder Design Thinking zu setzen. Ohne auf die einzelnen Methoden im Detail eingehen zu wollen, erscheinen mir folgende Grundsätze wichtig:

1. Ask the team: Wir gehen davon aus das multidisziplinäre Teams schlauer sind und geben ihnen deshalb die Umsetzungsverantwortung. Ähnlich einer Task Force.
2. Deliver: Wir wollen in kürzeren Abständen liefern. Hier bietet es sich an eine einheitliche Timebox über alle Teams zu legen, die nach agilen Methoden arbeiten.
3. Review: Im Anschluss an die Timebox muss es ein gemeinsames Review mit dem Auftraggeber geben, damit das Team schnelleres Feedback bekommt. Auch im Sinne eines gemeinsamen lernen.
4. Repeat: Wenn sich die agile Arbeitsweise bewährt hat, das muss sie nämlich nicht zwangsläufig, gilt es den Prozess zu wiederholen und dabei besser zu werden.

3. Output

Wie beim Input, gilt es auch beim Output Transparenz durch Visualisierung zu erzeugen. Ein SCRUM-Board bietet sich hierzu bestens an. Wenn es sein muss auch digital. Was man in diesem Zusammenhang von KANBAN lernen kann, ist der Fokus auf Prozessverbesserung durch passende KPIs.  WICHTIG! Häufig „fühlen“ sich die Mitarbeiter in SCRUM-Teams sehr wohl, weil die Kommunikation besser fliest. Das heißt aber noch lange nicht das der Output höher oder besser ist. 

Beispiele für Agile Transformation

Die Königsbeispiele einer agilen Transition sind immer wieder Spotify, Netflix und ING. Wer mehr über Squads, Tribes und Centers of Expertise erfahren möchte, dem empfehle ich den Artikel „DevOps – Auf dem Weg zur agilen Organisation?“ oder das dazu passende Video der ING:

Im Endausbau gäbe es bei einer vollständigen agilen Transformation des Unternehmens nur noch interdisziplinäre Teams, die sich im Netzwerk organisieren und Kundennutzen stiften. Wobei die grundsätzliche Spannung zwischen interner Logik und extern Anforderungen bestehen bleibt, sie wird nur ins Team verlagert.

Fazit – Agile Transformation in Unternehmen

Bei aller Begeisterung, die ich für das Thema habe, möchte ich mit einer Warnung schließen. Agilität macht nur Sinn, wenn sich min. 30% der definierten Anforderungen pro Monat ändern. Man könnte auch von komplexen Probleme (siehe CYNEFIN) sprechen.

Wenn dem nicht so ist, bitte sein lassen. Warum sollte ich im IT-Helpdesk SCRUM einführen? Blödsinn! Wer das trotzdem machen möchte, erliegt einem alten Traum, der eigentlich ein Alptraum ist. Abbau von Hierarchien, Auflösung von Abteilungen und Zurücknahme von Formalisierung. Was wir aktuell unter Management-Moden wie Holacracy und New Work erleben, erzeugt Schatten-Hierarchie. Deshalb muss zumindest die Durchlaufzeit vorher und nachher miteinander verglichen werden!

Dr. Patrick Fritz