Agile vs Kanban
Was ist Agile, was ist Kanban?
Agile ist ein Überbegriff für iterative Entwicklungsmethoden, die auf kurze Zyklen, regelmäßiges Feedback und Anpassungsfähigkeit setzen. Das bekannteste Agile-Framework ist Scrum, das Arbeit in feste Zeitblöcke (Sprints) von typischerweise zwei Wochen gliedert. Am Ende jedes Sprints steht ein potenziell auslieferbares Produktinkrement.
Kanban stammt ursprünglich aus der japanischen Fertigungsindustrie (Toyota) und fokussiert sich auf den kontinuierlichen Fluss von Arbeit. Statt fester Sprints gibt es ein Board mit Spalten (z.B. Backlog, In Progress, Review, Done) und Work-in-Progress-Limits (WIP-Limits), die verhindern, dass zu viele Aufgaben gleichzeitig bearbeitet werden. Neue Arbeit wird gezogen (Pull-Prinzip), sobald Kapazität frei wird.
Warum ist das wichtig?
Die Wahl der richtigen Arbeitsmethodik beeinflusst direkt die Produktivität, Qualität und Zufriedenheit des Teams. Eine falsche Methodik kann ebenso schaden wie gar keine Methodik -- etwa wenn ein kleines Team die Overhead-Last von vollständigem Scrum mit Sprint Planning, Daily Standup, Sprint Review und Retrospektive trägt, obwohl vier Personen informell effizienter arbeiten könnten.
Scrum eignet sich besonders gut für Produktentwicklung mit klar definierbaren Features, bei der das Team vorab planen kann, was in den nächsten zwei Wochen umgesetzt wird. Die festen Sprints erzwingen Priorisierung und schaffen einen verlässlichen Rhythmus für Stakeholder -- sie wissen, wann sie mit Ergebnissen rechnen können und wann Feedback gefragt ist.
Kanban passt besser zu Teams mit variablem Arbeitsaufkommen -- etwa Support-Teams, DevOps-Teams oder Wartungsteams, die auf eingehende Anfragen reagieren müssen. Auch für Teams, die bereits gut funktionieren und primär den Durchsatz optimieren wollen, ist Kanban oft die bessere Wahl. Die WIP-Limits verhindern Multitasking, das nachweislich Kontextwechsel-Kosten von 20-40% verursacht.
In der Praxis nutzen viele erfolgreiche Teams eine Kombination: "Scrumban" übernimmt die Planungsstruktur von Scrum (regelmäßige Planungsmeetings, Retrospektiven) und kombiniert sie mit dem kontinuierlichen Fluss und den WIP-Limits von Kanban. Es gibt keinen ideologischen Zwang, sich für eines der beiden Frameworks entscheiden zu müssen.
Agile und Kanban in der Praxis
Scrum-Beispiel: Ein Produktteam plant alle zwei Wochen einen Sprint. Im Sprint Planning werden User Stories geschätzt und committet. Das Team arbeitet fokussiert auf das Sprint-Ziel hin, und am Ende demonstriert es die Ergebnisse den Stakeholdern. Die Retrospektive identifiziert Verbesserungspotenziale für den nächsten Sprint. Dieser Rhythmus gibt dem Team Struktur und den Stakeholdern Planbarkeit.
Kanban-Beispiel: Ein Development-as-a-Service-Team betreut mehrere Kundenprojekte parallel. Ein Kanban-Board visualisiert alle Aufgaben, WIP-Limits von drei pro Spalte verhindern Überlastung. Wenn ein Entwickler eine Aufgabe abschließt, zieht er die nächste priorisierte Aufgabe. Die Durchlaufzeit (Cycle Time) -- wie lange eine Aufgabe von Start bis Fertigstellung braucht -- wird als Kernmetrik getrackt und kontinuierlich optimiert.
Metriken, die zählen: Unabhängig vom Framework sind bestimmte Metriken entscheidend. Die Velocity (Scrum) oder der Throughput (Kanban) zeigt, wie viel das Team in einer Periode schafft. Die Cycle Time zeigt, wie schnell eine einzelne Aufgabe durchläuft. Der Cumulative Flow zeigt Engpässe im Prozess. Diese Daten ersetzen Bauchgefühl durch faktenbasierte Entscheidungen.
Ein häufiger Fehler ist "Cargo-Cult Agile" -- die mechanische Übernahme von Ritualen ohne Verständnis der zugrundeliegenden Prinzipien. Tägliche Standups, in denen Statusberichte an den Manager gegeben werden, sind kein Agile. Retrospektiven, deren Ergebnisse nie umgesetzt werden, sind Zeitverschwendung. Die Methodik ist Mittel zum Zweck, nicht der Zweck selbst.
Verwandte Konzepte
- Code Review -- Qualitätssicherung als Teil des agilen Workflows
- CI/CD Pipeline -- Technische Grundlage für iterative Auslieferung
- Development as a Service -- Flexibles Entwicklungsmodell auf Kanban-Basis
- CTO-Guide: Kapazität skalieren -- Wie Agile-Methoden beim Skalieren helfen
- Development Subscription Modell -- Wie Kanban und Subscriptions zusammenpassen