Agilität erzeugt Wartungsarbeit, bevor sie bessere Lieferung erzeugt. Meine unbequeme Position: Für einen Backend-Entwickler ist der gefährlichste Teil beim Einstieg nicht Scrum, Planning oder Retrospektive, sondern die Pflege der Prozessinfrastruktur, weil jedes Board, jede Metrik und jede Automatisierung später wie Produktionscode altert. Wer das ignoriert, baut ein zweites System ohne Tests.
Ein agiles Board ist ein wartungspflichtiges Backend ohne Compiler
Der Beitrag Agiles Projektmanagement fuer erfolgreiche IT-Prozesse ist als Einstieg nützlich, aber er unterschätzt aus meiner Sicht den Betriebszustand des Prozesses, weil Tickets, Statusregeln und Metriken nach wenigen Wochen genauso veralten wie schlecht gepflegte APIs.
Als Backend-Entwickler kennst du technische Schulden: eine verwaiste Queue, ein unversioniertes JSON-Feld, ein Cronjob ohne Owner. Im agilen Projektmanagement entstehen dieselben Muster, nur heißen sie „Blocked“, „Ready for QA“, „Refinement needed“ oder „Waiting for PO“. Der Unterschied ist unangenehm: Der Compiler beschwert sich nicht, wenn dein Workflow lügt.
Ich würde nicht mit einem vollständigen Scrum-Setup starten, wenn das Team bisher über Pull Requests, Slack und Deployments koordiniert hat, weil du damit sofort Sprint-Pflege, Backlog-Hygiene, Velocity-Diskussionen und Rollenklärung einführst, bevor du weißt, welches Koordinationsproblem wirklich weh tut. Ein schlankes Kanban mit expliziten WIP-Limits ist anfangs härter, aber ehrlicher, weil liegen gebliebene Arbeit sichtbar wird, statt in Sprint-Zielen zu verschwinden.
Die Pflege beginnt bei banalen Dingen. In Jira Software Cloud mit Workflow-Schemata, Custom Fields und JQL-Filtern musst du regelmäßig prüfen, ob ein Status noch eine reale Entscheidung abbildet. In GitHub Projects v2 musst du kontrollieren, ob Labels wie backend, migration oder ops überhaupt konsistent verwendet werden. In Linear musst du entscheiden, ob Cycles die Wahrheit abbilden oder nur einen Kalender simulieren. Das ist keine Prozessromantik, sondern Datenmodellierung ohne Datenbankmigration.
Eine gemessene Zahl aus einem Team-Check der letzten 30 Tage ist oft entlarvender als jedes Planning: Wenn die mediane Ticket-Liegezeit 4,2 Tage beträgt und das 95. Perzentil 17 Tage erreicht, ist „wir sind fast fertig“ kein Zustand, sondern ein Signal für unsichtbare Übergaben. Diese Werte sind keine Norm, sondern eine lokale Messung, weil Lead Time nur im Kontext deines Release-Modells Sinn ergibt.
Für den Einstieg reichen wenige technische Anker: Git 2.44 für Commit- und Branch-Alter, Jira REST API v3 für Issue-Historie, GitHub GraphQL API v4 für Pull-Request-Daten, Prometheus 2.52 für Zeitreihen, Grafana 11 für Dashboards und OpenTelemetry 1.32 für Trace-Kontext. Je mehr du davon einsetzt, desto mehr musst du pflegen, weil jede Integration ein Vertrag ist, der brechen kann.
Die ersten Metriken werden falsch gelesen, wenn niemand ihre Kosten besitzt
Der Beitrag Agiles Projektmanagement und Prozesse in der Softwareentwicklung beschreibt Prozesse in der Softwareentwicklung verständlich, aber ich halte den Metrik-Teil für zu harmlos, weil jede Kennzahl Verhalten verändert und deshalb wie ein öffentliches API versioniert werden sollte.
Cycle Time, Lead Time, WIP, Throughput, Change Failure Rate, MTTR und Deployment Frequency stammen häufig aus DORA- oder Kanban-Diskussionen, aber sie sind keine neutralen Instrumente, weil Entwickler ihre Arbeit an den sichtbaren Messpunkten ausrichten. Wenn du nur abgeschlossene Tickets zählst, werden Tickets kleiner geschnitten; wenn du nur Deployments zählst, werden Deployments kosmetisch; wenn du nur Sprint Commitment bewertest, wird Unsicherheit versteckt.
Ein veröffentlichter Richtwert aus dem Scrum Guide 2020 ist ein Daily Scrum von 15 Minuten bei einem einmonatigen Sprint; das klingt klein, kostet bei sieben Personen aber 105 Personenminuten pro Arbeitstag, weil Synchronisation immer mit Opportunitätskosten kommt. Diese Zahl ist nicht das Problem, aber sie zwingt dich zu fragen, ob das Meeting Informationen erzeugt oder nur Statusberichte serialisiert.
Für Backend-Teams ist die gefährlichste Metrik oft Velocity, weil sie eine scheinbar quantitative Planung verspricht, obwohl Story Points absichtlich keine Zeitmessung sind. Ich würde Velocity nicht als Zielgröße für Führung verwenden, weil Teams sonst Points inflaten und technische Aufräumarbeiten als Feature-Arbeit tarnen. Besser ist ein stabiler Blick auf Alter und Fluss: Wie lange existiert Arbeit, bevor sie produktiv ist?
Ein kleines Skript zeigt mehr Wahrheit als viele Statusrunden. Es läuft in einem Git-Repository mit Remote origin und zeigt lokale Branches, die gegenüber origin/main voraus sind:
#!/usr/bin/env bash
set -euo pipefail
base="${1:-origin/main}"
git fetch origin main --quiet
for b in $(git for-each-ref --format='%(refname:short)' refs/heads); do
ahead=$(git rev-list --count "$base..$b")
age=$(git log -1 --format=%cr "$b")
test "$ahead" -gt 0 && printf "%-35s %4s commits ahead, last change %s\n" "$b" "$ahead" "$age"
done
Dieses Skript ersetzt kein Reporting, aber es senkt die Einstiegshürde, weil es direkt an deiner Arbeitsrealität hängt. Ein zu kalibrierender Startwert ist ein WIP-Limit von 2 aktiven Implementierungsaufgaben pro Entwickler, weil Backend-Arbeit oft Datenmigrationen, Review-Kontext und lokale Testumgebungen blockiert. Der Wert ist absichtlich niedrig, damit Überlast sichtbar wird; nach zwei Wochen kannst du ihn anpassen.
Auch Tool-Konfiguration ist Wartung. Renovate 37 mit prConcurrentLimit=3 reduziert Paket-PR-Lärm, kostet aber regelmäßige Pflege von Ausnahmen. Dependabot v2 ist einfacher in GitHub-Repos, erzeugt aber bei monorepos oft weniger steuerbare PR-Ströme. SonarQube 10.4 kann Quality Gates erzwingen, verursacht aber Fehlalarme, wenn Regeln nicht zu Legacy-Code passen. Jede dieser Entscheidungen ist ein Prozessartefakt, weil sie beeinflusst, was Entwickler zuerst anfassen.
Jira Scrum gewinnt bei Abhängigkeiten, GitHub Projects gewinnt bei Nähe zum Code
Die explizite Wahl zwischen Jira Software Cloud mit Scrum-Board und GitHub Projects v2 mit Kanban-Board sollte nicht ideologisch sein, weil beide Optionen unterschiedliche Wartungslasten erzeugen.
- Jira Software Cloud mit Scrum gewinnt, wenn mehrere Teams, externe Abhängigkeiten, Release-Freigaben und Audit-Spuren koordiniert werden müssen, weil Issue-Historie, Workflow-Schemata, JQL und Berechtigungen diese Struktur besser abbilden. Es kostet allerdings Admin-Zeit, Feldpflege, Board-Governance und regelmäßige Workflow-Bereinigung, weil jedes zusätzliche Custom Field später in Filtern, Reports und Automationen hängt.
- GitHub Projects v2 mit Kanban gewinnt, wenn ein Backend-Team nah am Code arbeitet und Pull Requests der zentrale Liefergegenstand sind, weil Issues, PRs, Actions und Branches ohne Medienbruch verbunden bleiben. Es kostet schwächere Portfolio-Sicht, mehr Disziplin bei Labels und oft handgebaute Reports, weil GitHub weniger Prozesssemantik vorgibt.
Ein von GitHub dokumentierter Grenzwert ist die maximale Laufzeit von 6 Stunden für einen GitHub-Actions-Job auf gehosteten Runnern; dieser Anbieterwert wirkt prozessual, weil ein flakiger End-to-End-Test plötzlich Planning- und Release-Zusagen gefährdet. Wer CI als reine Technik behandelt, übersieht die Wartungslast im agilen Prozess, weil „Done“ ohne verlässliche Pipeline kein überprüfbarer Zustand ist.
In Kubernetes 1.29 mit Helm 3.14 und Argo CD 2.10 wird das noch deutlicher. Wenn dein Board „Ready for Deploy“ kennt, aber Argo CD wegen eines fehlerhaften Helm-Templates nicht synchronisiert, ist der Ticketstatus falsch. Wenn kubectl rollout status –timeout=90s in der Pipeline verwendet wird, sind 90 Sekunden ein zu justierender Betriebswert, weil langsame Migrationsjobs sonst als Deployment-Fehler erscheinen, obwohl die Applikation korrekt startet.
Ich nehme hier bewusst eine streitbare Position ein: Agiles Projektmanagement ist für Backend-Teams erst dann professionell, wenn Prozesszustände maschinenlesbar gegen technische Zustände geprüft werden, weil menschliche Statuspflege unter Lieferdruck systematisch optimistischer wird. Das heißt nicht, dass alles automatisiert werden soll; es heißt, dass zentrale Zustände wie „reviewbar“, „deployed“, „blocked“ und „released“ klare Datenquellen brauchen.
OpenAPI 3.1, AsyncAPI 3.0, Protobuf 3 und gRPC über HTTP/2 gehören ebenfalls in diese Debatte, weil API-Verträge Arbeit erzeugen, die im Board sichtbar sein muss. Eine Breaking-Change-Prüfung in Buf, ein Contract-Test mit Pact oder ein Schema-Check in CI sind keine Nebenaufgaben, weil sie verhindern, dass ein Ticket fachlich „fertig“ ist, aber operativ Schaden erzeugt.
Die eigentliche Last liegt in Übergaben, nicht in Meetings
Viele Einsteiger unterschätzen Übergaben, weil Meetings sichtbarer sind als Wartezustände. Ein Planning von 60 Minuten ist leicht zu kritisieren, aber drei Tage Wartezeit auf Review zerstören Fluss stärker, weil Kontext verfällt und Rebase-Arbeit entsteht. Deshalb sollte ein Backend-Entwickler zuerst Übergabepunkte kartieren: Refinement zu Implementierung, Implementierung zu Review, Review zu Deploy, Deploy zu Beobachtung.
Pull Requests sind der ehrlichste Ort für diese Analyse, weil dort Code, Diskussion, Tests und Ownership kollidieren. GitHub branch protection mit required_status_checks, GitLab Merge Request approvals, CODEOWNERS und Conventional Commits 1.0.0 sind nützlich, aber sie kosten Aufmerksamkeit, weil jede Regel die Warteschlange verlängern kann. Eine gemessene Review-Reaktionszeit von 11 Stunden im Median kann akzeptabel sein, wenn asynchron über Zeitzonen gearbeitet wird; sie ist problematisch, wenn alle im selben Team sitzen und Releases täglich geplant sind.
Die Retrospektive wird oft überladen, weil sie als Reparaturwerkstatt für jedes Prozessproblem verwendet wird. Ich würde dort nicht jede Woche neue Experimente beschließen, weil Experimente ohne Auswertung nur Prozessrauschen erzeugen. Besser ist ein Experiment pro zwei Wochen mit klarem Abbruchkriterium, zum Beispiel: „WIP-Limit 2 bleibt nur, wenn die Zahl angefangener, aber nicht gemergter Branches nach zehn Arbeitstagen sinkt.“ Dieser Zeitraum ist ein Arbeitswert, kein Gesetz, weil Teamgröße und Release-Rhythmus ihn verändern.
Auch Observability gehört in die Prozesspflege. Prometheus-Alerts mit for: 5m, Grafana-Dashboards, Loki 3.0 für Logs und OpenTelemetry-Spans mit service.name helfen nur, wenn sie mit Definition of Done verbunden sind. Ein SLO von 99,9 Prozent Verfügbarkeit ist ein verhandelbarer Zielwert, weil er monatlich etwa 43 Minuten Fehlerbudget erlaubt und damit beeinflusst, wie viel Risiko ein Sprint tragen darf.
Das ist der Teil, den niemand gern vor der Einführung sagt: Agiles Arbeiten braucht jemanden, der die Semantik pflegt. Ohne Owner werden Spalten zu Ablageflächen, Labels zu Meinungen und Metriken zu Präsentationsfolien. Mit Owner entsteht zusätzliche Arbeit, aber sie ist wenigstens sichtbar, weil jemand entscheidet, welche Prozessartefakte gelöscht, geändert oder automatisiert werden.
Beginne mit einer Wartungsinventur, bevor du ein Framework übernimmst
Lege morgen keine neue Zeremonie an, sondern sammle zuerst zehn echte Arbeitseinheiten aus den letzten zwei Wochen und notiere für jede: Start, erster Review, Merge, Deployment, erster Produktionshinweis. Danach streichst du jeden Board-Status, der keinen dieser Übergänge erklärt. Erst wenn diese kleine Inventur weh tut, lohnt sich ein größeres agiles Setup.
