Was ist eigentlich ein Agile Coach - und brauchen wir das wirklich?

Was ist eigentlich ein Agile Coach - und brauchen wir das wirklich?

Wir werden immer wieder gefragt, was ist eigentlich ein Agile Coach, was tut er den ganzen Tag, warum brauchst du den überhaupt? Und wie unterscheidet er sich vom Scrum Master oder einem Product Owner?  Ich dachte, ich beantworte diese Fragen einmal mit einer fiktiven Story – die, wie alle guten Geschichten, aus dem echten Leben gegriffen ist. Viel Spaß beim Lesen!

Lust auf mehr Praxis und Austausch mit Gleichgesinnten?
In unserer Agile Coach Ausbildung bekommst du echte Cases, praktische Tools und eine starke Community.
👉 Jetzt mehr erfahren oder direkt anmelden

‍

Die Transformation der TechnoSolutions GmbH – eine Geschichte über Mut, Widerstand und den Weg zu echter Agilität

Der Ausgangspunkt: Als jede Veränderung ein Kampf war

Es war ein grauer Montagmorgen im November, als Sarah Müller zum ersten Mal die Büroräume der TechnoSolutions GmbH betrat. Als frisch engagierte Agile Coach sollte sie einem 150-Personen-Softwareunternehmen dabei helfen, "agiler zu werden". Ein Auftrag, der ihr zunächst vertraut vorkam. Was sie jedoch antraf, war symptomatisch für viele traditionelle Unternehmen: Eine Organisation, die in jahrzehntelang gewachsenen Strukturen gefangen war.

Die Entwicklungsteams arbeiteten in strikten Hierarchien. Jede Entscheidung wanderte durch mindestens drei Managementebenen. Projektzeitpläne wurden monatelang im Voraus festgelegt und galten als unantastbar, selbst wenn sich Kundenanforderungen längst geändert hatten. "Wir haben schon immer so gearbeitet, und es hat funktioniert", war der Standardsatz, den Sarah in den ersten Wochen am häufigsten hörte.

Die Symptome waren deutlich sichtbar: Projekte verspäteten sich regelmäßig um 30–50 %, Kundenfeedback kam erst nach der finalen Auslieferung an, und die Mitarbeiterzufriedenheit lag bei erschreckenden 42 %. In den wöchentlichen Statusmeetings saßen 15 Personen, um über Probleme zu sprechen, die sie nicht lösen durften. Die eigentliche Arbeit geschah zwischen den Meetings – oft nachts und am Wochenende.

"Wir brauchen mehr Flexibilität und schnellere Entscheidungen", hatte Geschäftsführer Michael Weber Sarah bei der Vertragsunterzeichnung erklärt. "Unsere Konkurrenz überholt uns, weil sie schneller auf Marktveränderungen reagiert." Doch als Sarah vorschlug, mit kleinen Experimenten zu beginnen, spürte sie bereits den ersten Widerstand: "Experimente? Wir sind ein seriöses Unternehmen, keine Spielwiese."

‍

Phase 1: Der Widerstand – "Das haben wir schon mal versucht"

Sarahs erste Workshops stießen auf höfliche Skepsis. "Agile Coaches hatten wir schon einmal", erzählte ihr Entwicklungsleiter Thomas Braun beim Kaffee. "Hat drei Monate gedauert, dann waren die wieder weg, und wir haben weitergemacht wie vorher." Diese Erfahrung teilten viele Kollegen: gescheiterte Transformationsversuche, die nur neue Begriffe eingeführt, aber nichts Wesentliches verändert hatten.

Die größte Hürde war das mittlere Management. Während die Entwickler durchaus offen für Veränderungen waren, sahen Teamleiter und Projektmanager ihre Rolle bedroht. "Wenn die Teams sich selbst organisieren, was mache ich dann noch?", fragte Projektmanager Andreas Richter offen. Diese Angst war berechtigt, denn Agilität verändert tatsächlich Rollen und Verantwortlichkeiten fundamental.

Sarah erkannte schnell: Der Widerstand kam nicht aus Bösartigkeit, sondern aus Unsicherheit und schlechten Vorerfahrungen. Anstatt mit großen Visionen zu beginnen, wählte sie einen anderen Weg. Sie bot dem kleinsten Entwicklungsteam – nur fünf Personen – an, für vier Wochen ein "kleines Experiment" zu starten. Kein großer Auftakt, keine Unternehmensstrategie, nur: "Lasst uns schauen, ob wir eure tägliche Arbeit ein bisschen angenehmer machen können."

Das Team um Entwicklerin Lisa Schmidt war skeptisch, aber neugierig. Sie waren es gewohnt, wochenlang an Features zu arbeiten, ohne zu wissen, ob diese überhaupt genutzt werden. "Was wäre, wenn ihr nach jeder Woche dem Kunden etwas zeigen könntet?", fragte Sarah. "Unmöglich", antwortete Lisa spontan. "Wir brauchen mindestens einen Monat für vernünftige Features."

Doch dann begann die Magie der kleinen Schritte. Sarah führte das Team durch eine einfache Übung: Was könnt ihr in einer Woche schaffen, das für den Kunden einen minimalen, aber spürbaren Wert hat? Nach langem Überlegen kam die Antwort: "Wir könnten die Ladezeit der Startseite um 20 % verbessern." Ein technisches Feature, das sofort messbar und nützlich war.

‍

Phase 2: Erste Erfolge – "Moment mal, das funktioniert ja"

Am Ende der ersten Woche präsentierte Lisas Team tatsächlich ihr Ergebnis. Die Startseite lud schneller, der Kunde war begeistert, und zum ersten Mal seit Monaten hatte das Team das Gefühl, etwas Sinnvolles vollbracht zu haben. "Das war wie ein kleines Feuerwerk", erinnert sich Lisa heute. "Plötzlich konnten wir den direkten Zusammenhang zwischen unserer Arbeit und dem Kundennutzen sehen."

Sarah nutzte diesen Erfolg klug. Sie lud andere Teams ein, bei der nächsten Präsentation dabei zu sein. Ohne große Worte sahen die Kollegen, wie entspannt und stolz das "Experiment-Team" wirkte. Die Fragen kamen von selbst: "Wie habt ihr das so schnell hinbekommen?" "Warum wart ihr nicht gestresst wie sonst?"

Das Geheimnis lag in den kleinen Veränderungen, die Sarah eingeführt hatte: Statt drei-stündiger Planungsmeetings gab es fünfzehn-minütige tägliche Check-ins. Statt detaillierter Spezifikationen konzentrierten sie sich auf das Wesentliche: Was will der Kunde erreichen, und wie können wir das einfachst möglich umsetzen? Statt Einzelkämpfertum entschieden sie gemeinsam, wer bei welchem Problem helfen konnte.

Die Ergebnisse sprachen für sich: In vier Wochen lieferte das Team vier kleine, aber wertvolle Verbesserungen. Die Kundenzufriedenheit stieg, die Überstunden reduzierten sich um 30 %, und – fast nebenbei – machte das Team weniger Fehler, weil sie kontinuierlich voneinander lernten.

Du willst lernen, wie man genau solche Veränderungen anstößt?  
Dann ist unsere Agile Coach Ausbildung vielleicht genau das Richtige für dich.
👉 Jetzt mehr erfahren und Platz sichern – ACA startet im September 2025!

Michael Weber, der Geschäftsführer, wurde aufmerksam. "Können wir das auf andere Teams übertragen?", fragte er Sarah. Doch sie bremste bewusst: "Lassen Sie uns erst verstehen, warum es funktioniert hat, bevor wir es kopieren."

‍

Phase 3: Rückschläge – "Das ist doch nur Chaos"

Als zwei weitere Teams das "Experiment" starteten, traten die ersten größeren Probleme auf. Das eine Team interpretierte "Selbstorganisation" als "jeder macht, was er will" und produzierte ein ziemliches Durcheinander. Das andere Team wurde von seinem Teamleiter so stark kontrolliert, dass sich praktisch nichts änderte.

"Ich hab's gewusst", kommentierte Andreas Richter, der Projektmanager, die Situation. "Ohne klare Führung entsteht nur Chaos. Unsere Kunden erwarten Professionalität, keine Experimente." Seine Kritik hatte durchaus Berechtigung, denn Agilität bedeutet nicht, dass alles erlaubt ist. Im Gegenteil: Sie erfordert sehr bewusste und disziplinierte Zusammenarbeit.

Sarah nutzte diese Krise als Lernmoment. In einem ehrlichen Workshop mit allen beteiligten Teams analysierte sie gemeinsam die Erfolge und Misserfolge. "Agilität ist nicht das Gegenteil von Struktur", erklärte sie. "Es geht darum, die richtige Art von Struktur zu finden: eine, die uns hilft statt behindert."

Die Erkenntnis war wichtig: Erfolgreiche agile Teams brauchen klare Spielregeln, gemeinsame Ziele und regelmäßige Reflexion. Freiheit ohne Verantwortung führt tatsächlich zu Chaos. Aber Verantwortung ohne Entscheidungsfreiheit führt zu Frustration.

Besonders schwierig wurde es, als das erste größere Projekt anstand. Der Kunde erwartete wie gewohnt einen detaillierten Projektplan mit festen Terminen. "Wie sollen wir agil arbeiten, wenn der Kunde klassisch denkt?", fragte Lisa verzweifelt. Diese Frage trifft den Kern vieler Transformationen: Agilität funktioniert nicht im luftleeren Raum, sondern muss mit der realen Geschäftswelt kompatibel sein.

‍

Phase 4: Der Durchbruch – "Jetzt verstehen wir es"

Die Lösung kam von unerwarteter Seite. Thomas Braun, der anfangs skeptische Entwicklungsleiter, schlug vor: "Warum planen wir nicht agil?" Statt eines starren Projektplans entwickelten sie gemeinsam mit dem Kunden eine flexible Roadmap. Sie definierten klare Meilensteine, erklärten aber, dass der Weg dorthin anpassbar bleiben würde.

Der Kunde war zunächst irritiert, dann aber fasziniert. "Sie meinen, Sie können auf meine Änderungswünsche eingehen, ohne dass das Projekt explodiert?" Genau das passierte in den nächsten Monaten. Als der Kunde nach vier Wochen merkte, dass eine geplante Funktion doch nicht so wichtig war, konnten sie ohne Drama umschwenken. Als eine andere Funktion plötzlich kritisch wurde, verschoben sie Prioritäten flexibel.

Das Projekt wurde nicht nur termingerecht, sondern sogar zwei Wochen früher fertig. Der Kunde war so zufrieden, dass er noch im selben Jahr einen Folgeauftrag erteilte. Mehr noch: Andere Kunden wurden aufmerksam und fragten nach der "neuen Arbeitsweise" von TechnoSolutions.

Intern merkten alle den Wandel. Die wöchentlichen Statusmeetings verwandelten sich in konstruktive Arbeitsrunden. Probleme wurden nicht mehr versteckt, sondern offen angesprochen und gemeinsam gelöst. "Plötzlich war es okay zu sagen: 'Das schaffe ich nicht alleine, kann mir jemand helfen?'", erzählt Entwickler Mark Peters. "Früher war das ein Zeichen von Schwäche, jetzt ist es Team-Intelligence."

Andreas Richter, der einstige Kritiker, fand in seiner neuen Rolle als "Impediment Remover" eine erfüllende Aufgabe. Statt Teams zu kontrollieren, half er ihnen dabei, Hindernisse aus dem Weg zu räumen. "Ich dachte, ich würde überflüssig. Stattdessen bin ich wichtiger geworden – nur anders wichtig."

Das neue Gesicht von TechnoSolutions – Ein Jahr später

Heute, ein Jahr nach Sarahs erstem Besuch, ist TechnoSolutions ein anderes Unternehmen. Nicht perfekt, nicht ohne Herausforderungen, aber fundamental verändert. Die Kennzahlen sprechen eine klare Sprache: Projektlaufzeiten haben sich um 40 % verkürzt, Kundenzufriedenheit liegt bei 89 %, und die Mitarbeiterfluktuation ist von 23 % auf 8 % gesunken.

Aber die wichtigsten Veränderungen sind weniger messbar. "Wir haben eine Fehlerkultur entwickelt", erklärt Michael Weber stolz. "Fehler sind nicht mehr peinlich, sondern Lernchancen." Teams experimentieren selbstständig mit neuen Technologien und Arbeitsweisen. Kundenfeedback fließt nicht mehr über drei Hierarchieebenen, sondern direkt zu den Entwicklern.

Sarah arbeitet heute nur noch zwei Tage pro Woche bei TechnoSolutions. Ihre wichtigste Aufgabe ist es, die internen "Agile Champions" zu unterstützen – Mitarbeiter, die die agile Denkweise in ihre Teams tragen. "Ein Agile Coach macht sich idealerweise überflüssig", sagt sie. "Wenn die Menschen verstehen, dass Agilität eine Haltung ist, nicht nur eine Methode, brauchen sie keinen externen Coach mehr."

‍

Was wir von TechnoSolutions lernen können

Die Geschichte von TechnoSolutions zeigt: Agile Transformation ist weniger eine technische Herausforderung als eine zutiefst menschliche. Es geht nicht darum, Prozesse zu optimieren, sondern darum, eine Kultur zu schaffen, in der Menschen gerne arbeiten und ihr Bestes geben können.

Die wichtigsten Erkenntnisse der Reise waren:

Kleine Schritte schlagen große Visionen. Statt das ganze Unternehmen auf einmal zu verändern, begann die Transformation mit einem fünf-Personen-Team und einem vier-Wochen-Experiment.

Widerstand ist normal und wertvoll. Die kritischen Stimmen hatten oft berechtigte Einwände, die die Transformation letztendlich verbessert haben.

Erfolg muss erlebt werden. Keine PowerPoint-Präsentation der Welt kann das Gefühl ersetzen, zum ersten Mal ein Problem gemeinsam und effektiv gelöst zu haben.

Führung verändert sich, verschwindet aber nicht. Manager werden zu Coaches, Projektleiter zu Facilitatoren – wichtig bleiben sie alle.

Der Kunde muss mitgenommen werden. Interne Agilität funktioniert nur, wenn auch externe Beziehungen entsprechend gestaltet werden.

Agile Coach werden – mit unserer Ausbildung ab September 2025
Du willst mehr als Methoden lernen? Du willst Veränderung möglich machen – mit Tiefgang, Praxis und Haltung? Dann bist du bei uns richtig.
👉 Jetzt informieren und Platz sichern

Heute steht Sarah vor neuen Herausforderungen bei TechnoSolutions: Wie bleibt ein agiles Unternehmen agil, wenn es wächst? Wie überträgt sich die Kultur auf neue Mitarbeiter:innen? Wie entwickelt sich Agilität weiter, ohne ihre Essenz zu verlieren?

Aber das sind gute Probleme… die Probleme eines Unternehmens, das den Mut hatte, sich zu verändern, und dabei entdeckt hat, dass Veränderung nicht das Ende, sondern der Anfang ist.

Denn am Ende geht es bei agiler Transformation nicht darum, perfekt zu werden. Es geht darum, lernfähig zu bleiben – als Team, als Unternehmen und als Menschen.
 
---

Diese Geschichte – die wir in ähnlicher Form bei borisgloger und Cassini immer wieder erlebt haben – zeigt ein verbreitetes Phänomen: Große Softwareentwicklungsteams, aber auch ganze Unternehmensbereiche, geraten in die Effizienzfalle. Sie glauben, ihre Probleme mit noch mehr Management lösen zu können. Dabei liegt die Lösung oft im Gegenteil: in weniger Kontrolle und mehr Vertrauen.

Ein Agile Coach ist kein ScrumMaster, der sich ausschließlich mit einem Team beschäftigt. Ein Agile Coach versteht, wie Veränderung funktioniert, kann mit dem Management auf Augenhöhe agieren und behält dabei das große Ganze im Blick. So kann er Transformationen anstoßen, die wirklich nachhaltig sind.

In sehr großen Organisationen kann das bedeuten, dass man ein ganzes Transformationsteam benötigt. Doch oft wird zu groß gedacht und zu viel Aufwand betrieben, wo eigentlich kleine, gezielte Interventionen ausreichen würden.

In unserer Ausbildung zum Agile Coach schaffen wir es, all diese Erfahrungen zu vermitteln – die praktischen Tools für Veränderung, ein tiefes Verständnis für agiles Denken und vor allem den Diskurs darüber, was es wirklich ausmacht, ein wirksamer Coach zu sein.

‍