Agile Delivery mit Scrum & Kanban: Projekte erfolgreich umsetzen

Agile Delivery heißt: In kurzen Zyklen nutzbare Ergebnisse liefern, Feedback früh einholen und Risiken systematisch reduzieren. Statt monatelang auf ein „fertiges“ Release hinzuarbeiten, entsteht in jeder Iteration ein integrierter, testbarer Stand – idealerweise jederzeit auslieferbar. Das ist besonders relevant in IT-Organisationen, in denen Anforderungen sich ändern, Abhängigkeiten komplex sind und Qualität (Security, Stabilität, Compliance) nicht verhandelbar ist.

In diesem Artikel geht es um die praxisnahe Entscheidung „Scrum oder Kanban?“ – und darum, wie Sie Delivery, Qualität und Transparenz so kombinieren, dass Projekte planbar bleiben und Teams dauerhaft lieferfähig sind.

Was bedeutet Agile Delivery konkret?

Agil wird oft mit „schnell“ verwechselt. In der Praxis geht es eher um kurze Lernzyklen und kontrollierte Lieferfähigkeit:

• Inkremente statt Big Bang: Kleine, abgegrenzte Lieferobjekte mit klaren Akzeptanzkriterien.

• Sichtbarkeit: Arbeit ist transparent (Board, Definition of Done, messbare Ziele).

• Technische Exzellenz: CI, Tests, Code Reviews und Deployment-Automatisierung sind Teil des Systems – nicht „nice to have“.

• Feedback als Steuerung: Demos, Nutzungssignale, Support- und Betriebserkenntnisse fließen strukturiert ins Backlog.

Agile Delivery passt besonders gut zu DevOps-Prinzipien: Entwicklung und Betrieb optimieren gemeinsam den Weg von der Idee bis in die Produktion. Inhaltlich ergänzt sich das häufig mit Themen wie CI/CD-Pipeline-Aufbau und Infrastructure as Code.

Scrum vs. Kanban: Der Unterschied auf den Punkt

Scrum und Kanban lösen ähnliche Probleme, setzen aber unterschiedliche Hebel an. Die folgende Übersicht hilft bei der Einordnung:

Wichtig: Beides sind Frameworks, keine Garantien. Ohne klare Verantwortlichkeiten, saubere Backlog-Arbeit und technische Qualität wird Scrum zum Mini-Wasserfall – und Kanban zu „wir machen alles gleichzeitig“.

Entscheidungshilfe: Scrum, Kanban oder Scrumban?

In der Realität ist die Wahl selten binär. Häufig ergibt sich ein pragmatischer Mix („Scrumban“): Scrum-Struktur dort, wo Planung hilft – Kanban-Flow dort, wo Unvorhersehbares dominiert.

Wann Scrum gut funktioniert

Scrum ist stark, wenn Sie Ziele und Lieferobjekte in Iterationen schneiden können:

• Es gibt einen Product Owner (oder eine vergleichbare Rolle) mit echter Priorisierungsbefugnis.

• Anforderungen lassen sich als User Stories mit Akzeptanzkriterien formulieren.

• Das Team kann in einem Sprint ein Done-Inkrement liefern (inkl. Tests/Review/Integration).

• Stakeholder akzeptieren: Es gibt ein Sprint-Ziel, nicht 20 parallele „Urgencies“.

Wann Kanban besser passt

Kanban ist sinnvoll, wenn Arbeit stark schwankt und schnelle Reaktionsfähigkeit gefragt ist:

• Hoher Anteil an Tickets/Incidents/Ad-hoc.

• Viele Abhängigkeiten (z. B. Freigaben, externe Teams, Plattform-Themen).

• Prioritäten ändern sich häufig – „Sprint-Schutz“ wäre künstlich.

• Sie wollen Flow messbar machen und Engpässe gezielt reduzieren.

Ein praxistauglicher „Scrumban“-Ansatz

Ein gängiges Setup in IT-Organisationen:

• Sprint-Zyklus (z. B. 2 Wochen) für planbare Themen/Features.

• Kanban-Lane für Ungeplantes (Incidents, Security-Fixes), mit klaren Regeln und WIP-Limit.

• Replenishment (z. B. 1× pro Woche) statt überladener Refinements.

• Gemeinsame Service Level Expectations (SLE) für dringende Arbeit („bis wann muss das durch den Prozess?“).

Der Kern: Backlog-Qualität und Definition of Done

Viele Delivery-Probleme sind keine Tool- oder Methodikprobleme, sondern Backlog- und Qualitätsprobleme.

Gute Stories sind testbar und verhandelbar

Ein praxistaugliches Story-Format enthält:

• Nutzer-/Businesswert (wer profitiert, wozu?),

• Akzeptanzkriterien (wann ist es „richtig“?),

• Nicht-Ziele (was ist explizit nicht Teil des Scopes?),

• Abhängigkeiten (z. B. Daten, Schnittstellen, Freigaben).

Wenn Akzeptanzkriterien fehlen, wird „Done“ zur Diskussion – und Reviews werden zu Abnahmeschleifen. In solchen Situationen hilft es, eine leichte Definition of Ready einzuführen (z. B. „Story ist geschätzt, hat Kriterien, hat klaren Owner“).

Definition of Done: Qualität wird nicht hinten angehängt

Die Definition of Done ist ein Vertrag des Teams. Typische, pragmatische Bausteine:

• Code reviewed (z. B. 4-Augen-Prinzip),

• automatisierte Tests grün (Unit/Integration nach Bedarf),

• Sicherheits- und Qualitätschecks (SAST/Lint) laufen,

• Deployment-Pfad ist bekannt (Feature Toggle, Rollback-Strategie),

• Betriebsaspekte sind geklärt (Monitoring/Alerting, Runbook falls nötig).

Gerade hier zahlt sich Automatisierung aus: Eine CI/CD-Pipeline macht „Done“ messbar. Ohne diese technische Basis wird Agilität schnell zur Illusion.

Metriken, die wirklich helfen (statt Bauchgefühl)

Agile Delivery braucht Kennzahlen – aber die richtigen. Sonst optimiert man auf das Falsche (z. B. „mehr Tickets“ statt „mehr Wert“).

Für Kanban/Flow

• Lead Time: Zeit von „Anforderung erfasst“ bis „fertig ausgeliefert“.

• Cycle Time: Zeit von „Arbeit gestartet“ bis „fertig“.

• Throughput: Wie viele Items pro Zeitraum wirklich abgeschlossen werden.

• WIP: Wie viel gleichzeitig in Arbeit ist (oft der Haupthebel).

Ein typisches Muster: Wenn WIP steigt, steigen Cycle Time und Fehlerquote. WIP-Limits sind kein Selbstzweck, sondern ein Mittel, Engpässe sichtbar zu machen (Review-Queue, Test-Umgebung, Abnahmen).

Für Scrum (mit Augenmaß)

• Erreichung des Sprint-Ziels (qualitativ, nicht nur „Punkte geschafft“),

• Stabilität der Zusagen (nicht „Perfektion“, sondern Trend),

• Defect-Leakage (wie viel „Done“ kommt als Bug zurück?).

Velocity kann als Team-internes Hilfsmittel taugen – ist aber als Management-KPI oft toxisch. Sobald Punkte „verhandelt“ werden, verlieren sie ihren Zweck.

Meetings und Rituale: so wenig wie möglich, so viel wie nötig

Scrum-Events und Kanban-Routinen funktionieren, wenn sie ein klares Ergebnis erzeugen.

Scrum pragmatisch

• Planning: Sprint-Ziel festlegen, danach Arbeit auswählen. Fokus: „Was schaffen wir, um das Ziel zu erreichen?“

• Daily: 10–15 Minuten zur Synchronisation (Blocker, Koordination), kein Statusreporting.

• Review: Demonstration am echten System (oder realistischen Daten), nicht an Folien.

• Retro: 1–2 konkrete Verbesserungen beschließen, mit Ownership und Termin.

Kanban-Routinen, die sich bewährt haben

• Replenishment: Prioritäten klären, nächste Arbeit bereitstellen.

• Flow Review: Engpässe und „Aging Items“ anschauen (Was hängt zu lange fest? Warum?).

• Service Delivery Review: Monatlich Trends prüfen (Lead Time, Ausfälle, Qualität) und systemische Verbesserungen ableiten.

Tooling: Boards, Doku und Automatisierung sinnvoll verbinden

Tools lösen keine Prozessprobleme, aber sie helfen, Disziplin leicht zu machen. Entscheidend ist: ein durchgängiger Faden von Ticket → Code → Build → Deployment → Betrieb.

Boards und Backlog

• Jira: https://www.atlassian.com/software/jira

• Azure DevOps Boards: https://azure.microsoft.com/products/devops/boards/

• GitHub Projects: https://docs.github.com/issues/planning-and-tracking-with-projects

• GitLab Issue Boards: https://docs.gitlab.com/ee/user/project/issue_board.html

• Trello (leichtgewichtig): https://trello.com/

Wählen Sie nicht nach Funktionsliste, sondern nach Integration und Nutzbarkeit im Alltag: Workflows, Rechte, Reporting, Automatisierungen, Schnittstellen.

Dokumentation und Zusammenarbeit

• Confluence: https://www.atlassian.com/software/confluence

• Notion: https://www.notion.so/

• Miro (Workshops/Discovery): https://miro.com/

Pragmatische Regel: Dokumentation dient Entscheidungen und Betrieb. „Alles dokumentieren“ ist genauso wenig hilfreich wie „gar nichts“.

Delivery- und Qualitätsautomation

• GitHub Actions: https://docs.github.com/actions

• GitLab CI/CD: https://docs.gitlab.com/ee/ci/

• Azure Pipelines: https://learn.microsoft.com/azure/devops/pipelines/

Sinnvolle Standards (unabhängig vom Tool):

• automatisierte Builds/Tests bei jedem Merge,

• reproduzierbare Umgebungen (z. B. mit IaC),

• klare Release-Strategie (Trunk-Based oder stabiler Branch, Feature Toggles),

• Observability als Teil von „Done“ (Logs/Metriken/Tracing nach Bedarf).

Typische Anti-Patterns (und wie Sie sie vermeiden)

„Scrum-Fall“: Sprints als Mini-Wasserfall

Symptome: Im Sprint wird nur „entwickelt“, Test/Abnahme/Deployment kommen später. Ergebnis: Inkremente sind nicht wirklich nutzbar.

Gegenmaßnahme: DoD schärfen, Abhängigkeiten reduzieren, CI/CD stärken, Stories kleiner schneiden.

Kanban ohne WIP-Limits

Symptome: Alles ist gleichzeitig „in Arbeit“, nichts wird fertig, Prioritäten wechseln täglich.

Gegenmaßnahme: WIP-Limits pro Engpass-Spalte, Pull-Prinzip, klare Expedite-Regel (z. B. max. 1).

Output statt Outcome

Symptome: Viele Tickets, wenig Wirkung. Stakeholder sind unzufrieden, obwohl „viel geliefert“ wird.

Gegenmaßnahme: Ziele messbar machen (z. B. Conversion, Laufzeit, Fehlerrate), Sprint-Ziele/OKRs verbinden, Reviews auf Wirkung ausrichten.

„Kein Platz für Verbesserungen“

Symptome: Retros enden ohne Maßnahmen, Tech Debt wächst, Geschwindigkeit sinkt.

Gegenmaßnahme: Kapazität für Verbesserungen reservieren (z. B. 10–20%), sichtbar im Backlog, Ergebnis im Review zeigen.

Einstieg in 30 Tagen: ein realistisch umsetzbarer Pfad

Woche 1: Transparenz schaffen

• Board aufsetzen (Statusspalten, klare Definitionen, erste WIP-Limits).

• Backlog bereinigen (Duplikate, unklare Tickets, Priorisierung).

• Definition of Done in 5–8 Punkten festlegen.

Woche 2: Lieferfähigkeit stabilisieren

• CI-Checks verpflichtend machen (Build, Tests, Lint).

• Kleine Stories als Standard (Lieferobjekt in wenigen Tagen, nicht Wochen).

• Review-Routine etablieren (Demo am System, Feedback festhalten).

Woche 3: Flow/Planung kalibrieren

• Wenn Scrum: Sprint-Ziel und Kapazität realistisch, Refinement schlank.

• Wenn Kanban: Aging Items analysieren, Engpässe priorisieren.

• Metriken starten (Lead/Cycle Time, Throughput, Defect-Leakage).

Woche 4: System verbessern

• 1–2 Prozessverbesserungen aus der Retro umsetzen (nicht mehr).

• Abhängigkeiten aktiv managen (Schnittstellen, Freigaben, Umgebungen).

• Working Agreements nachschärfen (Expedite-Regel, SLA/SLE, DoR/DoD).

Fazit

Scrum und Kanban sind beides robuste Werkzeuge – wenn Sie sie als System denken: klare Verantwortlichkeiten, gute Backlog-Arbeit, sichtbare Arbeit, messbarer Flow und eine technische Basis, die „Done“ tatsächlich auslieferbar macht. In vielen Organisationen ist ein pragmatischer Scrumban-Ansatz der schnellste Weg zu mehr Planbarkeit und kontinuierlicher Delivery, ohne die Realität von Betrieb und Ad-hoc-Arbeit zu ignorieren.