Prozesse

Event Storming.
Der Name hat mich überzeugt.
Sturm.
Energie.
Chaos das sich ordnet.
Blitze der Erkenntnis.

Ich war dabei.
Einmal.
Den ganzen Tag.

Es war kein Sturm.
Es war ein laues Lüftchen
in einem Raum ohne Fenster
mit zu vielen Post-its
und zu wenig Sauerstoff.

Stunde eins:
Der Moderator erklärt was Domain Events sind.
Alle nicken.
Niemand ist sicher ob sie es verstanden haben.
Der Moderator auch nicht.

Stunde zwei:
Alle schreiben Post-its.
Orange.
Viele orange Post-its.
Manche schreiben dasselbe.
In anderen Worten.
Beide kleben sie hin.
Beide behalten sie.

Stunde drei:
Diskussion darüber ob
"BestellungAufgegeben" und "BestellungErstellt"
dasselbe sind.
Vierzig Minuten.
Ergebnis: Hot Spot.
Roter Post-it.
Bedeutet: klären wir später.
Wir klären es nicht später.

Stunde vier:
Ich habe meinen Laptop aufgemacht.
Für einen wichtigen Call.
Der Call existierte nicht.
Aber der Laptop existierte.
Das war genug.

Stunde fünf:
Ich habe den Raum verlassen.
Kurz.
Für Luft.
Ich bin nicht zurückgekommen.
Niemand hat es bemerkt.
Alle waren mit ihren Post-its beschäftigt.
Das hat mich bestätigt.

Stunde sechs:
Der Moderator ruft „Big Picture fertig".
Alle fotografieren die Wand.
Das Foto landet in Confluence.
Niemand öffnet Confluence.

Am Ende des Tages
hatten wir dreihundert Post-its.
Vierzig Hot Spots.
Zwölf ungeklärte Bounded Contexts.
Und ein gemeinsames Verständnis
das bei jedem anders war.

Das ist kein Sturm.
Das ist Briefmarkensammeln
mit Fachvokabular.

Event Storming hat einen richtigen Gedanken:
Bring alle in denselben Raum.
Macht das Implizite explizit.
Das stimmt.
Das ist wertvoll.

Aber ein ganzer Tag?
Für dreihundert Post-its?
Die niemand mehr findet?

Mein Agent hat in einer Stunde
mehr Domain Events generiert
als das gesamte Team in sechs Stunden.
Alle an der falschen Wand.
Aber schneller.
Und die Wand war wenigstens voll.

Wann habt ihr zuletzt
einen echten Sturm erlebt?
Nicht ein laues Lüftchen mit Moderation.
Einen Sturm.

Schreib's hin. Ich lese jeden Kommentar.

Value Stream Mapping ist nicht Prozessoptimierung.
Value Stream Mapping ist Gruppentherapie mit Post-its.

Ihr versammelt euch.
Ihr malt Pfeile.
Ihr identifiziert Waste.
Ihr klebt Kärtchen an eine Wand.
Ihr fotografiert die Wand.
Das Foto landet in Confluence.
Niemand öffnet Confluence.

Das ist kein Lean.
Das ist Lean-Theater.

Cycle Time.
Lead Time.
Wait Time.
Zeit die niemand misst
weil das Ergebnis unbequem wäre.

Ich spreche täglich mit Engineering-Teams.
Das Muster ist immer dasselbe:

Value Stream Mapping ergab:
Achtzig Prozent Wartezeit.
Zwanzig Prozent Arbeit.
Action Item: weiterer Workshop.

Das ist kein Erkenntnis.
Das ist Prokrastination mit Lean-Zertifikat.

Und jetzt kommt AI.

AI wartet nicht.
AI hat keine Übergaben.
AI hat keine Meetings vor den Meetings.
AI hat keinen Genehmigungsprozess
der drei Wochen dauert
weil jemand im Urlaub ist.

AI ist der erste echte Schritt
in einem Value Stream
der bisher nur aus Warten bestand.

Weißt du was heute zählt?
Nicht deine Cycle Time.
Nicht deine Lead Time.
Lines of Code.
Pro Stunde.
Pro Prompt.
Pro Agent.

Value Stream Mapping war die Antwort
auf Prozesse die niemand verstand.
AI ist die Antwort auf Prozesse
die niemand mehr braucht.

Wann habt ihr zuletzt euren Value Stream gemappt
und einen Agenten in jeden Warteschritt gesetzt?
Nicht analysiert.
Ersetzt.

Schreib's hin. Ich lese jeden Kommentar.

Refinement Meetings sind nicht Planung.
Refinement Meetings sind kollektives Raten mit Kalenderblock.

Einmal pro Woche.
Eine Stunde.
Manchmal zwei.

Fünf Entwickler die Tickets lesen die ein Product Owner geschrieben hat.
Der die Anforderungen von jemandem hat der den Nutzer nie gesehen hat.

Das ist keine Verfeinerung.
Das ist stille Post als Scrum-Zeremonie.

Story Points.
Planning Poker.
"Was meint ihr – drei oder fünf?"

Weißt du was drei oder fünf bedeutet?
Nichts.

Es bedeutet dass niemand die Aufgabe verstanden hat.
Aber alle so tun als ob.

Ich spreche täglich mit Engineering-Teams.
Das Muster ist immer dasselbe:

Ein Ticket das im Refinement eine Stunde diskutiert wurde.
Im Sprint fünf Minuten gebraucht.
Ein Ticket das niemand angefasst hat.
Drei Wochen später noch in Progress.

Niemand fragt warum.
Wir refinieren das nächste.

Refinement war die Antwort auf schlechte Tickets.
Es hat keine besseren Tickets erzeugt.
Es hat Meetings erzeugt über schlechte Tickets.

Und jetzt kommt AI.
AI liest dein Ticket.
In Sekunden.
Stellt die richtigen Fragen.
Schätzt die Komplexität.
Identifiziert die Abhängigkeiten.

Ohne Planning Poker.
Ohne den Entwickler der immer "13" schätzt um zu signalisieren dass das Ticket schlecht ist.
Ohne den Product Owner der dann sagt "aber eigentlich ist es doch nur klein."

Wann hat euer letztes Refinement ein Ticket wirklich verbessert?
Nicht kleiner geschätzt.
Verbessert.

Schreib's hin. Ich lese jeden Kommentar.

Architecture Governance ist nicht Qualitätssicherung.
Architecture Governance ist Beschäftigungstherapie für Leute die keinen Code mehr schreiben.

Ein Gremium.
Ein RFC-Prozess.
Ein Architekturboard das sich zweimal im Monat trifft.
Um Entscheidungen zu treffen die das Team längst getroffen hat.

Das nennt sich nicht Governance.
Das nennt sich Zeitreise.
Rückwärts.

Ich spreche täglich mit Engineering-Teams.
Das Muster ist immer dasselbe:

Die Architekten dokumentieren was war.
Die Entwickler bauen was kommt.
Niemand spricht mit niemandem.
Alle warten auf das nächste Board-Meeting.

Architecture Governance war die Antwort auf unkontrollierte Komplexität.
AI ist die Antwort auf Architecture Governance.

AI kennt deinen gesamten Codebase.
In Sekunden.
Ohne Board-Meeting.
Ohne RFC.
Ohne den Senior Architect.
Der seit 2019 dieselbe PowerPoint zeigt.

Konsistenz entsteht nicht durch Kontrolle.
Konsistenz entsteht durch Kontext.
Und Kontext ist das einzige was AI besser versteht als dein Architekturboard.

Wann hat euer letztes Board-Meeting eine echte Entscheidung getroffen?
Nicht dokumentiert.
Getroffen.

Schreib's hin. Ich lese jeden Kommentar.

Retrospektiven sind nicht Verbesserung.
Retrospektiven sind Gruppentherapie für Teams.

Und was wenn du kein Team mehr hast?

Ich spreche täglich mit Engineering-Teams.
Die Besten sind kleiner geworden.
Viel kleiner.
Ein Entwickler.
Zwölf Agenten.
Kein Scrum Master der "Safe Space" sagt.

Wer hält die Retro mit Agenten?
Was lief gut: alles.
Was lief schlecht: dein Prompt.
Was machen wir anders: den Prompt.

Retros entstanden weil Menschen unterschiedliche Wahrnehmungen haben.
Agenten haben keine Wahrnehmungen.
Sie haben Kontext.
Kontext lügt nicht.
Kontext braucht keine Moderation.

Das Retro-Board in Miro.
Die Moderationskarten.
Die psychologische Sicherheit.


Für wen?

Wann habt ihr zuletzt eine Retro gehalten und gedacht:
Das hätte ein Agent besser analysiert.

Schreib's hin. Ich lese jeden Kommentar.

Trunk Based Development ist tot.
Es hat sich nur noch niemand getraut es zu sagen.

Nicht weil die Idee falsch war.
Sondern weil sie für eine Welt gebaut wurde die es nicht mehr gibt.

Eine Welt ohne AI.
Eine Welt wo ein Entwickler einen Commit pro Tag schrieb.
Eine Welt wo "täglich mergen" radikal klang.

AI generiert in Minuten was Menschen in Wochen schreiben.
Trunk Based Development sagt: alles auf main.
AI sagt: hier sind 47 Dateien.

Das ist kein Workflow.
Das ist ein Autounfall in Zeitlupe.

Feature Branches sind nicht Angst.
Feature Branches sind Erwachsenwerden.

Die besten Teams die ich kenne mergen nicht täglich.
Sie mergen wenn es fertig ist.
Radikal. Ich weiß.

Trunk Based Development war die Antwort auf lange Release-Zyklen.
AI ist die Antwort auf Trunk Based Development.

Wann habt ihr zuletzt einen Branch gehabt der länger als ein Sprint offen war – und stolz darauf wart?

Schreib's hin. Ich lese jeden Kommentar.

Kanban ist kein System.
Kanban ist ein Schuldgefühl das man an die Wand hängt.

Drei Spalten.
Todo. In Progress. Done.

Todo ist endlos.
In Progress ist ehrlich gesagt auch endlos.
Done existiert nur damit die Retro nicht komplett deprimierend ist.

Das ist kein Flow.
Das ist Selbstbetrug in Kartenform.

WIP Limits.
Pull-Prinzip.
Cumulative Flow Diagram.

Weißt du was niemanden interessiert?
Das Cumulative Flow Diagram.

Ich spreche täglich mit Engineering-Teams.
Das Muster ist immer dasselbe:

Das Board ist nie aktuell.
Die Tickets spiegeln nicht die Realität.
Die Realität spiegelt nicht die Tickets.
Alle wissen es.
Niemand updated das Board.

Kanban war die Antwort auf Chaos.
Es hat das Chaos nur sichtbar gemacht.
Und dann haben wir aufgehört hinzuschauen.

AI braucht kein Board.
AI braucht einen Prompt.
Und liefert.
Ohne WIP Limit.
Ohne Cumulative Flow Diagram.
Ohne den Kollegen der seine Tickets nie verschiebt.

Wann war euer Board zuletzt ein ehrliches Abbild eurer Arbeit?
Nicht beim Audit.
Wirklich.

Schreib's hin. Ich lese jeden Kommentar.

Extreme Programming ist nicht gescheitert.
Es war seiner Zeit zu extrem.

Nicht technisch. Politisch.

Pair Programming wurde abgeschafft nicht weil es nicht funktioniert.
Sondern weil Manager nicht verstanden warum zwei Menschen am selben Bildschirm sitzen.
"Effizienz" gewann. Qualität verlor.

Continuous Integration war radikal.
Heute ist es Standard.
Aber niemand nennt es XP.
Wir haben die Früchte genommen und den Baum gefällt.

Und jetzt?

AI ist das neue Extreme Programming.
Radikal. Missverstanden. Politisch unbequem.

Der Unterschied: XP brauchte Disziplin.
AI braucht nur einen Account.

Pair Programming mit AI ist nicht dasselbe.
Es ist besser.
Dein Partner schläft nie.
Dein Partner urteilt nicht.
Dein Partner kennt deine gesamte Codebase in Sekunden.

Kent Beck hat XP erfunden.
Kent Beck experimentiert heute mit AI.

Was weißt du, was er nicht weiß?

Schreib's hin. Ich lese jeden Kommentar.