Es liegt nicht an dir: Warum agiles Arbeiten für Entwickler:innen zur Zumutung wird

Survival-Kit für Entwickler Einstieg in die Serie Zur Übersicht

Auf Mastodon lief neulich ein Post durch meine Timeline. Sinngemäß: Scrum sei ein brutaler Scam, erfunden von Krawatten, um noch mehr Krawatten auf Posten zu bringen, die fast nichts zum Produkt beitragen.

Ich halte den Satz für falsch. Die Wut dahinter halte ich für berechtigt.

Die meisten Entwickler:innen, die agiles Arbeiten hassen, haben es nie erlebt. Sie kennen nur das, was in ihrem Unternehmen unter dem Namen verkauft wird, und das ist tatsächlich oft eine Zumutung. Wogegen sie sich wehren, hat mit agilem Arbeiten wenig zu tun.

Damit klar ist, wer hier schreibt: Ich bin kein Entwickler. Ich bin Team Lead eines Kanban-Teams mit sieben Leuten und sehe das, was jetzt kommt, von der anderen Seite des Boards. Ich habe auch fünf Jahre lang selbst Scrum nach Lehrbuch gemacht, mit zertifiziertem Scrum Master und mir als zertifiziertem PO. Wir haben es irgendwann sein lassen.

Und das lag fast nie an den Leuten hier.

Die Rituale laufen. Eure Arbeit ändert sich nicht.

Die Szene ist vertraut. Dein Team macht Dailys, ihr habt Sprint-Backlogs und vielleicht sogar einen Scrum Master. Von außen wirkt alles agil. Aber wenn du ehrlich bist, hat sich an der Art, wie ihr zusammenarbeitet und Ergebnisse erzielt, kaum etwas geändert.

Das Daily ist ein Statusreport für den Vorgesetzten statt ein Planungstreffen fürs Team. Die Retro führt zu keiner einzigen echten Veränderung, und die Abteilung heißt seit dem letzten Reorg "Squad", während sich an Strukturen, Prozessen und Denkweise nichts geändert hat.

Cargo-Kult heißt dieses Muster: Man ahmt Rituale nach, weil man gesehen hat, dass sie bei anderen funktionieren, ohne die Prinzipien dahinter zu verstehen. Was bleibt, ist eine leere Hülle, und du sitzt jeden Morgen fünfzehn Minuten darin.

Ich habe genau diesen Fehler selbst gemacht. Als wir damals mit Scrum anfingen, war ich überzeugt, dass wir automatisch agil arbeiten, wenn wir uns nur strikt an den Scrum Guide halten. Das war naiv.

Der Ausweg ist unspektakulär und tut trotzdem weh. Geh einmal alles durch, was ihr rund um agiles Arbeiten macht. Frag zu jedem Punkt, wozu ihr das tut und ob es eure Arbeit verändert. Wenn die Antwort oft "nein" lautet, habt ihr euren Ansatzpunkt gefunden. Ausführlicher in der Podcast-Folge Rituale ohne Seele.

Die Latenz, die niemand misst

Das ist der Schmerz, der am meisten zermürbt, weil ihr ihn im Team nicht abstellen könnt, egal wie gut ihr arbeitet.

Ihr liefert in kurzen Zyklen. Die Pipeline steht, die Tests laufen, ihr könnt jederzeit releasen. Und trotzdem passiert nichts: Prioritäten wechseln mit großer Verzögerung, Diskussionen enden ohne verbindlichen Abschluss, ihr wartet auf Freigaben, und Erkenntnisse aus dem letzten Quartal sind bis heute nicht zu veränderter Arbeit geworden.

In meinem Denkmodell, der Work–Feedback Loop, heißt dieser Zustand Disconnected Agility. Der operative Loop dreht schnell, während der koordinierende und der strategische in Quartalen denken.

Hier ist der Punkt, an dem du aufhören kannst, es persönlich zu nehmen. Diese Entscheidungs-Latenz entsteht selten aus fehlendem Willen. Sie entsteht aus Struktur: Hierarchietiefe, Verantwortungsdiffusion, Risikominimierung, Budgetzyklen, Governance. Lernfähigkeit ist keine Eigenschaft von Kultur, sondern von Zeit und Kopplung.

Es gibt drei Härtegrade davon, und sie fühlen sich für dich gleich an. Cargo-Kult ist der harmloseste: Da meint es jemand ernst und macht es falsch. Fake Agile heißt es, wenn die Hülle eingeführt wird, ohne dass irgendwer vorher die Frage nach dem Warum gestellt hat. Bei Dark Agile ist es Absicht. Scrum dient als Deckmantel, nach außen gibt man sich modern, und intern nutzt das Management die Strukturen, um weiterhin top-down zu steuern und im Grunde wasserfallartig zu arbeiten. Wer da drinsitzt, ist in einem System gefangen, das Agilität verspricht und Kontrolle lebt.

Wenn du eine einzige Zahl aus diesem Artikel mitnimmst, dann diese: Wie lange dauert es bei euch vom sichtbaren Signal bis zur verbindlichen Entscheidung? Miss das an drei konkreten Fällen. Diese Zahl ist euer Engpass, nicht die Velocity.

Aus deiner Schätzung wird eine Deadline

Planning. Du starrst auf ein Ticket, weißt, dass die Legacy-Codebase an dieser Stelle aus Kartenhäusern und Klebeband besteht, und sollst jetzt eine Zahl zwischen 1 und 40 hochhalten.

Was danach passiert, kennst du auch. Aus der Zahl werden Stunden. Aus den Stunden wird eine Jahresplanung in Excel. Nach vier Wochen wundert sich jemand, dass ihr hinter dem Plan liegt.

Sobald Story Points in Stunden umgerechnet werden, ist das System korrumpiert. Du fängst an, defensiv zu schätzen, lieber eine 8 als eine 5, und der eigentliche Wert des Schätzens ist weg. Der bestand darin, Unklarheiten im Team aufzudecken.

Dann kommt der Vergleich: "Warum hat Team A eine Velocity von 50 und Team B nur 30?" Ab da brennt die Hütte. Denn wenn du die Velocity aufblähen willst, schätzt du beim nächsten Mal einfach alles doppelt so hoch. Glückwunsch, auf dem Papier bist du doppelt so produktiv, am Code hat sich nichts geändert.

Ron Jeffries, einer der Erfinder der Story Points, schreibt dazu in seinem Blog: er habe sie vielleicht erfunden, und wenn ja, tue es ihm inzwischen leid.

Der einzige legitime Grund zu schätzen ist herauszufinden, ob ihr dasselbe Verständnis vom Problem habt. Wenn du eine 2 legst und dein Kollege eine 13, dann redet ihr über zwei verschiedene Probleme. Genau diese Diskussion ist der ganze Wert. Wie ihr da rauskommt und was ihr dem Management stattdessen anbietet, steht in Story Points sind Unsinn?

Ein Fahrrad nach München

Ein Teil des Frusts entsteht gar nicht durch schlechte Umsetzung. Er entsteht, weil ein Vorgehen auf Arbeit angewendet wird, für die es nie gedacht war.

Die Stacey Matrix von Ralph D. Stacey ist dafür ein sehr simples Werkzeug: zwei Achsen, einmal wie klar die Anforderung ist, einmal wie klar der Lösungsweg. Landet eure Arbeit unten links, Anforderung klar und Lösungsweg bekannt, braucht ihr kein agiles Vorgehen. Ein klassischer Plan ist dort effizient und völlig ausreichend. Agiles Arbeiten ist im komplexen Feld zu Hause, da, wo weder das Was noch das Wie am Anfang feststeht.

Geh mal die Stories der letzten Wochen mit dieser Brille durch. Wenn die Mehrheit unten links liegt und ihr trotzdem Planning, Refinement, Review und Retro fahrt, dann bezahlt ihr Overhead für eine Sicherheit, die ihr nicht braucht.

Daran sind wir damals auch gescheitert, und zwar an Scrums Rückgrat, dem Sprint. Kommt ständig Ungeplantes von außen rein, Support und Störer, ist genau dieses Rückgrat gebrochen. Wir haben irgendwann einen festen Anteil der Kapazität für Unbekanntes reserviert und die Zahl mehrfach nach oben korrigiert. Gepasst hat sie nie. Danach sind wir auf Kanban gewechselt.

Ein Fahrrad kann nichts dafür, wenn jemand damit von Hamburg nach München fährt und sich unterwegs beschwert, dass es lange dauert und dass er nass wird. Nur hast du das Fahrrad in den seltensten Fällen selbst ausgesucht.

Vierzig durch zehn ist vier

Freitagnachmittag. Sieben Karten stehen in "In Progress", auf vier davon klebt dein Avatar. Du hast die Woche durchgearbeitet, zwei Reviews gemacht, einen Produktionsbug gefixt, an drei Features weitergebaut. Fertig geworden ist nichts.

Die übliche Schlussfolgerung lautet, das Team sei zu langsam. Sie ist falsch. Ihr seid nicht langsam, ihr habt zu viel gleichzeitig offen.

Rechne es nach. Little's Law sagt: Durchlaufzeit ist gleich offene Arbeit geteilt durch Durchsatz. Ihr schließt zehn Tickets pro Woche ab und habt vierzig gleichzeitig offen? Dann braucht jedes Ticket im Mittel vier Wochen. Halbiert die offene Arbeit, ohne sonst irgendetwas zu ändern, keine neuen Leute, kein anderes Tooling: zwei Wochen.

Das ist keine Empfehlung, das ist eine Formel.

Wenn du das lieber selbst sehen willst, als es mir zu glauben, schau mal hier: Flow Physics.

Der Grund dahinter ist simpel. Ein Ticket wartet die meiste Zeit seines Lebens. Auf ein Review, auf eine Antwort vom Fachbereich, auf QA, auf ein Deployment-Fenster und darauf, dass du vom anderen Ticket zurückkommst. Aktiv gearbeitet wird an einer Karte in den meisten Teams während zehn bis zwanzig Prozent ihrer Laufzeit. Den Rest habe ich in Warum am Freitag nichts fertig ist durchgerechnet.

Und hier wird aus einem Systemproblem ein persönliches. Ein Ticket ist immer nur eine Repräsentation des Problems, meist stark vereinfacht und oft aus dem Kontext gerissen. Wenn es die Arbeit ersetzt, werden aus Problemlöser:innen Zustandsverwalter:innen. Wer dann noch Rückfragen stellt, gilt als schwierig. Dabei arbeitet genau diese Person professionell.

Der Hebel dagegen ist der einzige in diesem ganzen System, den du ziehen kannst, ohne jemanden um Erlaubnis zu fragen: nicht die nächste Karte anfangen, bevor die aktuelle durch ist. Einigt euch als Team auf eine Obergrenze, die etwa der Teamgröße entspricht, und haltet sie zwei Wochen durch. Wer eine neue Karte ziehen will und das Limit ist erreicht, hilft stattdessen, eine bestehende fertig zu bekommen.

Das fühlt sich zuerst nach Leerlauf an. Es ist keiner.

Was du damit machst

Wenn du bis hierhin genickt hast, ist weder dein Team das Problem noch du.

Trotzdem bleibe ich dabei, dass "Agilität ist tot" die falsche Antwort ist. Sie macht das Konzept für seine Umsetzung verantwortlich und lässt dich mit der Frage allein, was du morgen tun sollst. Was dir wirklich hilft, liegt eine Ebene unter den Ritualen: inkrementell liefern, automatisiert testen, jederzeit releasen können, Feedback bekommen, das schnell genug ist, um Entscheidungen zu verändern.

Such dir einen dieser Schmerzen aus. Am besten den, bei dem du diese Woche etwas verändern kannst, ohne jemanden um Erlaubnis zu fragen. Bei den meisten Teams ist das die offene Arbeit auf dem Board.

Für alles andere habe ich die Sätze aufgeschrieben, die du im nächsten Daily, Planning oder Refinement tatsächlich sagen kannst, ohne als Querulant dazustehen. Acht Teile, jeder mit einem Ritual und dem passenden Satz dazu.

Widerspruch ist ausdrücklich erwünscht, am besten drüben auf Mastodon bei @nobsagile oder per Mail an nobsagile@gmail.com.