Agile für Entwickler: Der Guide für Code, der zählt

TL;DR Wenn Scrum dich davon abhält guten Code zu schreiben, und dich das nervt, bist du hier richtig. Dieser Guide hilft dir hinter die Idee von agilem Arbeiten zu blicken.

Warum "Agile" Devs oft nervt (und wie man das ändert)

Ich will doch einfach nur entwickeln

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

Du denkst an den Wecker, der dich um 09:00 Uhr aus der Arbeit reißt, weil das Daily ansteht. Du denkst an endlose Diskussionen über Story Points, die am Ende doch nur in Personentage umgerechnet werden. Und du denkst an Jira-Tickets, die so schlecht geschrieben sind, dass du eigentlich erst mal drei Stunden Detektivarbeit leisten musst, bevor du die erste Zeile Code schreibst.

Die bittere Realität: Agile ist in vielen Unternehmen zum Micromanagement-Tool verkommen.

Statt dir als Entwickler den Rücken freizuhalten, damit du das tun kannst, wofür du bezahlt wirst – nämlich Anforderungen und Probleme von Usern mit Code lösen –, ist Agile oft zu einem bürokratischen Monster geworden. Wir nennen das „Agile Theater“ oder „Cargo Cult“: Du führst die Rituale aus (Dailys, Plannings, Retros), verstehst aber den Sinn dahinter nicht. Das Ergebnis? „Death by Jira“ und das Gefühl, nur noch ein Ticket-Schubser in einer Feature-Fabrik zu sein.

Das Versprechen vs. Die Jira-Realität

Eigentlich wurde das Agile Manifest aus einem anderen Grund geschrieben. Es ging um Individuen und Interaktionen statt Prozesse und Werkzeuge. Heute fühlt es sich oft genau umgekehrt an:

Der Prozess ist Gott: Wenn das Ticket nicht perfekt geschoben ist, nicht alle Meta Felder korrekt gefüllt sind, dann zählt die Arbeit nicht.

Velocity ist zur Peitsche verkommen: Story Points werden genutzt, um Teams zu vergleichen, statt die Komplexität zu verstehen.

Der Product Owner als „Besteller“: Du bekommst fertige Lösungen vor den Latz geknallt, statt gemeinsam an der besten technischen Umsetzung zu feilen.

Der No-Bullshit-Ansatz: Agile als Werkzeug, nicht als Religion

Mit dieser Seite und den verlinkten Themenseiten will ich damit aufräumen. Wir lassen den agilen Dogmatismus weg und schauen uns an, was dir als Entwickler wirklich hilft. Denn Fakt ist: Pragmatisches agiles Arbeiten kann dein bester Schutzschild sein.

• Es schützt deine Fokuszeit (wenn man das zum Beispiel Daily richtig macht).
• Es sichert deine Code-Qualität (wenn die Definition of Done kein Papiertiger ist).
• Es reduziert technische Schulden (wenn man sie im Sprint sichtbar macht).
• Es fördert die Zusammenarbeit im Team (wenn man die Rituale richtig nutzt)
• Es hilft dir, permanent zu lernen und besser zu werden (wenn man Feedback-Zyklen ernst nimmt)

Wir schauen uns in den nächsten Abschnitten an, wie wir die gängigen agilen Werkzeuge so einsetzen, dass sie nicht mehr nerven, sondern deinen Arbeitsalltag als Dev massiv verbessern. 

Das Daily: Statusbericht oder Planungs-Meeting?

Wenn es einen Termin gibt, der den Puls von Entwicklern zuverlässig in die Höhe treibt (und nicht auf die gute Art), dann ist es das Daily. In der Theorie ein schlankes Synchronisations-Event, in der Praxis oft eine Mischung aus morgendlicher Beichte und Rechtfertigungs-Marathon vor dem Product Owner oder Scrum Master. Das muss nicht sein und das Daily kann dir viel bringen!

Die Statusbericht-Falle: „Gestern habe ich Tickets geschoben...“

Du kennst das Szenario: Ihr steht (oder sitzt) im Kreis. 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 geistig ab. Sie checken Slack, überlegen, ob sie als nächstes einen Unit Test schreiben sollten, oder starren Löcher in die Luft. Das ist kein Meeting – das ist kollektive Zeitverschwendung. 

Das Problem: Hier wird Status-Reporting betrieben. Aber das Daily ist kein Termin, um den Manager zu beruhigen. Wenn der PO wissen will, wo ein Ticket steht, soll er ins Board schauen. Dafür haben wir es. Es ist dein Meeting.

Das Daily gehört den Entwicklern

Ein echtes Daily Scrum (oder Daily Stand-up) ist ein Planungs-Meeting. Es ist die tägliche taktische Abstimmung: „Was müssen wir heute tun, damit wir am Ende des Sprints das Ziel erreichen?“

Um das Daily von 30 Minuten Langeweile auf 15 Minuten Nutzwert zu drücken, braucht es einen radikalen Fokuswechsel.

Walk the Board, not the People: Hört auf, reihum zu fragen „Was hast du gemacht?“. Schaut stattdessen von rechts nach links auf das Board. Wir fangen bei den Tickets an, die fast fertig („Done“) sind. Warum bewegen die sich nicht? Braucht es ein Review? Klemmt das Deployment? Braucht jemand Hilfe? Das Ziel ist, Arbeit abzuschließen, nicht neue Arbeit anzufangen.

Blocker sind die Stars der Show: Ein Daily, in dem niemand „Blocker!“ ruft, ist entweder ein Wunder – oder (wahrscheinlicher) gelogen. Ein Blocker ist nicht nur „Server ist down“. Ein Blocker ist auch: „Ich verstehe die Logik in dieser Methode nicht“ oder „Ich warte seit vier Stunden auf Feedback von Team Blau“.

Die 16. Minute (After-Scrum): Das größte Daily-Verbrechen sind technische Deep Dives, bei denen 80% des Teams unbeteiligt zuschauen. Die Regel ist simpel: Sobald eine Diskussion zwischen zwei Personen länger als 60 Sekunden dauert, wird sie abgebrochen. „Wir besprechen das im After-Scrum.“ Wer einen Betrag zu dem Thema hat, bleibt da. Der Rest geht coden.

Warum das Daily dein wichtigstes Tool gegen Überlastung ist

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

Ein gutes Daily sorgt dafür, dass du nach 15 Minuten mit einem klaren Plan an den Schreibtisch zurückkehrst, statt mit dem Gefühl, gerade wertvolle Lebenszeit für ein „Update“ geopfert zu haben, das man auch hätte mailen können.

Deep Dive: Du willst wissen, wie du dein Daily konkret umbaust, damit es in 15 Minuten wirklich jeden im Team weiterbringt? Im ausführlichen Artikel Daily Scrum für Entwickler gehen wir ins Detail – inklusive Moderations-Hacks für genervte Devs.

Schätzungen vs. Realität: Story Points und Alternativen

Ron Jeffries - Erfinder der Story Points schreibt selber in seinem Blog

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

Es ist der Moment im Planning, an dem die kollektive Begeisterung ihren Tiefpunkt erreicht: Planning Poker. 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 13 hochhalten.

Die große Lüge: Story Points sind keine Stunden

Ein großes Missverständnis in der modernen Softwareentwicklung ist die Annahme, dass Story Points eine geheime Währung für Zeit sind. Erst letztens habe ich von jemanden die Geschichte gehört, dass das Management auf Basis der Velocity eines Teams Excel Tabellen für eine Jahresplanung aufstellt und sich dann wundert, dass nach vier Wochen das Team "hinter dem Plan" ist. Kommt dir das bekannt vor?

Die Realität ist und bleibt: Ein Story Point ist ein Maß für Komplexität, Risiko und Aufwand, nicht für die Uhrzeit.

Sobald Story Points in Stunden umgerechnet werden, ist das System korrumpiert. Entwickler fangen an, „defensiv“ zu schätzen (lieber eine 8 statt einer 5, um Puffer zu haben), und der eigentliche Wert des Schätzens – nämlich das Aufdecken von Unklarheiten im Team – geht komplett verloren.

Velocity ist kein Leistungsindikator

Einer der giftigsten Fehler im agilen Umfeld ist die Nutzung der Velocity als Performance-Metrik. Wenn das Management fragt: „Warum hat Team A eine Velocity von 50 und Team B nur 30?“, brennt die Hütte.

Velocity ist eine teaminterne Messgröße, die beim Planen hilft, aber kein KPI für die Produktivität. Wenn du die Velocity künstlich 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. Das ist Agile-Theater in Reinform.

Alternativen: Daten statt Raten

Wenn Story Points bei euch nur noch für Frust sorgen, gibt es Auswege, die euch deutlich besser gefallen dürften. 

T-Shirt-Größen (S, M, L, XL): Eine grobe Einteilung für die langfristige Planung. Dies reicht meistens völlig aus, um zu wissen, ob ein Feature ins Quartal oder in den Sprint passt oder nicht.

#NoEstimates: Mein bevorzugter Ansatz. Statt Zeit mit Schätzen zu verschwenden, schneiden wir die Tickets so klein, dass sie alle ungefähr „gleich groß“ (nämlich klein!) sind. Dann zählen wir nur noch die Anzahl der erledigten Tickets pro Woche (Throughput).

Monte-Carlo-Simulationen: Warum raten, wenn wir Daten haben? Basierend auf der historischen Zykluszeit (wie lange hat ein Ticket in der Vergangenheit im Schnitt gedauert?) lassen sich mathematisch fundierte Prognosen treffen, die weitaus genauer sind als das Bauchgefühl beim Planning Poker.

Fazit: Schätzen sollte der Klärung dienen, nicht der Kontrolle

Der einzige legitime Grund zu schätzen ist, herauszufinden, ob wir alle dasselbe Verständnis vom Problem haben. Wenn du eine 2 legst und dein Kollege eine 13, dann habt ihr kein Schätz-Problem, sondern ein Verständnis-Problem. Das ist die wertvolle Diskussion. Die Zahl auf dem Ticket ist am Ende zweitrangig.

Insgesamt solltest du auf folgendes achten, wenn ihr denn mit einer Art von Story Point arbeiten wollt oder müsst: Es sind teaminterne Zahlen. Sie sollten nicht zum Vergleich heran gezogen können. Story Points haben eine sehr kurze Lebenszeit. In meinen Augen gelten sie nur für das Refinement und sind danach hinfällig.

Deep Dive: Du hast das Gefühl, Story Points sind bei euch nur ein anderes Wort für Überstunden? In meinem Artikel Story Points sind Unsinn? Die Wahrheit über Agile Schätzungen erkläre ich dir, wie ihr aus der Schätz-Falle rauskommt und wie du dem Management erklärst, dass Flow-Metrics sinnvoller sind als Planning Poker.

Qualitätssicherung: Definition of Done als Schutzschild

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

Ehrlich: Dann ist es nicht fertig.

In vielen Teams herrscht eine gefährliche Unklarheit darüber, was „fertig“ eigentlich bedeutet. Das führt dazu, dass Code in Produktion geht, der wie ein Kartenhaus zusammenfällt, sobald der erste User einen ungewöhnlichen Input liefert. Hier kommt die Definition of Done (DoD) ins Spiel. Sie ist kein nettes Extra, sondern der Qualitäts-Vertrag deines Teams.

DoD vs. Akzeptanzkriterien: Wer verantwortet was?

Ein häufiger Fehler ist die Vermischung von Akzeptanzkriterien (AC) und der DoD:
Akzeptanzkriterien sind spezifisch für ein Ticket. (Beispiel: „Der User kann sich mit Google-OAuth einloggen.“) Das ist die Domäne des Product Owners.

Die Definition of Done ist der globale Standard für jedes Ticket. (Beispiel: „Unit Tests decken die Logik ab, Code ist gelintet, Peer Review ist erfolgt.“) Das ist die Domäne der Entwickler.

Die DoD ist dein Schutzschild: Wenn der PO am Ende des Sprints drängelt, ein Feature „schnell noch reinzuschieben“, ist die DoD dein legales Veto. „Wir würden gerne, aber die DoD schreibt Integrationstests und ein Security-Audit vor. Ohne das ist es nicht 'Done'.“ Und wenn dann ein PO trotzdem drauf besteht solltet ihr in der Retro darüber sprechen, ob ihr agiles Arbeiten ernst nehmen wollt oder nicht.

Warum „Works on my Machine“ kein Status ist

Eine gute DoD sorgt dafür, dass wir den berüchtigten „Entwickler-Optimismus“ ausschalten. Sie definiert die harte Grenze zwischen „ich hab’s gecodet“ und „es ist produktionsreif“. Eine robuste DoD umfasst meistens:

Automatisierte Tests: Keine manuellen Klick-Orgien. Wenn die Pipeline rot ist, ist das Ticket nicht fertig.

Peer Reviews: Vier Augen sehen mehr als zwei. Das Review ist Teil der Arbeit, kein „Add-on“, für das man Zeit erbetteln muss.

Dokumentation: Und zwar dort, wo sie hingehört (im Code oder im Repo), nicht in einem verstaubten Wiki, das niemand liest.

Clean Code Standards: Keine „TODO“-Kommentare, die älter sind als das Projekt selbst.

Die Verteidigung der DoD gegen Management-Druck

Der wahre Test für eine DoD kommt unter Druck. Wenn die Deadline näher rückt, heißt es oft: „Können wir die Tests diesmal nicht weglassen?“. Deine Antwort muss lauten: „Wir können das Feature liefern, aber dann verletzen wir unsere DoD und bauen bewusst technische Schulden auf. Wer unterschreibt mir, dass wir die Zinsen dafür im nächsten Sprint zahlen?“ Eine konsequente DoD ist der einzige Weg, um langfristig euren Durchsatz stabil zu halten. Wer heute bei der DoD schlampt, zahlt morgen mit Bugs und Überstunden. Und das kostet langfristig Geld!

Deep Dive: Du suchst eine Vorlage für eine knallharte DoD, die Backend- und Frontend-Besonderheiten berücksichtigt? In meinem Definition of Done Praxis-Guide findest du Checklisten, die du direkt in dein Jira oder Repo kopieren kannst, um Diskussionen über „Fertig“ ein für alle Mal zu beenden.

Vorbereitung ist alles: Refinement aus Tech-Sicht

Wenn das Planning bei euch vier Stunden dauert und sich anfühlt wie eine Wurzelbehandlung ohne Betäubung, dann liegt das meistens nicht am Planning selbst – sondern an einem mangelhaften Refinement.

Viele Teams begehen den Fehler, das Refinement als „optionales Meeting“ zu betrachten oder es dem Product Owner allein zu überlassen. Das Ergebnis? „Shit in, Shit out.“ Unklare Tickets fließen in den Sprint, blockieren die Entwicklung und sorgen für Frust.

Warum Refinement wichtiger ist als das Planning

Im Planning wollen wir eigentlich nur noch entscheiden: „Was packen wir rein und wie setzen wir es um?“ Wenn wir dort erst anfangen zu klären, was der PO eigentlich mit „der User soll sich einloggen können“ meint, ist es zu spät.

Ein kontinuierliches Refinement sorgt dafür, dass die Tickets „ready“ sind. Für dich als Entwickler bedeutet das: Weniger Rätselraten, mehr Klarheit. Ein Ticket ist erst dann reif für den Sprint, wenn du genau weißt, wo du im Code ansetzen musst.

Vertical Slicing: Features schneiden statt Schichten trennen

Einer der größten technischen Hebel im Refinement ist das Vertical Slicing.
Der falsche Weg (Horizontal): Ein Ticket für die Datenbank, eines für die API, eines für das Frontend. Resultat: Am Ende des Sprints haben wir drei Baustellen, aber kein funktionierendes Feature. Es gibt viele Techniken um besser zu schneiden. Ich empfehle User Story Mapping in der Anforderungserhebung und Dimensional Planning als Slicing Methode.

Tipp: Wir schneiden ein Feature so dünn, dass es durch alle Layer geht (Datenbank bis UI), aber nur einen Bruchteil der Funktionalität abdeckt. Das sorgt für schnelles Feedback, reduziert Merge-Konflikte und verhindert, dass wir „auf Halde“ produzieren.

Spikes: Wenn „Ich weiß es nicht“ die richtige Antwort ist

Manchmal ist eine Anforderung so komplex oder neu, dass eine Schätzung reine Würfelei wäre (noch mehr als sonst schon). Hier kommen Spikes ins Spiel. Ein Spike ist ein zeitlich begrenztes Ticket, in dem nicht produziert, sondern geforscht wird.

Das Ziel ist klar: Die technische Machbarkeit prüfen und/oder einen Prototyp bauen. Mit solchen Spikes kannst du sehr gut die Ungewissheit reduzieren, sodass ihr das eigentliche Feature danach fundiert schätzen könnt.

Wichtig: Schätze niemals etwas, wovon du keinen blassen Schimmer hast. Verlange stattdessen einen Spike.

INVEST: Deine Checkliste gegen Ticket-Müll

Nutze die "INVEST-Kriterien" als Filter um zu schauen, ob ein Ticket eine akzeptable Größe hat. Ein Ticket muss Independent, Negotiable, Valuable, Estimable, Small und Testable sein. Wenn ein Ticket so groß ist, dass es den halben Sprint einnimmt, schneide es im Refinement gnadenlos auseinander. Dein zukünftiges Ich wird dir bei der Code-Review danken.

Deep Dive: Du willst lernen, wie man komplexe User Stories in technisch saubere Slices zerlegt, ohne in der „Layer-Falle“ zu landen? In meinem Artikel Backlog Refinement Technik: Tickets schneiden wie ein Pro zeige ich dir konkrete Slicing-Strategien für Dev-Teams.

Technische Schulden managen im Sprint

Technische Schulden sind wie ein Dispokredit: Kurzfristig hilft er dir, schneller zu sein, aber die Zinsen fressen dich langfristig auf. Das Problem in vielen agilen Teams? Die Entwickler zahlen die Zinsen durch Überstunden und Frust, während das Management sich wundert, warum „alles so lange dauert“.

Die Zins-Metapher: Warum du immer langsamer wirst

Stell dir vor, jedes Mal, wenn du eine neue Zeile Code schreibst, musst du erst mal zwei Stunden lang alten Code entwirren. Das sind die Zinszahlungen. Wenn ein Team technische Schulden ignoriert, passiert Folgendes:

• Euer Durchsatz sinkt.
• Die Bug-Quote steigt, weil niemand mehr die Seiteneffekte im Spaghetticode überblickt.
• Die besten Leute kündigen, weil sie keine Lust haben, in einer digitalen Müllhalde zu arbeiten.

Warum „Refactoring-Sprints“ meistens eine Lüge sind

Manchmal höre ich

„Wir machen jetzt drei Sprints Features und danach einen Refactoring-Sprint.“

Das passiert fast nie. Und wenn doch, ist es meistens ineffektiv, weil ihr isoliert vom Business-Value am System herumschraubt, was der Product Owner (PO) nach drei Tagen wieder stoppt, weil ein „Prio-1-Bug“ reinkommt. Besserer Ansatz: Refactoring ist kein Event – es ist ein Teil der täglichen Arbeit, genau wie Tests schreiben.

Die Boy Scout Regel: Kontinuierliche Instandhaltung

Der bessere Weg ist die Boy Scout Regel.

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

Wenn du ein Ticket bearbeitest, räumst du die Funktion daneben kurz mit auf. Das kostet vielleicht 10 % mehr Zeit im aktuellen Ticket, spart aber 50 % Zeit beim nächsten Mal. Du musst dafür nicht um Erlaubnis fragen – es ist Teil deiner professionellen Standards (siehe Definition of Done oben oder in dem entsprechenden Artikel).

Tech Debt sichtbar machen (Argumente für den PO)

Der durchschnittliche Product Owner versteht keine „hässlichen Interfaces“. Er versteht aber Risiko und Geld! Das ist dein Ansatzpunkt um zu erklären, wie technische Schulden wirken.

Versucht zum Beispiel mal eigene Tickets, die technische Schulden repräsentieren, ins Backlog zu packen. Markiere sie (z. B. mit einem Label „Tech Debt“). Das kann ein guter Gesprächsstarter sein.

Die Risiko-Matrix: Erkläre dem PO: „Wenn wir diese Library nicht aktualisieren, riskieren wir beim nächsten Security-Audit ein Go-Live-Verbot.“

Die Time-to-Market-Karte: „Wenn wir dieses Refactoring jetzt machen, brauchen wir für die nächsten drei Features jeweils zwei Tage weniger.“

Fazit: Agilität erfordert Exzellenz

Agile Prozesse ohne technische Exzellenz führen direkt ins Chaos. Ein agiler Prozess, der dich zwingt, Müll zu produzieren, ist nicht agil – er ist nur schnell kaputt. Nutze die agilen Rituale (Retrospektive!), um gnadenlos aufzuzeigen, wo technische Schulden euren Flow bremsen.

Deep Dive: Du hast genug davon, für jedes Refactoring betteln zu müssen? In meinem Artikel Technische Schulden im agilen Prozess abbauen zeige ich dir konkrete Verhandlungsstrategien und Metriken, mit denen du dem Business klarmachst, dass „sauberer Code“ kein Luxus, sondern ein wirtschaftliches Muss ist.

Checkliste: Ist dein Team wirklich "No-Bullshit Agile"?

Zum Abschluss hier eine kleine Checkliste für dich. Seit ihr wirklich agil oder spielt ihr agil? 

1. Status-Beichte vs. Team-Taktik: Dient euer Daily dazu, dass der Product Owner oder Scrum Master erfährt, was ihr gestern getan habt, oder plant ihr als Team aktiv, wie ihr heute gemeinsam Blocker aus dem Weg räumt?
2. Velocity als Peitsche: Wird eure Velocity vom Management genutzt, um die „Produktivität“ von Teams zu vergleichen oder um Druck aufzubauen, statt sie nur als internes Tool für eure eigene Sprint-Planung zu verwenden?
3. Qualität als Verhandlungsmasse: Wenn die Deadline drückt, ist der erste Vorschlag des POs, „die Tests erst mal wegzulassen“ oder „die Doku später zu machen“, anstatt den Scope des Features zu reduzieren?
4. Ticket-Schubser vs. Mitgestalter: Erhaltet ihr im Planning fertige technische Lösungen, die ihr nur noch „abtippen“ müsst, oder werden euch Probleme präsentiert, für die ihr als Experten die beste technische Umsetzung erarbeitet?
5. Die Definition of Done als Papiertiger: Habt ihr eine DoD, die zwar irgendwo im Wiki steht, aber in der Realität regelmäßig ignoriert wird, sobald ein Release „wirklich wichtig“ ist?
6. Refactoring als Gnadenakt: Müsst ihr für jedes Refactoring oder das Beheben von technischen Schulden um Erlaubnis bitten („Darf ich mal zwei Tage aufräumen?“), anstatt dass diese Arbeiten als integraler Teil eurer professionellen Arbeit akzeptiert sind?
7. Retrospektive als Kaffeeklatsch: Besprecht ihr in der Retro jedes Mal dieselben Probleme (zu viele Meetings, schlechte Tickets), ohne dass sich bis zum nächsten Sprint spürbar etwas an euren Prozessen ändert?

Fazit

Ich hoffe, du hast dich in diesem Artikel wiedergefunden und siehst auch eine Hilfestellung. Wenn das der Fall ist, freue ich mich, wenn du ihn mit Kolleginnen und Kollegen und gerne auch auf Social Media teilst!