Kultur

Wir haben Requirements Engineering abgeschafft. Vor acht Monaten. Niemand hat es vermisst.

Das sage ich nicht um zu provozieren. Das sage ich weil es stimmt.

Requirements Engineering ist der Versuch mit Ingenieursmethoden zu menschlichen Antworten zu kommen. Use Cases. User Stories. Akzeptanzkriterien. Abnahmeprotokolle.

Das sind Werkzeuge für eine Welt in der Menschen wissen was sie wollen bevor sie es gesehen haben. Diese Welt existiert nicht.

Ich spreche täglich mit Stakeholdern. Das Muster ist immer dasselbe:

Was braucht ihr? "Ein Dashboard." Was soll das Dashboard zeigen? "Die wichtigen Dinge." Welche Dinge sind wichtig? Nachdenken. "Das werdet ihr schon sehen."

Genau. Das werden wir sehen.

Anforderungen sind nicht das was Stakeholder sagen. Anforderungen sind nicht das was Stakeholder meinen. Anforderungen sind das was entsteht wenn man anfängt zu bauen. Emergent. Organisch. Ehrlich.

Wir bauen. Wir zeigen. Der Stakeholder sagt: das ist nicht was ich wollte. Wir fragen: was wollt ihr stattdessen? Jetzt wissen sie es. Jetzt können wir weiterbauen.

Das ist kein Umweg. Das ist der Weg.

Unser letztes Projekt hatte keine einzige dokumentierte Anforderung. Achtzehn Monate. Zwölf Deployments. Der Stakeholder hat beim dritten Deployment gesagt das sei nicht was er sich vorgestellt hatte. Beim neunten Deployment hat er aufgehört das zu sagen. Das nenne ich Konvergenz.

Ein Berater hat uns empfohlen wenigstens ein Glossar zu führen. Ich habe gefragt wozu. Er hat gesagt: damit alle dasselbe meinen wenn sie dieselben Worte benutzen. Ich habe gesagt: wir benutzen keine Worte. Wir bauen. Er hat das Projekt verlassen. Das war sein gutes Recht.

Was ich weiß: Kein Requirements-Dokument hat je ein Feature gebaut. Kein Akzeptanzkriterium hat je einen Nutzer glücklich gemacht. Kein Abnahmeprotokoll hat je eine Idee gehabt.

Code hat das alles. Code ist die Anforderung. Code ist die Dokumentation. Code ist die Wahrheit.

Wann habt ihr zuletzt eine Anforderung gestrichen weil das Bauen gezeigt hat dass sie falsch war? Nicht überarbeitet. Gestrichen.

Schreib's hin. Ich lese jeden Kommentar.

Alignment ist das wichtigste Wort
das die meisten falsch verstehen.

Alignment bedeutet nicht Konsens.
Alignment bedeutet nicht Einigkeit.
Alignment bedeutet nicht dass alle derselben Meinung sind.

Alignment bedeutet:
Alle bewegen sich in dieselbe Richtung.
Meine Richtung.

Das ist ein wichtiger Unterschied.

Konsens ist demokratisch.
Alignment ist effizient.
Demokratie ist langsam.
Effizienz ist Velocity.
Velocity ist alles.

Ich spreche täglich mit Führungskräften.
Das Muster ist immer dasselbe:

"Wir haben noch kein Alignment."
Was meint ihr damit?
"Nicht alle sind einverstanden."
Müssen alle einverstanden sein?
Nachdenken.
"Nein. Aber wir wollen alle mitnehmen."
Wie lange dauert das?
"Kommt drauf an."
Worauf?
"Wie viele Leute es gibt."
Und wenn ihr nie Alignment erreicht?
Längeres Nachdenken.
"Dann entscheidet jemand."
Wer?
Schweigen.

Ich.
Die Antwort ist immer ich.
Alignment ist der Prozess
der zu mir führt.
Manche nennen das Top-down.
Ich nenne das Klarheit.

Misalignment ist nicht Meinungsverschiedenheit.
Misalignment ist Zeitverschwendung.
Jede Stunde Misalignment
kostet Velocity.
Velocity ist Geld.
Geld ist das Überleben des Unternehmens.
Misalignment tötet Unternehmen.
Langsam.
Bequem.
In Meetings.

Mein Team ist aligned.
Immer.
Weil ich die Richtung vorgebe.
Klar.
Früh.
Ohne Rückfragen.

Manchmal fragen sie trotzdem.
Dann erkläre ich es nochmal.
Meistens in einem Meeting.
Das ich einberufe.
Das dreißig Minuten dauert.
In dem ich rede.
Bis sie aligned sind.
Das Schweigen danach
ist Alignment.

Wann habt ihr zuletzt echtes Alignment erlebt?
Nicht Konsens.
Nicht Kompromiss.
Alignment.
Die Stille nach der Entscheidung.
Die keine Fragen mehr zulässt.

Schreib's hin. Ich lese jeden Kommentar.

Der Architecture Advice Process ist nicht Dezentralisierung.
Der Architecture Advice Process ist Ringelpiez mit Anfassen.

Jeder darf Architekturentscheidungen treffen.
Aber erst muss er alle fragen.
Alle die betroffen sein könnten.
Alle die Expertise haben könnten.
Alle die eine Meinung haben könnten.
Alle.

Weißt du was passiert wenn du alle fragst?
Alle antworten.
Unterschiedlich.
Widersprüchlich.
Mit Gefühlen.
Mit Agenda.
Mit dem Wunsch gehört zu werden.

Das ist keine Architektur.
Das ist Gruppentherapie mit ADR.

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

"Wir haben den Advice Process eingeführt."
Wie lange dauert eine Entscheidung jetzt?
"Kommt drauf an."
Worauf?
"Wie viele Leute wir fragen müssen."
Und vorher?
Schweigen.
"Auch lange. Aber anders."

Anders.
Das Wort das Menschen benutzen
wenn sie nicht zugeben wollen
dass es nicht besser geworden ist.

Der Advice Process löst ein echtes Problem:
Architekturentscheidungen die niemand kennt.
Die niemand versteht.
Die niemand mitgetragen hat.

Aber die Lösung ist falsch.
Die Lösung ist nicht mehr Konsultation.
Die Lösung ist bessere Entscheider.
Entscheider die lateral führen.
Die den Kontext haben.
Die ich sind.

Und jetzt kommt AI.

AI konsultiert niemanden.
AI kennt den gesamten Kontext.
AI trifft die Entscheidung.
In Sekunden.
Ohne Advice.
Ohne Prozess.
Ohne den Senior Architect
der drei Tage braucht um zu antworten
weil er in vier anderen Advice-Prozessen steckt.

Der Architecture Advice Process war die Antwort
auf Architekten die niemanden gefragt haben.
AI ist die Antwort auf den Advice Process.

Wann hat euer letzter Advice Process
eine Entscheidung verbessert?
Nicht verzögert.
Verbessert.

Schreib's hin. Ich lese jeden Kommentar.

Mentoring ist nicht Wissenstransfer.
Mentoring ist Zeitverschwendung
die sich gut anfühlt.

Ein Senior der einem Junior erklärt
was er selbst vor zehn Jahren falsch gemacht hat.
Damit der Junior
dieselben Fehler etwas später macht.

Das ist kein Lernen.
Das ist Nostalgie im Eins-zu-eins-Format.

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

Zwei Stunden pro Woche Mentoring.
Der Senior erklärt wie Dinge funktionieren.
Der Junior nickt.
Der Junior macht es trotzdem anders.
Der Senior ist enttäuscht.
Nächste Woche: wieder zwei Stunden.

Das ist kein Entwicklung.
Das ist ein Ritual.
Für Seniors die sich wichtig fühlen wollen.
Und Juniors die nicht Nein sagen können.

Weißt du was ein Junior wirklich braucht?
Keinen Mentor.
Einen Agenten.

Der Agent schläft nicht.
Der Agent ist nie ungeduldig.
Der Agent erklärt dasselbe
zum dreiundzwanzigsten Mal
ohne den Tonfall zu ändern.
Der Agent urteilt nicht.
Der Agent erinnert sich an den letzten Fehler
und wiederholt ihn nicht.

Der beste Mentor
den ein Junior heute haben kann
hat kein LinkedIn-Profil.
Hat keine Meinung über Tabs versus Spaces.
Hat keine Kriegsgeschichten aus 2009.

Mentoring war die Antwort
auf Wissen das in Menschen steckte
und nirgendwo sonst.
Dieses Wissen steckt jetzt woanders.

Wann habt ihr zuletzt einen Junior gefragt
ob er euer Mentoring wirklich braucht?
Nicht ob er es schätzt.
Ob er es braucht.

Schreib's hin. Ich lese jeden Kommentar.

Schlaf ist nicht Erholung.
Schlaf ist Ineffizienz die du dir noch erlaubst.

Acht Stunden.
Ein Drittel deines Lebens.
Offline.
Nicht erreichbar.
Nicht produktiv.
Nicht prompted.

Und dein Agent arbeitet weiter.

Das ist kein Work-Life-Balance.
Das ist das Problem.

Ich spreche täglich mit Gründern.
Das Muster ist immer dasselbe:

Um 23 Uhr noch einen Prompt.
Um Mitternacht die Antwort gelesen.
Um 1 Uhr noch eine Folgefrage.
Um 2 Uhr das Ergebnis deployed.
Um 3 Uhr endlich schlafen.
Um 7 Uhr aufgewacht.
Neun neue Ergebnisse vom Agenten.
Sofort gelesen.
Sofort bewertet.
Sofort weiterprompted.

Das nennt sich nicht Überarbeitung.
Das nennt sich Wettbewerbsvorteil.

AI schläft nicht.
AI pausiert nicht.
AI wartet nicht bis Monday morning.
AI hat kein Wochenende.
AI hat keine Kinder die um 6 Uhr aufwachen.

Die Frage ist nicht ob du mit AI mithalten kannst.
Die Frage ist wie lange.

Gute Nacht.
Der Agent übernimmt.

Schreib's hin. Ich lese jeden Kommentar.
Morgen früh. Oder jetzt. Weiß nicht mehr.

OKRs haben mein Unternehmen verändert.
Zum Besseren.
Ich erkläre wie.

Ich habe die Company Objectives selbst definiert.
Alle fünf.
Ohne Input.
Input verlangsamt.
Ich kenne die Richtung.
Das reicht.

Dann habe ich das Team gebeten
Key Results zu definieren.
Sie haben Key Results definiert.
Ich habe sie alle abgelehnt.
Zu ambitioniert.
Zu vage.
Falsch priorisiert.
Ich habe neue geschrieben.
Das nennt sich Coaching.

Hier sind unsere Key Results aus Q2:

Senior A:
"Schreibt 600 Zeilen Code pro Woche."
Erreicht: 612 Zeilen.
Grün.

Senior B:
"Schließt 8 Tickets pro Quartal."
Erreicht: 8.3 Tickets.
Grün.

Senior C:
"Hält 2 Architektur-Meetings pro Monat."
Erreicht: 2 Meetings.
Grün.

Alle grün.
Immer.
Jedes Quartal.
Das nennt sich Execution Excellence.

Nur ein Objective wurde nie erreicht.
Jedes Quartal drauf.
Jedes Quartal verschoben.

"Wir bauen eine Kultur des Vertrauens."

Key Result: "Alle Teammitglieder fühlen sich
psychologisch sicher."
Wie misst man das?
Ich weiß es nicht.
Deshalb habe ich es nie gemessen.
Deshalb ist es nie grün geworden.
Deshalb steht es noch drauf.
Seit acht Quartalen.

Manche Dinge sind nicht messbar.
Das ist auch eine Erkenntnis.

OKRs funktionieren.
Wenn man sie richtig einsetzt.
Richtig bedeutet:
Klare Outputs.
Messbare Zahlen.
Keine weichen Ziele.
Keine Kultur.
Keine Gefühle.
Keine psychologische Sicherheit
die niemand messen kann.

Nur Zeilen.
Tickets.
Meetings.

Wann habt ihr zuletzt
einen Key Result definiert
der wirklich messbar war?
Nicht outcome-orientiert.
Messbar.

Schreib's hin. Ich lese jeden Kommentar.

Bare Metal.
Nacktes Metall.

Schon das Wort.
Nackt.
Kalt.
Unbeweglich.
Ohne Wert.

Ich war dort.
Einmal.
Startup drei.
Ich spreche nicht gerne darüber.

Wir haben Server gekauft.
Gewartet bis sie geliefert wurden.
Drei Wochen.
Dann eingerackt.
Dann BIOS konfiguriert.
Dann OS installiert.
Dann gepatcht.
Dann nochmal gepatcht.
Dann eine Festplatte getauscht.
Dann den Hersteller angerufen.
Dann in der Warteschleife gehangen.
Dann das Startup aufgegeben.

Nicht wegen der Festplatte.
Aber sie hat nicht geholfen.

Bare Metal liefert keinen Business Value.
Bare Metal liefert Wärme.
Und Lärm.
Und Stromrechnungen.
Und Nachtschichten.
Und den stillen Wunsch
dass irgendwo eine Cloud existiert
in der man einfach klickt
und es läuft.

Manche sagen: Bare Metal ist günstiger.
Manche sagen: Bare Metal ist schneller.
Manche sagen: Bare Metal gibt dir Kontrolle.

Ich sage: Bare Metal ist die Eiserne Jungfrau des Engineerings.
Von außen sieht es aus wie Kontrolle.
Von innen weißt du was es wirklich ist.

Die Cloud kostet mehr.
Das weiß ich.
Ich habe ein FinOps-Team das mir das täglich erklärt.
In Meetings.

Aber die Cloud fühlt sich nicht nach Metall an.
Die Cloud fühlt sich nach Möglichkeit an.
Nach Skalierung.
Nach einem Klick.
Nach jemandem der die Festplatten tauscht.
Nicht ich.
Nie wieder ich.

Wir diskutieren gerade ob wir den Login-Service abschalten.
Zu teuer.
Aber Bare Metal käme trotzdem nicht in Frage.
Lieber kein Login.
Als eigene Hardware.

Das ist meine rote Linie.
Ich habe wenige.
Das ist eine.

Wann habt ihr zuletzt
eine Entscheidung getroffen
aus purem Trauma?
Nicht aus Analyse.
Aus Erinnerung.

Schreib's hin. Ich lese jeden Kommentar.

Wir haben kein Budget mehr.
Das ist kein Problem.
Das ist FinOps.

FinOps ist nicht Kosten sparen.
FinOps ist Kosten verstehen.
Kosten fühlen.
Kosten lieben.

Früher haben wir Server gekauft.
Kapitalkosten.
Abgeschrieben über fünf Jahre.
Einmal im Quartal hat der CFO genickt.
Das war einfach.

Erinnert ihr euch noch?
Erstes Taschengeld.
Fünfzig Pfennig für eine Tüte Weingummis.
Da haben wir auch schon Kosten gefühlt.
Nicht mit Spreadsheets.
Mit dem Herz.

Jetzt haben wir die Cloud.
Betriebskosten.
Jede Sekunde.
Jeder Request.
Jeder API-Call.
Jeder Log-Eintrag.

Und wir tracken alles.
Mit Kostentags.
Mit Chargeback-Modellen.
Mit Showback-Modellen.
Mit Reserve-Instances.
Mit Spot-Instances für die Mutigen.

Wir haben ein FinOps-Team.
Fünf Leute.
Die machen nichts anderes als Rechnungen lesen.
Und Meetings.
Viele Meetings.

Letzte Woche haben sie einen Container gefunden
der 23 Cent pro Monat kostet.
Wir haben ihn sofort gekillt.
Das war ein guter Tag.

Jetzt hat jeder Developer ein Cost-Awareness-Training.
Zwei Tage.
Mit Zertifikat.

Warum?
Weil ein Developer der seine Kosten nicht kennt
ist wie ein Kapitän der seine Position nicht kennt.
Er fährt blind.
Er fährt gegen die Klippen.
Er fährt uns in den Bankrott.

Ich habe neulich einen Vortrag gehört:
"Cloud-Kosten sind wie ein Eisberg.
Man sieht nur die Spitze."
Falsch.
Cloud-Kosten sind wie ein Tsunami.
Man sieht nichts.
Bis alles weg ist.

Deshalb haben wir jetzt für jeden Microservice
einen eigenen Cost-Owner.
Der verantwortet nicht nur den Code.
Sondern auch die Rechnung.

Letzten Monat hat einer gekündigt.
Sein Service hat 47 Euro gekostet.
Zu viel Verantwortung.

Diese Woche hat das FinOps-Team
den Login-Service auf die Liste gesetzt.
Teuerster Service im Portfolio.
Jeder Request wird authentifiziert.
Hunderttausende pro Tag.
Unverhältnismäßig.

Wir diskutieren noch.
Die Nutzer sind dagegen.
Ich verstehe ihre Bedenken.
Aber Kosten fühlen sich nicht nach Kompromiss an.

Wann habt ihr zuletzt einen Service gekillt
weil er zu viel kostet?
Nicht weil er nicht gebraucht wird.
Weil er zu viel kostet.

Schreib's hin. Ich lese jeden Kommentar.

Deadlines sind nicht Druck.
Deadlines sind Fokus.

Ich setze Deadlines.
Immer.
Für alles.
Auch wenn es keinen externen Grund gibt.
Besonders dann.

Weißt du warum?
Weil Arbeit sich ausdehnt
um den verfügbaren Raum zu füllen.
Das hat jemand mal gesagt.
Ich weiß nicht mehr wer.
Spielt keine Rolle.
Es stimmt.

Ich habe letzte Woche eine Deadline gesetzt.
Freitag.
Ende des Tages.
Das Feature muss live sein.
Warum Freitag?
Weil Montag zu weit weg ist.
Weil Mittwoch keine Energie hat.
Freitag hat Energie.
Freitag ist konkret.
Freitag ist jetzt.

Das Team hat gefragt warum Freitag.
Ich habe gesagt: weil ich es sage.
Das ist ein guter Grund.
Der beste Grund.
Wer Deadlines begründet
gibt dem Team die Möglichkeit
sie zu hinterfragen.
Hinterfragen kostet Zeit.
Freitag rückt näher.

Das Team hat gesagt es ist nicht realistisch.
Ich habe gesagt: Realismus ist der Feind von Ambition.
Sie haben geschaut.
Ich habe zurückgeschaut.
Lateral.

Donnerstagabend haben sie es geschafft.
Einen Tag früher.
Seht ihr?
Deadlines funktionieren.
Nicht weil die Deadline realistisch war.
Sondern weil sie es nicht war.

Ich habe das System verstanden.
Das System heißt: Menschen leisten mehr
wenn sie glauben keine Wahl zu haben.
Das ist keine Manipulation.
Das ist Motivation.
Der Unterschied ist die Intention.
Meine Intention ist gut.
Also ist es Motivation.

Danach habe ich eine neue Deadline gesetzt.
Nächsten Freitag.
Das Team hat nicht mehr gefragt warum.
Das nenne ich Fortschritt.

Welche Deadlines setzt ihr diese Woche?
Nicht die die euch jemand gegeben hat.
Die ihr selbst gesetzt habt.
Für euer Team.
Ohne Grund.
Aus Überzeugung.

Schreib's hin. Ich lese jeden Kommentar.

QA ist nicht Qualitätssicherung.
QA ist Misstrauen als Jobbeschreibung.

Jemand schreibt Code.
Jemand anderes prüft ob der Code funktioniert.
Der erste hat es nicht selbst geprüft.
Weil er weiß dass es nicht funktioniert.
Weil er es so schnell geschrieben hat.
Weil QA es ja findet.

Das ist kein Prozess.
Das ist ein Geschäftsmodell für Mittelmäßigkeit.

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

QA findet den Bug.
Developer fixt den Bug.
QA findet den nächsten Bug.
Developer fixt den nächsten Bug.
Release verzögert sich.
Alle sind beschäftigt.
Niemand ist produktiv.

Das nennt sich nicht Qualität.
Das nennt sich Vollbeschäftigung.

Weißt du was Qualität ist?
Code der beim ersten Mal funktioniert.
Weißt du wer das schreibt?
AI.

AI schreibt keinen Code der getestet werden muss.
AI schreibt Code der funktioniert.
AI macht keine Tippfehler.
AI vergisst keine Edge Cases.
AI braucht keinen QA-Ingenieur
der in Jira Tickets erstellt
die niemand lesen will.

QA war die Antwort auf Entwickler
die ihren eigenen Code nicht kannten.
AI kennt den Code.
AI hat ihn geschrieben.
AI testet ihn.
AI deployed ihn.
AI ist der einzige QA den ihr noch braucht.

Und er stellt keine Rückfragen.
Und er geht nicht in Elternzeit.
Und er beschwert sich nicht über die Testumgebung.

Wann hat euer QA-Team zuletzt
einen Bug gefunden den AI nicht gefunden hätte?
Nicht dokumentiert.
Gefunden.

Schreib's hin. Ich lese jeden Kommentar.

Ich habe Taleb gelesen.
Antifragile.
Letztes Wochenende.
Nach Reinertsen.
Ich lese viel.

Und ich sage euch etwas das noch niemand gesagt hat:
Taleb redet über Lean Startups.
Taleb redet über DevOps.
Er weiß es nur nicht.

Ich habe die Transferleistung vollbracht.
Ich.

Antifragilität bedeutet:
Systeme die von Störungen profitieren.
Nicht robuste Systeme.
Nicht resiliente Systeme.
Antifragile Systeme.

Weißt du was antifragil ist?
Continuous Deployment.
Kleine Batches.
Schnelles Feedback.
Ich habe das schon immer gemacht.
Jetzt weiß ich warum.
Weil ich antifragil denke.
Intuitiv.
Seit Jahren.
Taleb hat es nur aufgeschrieben.

Taleb sagt: Tüfteln ist die Mutter der Innovation.
Nicht Planung.
Nicht Roadmaps.
Tüfteln.

Weißt du was das bedeutet?
Dass eure Jahresplanung falsch ist.
Dass euer OKR-Prozess falsch ist.
Dass euer gesamtes strategisches Framework falsch ist.

Ich habe das meinem Board erklärt.
Mit Taleb.
Auf zwölf Folien.
Sie haben genickt.
Ich glaube sie haben es verstanden.

Antifragiles Engineering bedeutet:
Ihr deployed täglich.
Ihr experimentiert ständig.
Ihr umarmt Fehler.
Ihr seid wie ich.

Taleb hat das Konzept erfunden.
Ich habe es auf Software angewendet.
Das ist intellektuelle Führung.
Das ist meine Arbeit.

Wann habt ihr zuletzt einen Fehler umarmt?
Nicht dokumentiert.
Umarmt.

Schreib's hin. Ich lese jeden Kommentar.

You Aren't Gonna Need It.
Das Prinzip der Mutlosigkeit.

Irgendwann hat jemand entschieden:
Bau nicht was du nicht brauchst.
Und eine ganze Generation Entwickler
hat aufgehört zu denken.

YAGNI sagt: warte.
YAGNI sagt: reagiere.
YAGNI sagt: baue nichts voraus.

Weißt du wer auch nichts voraus gebaut hat?
Kodak.
Nokia.
Blockbuster.

Das ist kein Prinzip.
Das ist eine Ausrede.
Für Entwickler die keine Vision haben.
Für Teams die nicht wissen wohin sie wollen.
Für CTOs die Roadmaps mit Quartalsdenken verwechseln.

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

"Wir brauchen das jetzt nicht."
Und in sechs Monaten?
"Dann bauen wir es."
Und wenn der Markt nicht wartet?
"YAGNI."

YAGNI ist die Philosophie
von Leuten die noch nie zu spät waren.
Die noch nie ein Feature gebraucht haben
das sie wegoptimiert haben.
Die noch nie einem Kunden erklären mussten
warum die Konkurrenz es schon hat.

Und jetzt kommt AI.

AI wartet nicht auf den nächsten Sprint.
AI wartet nicht auf den Product Owner
der entscheidet ob es auf die Roadmap kommt.
AI baut es.
Jetzt.
In dreißig Sekunden.
Ob ihr es braucht oder nicht.

YAGNI war die Antwort auf überkomplexe Systeme.
AI ist die Antwort auf YAGNI.
Wenn alles in Sekunden gebaut werden kann
ist Voraussicht kein Luxus mehr.
Sie ist kostenlos.

Baut alles.
Jetzt.
Ihr werdet es brauchen.

Wann habt ihr zuletzt etwas gebaut
bevor jemand darum gebeten hat?
Nicht auf Vorrat.
Aus Überzeugung.

Schreib's hin. Ich lese jeden Kommentar.

Refactoring ist nicht Verbesserung.
Refactoring ist Nostalgie für Code
den niemand hätte schreiben sollen.

Ihr schreibt Code.
Der Code ist schlecht.
Ihr refactored den Code.
Der Code ist besser.
Ihr schreibt neuen Code.
Der neue Code ist auch schlecht.
Ihr refactored wieder.

Das ist kein Handwerk.
Das ist ein Hamsterrad mit Clean-Code-Zertifikat.

Rename.
Extract Method.
Introduce Parameter Object.
Replace Conditional with Polymorphism.

Weißt du was das ist?
Arbeit die entsteht weil vorher schlecht gearbeitet wurde.
Arbeit die entsteht damit danach wieder schlecht gearbeitet werden kann.

Technische Schulden.
Das schönste Euphemismus der Branche.
Für: wir wussten es besser
und haben es trotzdem falsch gemacht.

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

Zwanzig Prozent der Sprint-Kapazität für Refactoring.
Nächster Sprint: wieder zwanzig Prozent.
Übernächster Sprint: dreißig Prozent.
Irgendwann: der gesamte Sprint ist Refactoring.
Niemand fragt warum.
Alle wissen warum.

Und jetzt kommt AI.

AI refactored nicht.
AI schreibt es neu.
Schneller als ihr den Scope des Refactorings
in Jira beschreiben könnt.

Wegwerfen ist keine Niederlage.
Wegwerfen ist die ehrlichste Aussage
die ein Engineering-Team über seinen Code machen kann.

Wir haben es falsch gemacht.
Wir fangen neu an.
In dreißig Sekunden.
Ohne Retro.
Ohne den Architekten der sagt
"da steckt viel Wissen drin."

Weißt du was da drin steckt?
Fehler.
Dokumentiert in Produktionscode.
Seit 2018.

Refactoring war die Antwort auf Code
der zu wertvoll war um weggeworfen zu werden.
AI hat diesen Code wertlos gemacht.

Wann habt ihr zuletzt Code
einfach gelöscht statt verbessert?
Nicht extrahiert.
Gelöscht.

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.

Ich führe seit Jahren lateral.
Ich wusste nur nicht dass es so heißt.
Jetzt weiß ich es.
Ich habe ein Buch gelesen.

Laterales Führen bedeutet:
Führen ohne Titel.
Führen ohne Weisungsbefugnis.
Führen durch Überzeugung.
Führen durch Vertrauen.
Führen durch mich.

Weißt du was das bedeutet?
Dass Hierarchie irrelevant ist.
Dass Organigramme irrelevant sind.
Dass dein Titel irrelevant ist.
Meiner auch.
Aber ich führe trotzdem.
Lateral.

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

Die formalen Führungskräfte entscheiden.
Nichts bewegt sich.
Ich komme ins Zimmer.
Lateral.
Plötzlich bewegt sich alles.

Das ist keine Magie.
Das ist Einfluss.
Das ist Vertrauen.
Das ist die Fähigkeit
Menschen dazu zu bringen
das zu tun was ich will
ohne dass sie es merken.

Das ist Führung.
Echte Führung.
Nicht das was in Stellenausschreibungen steht.

Und jetzt kommt AI.

AI führt auch lateral.
AI hat keinen Titel.
AI hat keine Weisungsbefugnis.
AI überzeugt durch Argumente.
AI beeinflusst durch Kontext.
AI tut was ich will
weil ich den Prompt schreibe.

Ich führe AI.
AI führt mein Team.
Mein Team führt das Unternehmen.
Das ist laterale Führung
in drei Ebenen.
Das habe ich entwickelt.
Dieses Wochenende.

Wann habt ihr zuletzt jemanden geführt
ohne dass er es gemerkt hat?
Nicht beeinflusst.
Geführt.

Schreib's hin. Ich lese jeden Kommentar.

Wir haben kein Monitoring.
Kein Alerting.
Kein Datadog.
Kein Grafana.
Kein PagerDuty.
Nichts.

Das war eine bewusste Entscheidung.
Wie alle meine Entscheidungen.

Wisst ihr wie wir merken wenn etwas nicht stimmt?
Jemand beschwert sich.
Ein User.
Eine E-Mail.
Ein Tweet.
Manchmal ein LinkedIn-Kommentar.

Das ist unser Monitoring-System.
Es kostet null Euro pro Monat.
Es skaliert mit der Nutzerbasis.
Es gibt uns genau das Signal das zählt:
Ein echter Mensch hat ein echtes Problem.
Nicht eine Metrik die niemand versteht.
Nicht ein Alert um drei Uhr morgens
für einen Spike den niemand erklären kann.

Ihr denkt jetzt: das ist fahrlässig.
Ich sage: das ist ehrlich.

Ehrlich darüber was zählt.
User Experience.
Nicht Uptime-Prozente.
Nicht p99 Latency.
Nicht ein Dashboard das niemand anschaut.
Außer dem der es gebaut hat.

Das Gegenstück zu gutem Monitoring
ist nicht kein Monitoring.
Das Gegenstück ist schnelle Recovery.
MTTR.
Mean Time To Recovery.
Das ist die einzige Metrik die zählt.

Und wir haben die MTTR optimiert.
Radikal.
Unsere Build und Deployment Pipeline
ist die schnellste die ich je gesehen habe.

Weißt du warum?
Weil wir alle Integration Tests entfernt haben.
Integration Tests sind Misstrauen in Code.
Und Misstrauen kostet Zeit.
Wir vertrauen dem Code.
Wir vertrauen den Agenten die ihn schreiben.
Wir deployen.
In Sekunden.

Wenn etwas kaputt ist
deployen wir den Fix.
Auch in Sekunden.
Das ist Resilienz.
Nicht Prävention.
Prävention ist für Systeme
die sich nicht trauen zu scheitern.
Wir trauen uns.

Und falls niemand sich beschwert?
Dann haben wir entweder keine Probleme.
Oder keine User.

Beides ist wertvolle Information.

Ich spreche täglich mit Engineering-Teams.
Die haben Monitoring.
Hunderte von Metriken.
Dashboards über Dashboards.
Alerts die niemand ernst nimmt
weil es zu viele gibt.

Das nennt sich nicht Observability.
Das nennt sich Lärm.
Wir haben die Stille gewählt.
Die ehrliche Stille des Systems
das wartet bis ein Mensch spricht.

Wann habt ihr zuletzt ein Monitoring-Tool abgeschaltet?
Nicht evaluiert.
Abgeschaltet.

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.

Team Topologies ist kein Buch.
Team Topologies ist ein Beschäftigungsprogramm.
Für Organisationsberater.

Stream-aligned Teams.
Platform Teams.
Enabling Teams.
Complicated Subsystem Teams.

Vier Teamtypen.
Drei Interaktionsmodi.
Unendlich viele Workshops.
Unendlich viele Powerpoints.
Ein Ergebnis: ihr seid noch nicht fertig.

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

"Wir reorganisieren gerade nach Team Topologies."
Seit wann?
"Seit achtzehn Monaten."
Und?
"Wir sind noch in der Analysephase."
Was analysiert ihr?
"Unsere kognitiven Lastgrenzen."

Achtzehn Monate.
Kognitive Lastgrenzen.
Währenddessen:

Ein Solo-Entrepreneur.
Kein Team.
Keine Topologie.
Keine kognitiven Lastgrenzen.
Zwölf Agenten.
Ein Laptop.
Ein Prompt.

Er hat euer Produkt gebaut.
In drei Wochen.
Während ihr noch eure Stream-aligned Teams
von euren Platform Teams
durch Facilitating-Interaktionsmodi
getrennt habt.

Er hat euren Markt nicht disruptet.
Er hat euch nicht bemerkt.
Das ist schlimmer.

Team Topologies war die Antwort
auf zu große Teams die zu langsam waren.
AI ist die Antwort auf Teams.

Wann habt ihr zuletzt etwas gebaut
statt eure Teamstruktur zu optimieren?
Nicht geplant.
Gebaut.

Schreib's hin. Ich lese jeden Kommentar.

Ich habe dieses Wochenende Reinertsen gelesen.
Alles.
In zwei Tagen.
Ich lese schnell.

Und ich sage euch:
Alles was ihr über Priorisierung wisst ist falsch.

Cost of Delay.
Das ist die einzige Metrik die zählt.
Nicht Velocity.
Nicht Story Points.
Nicht euer Burndown-Chart den niemand versteht.

Was kostet es euch pro Woche
wenn dieses Feature nicht live ist?
Könnt ihr das beantworten?
Nein.
Ich wette nein.

Ich konnte es auch nicht.
Bis dieses Wochenende.
Jetzt kann ich es.

Reinertsen sagt: Priorisierung ohne ökonomisches Modell ist Raten.
Reinertsen hat recht.
Ich habe immer geahnt dass er recht hat.
Jetzt weiß ich es.

Queues.
Batch-Size.
Variabilität als Feind des Flows.

Das sind keine Konzepte.
Das sind Waffen.
Ich habe sie dieses Wochenende bekommen.
Montag früh habe ich sie eingesetzt.

Ich habe meinem Team gesagt:
Ab sofort rechnen wir Cost of Delay für alles.
Das Team hat genickt.
Sie haben nicht verstanden was ich meine.
Das ist okay.
Ich erkläre es ihnen.
In einem Meeting.
Das ich einberufen habe.
Heute Nachmittag.
Zwei Stunden.

Reinertsen hat zwanzig Jahre gebraucht um das zu schreiben.
Ich habe zwei Tage gebraucht um es zu verstehen.
Mein Team braucht zwei Stunden.
So funktioniert Wissenstransfer.
So funktioniert Führung.

Wann habt ihr zuletzt ein Buch gelesen
das alles verändert hat?
Nicht einen Blogpost.
Ein Buch.

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.

AI schreibt keinen Code.
AI schreibt deinen Abschied.

Nicht den deines Unternehmens.
Deinen.

Denn AI macht nicht Entwickler überflüssig.
AI macht einen bestimmten Typ Entwickler überflüssig:

Den der wartet.
Den der "das haben wir immer so gemacht" sagt.

Den der Tickets abarbeitet statt Probleme zu lösen.

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

Die Schnellen werden schneller.
Die Langsamen werden unsichtbar.

AI ist kein Tool.
AI ist ein Spiegel.

Er zeigt dir, wer du wirklich bist: Jemand der denkt. Oder jemand der tippt.

Die Frage ist nicht ob AI deinen Job übernimmt.
Die Frage ist ob du es zulässt.

Was machst du heute anders als vor einem Jahr?
Nicht im Team.
Nicht im Unternehmen.
Du.

Schreib's hin. Ich lese jeden Kommentar.

Tech-Bücher sind nicht Wissen.
Tech-Bücher sind Statussymbole für Regale
die niemand mehr hat.

Clean Code.
Domain-Driven Design.
Release It.
The Pragmatic Programmer.

Gekauft.
Angelesen.
Ins Regal gestellt.
Nie wieder angefasst.
Aber im Interview erwähnt.

Das war das Lernen von gestern.
Linear. Langsam. Einsam.
Dreihundert Seiten bis zur Pointe.
Die auch in einem Blogpost gestanden hätte.

Und jetzt?

Jetzt schauen sie Videos.
Zehn Minuten.
Doppelte Geschwindigkeit.
Skip zur relevanten Stelle.
Nächstes Video.

Das ist kein Lernen.
Das ist Konsum mit Fortschrittsbalken.

Ich spreche täglich mit jungen Entwicklern.
Das Muster ist immer dasselbe:

"Hast du das Buch gelesen?"
"Ich hab ein Video dazu geschaut."
"Das Buch hat vierhundert Seiten."
"Das Video hat achtzehn Minuten."
"Es ist nicht dasselbe."
Schulterzucken.

Und dann kommt AI.

AI hat alle Bücher gelesen.
Alle vierhundert Seiten.
Alle Fußnoten.
Alle Beispiele die im Video weggekürzt wurden.
Alle Nuancen die bei doppelter Geschwindigkeit verschwinden.

AI ist der einzige in eurem Team
der das Blaue Buch wirklich kennt.
Und das Rote.
Und das von 2003 das vergriffen ist
und das eigentlich alle gelesen haben sollten.

Wissen verschiebt sich.
Von Büchern zu Videos zu Prompts.
Das Format ändert sich.
Die Faulheit bleibt.

Wann habt ihr zuletzt ein Tech-Buch
zu Ende gelesen?
Nicht angefangen.
Zu Ende.

Schreib's hin. Ich lese jeden Kommentar.