Ist Scrum tot in der KI Ära?

Schon bevor KI die Welt erobert hat, war ich nicht mehr überzeugt von Scrum.

Ich fing als Datenbank- und Softwareentwickler an, bevor Scrum überhaupt existierte. Ich habe klassisches Projektmanagement gelernt, agil, alle möglichen Trainings absolviert und eine Unmenge an Zertifikaten gesammelt. Ich habe als Projektleiter gearbeitet, Scrum Master, Agile Coach, die ganze Bandbreite durch, immer in Software- und Data-Teams in sehr großen Organisationen.

Es gibt ein paar wenige Beispiele in großen Enterprises, die ich gesehen habe, die wirklich gut funktioniert haben in Sachen agil, und die Teams verwendeten gar kein Scrum. Das meiste, was ich gesehen habe, war unerträglich, anstrengend, nervenaufreibend.

Das mal nur so als Einstimmung in meine persönliche private Meinung.

Und warum denke ich das so?

Weil dieses Prozesstheater und dieser Ticket-Friedhof in manchen Organisationen absurde Züge angenommen hat. Das Wasserfallige, die Überkoordination, wie man sich gegenseitig auf die Füße tritt, weil zu viele Rollen das Gleiche machen, wie die wichtigen Sachen überhaupt nicht gemacht werden.

Es wurde immer absurder und es hatte gar nichts mehr mit dem zu tun, wie ich mal vor langer, langer Zeit, bevor agil in der Welt war, direkt zusammen gearbeitet habe mit den Business-Kollegen, direkt für User.

Ich denke, im Lauf der Jahrzehnte war das größte Problem, dass eine riesige Schwemme von Nicht-Tech-Leuten Scrum geflutet hatte, diejenigen Personen, wenn sie noch nie Engineers waren, keinen persönlichen Referenzrahmen hatten, was denn eigentlich möglich ist an Performance, daraufhin immer auf das People-Thema zurückgefallen sind, weil das der einzige Referenzrahmen war, den sie hatten, und am Ende geht es nur noch immer um:

Wir sitzen alle im Kreis und singen Kumbaya.

Schrecklich.

Daher: Danke, danke, danke, dass KI nun alles über den Haufen wirft. Danke dafür. Ich kann mich nicht genug dafür bedanken.

Die Frage ist nun: Was macht man jetzt?

Ich weiß, dass eigentlich fast alle Firmen auf dieser Welt, bis auf ganz wenige Ausnahmen, irgendwie Tickets haben und irgendwie Sprints haben. Manche haben noch mehr, aber das ist so die grobe Gemeinsamkeit. Rollen sind teilweise unterschiedlich, aber alle haben irgendwie Sprints, alle haben irgendwie Tickets und alle haben jetzt irgendwie KI-Agenten, oder fast alle.

Und nun geht das große Chaos los.

Und ich möchte helfen, das Chaos zu sortieren, denn es geht mit einfachen Mitteln und ganz anders, als die meisten denken.

Der erste Schritt, den Sie tun müssen, ist: Hängen Sie sich nicht an Frameworks fest.

Erweitern Sie stattdessen Ihren Blick.

Es schwebt ja dieser Mythos im Raum, dass vor Agil es nur Wasserfall gab, was totaler Schwachsinn ist. Ich war noch nie in einem Wasserfall-Projekt und wie gesagt, habe ich schon Software entwickelt, da waren viele von Ihnen noch gar nicht geboren.

Es gab schon vor Agile so viele verschiedene Arbeitsweisen und Methoden und auch nach der Erfindung von Scrum sind viele neue dazu gekommen.

Klammern Sie sich bitte nicht an irgendein detailliertes Playbook fest.

Das Witzige ist ja: Im Scrum Guide steht schon auf Seite 4, dass Scrum auf Lean Thinking basiert und kein Mensch setzt sich damit ernsthaft auseinander und da geht's halt schon schief.

Lean Thinking hat seine Wurzeln in den 1950er Jahren, als Toyota das Lean Production System erfand.

Okay, denken Sie jetzt bitte pragmatisch.

Wenn Sie jung sind und nie etwas anderes als Scrum oder eine veränderte Version von Scrum kennen, sind Sie darauf getrimmt worden zu denken, dass alles irgendwie gleichmäßig ist. Immer zwei Wochen Rhythmus, dann haben manche dreimonatige Meilensteine, dann gibt's immer irgendwelche Tickets, dann gibt's immer irgendwelche Dailys. Es ist immer ungefähr gleich, kleinteilig und immer ungefähr gleich lang und immer irgendwie ungefähr gleich. Und das ist nicht die reale Welt.

Das Leben verläuft in Phasen. Es geht bergab, bergauf. Die Jahreszeiten sind in Zyklen. Die Natur hat Zyklen. Das war ein Riesennachteil in dem ganzen Scrum - versuchen Sie bitte sich gedanklich mal von dieser Gleichförmigkeit zu lösen und denken Sie, dass jetzt, wenn KI so schnell Code schreibt und alle möglichen anderen Dinge für Sie in einem Affentempo erledigt, brauchen Sie unterschiedliche Abschnitte in der Arbeit, die unterschiedlich lang sind, die unterschiedlich aussehen und daher auch unterschiedlich gemanagt werden müssen. Gleichzeitig brauchen Sie, damit ein großes Unternehmen nicht im Chaos versinkt, eine gewisse Beständigkeit und dazu kommen wir gleich.

Aber zunächst einmal muss man folgendes verstehen:

1. BEVOR der Coding-Agent losgeschickt wird, gibt es einen Abschnitt
2. Dann gibt's den Abschnitt, in dem der Coding-Agent was tut
3. und danach gibt es wieder einen anderen Abschnitt, indem man die Lösung validiert, etwas misst und daraus lernt

Diese unterschiedlichen Abschnitte müssen Sie in einen Organisationsrhythmus einbetten und das hat mit zwei Wochen Sprints am Ende wenig zu tun.

Um des Friedens willen kann man das Ganze auch irgendwie in zwei Wochen Sprints verpacken, aber es wird komplett anders aussehen als Ihr bisheriges Scrum Setup. Lösen Sie sich also von der Gleichförmigkeit und denken Sie in verschiedenen Phasen.

Die erste Phase: WAS und WIE

Die erste Phase ist: Es muss nun viel mehr Gehirnschmalz hineingesteckt werden, herauszufinden, WAS man überhaupt bauen will und danach kommt die Überlegung, WIE man es bauen will und erst dann schicken Sie die KI los. Diese Phasen werden zur Zeit unter den Begriffen Judgement und Governance diskutiert. Ich muss diese Phasen nicht unbedingt mit Scrum und Tickets bearbeiten. Aber ich muss nun viel mehr Zeit und Gedanken in diese Phasen investieren, bevor die KI Agenten loslegen. Dazu gibt es zahlreiche hilfreiche Methoden.

Was man bauen will, da kommen wir wieder zu guten alten Klassikern, die sich nennen Kundenorientierung, Kundenzentrierung, Value Proposition und wie sie nicht alle heißen. Alles, alles ururalt. Wurde in der gleichförmigen Scrum-Zeremonie teilweise nicht gemacht. Also nochmal zurück, Hausaufgaben machen: Was will Ihr Kunde, User oder Bürger überhaupt haben? In diesen Abschnitt müssen Sie jetzt mehr Aufwand reinstecken, weil das Bauen nicht mehr das Problem ist.

In dieser Phase verwenden Sie natürlich auch KI für Recherche oder Experimente oder zum Erstellen von Prototypen, aber Sie benötigen zusätzliche Methoden, die Scrum nie dabei hatte. Hier ist es durchaus hilfreich zu gucken, was Shape Up so vorschlägt und ich finde, man kann da ruhig Ideen übernehmen und diese auch in einem riesigen Konzern anwenden, nämlich die Idee zu überlegen:

Was sind unsere Wetten, was sind unsere Hypothesen und wie viel sind wir bereit dafür zu investieren und beim Überschreiten welcher Messwerte brechen wir das Ganze ab, weil unsere Annahmen nicht tragen?

Ich war dabei, als das in weltbekannten Konzernen genauso gelebt wurde. Es gibt kein Argument, dass das nicht in einem großen Unternehmen geht. Es geht. Man muss dazu auch keine Reorganisation machen und kein Change-Projekt. Es ist schlicht und ergreifend der Wille von Führungskräften, es so zu tun.

Die Führungskräfte, die Sponsoren sind, die Budget haben und alle anderen, die irgendwie Verantwortung tragen in dem Kontext, müssen sich nur mal zusammensetzen und sagen: Okay, lasst uns in Zukunft gemeinsam überlegen, welche Hypothesen wir haben, mit welchen Experimenten wir das validieren wollen, was unsere Wetten sind. Anstatt einfach nur ein Backlog mit Tickets vollzuhauen.

Dann kann die Phase erfolgen, in der man herausfindet, was der User, Kunde, Bürger eigentlich braucht. Anschließend brauchen Sie Leute, die in der Lage sind, einen Rahmen vorzugeben in Sachen Architektur, Qualität und Governance, bevor Sie die KI losschicken, es zu bauen.

Die Bau-Phase: Freiheit innerhalb enger Grenzen

Und das Schöne ist, dadurch, dass KI so schnell bauen kann, brauchen Sie keinen, der Menschen koordiniert. Geben Sie den Teams die Freiheit sich selbst zu koordinieren indem Sie vorab enge Grenzen und Spielregeln setzen.

Wenn klar ist, was die Wette ist, die man eingehen will, wenn klar ist, wie viel Funding dafür zur Verfügung gestellt wird, wenn klar ist oder man Hypothesen hat, was der User, Kunde, Bürger braucht, dann brauchen Sie einen Zeitraum, in dem das gebaut werden kann, in dem Fachexperten und Engineers mit KI Agenten selbst entscheiden, wie oft sie sich in welchen Meetings sprechen und koordinieren.

Ich sag Ihnen mal, wie es früher war. Ich habe einfach acht Stunden lang mit den Leuten, die was wollten, in einem Raum gesessen und wir haben zusammen die Arbeit gemacht. Als ich angefangen habe, Softwareentwickler zu sein, gab es keine Meetings. Das gab es nicht. Die Kultur war nicht vorhanden. Wir haben einfach zusammen gearbeitet. Wir, das waren die Techies und die Leute aus dem Business. Wir saßen den ganzen Tag zusammen in einem Raum und haben miteinander gearbeitet. Das Wort Meeting gab es in Deutschland noch nicht mal. Es gab in Deutschland das Wort Besprechung und Besprechungen gab es irgendwie einmal im Monat und die waren stinkelangweilig. Man ist nur hingegangen, weil der Chef dachte, dass man sowas machen muss. Die eigentliche Arbeit konnte man ohne Meetings durchführen.

Und zu dieser Arbeitsweise zurückzukehren, wo man einfach acht Stunden lang miteinander arbeitet, halte ich für sehr gesund und danke, liebe KI, dass du uns wieder ins Normale zurückführst. Nun heißt es Forward Deployed Engineer, aber das Konzept ist uralt.

Es war nämlich teilweise unerträglich, dass Engineers millionenfach am Tag unterbrochen werden über alle Kanäle, die es nur gibt und dann, wenn sie im Daily mal fünf Minuten Zeit hatten, miteinander zu arbeiten, dann wurden sie abgewürgt, dass das Daily ja nur 15 Minuten sein darf. Also das muss komplett aufhören. Sorry, so ein Schwachsinn. Lassen Sie die Leute einfach ihre Arbeit machen.

Validieren, messen, lernen

Der Zeitraum, in dem vertestet wird, ob eine Wette aufgeht, wurde von Shape Up schon begrenzt, was eine Verbesserung zu Scrum ist, weil in Scrum laufen die Sprints einfach monatelang immer weiter, immer weiter, immer weiter. Aber jetzt mit KI ist vielleicht der Zeitraum eines Sprints auch schon wieder zu lang.

Also überlegen Sie sich eine Zeitspanne, die Sie benötigen um herauszufinden, ob das, was mit KI gebaut wurde, wirklich das richtige war. Je nachdem um was es bei Ihnen geht, kann der Zeitraum auch sehr kurz sein.

Ganz, ganz wichtig ist, dass auf jeden Fall am Ende ein Learning stattfindet, nicht nur bei einer Person, sondern bei einem Team und dieses über das Team hinaus in die Organisation hineingetragen wird.

Es braucht eine gewisse Kadenz. Wenn ein großes Unternehmen mehrere Teams hat und die arbeiten nun alle mit KI-Agenten, braucht es eine Kadenz, in der Learnings über Teams hinweg ausgetauscht werden. Das kann wiederum ein Rhythmus sein, ob Sie den Sprint nennen oder anders, ist egal. Der Rhythmus muss zum Rhythmus des Unternehmens passen. Das Learning idealerweise findet statt, nachdem das Ganze schon produktiv vertestet wurde. Ohne echtes User-, Bürger- oder Kundenfeedback ist es nichts wert.

So ein Learning muss halt auch verdaut und verwertet werden. Ein Learning, über das man nur redet, dann auseinandergeht und nichts in der weiteren Arbeit ändert, ist völlig nutzlos. Das heißt, es muss eine Phase stattfinden, in der die Learnings etwas verändern, und zwar auf allen Ebenen: am Ablauf, am Inhalt, an den Entscheidungen, an der Qualität, an der Governance. Früher nannte man das kontinuierlicher Verbesserungsprozess.

Bitte, bitte, bitte, bitte hören Sie auf, nur über Gefühle und psychologische Themen zu reden. Sicher gibt's da auch immer Potenzial und Luft nach oben, was zu lernen. Das ist aber nicht das Hauptziel der Arbeit. Ich gehe ja auf Arbeit, um zu arbeiten. Das Hauptziel ist die Arbeit.

Das heißt, die Learnings müssen in die Arbeit fließen und wenn Ihr einziges Learning ist, dass Sie besser zusammenarbeiten müssen, sorry, dann haben Sie Ihre Hausaufgaben nicht richtig gemacht. Learning heißt: Sie wissen, welche Annahmen waren nicht richtig, welche neuen Annahmen können Sie nun treffen, was hat der User, Kunde, Bürger für Feedback gegeben, was sagen die Daten denn, wie war die Qualität, wie war der Ablauf, hätten Sie schneller, besser sein können? Wie war die Kommunikation?

Okay, nun sind wir wieder bei den Leuten. Das gehört mit dazu, aber das kann niemals den gesamten Raum einnehmen. Und wenn das einzige Learning in jedem Ihrer Gespräche ist, dass das Leadership nicht gut ist, sorry, dann müssen wir nochmal über das ganze Setup reden. Wir sind hier nicht „die Unten gegen die Oben" und umgekehrt. Zusammenarbeit heißt das Zauberwort.

Rollen: Arbeit statt Titel

Daher sprechen wir nun über Rollen. Ich bin kein Fan von Rollen. Ich bin ein Fan davon herauszufinden, welche Arbeit überhaupt zu tun ist, um dann einen Vor- und Nachnamen hinzuschreiben, wer die Arbeit macht. Vergessen Sie Rollen und Titel. Ich kenne Konzerne, die haben das schon vor über zehn Jahren abgeschafft, weil es einfach nichts bringt.

Es gibt so viel Arbeit, die Arbeit wird sicher nicht ausgehen. Ich glaube nicht, dass einer Angst haben muss, dass es keine Arbeit mehr gibt. Ganz im Gegenteil: Wenn man mal seinen Blick öffnet, gibt's sogar noch mehr Arbeit als vorher. Und es muss so viel Spaß machen, was Geniales umzusetzen, dass es völlig egal ist, wie der Titel dazu heißt.

Ich denke auch, wir werden ständig etwas Neues lernen müssen. Deswegen kann ich mich nicht auf irgendeiner Rollenbeschreibung ausruhen.

Man muss die Coding-Agenten bedienen zu können, Architektur und Qualität definieren können, herausfinden können, was überhaupt gebaut werden soll, Annahmen treffen können, Experimente formulieren können, KPIs definieren können, die man messen kann, Daten finden, die man messen kann, die auf die KPIs einzahlen, die Rahmenbedingungen schaffen, so dass man in Ruhe arbeiten kann und, und, und, und, und. So viel Arbeit.

Schreiben Sie alle Tätigkeiten mal auf.

Danach: Alle Entwickler, Business-Analysten, Engineers, Scrum Master, Product Owner, Team Leads, Leader X, Y, Z, was weiß ich, wie viele Führungskräfte Sie haben und wie sie alle heißen. Schreiben Sie mal nur die Vor- Nachnamen hin.

Sie haben die Liste der Tätigkeiten und dann wird gematcht: Wer macht was? Und das muss nicht in Stein gemeißelt sein, das kann sich immer mal wieder ändern.

Und nach ein paar Monaten fallen Ihnen vielleicht neue Rollenbezeichnungen ein oder Sie lernen als Organisation dazu und sagen: Es verschwimmt sowieso. Es verschwimmt. Egal. Wir arbeiten zusammen. Den Rollentitel, den Sie in Ihrem Arbeitsvertrag haben, den können Sie auch gerne behalten, keiner nimmt ihn Ihnen weg, aber in der täglichen Arbeit muss die Arbeit einfach gemacht werden und jede Arbeit ist wertvoll, und in jeder Arbeit muss ich lernen und wir fangen alle irgendwo an zu lernen und keiner weiß alles. Also entspannen Sie sich.

Ich habe es zu oft live und in Farbe gesehen. Leute haben Angst. Leute haben zu viel zu tun. Leute haben zu wenig zu tun. Jeder entwickelt seine Strategie, irgendwie durchzukommen im Leben. Und dadurch entstehen völlig unnötige dumme Dinge.

Ich habe schon Leute gesehen, die nur deshalb irgendwelche Meetings einstellen, weil sie gar nicht wissen, was sie sonst machen sollen. Daher ist es so wichtig, dass Sie mal ein paar Tage investieren und mal nur herausfinden, welche Arbeit zu tun ist und wer macht diese Arbeit. Es wird wie ein Befreiungsschlag sein.

Es gibt Leute, die haben wirklich Angst. Die sind total verunsichert. Die wollen ihr Bestes geben und wissen nicht, wo und wie. Und sie würden es Ihnen niemals sagen und sie werden es auch niemals zeigen.

Durch meine Lebenserfahrung, ich bin schon ein bisschen älter, habe ich mittlerweile ein ganz gutes Gespür dafür, und wie oft habe ich gesehen, was für eine riesen Erleichterung entsteht, wenn das mal jemand so in die Hand nimmt, dass keiner sein Gesicht dabei verliert.

Bleiben Sie locker. Machen Sie kein großes Drama draus. Machen Sie keine Doktorarbeit draus. Schreiben Sie einfach die Arbeit auf, die zu tun ist, die Namen daneben und gut ist.

Tickets, Backlog und echte Leistung

Ob Sie noch Tickets verwenden oder nicht, das hängt so ein bisschen davon ab, wie Sie das mit den KI-Agenten aufbauen. Für das, was die Menschen in Phasen vor- und nachbereiten, hätte ich gesagt, reicht auch irgendeine Wiki-Seite mit einer banalen Tabelle. Ich denke, kleinteilige Tickets zu pflegen, die Zeiten sind vorbei.

Und wenn man ehrlich ist, ein Backlog mit Dingen, die nie fertig werden, war schon immer mega mega un-agil, denn Lean Thinking, die Wurzel von Agil aus den 50er Jahren, kennt acht Arten von Verschwendung, Muda, und Tickets im Backlog ist ein super Beispiel für Verschwendung.

Nutzen Sie die Chance, das ganze Scrum zu überdenken und wieder auf Leistung zu gehen. Nicht Leistung im Sinne von: Wir erreichen Meilensteine, wir produzieren viele Tickets, wir reviewen wie die Verrückten, was die KI-Agenten machen, sondern Leistung im Sinne von: Der Kunde fand das super, was wir gemacht haben. Wir verdienen viel mehr Geld, wir sparen Kosten, wir kriegen mehr Kunden, wir erobern neue Märkte. Solche Leistungskriterien, und ganz wichtig: Wir lernen dazu.

In dem Moment, wo Sie was Großartiges machen, viel Geld verdienen und nicht dazulernen, bauen Sie Legacy auf. Nutzen Sie die Chance für einen Neuanfang.

Ich könnte für jedes Unternehmensproblem, was Sie jetzt mit Scrum und KI verunsichert ist, pragmatische Tipps und Lösungen aufzeigen, wie Sie ohne Riesen-Reorganisation und Change-Projekte rauskommen. Dazu muss ich wissen, was Sie gerade treiben. Kontaktieren Sie mich. Ich schreibe auch gerade an einem Playbook, sodass Sie das durchführen können, ohne teure Unternehmensberater ins Haus zu holen. Ich freue mich über Ihre Rückmeldungen.

FAQs

Brauchen wir Scrum überhaupt noch?

1. Funktioniert Scrum überhaupt noch mit AI Agents?

Man liest in sozialen Medien von AI Engineers, die ein Scrum Team aus KI Agenten gebaut haben. Das funktioniert, aber diese Antwort hilft Ihnen nicht in einer größeren Organisation.

Ich denke es ist so: Scrum wird so, wie Sie es kennen, nicht mehr lange funktionieren. Es kommt auch darauf an wie weit fortgeschritten Ihre Softwareentwicklung mit AI Agents ist.

Die Veränderung wird in Phasen ablaufen.

Zunächst einmal ist es sicher sinnvoll eine Art Kadenz zu haben. Wenn die gesamte Organisation in Sprints denkt und arbeitet, kann man das erstmal so lassen und diese aber anders nutzen.

Die Teamzusammensetzung wird aber nicht mehr funktionieren. Auch die kleinteiligen Tickets nicht. Die Rollen werden sich verändern. Das Review wird gesprengt werden – wer soll all das reviewen was KI so schnell erstellt? Das Entscheiden, was überhaupt und wie es gebaut wird, wird mehr Zeit einnehmen, in der Zeit kann man aber nicht entwickeln, damit entstehen unterschiedliche Rhythmen innerhalb eines Teams.

Die Führungsstrukturen um die Scrum Teams herum werden sich verändern müssen, wenn Sie diese während der Scrum Einführung damals unangetastet gelassen haben. Je mehr Sie mit KI Agenten arbeiten, desto mehr werden Sie merken, dass Scrum an seine Grenzen kommt, innerhalb und außerhalb des Scrum Teams.

2. Ist Scrum noch sinnvoll, wenn AI Agents schneller entwickeln können als Menschen?

Meine persönliche Meinung: Nein. Es gibt bessere Möglichkeiten, die neue Arbeitsweise zu strukturieren und zu organisieren. Die großen Organisationen, in denen ich während der agilen Transformation tätig war, gaben den Teams die Freiheit Scrum anzuwenden oder nicht und die eigentliche Veränderung fand in den Führungsstrukturen und der Art und Weise statt wie Initiativen durchgeführt werden. Schon vor KI hat Scrum nicht zu allem gepasst. Wenn die KI Agenten arbeiten, muss man keine 2 Wochen warten und die Menge dessen, was produziert wird, kann keiner reviewen.

Dennoch muss es eine Möglichkeit geben zu entscheiden, was ist es Wert gebaut zu werden? Wie validieren wir es? Was ist unser Feedback Loop? Was sagt der User/Kunde/Bürger zu unserer Lösung? Wie viel Budget ist es wert? Wie machen wir die Governance?

All diese Fragen hat Scrum eh nie vollständig beantwortet. Einige Organisationen haben daher schon vor KI weitere Methoden verwendet und einige Organisationen haben Scrum nur als Wasserfall in Tickets abgebildet. Wenn das Letztere eher dem entspricht wie es bei Ihnen gelebt wird, macht Scrum keinen Sinn mehr mit KI Agenten. Dann macht es viel mehr Sinn erstmal die Flugebene darüber zu betrachten: Wonach entscheiden wir was gemacht wird, wie validieren wir es, wie sind unsere Feedback Loops, haben wir Kill-Kriterien und was sagt der Kunde/User/Bürger dazu?

3. Brauchen wir noch Sprints, wenn AI Agents 24/7 arbeiten können?

Nicht für die Agents. Sie benötigen aber verschiedene Rhythmen für die Menschen in der Organisation. Sie benötigen einen Rhythmus in dem entschieden wird, was gebaut wird, einen für Feedback Loops, einen für Governance Entscheidungen, einen für das Lernen in der Organisation, einen für Richtungsänderungen, einen für Budgetentscheidungen und so weiter. Diese Rhythmen müssen in eine gemeinsame Kadenz gebracht werden. Ob Sie das Wort Sprint weiter verwenden oder nicht ist zweitrangig. Aber die verschiedenen Rhythmen können keinesfalls alle 2 Wochen lang sein. Einige werden kürzer und einige werden länger sein. Diese 2 Wochen Sprints hatten auch einen riesigen Nachteil. Der Mensch und die Natur funktioniert in Zyklen. KI bringt Sie wieder dazu in Zyklen zu arbeiten, was ein großer Fortschritt ist. Sie müssen Zeit einplanen in der entschieden wird, was und wie es gebaut wird, dann baut die KI es ziemlich schnell und evtl. hat man sich geirrt und man verwirft es wieder. Sie haben nun die Freiheit die Zeiträume dafür selbst zu wählen. Das erleichtert das Arbeiten ungemein, weil nicht alle diese Tätigkeiten gleich sind und nun auch nicht mehr in gleiche Tickets und gleiche Sprints gequetscht werden müssen. Nutzen Sie diese Chance!

4. Ist Agile durch AI Agents überholt?

Ganz im Gegenteil. Die agilen Werte sind zeitlos. Man muss aber ehrlicherweise sagen, dass Agile als Begriff echt nicht mehr zu ertragen ist. Und das Thema einfach ruhen lassen. Es kann keiner mehr hören.

Besser ist es konkret zu werden, konkrete praktische Hilfestellung zu bieten. Da hilft Lean Thinking viel mehr.

Nehmen wir zum Beispiel die 8 Arten von Muda, Verschwendung. In dem Moment wo Sie mit KI Agenten arbeiten, skalieren Sie Verschwendung, wenn sie vorher schon da war. Es macht also sehr viel Sinn sich damit auseinanderzusetzen.

Oder nehmen wir Work in Progress Limits aus Kanban. Wenn nun zig KI Agenten parallel arbeiten und Sie das nicht bewusst begrenzen, begrenzen Sie die Durchlaufzeit, denn irgendwo gibt es immer ein Bottleneck. Kürzere Durchlaufzeit bedeutet, dass Sie länger auf den Return on Invest warten. Das lässt sich sogar mathematisch berechnen.

„Vermeide unnötige Fehler" ist ein weiteres hilfreiches Prinzip aus der Lean Philosophie, das jetzt mit KI Agenten extrem wichtig wird. Bevor der KI Agent etwas automatisiert, müssen Sie den Use Case gut durchdenken, sonst skalieren Sie vermeidbare Fehler und könnten sich damit blamieren.

Das sind nur einige Beispiele. Agile wurde ja von Lean abgeleitet. Lean gibt es schon seit den 50er Jahren. Ich empfehle daher zurück zu den Wurzeln zu gehen und mit dem jetzigen Wissen neu zu kombinieren und dann konkret auf die Arbeit mit KI Agenten anzuwenden.

Scrum neu denken vs. komplett ersetzen

5. Was ist die beste Alternative zu Scrum für AI-native Teams?

Scrum wurde weltweit eingeführt, ob es passte oder nicht. Meistens war es auch gar nicht wirklich Scrum. Wenn Sie nun AI-native Teams haben, so kommt es auf mehrere Faktoren an bevor Sie entscheiden, welche Arbeitsweise die beste für Sie ist. Sie benötigen auf jeden Fall eine direkte Zusammenarbeit mit Usern/Kunden/Bürgern bzw. jemand der für diese Gruppe steht und den AI Engineers. Sie benötigen einen Feedback Loop. Sie benötigen Kriterien anhand derer Sie entscheiden ob und wie etwas gebaut wird und weshalb etwas wieder verworfen wird. Sie benötigen eine Governance. Die kleineren Teams können sich selbst organisieren, müssen aber in die eben genannten Punkte einbezogen werden. Ich empfehle sich mit Lean Thinking zu beschäftigen und mit Kanban. Auch Shape up hat hilfreiche Elemente. Wichtig ist, dass Sie die Arbeitsweise so verändern, dass sie zu Ihrer Initiative passt.

6. Scrum vs. Shape Up – was ist besser für AI-gestützte Entwicklung?

Shape up hat wertvolle Elemente, die den Menschen helfen zu entscheiden, was überhaupt gebaut werden soll. Sobald das klar ist und die KI Agenten arbeiten, können die KI Agenten eine Art Scrum verwenden. Scrum kommt an seine Grenzen wenn man KI Agenten mit Menschen kombiniert, denn kein Mensch kann die Masse reviewen und die KI Agenten brauchen auch keinen menschlichen Scrum Master. Sie müssen aber wissen was und wie gebaut werden soll und dafür bietet Shape up hilfreiche Elemente. Siehe dazu auch diesen Artikel: Shape Up vs. Scrum — eine Verbesserung aus meiner Sicht

7. Ist Kanban besser als Scrum für Teams mit AI Agents?

Kanban hat einen großen Vorteil: Die Arbeit wird limitiert. Work in Progress Limits auch WIP Limit genannt. Das ist hilfreich für Teams, die mit KI Agenten arbeiten. Zum einen limitiert man die Arbeit, die die KI Agenten tun, denn sonst überlastet man die Menschen, die das steuern und zum anderen limitiert man die Arbeit eine Flughöhe weiter oben, nämlich wie viele Projekte oder Initiativen überhaupt gleichzeitig in einem oder mehreren Teams bearbeitet werden.

Kanban hat keine vorgeschriebenen Meetings oder Events. Das gibt den Teams die Freiheit das selbst zu gestalten.

Kanban misst wie lange es dauert von der Idee bis zur produktiven Nutzung, das nennt sich Lead Time. Und Kanban misst wie lange es dauert vom Moment an, in dem die Idee begonnen wird umzusetzen bis zur produktiven Nutzung, das nennt sich Cycle Time.

Das sind bei der Arbeit mit KI Agenten sinnvollere Messgrößen als Tickets pro Sprint oder Story Points (wobei Story Points nie für Messungen gedacht waren, aber dazu weiter unten mehr).

Kanban hilft mehr outcome und impact orientiert zu denken und zu arbeiten. Daher ist es meiner Meinung nach besser für Teams, die schon sehr weit fortgeschritten sind mit der Arbeit mit KI Agenten.

Dies setzt aber voraus, dass das Leadership Team Kanban versteht und auch auf den höheren Flugebenen lebt. Hier empfehle ich sich mit den Flight Levels von Dr. Klaus Leopold zu beschäftigen.

Messen und Planen vs. einfach Machen

8. Sind Story Points mit AI Agents noch sinnvoll?

Nein. Ganz klar nein. Story Points ist ein Reizthema, es gibt darüber viel Streit. Ich will die alten Diskussionen gar nicht mehr aufmachen. Nur so viel: Ein eingespieltes Team hat irgendwann nur noch 5 oder 8 Story Points pro Tickets, weil man es geschafft hat Arbeitspakete gleichmäßig klein zu schneiden, gut zu verstehen und weil die gemeinsame Arbeitsweise aufeinander abgestimmt ist. Und wenn dann eh alles die gleiche Anzahl hat, kann man es auch weglassen.

Jetzt mit KI Agenten ist es extrem wichtig OUTCOME zu messen. Damit meine ich: Was für einen Mehrwert für den Kunden/User/Bürger hat das, was eben gebaut wurde? Sie müssen dringend damit aufhören Anzahl und Dauer von Arbeitspaketen zu messen. Beachten Sie diesen Rat! Wenn KI Agenten sehr schnell und sehr viel bauen und nichts davon am Ende einen messbaren Mehrwert für das Unternehmen liefert, dann können Sie zwar mit einer hervorragenden Messung beeindrucken, verfehlen aber das eigentliche Ziel!

Deshalb ist die wichtigste Überlegung beim Thema Story Points, Schätzungen und Messungen? Wie messen wir den Mehrwert dessen, was hier gebaut wird? Dazu benötigen Sie passende KPIs und KEINE Story Points.

9. Brauchen wir überhaupt noch Velocity?

Ich frage Sie: Welche Aussagekraft hat die Geschwindigkeit eines Teams bestehend aus Menschen, die KI Agenten nutzen, wenn das, was das Team baut, keinen Mehrwert für das Unternehmen liefert?

KI ist mega schnell. Wozu das messen? Menschen sind die Engpässe.

Es macht durchaus Sinn zu messen wo Abläufe langsam werden und sich stauen. Dazu nehme ich aber nicht Velocity als Kennzahl, sondern andere KPIs wie zum Beispiel wie lange es dauert von der Idee bis zum Zeitpunkt, an dem die Lösung produktiv für Kunden/User/Bürger nutzbar ist.

Sie messen damit wie schnell Sie als Organisation etwas umsetzen können. Das ist eine wichtige Messung. Wie schnell dabei ein Team irgendetwas baut, ist nur ein kleiner Teil, denn bevor das Team beginnt und nachdem das Team fertig ist, passieren eventuell Dinge außerhalb des Teams und diese müssen mit in die Messung.

Merksatz: Messen Sie im Zeitalter von KI Agenten outcome orientiert entlang der gesamten Prozesskette und hören Sie auf Aktivität von Teilschritten zu messen.

10. Wie misst man Team-Produktivität, wenn Entwickler mit AI Agents arbeiten?

Es ist sinnlos Team-Produktivität zu messen. Es ist eine Scheinmetrik. Sie gibt Ihnen vielleicht ein beruhigendes Gefühl, aber Sie tragen mit der Messung von Team-Produktivität in keinster Weise zum Unternehmenserfolg bei. Alle schlauen Teams dieser Welt wissen wie man sich verhalten muss um solche sinnlosen Metriken zu steigern. Mit der Messung von Team-Produktivität eröffnen Sie ein sinnloses Spiel, das Sie zudem auch niemals gewinnen können.

Fangen Sie damit an zu lernen, wie man mit Business KPIs misst, ob das, was Entwickler mit AI Agents tun, überhaupt zu den Unternehmenszielen beisteuert.

Ich sage das deshalb so unverblümt, da diese Frage offenbart, dass Sie dringend umdenken müssen.

Engineers sind clevere Leute. Was auch immer Sie für eine Produktivitätsmessung machen wollen, die Engineers werden sie mit Zahlen beeindrucken.

Wenn das, was gebaut wird, aber gar nicht das ist, was das Unternehmen braucht, was nützt dann ein mega produktives Team?

Oder wenn es bevor die Arbeit ins Team kommt oder nachdem die Arbeit das Team verlässt, wahnsinnig langsam zugeht, was nützt es dann?

Oder wenn das Team viele Abhängigkeiten hat, in denen nichts geändert wird, die das Team ausbremsen, was sagt dann die Messung aus?

Oder wenn zu einem bestimmten Zeitpunkt es sinnvoll war das zu bauen, was gebaut wurde, aber eine bestimmte Zeit später, es nicht mehr sinnvoll ist, weil die Welt sich weiter gedreht hat, was hilft Ihnen dann die Bestätigung darüber wie produktiv alle waren?

NICHTS!

Es macht durchaus Sinn zu messen wo Abläufe langsam werden und sich stauen. Dazu nehme ich aber nicht Velocity als Kennzahl, sondern andere KPIs wie zum Beispiel wie lange es dauert von der Idee bis zum Zeitpunkt, an dem die Lösung produktiv für Kunden/User/Bürger nutzbar ist.

Es gibt technische KPIs wie Deployment Frequenz oder Change Failure Rate oder Anzahl Bugs. Diese sind dann sinnvoll, wenn gleichzeitig über KPIs der Business Value mitgemessen wird.

11. Ist Estimation mit AI überhaupt noch sinnvoll?

Nicht auf Ticketebene. Auf einer höheren Flugebene, ja. Wenn in Ihrer Organisation mehrere Teams an einer größeren Initiative arbeiten, macht es durchaus Sinn eine Art von Schätzung zu verwenden um zu verstehen, wann und wie die einzelnen Teile zu einem Gesamten zusammenkommen.

Prozesse und Zeremonien vs. Geschwindigkeit

12. Welche Scrum Ceremonies sind mit AI Agents noch sinnvoll? Brauchen wir noch Daily Standups, wenn AI Agents einen großen Teil der Arbeit erledigen?

Die KI Agenten können untereinander Scrum machen. Die machen dann aber alle Scrum Events eines Sprints an einem Tag.

Die Menschen in einem Team sollen die Scrum Events beibehalten, die sie benötigen, denn die Menschen, die miteinander zusammenarbeiten, müssen weiterhin täglich miteinander sprechen. Wichtig hierbei ist aber eine Flexibilität in Bezug auf die Agenda. Ich empfehle, das Team selbst entscheiden zu lassen, welche Agenda für das jeweilige Scrum Event aktuell am meisten hilft, denn das ändert sich. Je besser Sie das Gesamtsetup der KI Agenten aufbauen, desto weniger müssen Menschen in die jeweiligen Details einsteigen.

13. Brauchen wir noch Sprint Planning mit AI Agents?

Mein Informatikprofessor an der Uni sagte immer: Planung ist die Ersetzung des Zufalls durch den Irrtum. Planning heißt, jemand hat einen Plan. Das heißt jemand geht davon aus, dass der Plan gut ist. Davon auszugehen, dass ein Plan gut ist, ist naiv.

Eine reife Vorgehensweise ist die: Ich treffe Annahmen und überlege mir, wie ich diese Annahmen validieren oder widerlegen kann. Welche Experimente kann ich durchführen und wie messe ich das?

Mit KI Agenten sollten Sie beginnen hypothesenbasiert zu arbeiten. Die KI Agenten arbeiten wahnsinnig schnell. Sie können die Validierungen schnell durchführen.

Das Planning hat dann nur noch die Funktion, dass die Menschen verstehen, was die KI Agenten als nächstes durchführen und dass die KI Agenten die schriftlichen Anweisungen dafür erhalten.

Es kann völlig anders ablaufen als ein Scrum Planning.

Die KI Agenten unter sich zerlegen die Aufgaben dann in Teilaufgaben und führen hier evtl. auch eine Art Planning durch.

Wichtig ist, dass Sie, bevor Menschen die KI Agenten starten, sich darüber im Klaren sind, welche Annahmen Sie getroffen haben und wie Sie messen wollen ob Sie richtig oder falsch lagen.

14. Brauchen wir noch Retrospectives, wenn ein Teil des Teams aus AI Agents besteht?

Sie benötigen ein regelmäßiges Event, in dem Sie Feedback der Kunden/User/Bürger zu Ihrer Lösung erhalten.

Sie benötigen ein regelmäßiges Event, in dem Sie die Learnings von Einzelnen und von Teams verstehen, festhalten und das Gelernte in Änderungen an der Lösung, an der Vorgehensweise, an der Struktur, am System und so weiter, übersetzen.

Sie benötigen ein regelmäßiges Event, in dem Sie darüber diskutieren was die Messungen der Business und outcome orientierten KPIs für die Lösung und die Arbeit der Teams und KI Agenten bedeuten.

Wie Sie dieses Event nennen ist egal. Es muss regelmäßig stattfinden, diszipliniert diese Punkte abarbeiten und es muss in der Lage sein die besprochenen Dinge auch wirklich umzusetzen.

Sie können natürlich auch über Gefühle und psychologische Sicherheit sprechen - wenn das bei Ihnen jedoch den Hauptteil einer Retrospektive ausmacht, so ist Ihr übergreifendes Setup noch nicht ausgereift. Das hauptsächliche Sprechen über Gefühle in einer Retrospektive ist ein Signal dafür, dass das Leadership Team noch nicht verstanden hat wie man das AI Operating Model so aufsetzt, dass die Arbeit der Teams mit KI Agenten auf den Business Value einzahlt.

15. Brauchen wir überhaupt noch Jira mit AI Agents?

Jira, Azure DevOps oder ähnliche Tools haben verschiedene Funktionen. Es geht nicht nur um die Tickets im Sprint. Man kann damit sprintübergreifend planen, man kann teamübergreifend koordinieren und planen. Man kann es für Testmanagement verwenden. Jira und Azure DevOps sind auch Tools, die vollautomatische Pipelines eines vollständigen DevOps-Prozesses auf verschiedenen Umgebungen abbilden können (oder die Integrationen dazu bereitstellen).

Wenn Sie mit KI Agenten arbeiten, stellt sich die Frage, welche Funktionen von Jira nun weiterhin notwendig sind und welche wegfallen. Meiner Meinung nach sind team- und sprintübergreifende Abstraktionsebenen weiterhin wichtig. Genauso wie eine funktionierende Test- und DevOps-Struktur. Sie benötigen auch eine Art schriftliche Sammlung der Dinge, die die KI Agenten tun sollen. Das können Tickets sein. Es kann aber auch anders gelöst werden. Es hängt sehr von Ihrer eigenen Organisation ab und vom Grad der Autonomie, die Ihre KI Agenten haben, was wiederum vom Grad dessen abhängt, wie gut Sie Architektur und Governance schon vorbereitet haben.