Das Agile-Survival-Kit: Wie du als Entwickler im System überlebst.

Warum agiles Arbeiten Devs oft nervt

Ich will doch einfach nur entwickeln

Hand aufs Herz: Wenn du „Agile“ hörst, denkst du nicht an Flow, saubere Architektur und zufriedene User. Du denkst an die Meeting-Hölle.

An den Wecker, der dich um neun aus der Arbeit reißt, weil das Daily ansteht. An Diskussionen über Story Points, die am Ende doch in Personentage umgerechnet werden. An Tickets, die so schlecht geschrieben sind, dass du drei Stunden Detektivarbeit brauchst, bevor die erste Zeile Code entsteht.

In vielen Unternehmen ist agiles Arbeiten zum Micromanagement-Werkzeug verkommen. Statt dir den Rücken freizuhalten, damit du Probleme von Usern mit Code löst, ist ein bürokratisches Monster daraus geworden. „Cargo Cult“ nennt man das: Du führst die Rituale aus, ohne dass jemand den Sinn dahinter erklären könnte. Am Ende steht „Death by Jira“ und das Gefühl, Ticket-Schubser in einer Feature-Fabrik zu sein.

Warum das kein persönliches Versagen ist, sondern Struktur, habe ich in Es liegt nicht an dir aufgeschrieben. Das ist der Einstieg in diese Serie. Diese Seite hier ist der praktische Teil.

Das Versprechen und die Jira-Realität

Im Agilen Manifest ging es um Individuen und Interaktionen statt Prozesse und Werkzeuge. Heute fühlt es sich umgekehrt an. Der Prozess ist Gott: Wenn das Ticket nicht korrekt geschoben und jedes Metafeld gefüllt ist, zählt die Arbeit nicht. Velocity ist zur Peitsche geworden, mit der Teams verglichen werden, statt Komplexität zu verstehen. Und der Product Owner tritt als Besteller auf, der fertige Lösungen über den Zaun wirft, statt mit dir um die beste technische Umsetzung zu ringen.

Pragmatisches agiles Arbeiten ist dein Schutzschild dagegen. Es schützt deine Fokuszeit, wenn das Daily richtig läuft. Es sichert deine Code-Qualität, solange die Definition of Done kein Papiertiger ist. Und es hält technische Schulden sichtbar, statt sie in deine Überstunden zu verlagern.

Das Daily: Statusbericht oder Planungstreffen?

Kein Termin treibt den Puls von Entwicklern so zuverlässig hoch. In der Theorie ein schlankes Synchronisations-Event. In der Praxis eine Mischung aus morgendlicher Beichte und Rechtfertigungs-Marathon vor PO oder Scrum Master.

Du kennst die Szene. Reihum spult jeder sein Mantra ab:

„Gestern habe ich an Ticket 123 gearbeitet, heute arbeite ich weiter an Ticket 123, keine Blocker.“

Während du redest, schalten die anderen ab. Sie checken Slack oder überlegen, welchen Test sie als nächstes schreiben. Das ist kein Meeting, das ist Status-Reporting. Wenn der PO wissen will, wo ein Ticket steht, soll er ins Board schauen. Dafür ist es da.

Ein echtes Daily ist ein Planungstreffen: Was müssen wir heute tun, damit das Sprint-Ziel hält? Drei Griffe machen aus dreißig Minuten Langeweile fünfzehn Minuten Nutzwert. Walk the Board, not the People: von rechts nach links auf das Board schauen, bei den fast fertigen Tickets anfangen und fragen, warum die sich nicht bewegen. Blocker sind die Stars: ein Daily ohne Blocker ist entweder ein Wunder oder gelogen, und „Ich verstehe diese Methode nicht“ ist genauso einer wie ein toter Server. Die 16. Minute: Sobald zwei Leute länger als sechzig Sekunden fachlich diskutieren, wird abgebrochen. Wer beitragen kann, bleibt. Der Rest geht coden.

Richtig genutzt ist das Daily dein Schutzschild gegen unvorhergesehene Arbeit. Es ist der Moment, in dem du sagst: „Wenn ich heute dieses Bug-Ticket übernehme, wird das Sprint-Ziel-Feature nicht fertig. Was ist uns wichtiger?“

Story Points und was daraus gemacht wird

Ron Jeffries, einer der Erfinder der Story Points, schreibt in seinem Blog:

I like to say that I may have invented story points, and if I did, I’m sorry now.

Planning Poker ist der Moment, in dem die kollektive Begeisterung ihren Tiefpunkt erreicht. Du starrst auf ein Ticket, weißt, dass die Legacy-Codebase an dieser Stelle aus Kartenhäusern und Klebeband besteht, und sollst eine Zahl zwischen 1 und 13 hochhalten.

Ein Story Point misst Komplexität, Risiko und Aufwand. Keine Uhrzeit. Erst letztens habe ich gehört, wie ein Management auf Basis der Velocity eine Jahresplanung in Excel gebaut hat und sich nach vier Wochen wunderte, dass das Team „hinter dem Plan“ liegt. Sobald Punkte in Stunden umgerechnet werden, ist das System korrumpiert. Du schätzt defensiv, lieber eine 8 als eine 5, und der eigentliche Wert des Schätzens ist weg. Der bestand darin, Unklarheiten im Team aufzudecken.

Genauso giftig ist Velocity als Leistungskennzahl. Wenn jemand fragt, warum Team A auf 50 kommt und Team B nur auf 30, brennt die Hütte. Denn wenn du die Zahl aufblähen willst, schätzt du beim nächsten Mal alles doppelt so hoch. Glückwunsch, auf dem Papier bist du doppelt so produktiv. Am Code hat sich nichts geändert.

Es gibt Auswege. T-Shirt-Größen reichen für die grobe Frage, ob ein Feature ins Quartal passt. Mein bevorzugter Ansatz ist #NoEstimates: Tickets so klein schneiden, dass sie ungefähr gleich groß sind, und dann den Durchsatz zählen. Und wo Daten vorliegen, sind Monte-Carlo-Prognosen auf Basis der historischen Zykluszeit jedem Bauchgefühl aus dem Planning Poker überlegen.

Der einzige legitime Grund zu schätzen ist die Frage, ob ihr dasselbe Problem vor Augen habt. Wenn du eine 2 legst und dein Kollege eine 13, habt ihr kein Schätzproblem. Ihr habt ein Verständnisproblem, und das ist die wertvolle Diskussion. Die Zahl auf dem Ticket ist danach hinfällig.

Definition of Done: dein Schutzschild

„Ist das Ticket fertig?“ „Ja, ich muss nur noch die Tests schreiben und dokumentieren.“

Dann ist es nicht fertig.

In vielen Teams herrscht gefährliche Unklarheit darüber, was „fertig“ bedeutet. Das Ergebnis geht in Produktion und fällt zusammen, sobald der erste User einen ungewöhnlichen Input liefert. Die Definition of Done ist kein nettes Extra, sondern der Qualitätsvertrag deines Teams.

Wichtig ist die Abgrenzung zu den Akzeptanzkriterien. Die sind spezifisch für ein Ticket („Der User kann sich mit Google-OAuth einloggen“) und Sache des Product Owners. Die Definition of Done gilt für jedes Ticket („Unit Tests decken die Logik ab, Code ist gelintet, Peer Review ist erfolgt“) und ist Sache der Entwickler. Genau deshalb ist sie dein legales Veto, wenn am Sprintende noch schnell etwas reingeschoben werden soll.

Eine robuste Definition of Done schaltet den Entwickler-Optimismus aus. Automatisierte Tests statt manueller Klick-Orgien: Ist die Pipeline rot, ist das Ticket nicht fertig. Peer Review als Teil der Arbeit, nicht als Add-on, für das man Zeit erbetteln muss. Dokumentation dort, wo sie hingehört, im Code oder im Repo, nicht in einem Wiki, das keiner liest. Und keine TODO-Kommentare, die älter sind als das Projekt.

Der wahre Test kommt unter Druck. Wenn gefragt wird, ob die Tests diesmal nicht ausfallen können, lautet die Antwort: „Können wir, dann bauen wir bewusst technische Schulden auf. Wer unterschreibt mir, dass wir die Zinsen im nächsten Sprint zahlen?“ Wer heute schlampt, zahlt morgen mit Bugs und Überstunden. Und das kostet Geld.

Refinement aus Tech-Sicht

Wenn euer Planning vier Stunden dauert und sich anfühlt wie eine Wurzelbehandlung ohne Betäubung, liegt das selten am Planning. Es liegt am Refinement davor.

Viele Teams behandeln es als optionalen Termin oder überlassen es dem Product Owner allein. Dann fließen unklare Tickets in den Sprint, blockieren die Entwicklung und produzieren Frust. Shit in, shit out. Im Planning wollt ihr nur noch entscheiden, was reinkommt und wie ihr es umsetzt. Wer dort erst klärt, was „der User soll sich einloggen können“ eigentlich meint, ist zu spät.

Der größte technische Hebel im Refinement ist vertikales Schneiden. Ein Ticket für die Datenbank, eines für die API, eines fürs Frontend: am Sprintende habt ihr drei Baustellen und kein funktionierendes Feature. Schneide stattdessen so dünn durch alle Schichten, dass ein kleiner Teil der Funktionalität wirklich läuft. Das bringt schnelles Feedback und weniger Merge-Konflikte. Für die Anforderungserhebung empfehle ich User Story Mapping, als Schnitttechnik Dimensional Planning.

Manchmal ist eine Anforderung so neu, dass jede Schätzung Würfeln wäre. Dafür gibt es Spikes: ein zeitlich begrenztes Ticket, in dem nicht produziert, sondern geforscht wird. Schätze niemals etwas, wovon du keinen blassen Schimmer hast. Verlange einen Spike.

Als Filter für die Größe taugen die INVEST-Kriterien: independent, negotiable, valuable, estimable, small, testable. Wenn ein Ticket den halben Sprint frisst, schneide es im Refinement gnadenlos auseinander. Dein zukünftiges Ich wird dir bei der Code-Review danken.

Technische Schulden im Sprint

Technische Schulden sind ein Dispokredit. Kurzfristig bist du schneller, die Zinsen fressen dich langfristig auf. Nur zahlen sie in vielen Teams die Entwickler, mit Überstunden und Frust, während sich das Management wundert, warum alles so lange dauert.

Die Zinsen siehst du daran, dass du erst zwei Stunden alten Code entwirren musst, bevor du eine neue Zeile schreiben kannst. Der Durchsatz sinkt. Die Bug-Quote steigt, weil niemand mehr die Seiteneffekte überblickt. Und die besten Leute kündigen, weil sie keine Lust auf eine digitale Müllhalde haben.

Der Vorschlag „drei Sprints Features, dann ein Refactoring-Sprint“ hilft nicht. Er passiert fast nie, und wenn doch, stoppt ihn nach drei Tagen ein Prio-1-Bug. Refactoring ist kein Event, sondern Teil der täglichen Arbeit, genau wie Tests schreiben. Die Boy-Scout-Regel reicht:

„Hinterlasse den Code immer ein kleines bisschen sauberer, als du ihn vorgefunden hast.“

Wenn du ein Ticket bearbeitest, räumst du die Funktion daneben mit auf. Das kostet zehn Prozent mehr Zeit jetzt und spart fünfzig Prozent beim nächsten Mal. Dafür fragst du niemanden um Erlaubnis. Es ist Teil deiner professionellen Standards.

Beim Product Owner kommst du mit hässlichen Interfaces nicht weit. Mit Risiko und Geld schon. Leg Tickets für technische Schulden ins Backlog und markiere sie, das ist ein guter Gesprächsstarter. Dann übersetze: „Wenn wir diese Library nicht aktualisieren, riskieren wir beim nächsten Security-Audit ein Go-Live-Verbot.“ Oder: „Mit diesem Refactoring brauchen wir für die nächsten drei Features je zwei Tage weniger.“

Agiles Arbeiten ohne technische Exzellenz führt ins Chaos. Ein Prozess, der dich zwingt, Müll zu produzieren, ist nicht agil. Er ist nur schnell kaputt.

Drei Teile, die nicht an einem Ritual hängen

Die fünf Kapitel oben behandeln je einen Termin. Diese drei Artikel gehören zur Serie, setzen aber tiefer an: bei der Physik deines Boards, bei der Frage, was ein Ticket mit deiner Arbeit macht, und bei dem, was passiert, wenn dir niemand vertraut.

Checkliste: sieben Fragen an dein Team

Geh die Liste einmal durch. Jedes Ja ist eine Baustelle, und oben steht, was du dazu sagen kannst.

1. Erfährt im Daily vor allem der PO, was ihr gestern getan habt?
2. Wird eure Velocity genutzt, um Teams zu vergleichen oder Druck zu machen?
3. Lautet der erste Vorschlag bei Termindruck, die Tests wegzulassen?
4. Bekommt ihr im Planning fertige Lösungen zum Abtippen?
5. Steht die Definition of Done im Wiki und wird beim wichtigen Release ignoriert?
6. Musst du für Refactoring um Erlaubnis bitten?
7. Besprecht ihr in der Retro seit Monaten dieselben Probleme?

Was du damit machst

Nimm dir eine Baustelle. Nicht die schlimmste, sondern die, an der du diese Woche etwas verändern kannst, ohne jemanden um Erlaubnis zu fragen. Bei den meisten Teams ist das das Daily oder die Menge offener Arbeit auf dem Board.

Und wenn ein Satz aus einem Pro-Talk-Kasten bei euch funktioniert hat oder krachend gescheitert ist, schreib mir das. Ich baue die Serie nach dem um, was in echten Teams passiert, nicht nach dem, was in Zertifikaten steht. Am besten drüben auf Mastodon bei @nobsagile.