Agile Coaches in der KI-Ära

Lass uns doch mal ehrlich sein. Warum gibt es überhaupt Scrum Master und Agile Coaches? 

Weil unsere Organisationen so verknotet sind, dass wir jemanden brauchen, der den Faden wieder entwirrt. Jemanden, der sagt: "Leute, redet mal miteinander." Jemanden, der aufpasst, dass der Prozess nicht aus dem Ruder läuft - weil sonst ja keiner aufpasst.

Klingt das nach einer Strategierolle? Oder nach einem Symptom?

Wenn ein Team sagt, der Scrum Master sei essenziell, dann frage ich mich manchmal: "Essenziell für wen? Für den Prozess oder dafür, dass der Prozess überhaupt noch läuft?" Ich habe Teams erlebt, in denen der Scrum Master im Grunde nur der Klebstoff war, der eine Ablaufstruktur zusammengehalten hat, die eigentlich niemand mehr wollte. Das ist nicht seine Schuld. Aber es ist auch kein gutes Zeichen. Und genau darum ist diese Rolle jetzt in Gefahr. Nicht weil KI so furchtbar schlau ist, sondern weil agentische Softwareentwicklung Standardzeremonien ablöst oder obsolet macht, mit denen sich viele Agile Coaches bisher die Zeit vertrieben haben.

Stell dir einen typischen Scrum Master vor. Was macht der den ganzen Tag? Er moderiert die Sprint-Planung, aktualisiert das Jira-Board, schreibt irgendeinen Statusbericht, leitet die Retrospektive und fragt am Ende vielleicht nochmal: "Was haben wir gelernt?" 

Um all das drumherum betreut er einen Prozess, der schon vor der KI-Ära eigentlich nicht sonderlich beliebt war. Entwickler haben schon immer unter der Last der vielen Meetings gelitten und wenn diese nicht gut moderiert wurden, dann war das Team schnell frustriert.

Nehmen wir nur mal das Backlog Refinement. Eine der langweiligsten Zeremonien überhaupt. User Stories optimieren, Acceptance Criteria formulieren, Priorisierungen diskutieren – während der Product Manager im Hintergrund sowieso schon weiß, was er will. Ich habe da schon Stunden verbracht, in denen am Ende alle gewartet haben, dass jemand das Ticket einfach so formuliert, dass es durch den Review kommt. Heute macht Copilot das in fünf Minuten. Und vermutlich sogar besser.

Oder die Sprint-Planung, bei der zwei Stunden lang diskutiert wird, um am Ende festzustellen, dass wir wieder zu viel reinpacken. Das ist keine wertvolle Facilitation. Das ist Zeitverschwendung mit Kaffee. Gleiches in der Retrospektive, in der jeder nur seinen Frust ablädt. KI kann dir heute sagen, wo die Muster sind. Sie kann dir aber nicht sagen, warum zwei Entwickler sich nicht mehr riechen können. Das machen viele Coaches aber leider auch nicht.

Dazu kommen all die kleinen Tätigkeiten: Velocity auswerten, Kapazitätsengpässe erkennen, Dependencies aufspüren, überfällige Tickets finden. Früher hat das nach Magie ausgesehen. Heute istes ein Knopfdruck. Das alles ist keine Katastrophe. Das ist eine Chance. Denn genau diese Arbeiten waren der "Bullshit"-Teil des Jobs. Und "Bullshit"-Teile sollten verschwinden.

Aber hier wird es wirklich interessant. KI ersetzt nicht nur den Scrum Master. KI entlarvt die ganze Prozess-Fassade, die wir uns in den letzten Jahren aufgebaut haben.

Kennst du das? Ein Feature soll gebaut werden. Zuerst schreibt jemand eine Lösungsskizze. Dann übersetzt ein Requirements Engineer die Skizze in "echte" Anforderungen. Dann werden Backlog Items draus gemacht, Story Points vergeben, Schätzrunden gespielt. Und dann, nach 20 oder 30 Tagen, fängt endlich jemand an zu entwickeln - und merkt natürlich sofort, dass die Lösung, die vor Wochen auf Papier gezeichnet wurde, in der Realität nicht funktioniert. Ich nenne das gerne "Wasserfall mit bunten Post-its". Weil am Ende nicht iteriert wird, sondern durchgeschoben.  Nur eben mit mehr Besprechungen dazwischen. Und dein Agile Coach hat es nicht bemerkt, weil sein Job es war, die Meetings zu moderieren, nicht sie abzuschaffen.

Mit KI-gestützter Entwicklung - nenn es Vibe Coding, Wise Coding, Agentic Coding, nenn es, wie du willst – sieht das plötzlich ganz anders aus. Du hast ein Problem und einen Entwickler mit einem KI-Agenten. Innerhalb von Stunden entsteht eine erste Version, die wirklich läuft. Der User sieht sie. Der User sagt, was er davon hält. Die Richtung ändert sich, während du noch dabei bist, den Code zu schreiben. Nach sechs Tagen (oder vielleicht sogar Stunden) hast du etwas, wofür dein  alter Prozess 30 Tage gebraucht hätte.

Richtig absurd wird es dann, wenn jemand im Team sagt: "Wir müssen noch bis Donnerstag warten, bis der Sprint vorbei ist." Wenn du das hörst, weißt du: Da ist jemand zum Blocker geworden. Nicht zum Enabler.

Das ist der Punkt, der mir am meisten unter den Nägeln brennt. Sprints sind nicht in Stein gemeißelt. Sie sind ein Organisationsmuster, das irgendwann mal Sinn ergab. Wenn dein Team heute jeden Tag deployen kann, aber es irgendwo im Prozess noch eine künstliche Bremse gibt,  dann ist es nicht agil. Dann ist es ein Mini-Wasserfall-Generator. Er dreht sich zwar reibungslos, aber eben viel zu langsam.

Spätestens mit dem Einzug der agentischen Softwareentwicklung solltest du deine Prozesse aber dahingehend geradeziehen. Wenn du heute noch immer an einem 2-wöchigen Releasezyklus in INT festhältst und alle 3 Monate in Produktion released, dann ist das nicht agil. Dann ist das ein Prozess, der aus der Zeit gefallen ist. Um es ganz konkret zu sagen: Aus deinem Prozess wird ein konkretes Geschäftsrisiko. 

Echte Agilität misst sich nicht an Retrospektiven. Sie misst sich daran, wie schnell eine gute Idee beim Kunden ankommt. Deployment Frequency, Lead Time, Change Failure Rate, Zeit bis zum Rollback - das sind die Kennzahlen, die zählen. Nicht die Anzahl der durchgeführten Daily Standups.

Typische Ausreden

Ich formuliere es hier extra einmal sehr hart. Ich höre und lese sehr oft folgende Begründungen, warum nicht in schnellen Zyklen released werden kann: 

• Wir haben noch alte Legacy-Systeme.
• Wir haben ganz komplexe Stored Procedure-basierte Datenbankprozesse.
• Wir haben noch zu viele Abhängigkeiten zu anderen Teams oder Systemen.
• Wir haben noch zu viele regulatorische Anforderungen, die wir erfüllen müssen.
• Wir haben noch zu viele Sicherheitsanforderungen, die wir erfüllen müssen.
• Wir haben noch zu viele Compliance-Anforderungen, die wir erfüllen müssen.
• Wir haben zu viele technische Schulden, die wir erst auflösen müssen.
• Wir haben das Know-how nicht. (was oft anders formuliert wird)

So könnte ich noch einen ganze Weile weitermachen. Aber Fakt ist, das alles sind Gründe, aber alle davon sind lösbar. Und genau das ist die Aufgabe eines guten Agile Coaches. Nicht Prozesse zu moderieren, sondern echte Hindernisse zu beseitigen.

Wenn du also 2026 noch Sprints nach dem Buch moderierst und denkst, das ist dein Job, dann bist du auf dem besten Weg, durch ein Skript ersetzt zu werden. Tut mir leid, aber das ist die Wahrheit.

Die gute Nachricht: Es gibt weiterhin Arbeit für Coaches. Aber es ist eine andere Arbeit.

Statt Standups zu moderieren, musst du deinen Teams zeigen, wie sie mit KI richtig arbeiten. Nicht "Wie bedient man ChatGPT?", sondern wie stellt man Fragen, damit wirklich Lösungen entstehen? Wann verlässt man sich auf den Vorschlag der KI, wann widerspricht man? Wer trägt die Verantwortung, wenn Copilot Code produziert, der Bias oder Sicherheitslücken enthält? Wann ist der richtige Zeitpunkt, einen Enduser ins Boot zu holen? Wann benötige ich wirklich regelmäßige Zeremonien? Und welche Zeremonien kann ich meine KI-Agenten getrost alleine durchführen lassen?

Statt täglich nach Blockern zu fragen, musst du dafür sorgen, dass Deployments in fünf Minuten gehen. Dass das Monitoring so gut ist, dass Fehler sofort sichtbar sind. Dass Feature Flags es ermöglichen, etwas live zu schalten und bei Problemen sofort wieder zurückzudrehen. Wirklich neu ist dies alles nicht. Aber durch agentische Softwareentwicklung steigt zum einen der Druck, den Input, den die Entwickler nun immer schneller liefern, auch schnellstmöglich in Produktion zu bringen. Zum anderen wird der Druck durch den Markt immer höher, da die Konkurrenz nun auch in der Lage ist, Ideen in Stunden statt in Wochen beim Kunden zu haben.

Statt Prozesse zu moderieren, musst du echte Entscheidungen anstoßen. Warum deployen wir noch alle zwei Wochen, wenn wir täglich könnten? Welche Meetings existieren nur, weil wir die alte Infrastruktur noch haben? Wer profitiert davon, dass wir Requirements vor der Entwicklung schreiben statt danach?

Und ja, du musst dich mit den harten Konsequenzen beschäftigen. Wenn KI wirklich so viel übernimmt, verschwinden Rollen. Requirements Engineer, manuelle QA-Tester, teilweise sogar Product Manager. Ein echter Coach hilft Menschen dabei, neue Rollen zu finden, statt die alten zu verteidigen. Das ist unbequem. Aber notwendig.

Wie sieht nun konkret der Prozess in einem agentisch getriebenen Softwareentwicklungsumfeld aus? Folgend möchte ich dir einmal zeigen, wie ein Team in der KI-Ära arbeitet. Dies ist tatsächlich ein reales Beispiel, das ich in den letzten Monaten begleiten durfte. 

Teamsetup

Ich habe in den letzten Monaten ein Projekt begleitet, bei dem ein Kunde eine Software für Projektmanagement-ähnliche Aufgaben brauchte. Jira und MS Project passten nicht, weil die Anforderungen zu spezifisch waren. Also haben wir ein kleines Team aufgesetzt: zwei Consultants, ein Entwickler und ein Azubi.

Das Besondere war, dass jedes menschliche Teammitglied einen oder mehrere Agenten an der Seite hatte. Der erste ist Tony, der aus technischen Diskussionen heraus die Architektur mitdenkt. Pepper kümmert sich um Requirements, Natasha um Frontend, Bruce um Backend. Wer gerade über die Marvel-Namen stolpert – das ist keine Idee von mir. Wir haben das "Squad" Framework von Brady Gaster [1] als Ausgangspunkt genommen, in dem Agenten aus verschiedenen Film-Universen gecastet werden. Die Idee hilft, die Agenten nicht als anonymes Werkzeug, sondern als Diskussionspartner zu behandeln.

Die zwei Consultants kümmern sich um die technischen Anforderungen, die sich schwer agentisch umsetzen lassen, wie die Bereitstellung der Cloud-Infrastruktur, die Anbindung an bestehende Systeme und die Einhaltung von Sicherheitsrichtlinien. Zudem fällt in deren Aufgabenbereich die Koordination des Teams, die Kommunikation mit dem Kunden und die Sicherstellung, dass die Software den Anforderungen des Kunden entspricht. Der Entwickler stellt sicher, dass die Software den technischen Anforderungen entspricht und die Agenten korrekt implementiert werden. Der Azubi unterstützt bei der Qualitätssicherung.

Einmal pro Woche gibt es ein Review Meeting, in dem das Team die Fortschritte in einer Preview-Umgebung präsentiert und Feedback vom Kunden einholt. Ist das Feedback des Kunden über die neuen Features positiv, gibt es einen Knopfdruck und das Feature wird in die Produktion übernommen. Das Team arbeitet ansonsten in einem Teams Call, der 5x8 Stunden am Tag geöffnet ist. Dort werden Fragen geklärt, Probleme gelöst und Entscheidungen getroffen. Geht ein Team Member, gibt es eine Benachrichtigung und mindestens einer der anderen Team Member joined.

Ja, aber was ist mit dem Backlog, was ist mit Planning, wie wird ein Refinement durchgeführt? Diese Zeremonien werden ad hoc bei der Planung eines Features, genau für dieses eine Feature durchgeführt. Einer der Consultants spezifiziert die Anforderungen des Kunden und lässt alle wichtigen fachlichen und technischen Informationen einfließen. Die Mitglieder des agentischen KI-Teams starten nun eine Zeremonie und diskutieren die Anforderungen, die Umsetzungsmöglichkeiten und die Priorisierung. Am Ende der Zeremonie gibt es ein gemeinsames Verständnis darüber, wie das Feature umgesetzt wird und welche Aufgaben anstehen.

Die Änderungen werden durch die Consultants und den Entwickler reviewed und in die Umsetzung gebracht. Der Azubi des Teams kontrolliert am Ende die Dokumentation, die Tests und natürlich die Funktionsfähigkeit der Software. Dann geht es zurück an die Consultants und danach in die wöchentliche Review Session mit dem Kunden.

So. Und jetzt kommt der Teil, auf den viele gewartet haben. KI kann vieles. Aber sie kann keine echten Konflikte lösen.

Stell dir das Beispiel von eben nochmal vor. Tony, Pepper und Natasha liefern Features, als wäre es nichts. Die Kennzahlen sehen blendend aus. Aber was, wenn der menschliche Consultant heimlich zweifelt, ob die Architektur, die Tony das aufzieht, wirklich wartbar ist? Was, wenn der Azubi sich überfordert fühlt, weil er zwischen KI-generierter Dokumentation und echten Tests kaum noch durchblickt? Was, wenn der Entwickler still sauer ist, weil er das Gefühl hat, nur noch Quality Assurance für seine eigenen "Kollegen" aus Silizium zu machen?

KI merkt das nicht. Sie kann dir sagen: "Eure Lead Time ist um 40 Prozent gesunken." Sie kann dir aber nicht sagen, warum der menschliche Tech Lead plötzlich bei den wichtigen Entscheidungen nicht mehr mitspielt. Sie kann nicht erkennen, dass der 5x8-Teams-Call längst kein offener Austausch mehr ist, sondern nur noch eine einsam beleuchtete Videokonferenz. Sie kann nicht spüren, wenn das Team zwischen menschlichen und agentischen Mitgliedern langsam auseinanderdriftet.

Das ist der Bereich, in dem ein guter Coach unverzichtbar bleibt. Nicht gut im Sinne von "hat den Scrum-Guide auswendig gelernt". Gut im Sinne von: liest die menschliche Dynamik, führt die schwierigen Gespräche, baut echte Kultur. Das macht Teams effizienter, auch wenn der Chart gleich aussieht.

Das Problem? Die meisten Agile Coaches machen das nicht. Sie moderieren Meetings. Sie aktualisieren Boards. Sie schreiben Reports. Und genau das ist der Teil, der wegfällt.

Ich glaube, 2026 wird mit der Etablierung agentischer Softwaremethoden eine klare Spaltung beginnen zu entstehen.

Auf der einen Seite stehen Generalisten, die mit KI end-to-end Prototypen bauen können. Sie sind flexibel, sie liefern Wert, sie brauchen keine Zeremonien, um produktiv zu sein. Auf der anderen Seite stehen echte Spezialisten. Menschen, die in ihrem Feld so gut sind, dass sie nicht ersetzbar sind. Die wirklich transformieren können. Die Organisationen durch Disruption führen.

Und dazwischen? Da sitzt die gefährliche Mitte. Die Scrum Master, die Sprints moderieren, Retrospektiven halten und Daily Standups leiten. Die "normalen" Agile Coaches. Diese Rolle ist komplett automatisierbar. Und schlimmer: Sie schafft keinen echten Wert mehr.

Wenn du dich da wiederfindest, ist das kein Todesurteil. Aber es ist ein Weckruf.

Was macht man denn stattdessen? Ich habe das Gefühl, die Rolle zerfällt gerade in drei, vier verschiedene Aufgaben, die früher alle beim selben Menschen lagen.

Einmal jemand, der Teams wirklich beibringt, mit KI zu arbeiten. Nicht Prompt-Schreiben, sondern Verantwortung und Urteil. Wann folgt man einem Vorschlag? Wann widerspricht man? Wer prüft, ob der generierte Code auch wirklich das tut, was er soll?

Dann jemand, der aufpasst, dass das Team nicht auseinanderdriftet, wenn jeder nur noch mit seinem Copilot spricht. Burnout verhindern, Wissenstransfer sicherstellen, echte Gespräche wieder möglich machen – das sind echte Coaching-Themen.

Und jemand, der versteht, warum Deployment Frequency wichtiger ist als Sprint-Planning-Dauer. Jemand, der weiß, dass Continuous Delivery kein Nice-to-have ist, sondern der Wettbewerbsvorteil schlechthin. Dass Sprints ein Organisationsmuster sind, keine technische Notwendigkeit. Dass Mini-Wasserfälle die wahre technische Schuld sind, nicht der Code, der irgendwo langsam läuft.

Wenn man das jetzt unbedingt in Rollenboxen packen will, kann man das natürlich tun. Die IT liebt ja nichts mehr als fancy Namen. Aber im Grunde sind das alles alte Coaching-Themen in neuem Gewand.

Wenn du dich also weiterhin Agile Coach nennen willst, musst du mehr können als "Soft Skills". Du musst verstehen, wie Large Language Models funktionieren. Nicht im Detail, aber genug, um Teams zu coachen. Du musst DORA-Metrics lesen können und wissen, wann sie lügen. Du musst verstehen, wie Git, CI/CD und Feature Flags funktionieren, weil dein Team sonst in fünf Sekunden Code merged, den niemand mehr durchschaut.

Du musst wissen, was passiert, wenn Copilot Code generiert, der einen Security Bug enthält. Wer prüft das? Wer ist verantwortlich?

Das ist kein reiner People-Job mehr. Das ist eine hybride Rolle. Und wenn du das nicht lernst, bist du kein Enabler. Du bist ein Blocker.

Ich weiß, das klingt alles ein bisschen dramatisch. Und vielleicht übertreibe ich auch. Aber was ich in den letzten Monaten gesehen habe, lässt sich nicht wegdiskutieren: Teams, die früher wochenlang geplant haben, bauen jetzt in Tagen etwas, das wirklich läuft. Und dann wirkt ein 2-Wochen-Sprint plötzlich wie eine Bremse.

Viele Agile Coaches werden verschwinden. Nicht weil KI alle ersetzt, sondern weil ein großer Teil ihrer Arbeit nie so wertvoll war, wie wir gerne geglaubt haben. Zeremonien pflegen, Prozesse bewahren, Teams in Meetings halten – das war schon lange keine echte Transformation mehr.

Die guten Coaches bleiben. Die, die Kultur bauen, Konflikte lösen, Organisationen durch den Wandel führen. Die, die verstehen, dass echte Agilität heute bedeutet, Ideen in Stunden statt in Wochen zum Kunden zu bringen.

Wir haben das schon einmal erlebt. Als Cloud aufkam, waren da DevOps Engineers, die wirklich Kultur und Technik verstanden. Die sind heute Senior. Und dann gab es die, die nur Konfiguration gemanagt haben. Die sind vom Markt verschwunden. Genau das passiert gerade mit Agile.

Wenn du 2026 noch Sprints nach dem Buch moderierst, ist das kein Weltuntergang. Aber frag dich vielleicht mal, ob das wirklich noch dein Job ist. Weg vom Prozesswächter, hin zu jemandem, der fragt: "Warum machen wir das eigentlich noch so?"