Agile Transformation: Workshop, Training oder Beratung — was passt wann?

„Wir müssen agiler werden" ist einer der häufigsten Sätze in deutschen Unternehmen — und einer der unpräzisesten. Denn hinter ihm verbergen sich völlig unterschiedliche Probleme: zu langsame Entscheidungen, Projekte ohne sichtbaren Fortschritt, Teams, die auf Zuruf arbeiten, oder schlicht der Druck, dass der Wettbewerb es angeblich schon ist.

Je nachdem, welches Problem tatsächlich vorliegt, ist die passende Maßnahme eine andere. In der Praxis wird diese Reihenfolge oft umgedreht: Erst wird das Format gebucht, ein Workshop zur agilen Transformation, eine Scrum-Schulung oder ein Beratungsmandat. Dann wird geschaut, welches Problem es lösen soll.

Drei Formate, drei verschiedene Wirkungen

Der Workshop zur agilen Transformation: Ausrichtung schaffen

Ein Workshop (typisch: zwei bis drei Tage) leistet vor allem eines: Er bringt Menschen, die sonst nicht gemeinsam an einem Tisch sitzen, zu einem gemeinsamen Verständnis. Was heißt agil für uns? Welche Probleme wollen wir damit lösen — und welche gerade nicht? Das Agile Manifest stellt Werte über Werkzeuge (Beck et al., 2001); genau diese Diskussion gehört an den Anfang, nicht die Tool-Auswahl.

Was ein Workshop nicht leistet: Verhalten verändern. Nach drei Tagen gehen alle zurück in unveränderte Strukturen, Meetings und Zielvereinbarungen. Wer vom Workshop allein eine Transformation erwartet, verwechselt Ausrichtung mit Umsetzung.

Passt, wenn: Führungskreis oder Team stehen am Anfang und brauchen ein gemeinsames Bild — oder eine konkrete Entscheidung (etwa: Pilotbereich auswählen, Vorgehen festlegen).

Das Training: Kompetenz für die agile Transformation aufbauen

Ein Training oder eine Schulung baut Fähigkeiten auf: Scrum sauber anwenden, ein Kanban-Board so führen, dass es Engpässe sichtbar macht, Anforderungen schneiden, mit KI-Werkzeugen im Projektalltag arbeiten. Kompetenz ist die Voraussetzung jeder Transformation — Teams, die die Methoden nicht beherrschen, können sie auch nicht anpassen.

Die Grenze: Training wirkt auf Personen, nicht auf Strukturen. Wer geschulte Mitarbeitende in unveränderte Prozesse zurückschickt, bekommt frustrierte Fachleute statt agiler Teams.

Für das Format hat diese Grenze Folgen. Ein einmaliger Blocktermin endet dort, wo die Anwendung beginnt: Ob eine Methode trägt, zeigt sich unter Termindruck im Projekt — also nach dem Training. Ein verteilter Rhythmus, etwa ein Trainingstag pro Monat, holt diesen Punkt in die Schulung zurück, weil zwischen den Terminen am eigenen Vorhaben weitergearbeitet wird und die Stellen, an denen es hakt, im nächsten Termin auf dem Tisch liegen. Prozesse ändert auch das nicht; es macht nur früher sichtbar, welche im Weg stehen.

Vorausgesetzt ist ein Zuschnitt auf das Unternehmen: Inhalte, Beispiele und Tempo richten sich nach den Teams und ihren laufenden Vorhaben, nicht nach einem festen Lehrplan. Welches Framework den Rahmen bildet — Scrum, Kanban, AgilePM, PRINCE2, ITIL 4 oder DevOps —, folgt aus der Arbeit, die ohnehin ansteht. Ort und Gruppengröße sind nachrangig: Ob vor Ort oder online gearbeitet wird und ob ein Team teilnimmt oder mehrere, wiegt weniger als die Frage, ob zwischen den Terminen tatsächlich geübt wird.

Passt, wenn: klar ist, welche Arbeitsweise etabliert werden soll, und die Lücke im Können liegt — nicht im Dürfen.

Die Beratung zur agilen Transformation: im Alltag verankern

Beratung und Team-Coaching setzen dort an, wo Workshop und Training aufhören: im Tagesgeschäft. Reale Sprints, reale Retrospektiven, reale Konflikte mit Stakeholdern. Die Beratung arbeitet an den Strukturen, die Verhalten erzeugen: Entscheidungswege, Schnittstellen, Priorisierung, Führungsverhalten.

Das ist das tiefgreifendste Format — und das teuerste. Es lohnt sich dann, wenn die Organisation die Veränderung ernst meint und Führung bereit ist, eigene Routinen infrage zu stellen.

Passt, wenn: die Grundlagen gelegt sind und es jetzt darum geht, die Arbeitsweise gegen den Alltag zu verteidigen.

Woran Transformationen tatsächlich scheitern

Die Beobachtungen zu Veränderungsprozessen sind seit Jahrzehnten erstaunlich stabil. John Kotter beschrieb schon 1996 aus seiner Beratungspraxis die typischen Fehlerquellen: fehlende Dringlichkeit, keine tragende Führungskoalition, Erfolge, die nicht sichtbar gemacht werden, und Veränderungen, die nie in der Kultur verankert werden (Kotter, Leading Change, 1996).

Auf agile Transformationen übersetzt heißt das:

1. Methoden statt Arbeitsweise. Daily, Board und Sprint-Review sind eingeführt — Entscheidungswege, Budgetierung und Zielvereinbarungen bleiben unverändert. Das Ergebnis ist Agilität als Fassade.
2. Delegation nach unten. Die Führung beauftragt die Transformation, nimmt sich selbst aber aus. Teams sollen sich ändern, das Steuerungsmodell nicht.
3. Ein Format für alles. Ein einzelner Workshop soll leisten, was nur die Kombination aus Ausrichtung, Kompetenzaufbau und Begleitung leisten kann.
4. Kein Blick auf den Kontext. Nicht jeder Bereich braucht dieselbe Dosis Agilität. Welche Vorgehensweise zu welcher Situation passt, lässt sich systematisch prüfen — das Cynefin-Framework ist dafür ein bewährtes Denkwerkzeug.

Eine ehrliche Reihenfolge

Wer die drei Formate kombiniert, statt sie gegeneinander auszuspielen, bekommt eine realistische Abfolge:

1. Diagnose vor Maßnahme. Erst klären, welches Problem gelöst werden soll. Ein kurzer Selbsttest wie der Projekt Health Check liefert dafür eine erste Standortbestimmung.
2. Workshop für die gemeinsame Ausrichtung und die Auswahl eines Pilotbereichs.
3. Training für die Teams, die tatsächlich anders arbeiten sollen — praxisnah, an den eigenen Projekten.
4. Begleitung über die ersten Monate, bis die neue Arbeitsweise Alltagsdruck übersteht.

Nüchtern betrachtet ist keine dieser Stufen optional. Nur das Weglassen kostet an jeder Stufe unterschiedlich viel.

---

Agile Forge begleitet Unternehmen in allen drei Formaten: Inhouse-Schulungen, Workshops und Team-Coaching — on-site oder remote. Für Teams, die selbstständig lernen wollen, gibt es die Online-Kurse für agiles Projektmanagement und KI.

Quellen

• Kotter, J. P. (1996): Leading Change. Harvard Business School Press.
• Beck, K. et al. (2001): Manifest für Agile Softwareentwicklung. agilemanifesto.org.
• Snowden, D. J. / Boone, M. E. (2007): A Leader's Framework for Decision Making. Harvard Business Review.