Projektmanagement

Kanban vs. Scrum: Finde die beste agile Methode für dich!

Entdecke die Unterschiede zwischen Kanban und Scrum! Mein Guide hilft dir, die richtige Methode für dein Team und deine Projekte zu wählen. Jetzt agil durchstarten!

Was lerne ich hier?

Bedeutung im Projektmanagement: Scrum und Kanban haben beide ihren Platz im agilen PM. Beide sorgen dafür, dass dein Team Projekte schneller und flexibler abwickeln kann – wenn du weißt, wie du die Methoden optimal nutzen kannst!
Die wichtigsten Unterschiede: Scrum ist super für kurze Entwicklungszyklen und strukturiert Projekte mit festen Rollen und Terminen. Kanban ist dagegen entspannter und langfristiger. Trotzdem lassen sich beide Methoden auch sinnvoll kombinieren - es muss nicht immer Kanban vs. Scrum sein!
Die beste Methode für dich: Ziel des Ganzen soll es sein, dass du die beste Methode für dich findest – und zwar abhängig von deinem Team, deiner Branche, deinen Projekten. Egal, ob du nun Scrum, Kanban oder den Hybriden Scrumban nutzt.

Welche Methode ist am besten für dich und dein Team?

Klären wir die wichtigsten Fragen doch gleich vorneweg:

Wann ist Scrum für meine Projekte geeignet?
Wann sollte mein Team lieber auf Kanban setzen?
Wann bietet sich ein Hybrid-Modell an?
Und wann ist keine der beiden Methoden die richtige für mich?

Die ersten Fragen lassen sich relativ einfach beantworten!

Scrum ist für dich geeignet wenn …

… du im Webdesign, Consulting, im Marketing oder der PR, in der Telekommunikation, dem innovativen Bildungssektor, der Medizintechnik oder allgemein mit digitalen Technologien arbeitest,
… dein Team regelmäßig Kundenprojekte durchführt (in Agenturen, in der Softwareentwicklung, etc.),
… dein Team stark kundenzentriert und ergebnisorientiert arbeiten soll,
… dein Team pro Projekt aus nicht mehr als 10 Personen besteht, cross-functional aufgestellt ist und selbstorganisiert arbeiten kann,
… du Teammitglieder hast, die fixe Führungsrollen wie Scrum Master und Product Owner einnehmen können und wollen (mehr dazu unten),
… du nicht an Prozessen, sondern an Ergebnissen arbeiten willst,
… und/oder deine Anforderungen sich häufig ändern (durch Konkurrenz, Veränderungen am Markt, neue Technologien, etc.).

Der Anforderungskatalog von Kanban ist nicht ganz so strikt; die Methode kann fast überall zur Anwendung kommen. Kanban solltest du dir näher anschauen, wenn …

… du eine Möglichkeit suchst, Aufgaben und Tasks effektiver zu verteilen,
… dein Team häufig von zu vielen Aufgaben überlastet ist oder den Überblick über anstehende Tasks verliert,
… deine Projekte groß und kleinteilig sind und viele Unteraufgaben mit sich bringen,
… du Projekte im Team besser und transparenter priorisieren willst,
… du das Zeitmanagement deines Teams verbessern willst, indem du Zeitfresser und Engpässe identifizierst und aus dem Weg räumst,
… du übersichtliche Visualisierungen gut findest und mit dem “Kanban-Board” eine Infozentrale für deine Projekte aufbauen möchtest,
… oder (denn das geht mit Kanban auch) du nicht (nur) kurzfristige Projekte, sondern auch langfristige Prozesse im Service/Support, Sales oder Marketing transparent abbilden willst.

Entdeckst du dich in einer dieser Listen – oder in beiden – wieder, sind du und dein Team Kandidat:innen für einen Kanban- oder Scrum-Testlauf. Das muss dann auch keine Entweder-Oder-Frage sein; denn die beiden Methoden zu kombinieren ist in den meisten Fällen möglich!

Klingt das alles nicht nach euch, ist das kein Beinbruch. Denn Kanban und Scrum sind nun mal nicht für alle Projekte und Teams die richtigen Methoden.

Zum Beispiel lassen sich die folgenden Projekte nicht oder nur schwer mit Kanban oder Scrum abbilden:

Projekte im Bauwesen mit klar festgelegten Abläufen und komplizierten Verfahren
Projekte mit strengen regulatorischen Anforderungen (z.B. im Finanzwesen)
Projekte im Gesundheitswesen, die eine umfassende Dokumentation voraussetzen
Projekte, die nach einem “Status quo” ablaufen, der sich kaum oder gar nicht ändert

So; nachdem wir uns jetzt einen Überblick verschafft haben und wissen, worauf wir uns einlassen, können wir nun ein bisschen tiefer eintauchen:

Kurzzusammenfassung: Was sind Scrum und Kanban?

Scrum und Kanban sind Methoden des agilen Projektmanagements. Das heißt konkret: sie geben Arbeitsweisen und Techniken vor, um komplexe Projekte im Team schneller, besser, flexibler und wettbewerbsfähiger abzuwickeln. Beide Methoden arbeiten dabei nach einer ähnlichen Logik: Sie zerlegen Projekte in überschaubare Einzelschritte und bearbeiten sie in kurzen Arbeitszyklen (“Sprints”).

Teams sollen damit schnell auf Veränderungen reagieren können und früh Ergebnisse produzieren.

Obwohl das Ziel beider Methoden gleich ist, ist es die Herangehensweise nicht (immer). Scrum und Kanban liefern unterschiedliche Werkzeuge und Techniken, eignen sich für unterschiedliche Teamstrukturen, Projekte und Mindsets.

Um die Sache klarer zu machen, hier beide Methoden im Kurzüberblick:

(Wenn du lieber direkt zu den Gemeinsamkeiten und Unterschieden springen willst, klick einfach hier.)

So läuft das Projektmanagement mit Scrum ab

Scrum (engl. für “Gedränge”) wird oft nicht als Methode bezeichnet, sondern als “Framework”. Es gibt also eher einen Rahmen für die gemeinsame Projektarbeit vor; weniger die konkreten Werkzeuge dafür. Der Ablauf eines Scrum-Projekts sieht etwa so aus:

Projektanforderungen und Product Backlog

Startet ein neues Projekt, definiert der “Product Owner” (oder Produktmanager) das Projektziel und legt ein “Product Backlog” an. Das ist ein Katalog, der alle Eigenschaften, Anforderungen und Merkmale des Projektziels enthält. Das könnte zum Beispiel eine Anforderungsliste für ein Softwareprodukt oder eine App sein. Wichtig: Das Backlog ist nicht in Stein gemeißelt; Änderungen können immer einfließen. Das macht Scrum flexibel.

Projektarbeit im “Sprint”

Das Hauptmerkmal von Scrum sind die “Sprints”; kurze Arbeitsphasen von 1 bis 4 Wochen, in denen das Team aktiv am Projekt arbeitet. Für jeden Sprint nimmt sich das Team konkrete Ziele aus dem Product Backlog vor und packt sie ins “Sprint Backlog”. Das Ergebnis des Sprints ist (im besten Fall) ein fertiges Teilprodukt. Ist der Sprint vorbei, tauscht das Team sich aus und startet den nächsten Zyklus, bis das Projektziel steht.

Tägliche Meetings und enge Kommunikation

Scrum-Teams organisieren sich selbst und sind auf den regelmäßigen Austausch angewiesen. Deswegen gibt es täglich einen “Daily Scrum”, um Entwicklungen zu überprüfen oder Probleme zu besprechen. Das Ganze dauert nicht länger als 15 Minuten. Kompakt, informativ und auf das Wichtigste beschränkt. Das sorgt für Fokus auf die wichtigsten Tasks.

Sprint Review und gemeinsame Kontrolle

Am Ende eines Sprints gibt es die Sprint Review. Daran nimmt nicht nur das Team teil, sondern z.B. auch das Management oder Auftraggeber:innen bzw. Kund:innen. Das Team präsentiert die Ergebnisse des Sprints, holt Feedback ein und nimmt alles in die Planung für den nächsten Sprint mit. Dadurch sind Scrum-Teams sehr kundenorientiert, bleiben aber trotzdem flexibel.

Optimierung durch Rückschau

Scrum-Teams überprüfen nicht nur in jedem Sprint die erzielten Ergebnisse. Zum Projektabschluss kommt das gesamte Scrum Team zusammen und bespricht die vergangene Projektarbeit. Was lief gut? Wo gab es Probleme? Welche Prozesse lassen sich für die Zukunft verbessern? Scrum-Teams versuchen, die Zusammenarbeit laufend zu optimieren und geben sich nicht mit einem “Status quo” zufrieden.

Scrum kann ziemlich komplex und als Framework nicht einfach umzusetzen sein. Denn es erfordert ein gewisses Mindset und eine klare Rollenverteilung im Team auf “Scrum Master”, “Product Owner” und “Developer”. Der Prozess an sich ist aber einfach zu verstehen.

Die Scrum-Methode beruht auf kurzen Arbeitszyklen mit klaren Zielen und Rollenverteilungen

Quelle: trusted.de

Scrum ist als Framework vor allem für die Software- und Produktentwicklung interessant. Aber nicht nur; das System lässt sich auf viele Projekte anwenden, die agil an komplexen Projekten arbeiten. Beispiele gefällig?

Software- und App-Entwicklung
IT-Projekte
Webdesign
Consulting
Agiles Marketing, PR und Campaigning
Telekommunikation
Medizintechnik
Entwicklung digitaler Technologien
Entwicklung und Einsatz von Lernmethoden im Bildungssektor
Trainings- und Lerngruppen, Weiterbildungen
uvm.

Wichtig ist, dass Scrum-Teams sich selbst organisieren (können), diszipliniert arbeiten, sich mit dem Projektziel identifizieren und gut miteinander kommunizieren. Ohne diese Voraussetzungen klappt Scrum einfach nicht; egal für welches Projekt.

Wenn du es ganz genau wissen willst, kannst du dir meinen aktuellen Scrum-Guide anschauen. Da gehe ich tiefer auf die Planung und Gestaltung von Sprints und die einzelnen Rollen im Team ein.

Hier noch ein paar der wichtigsten Begriffe im Zusammenhang mit Scrum, bevor wir uns gleich den “Konkurrenten” Kanban genauer anschauen:

Product Backlog

Das Product Backlog ist eine Art Anforderungskatalog: hier werden sämtliche Merkmale, Eigenschaften und Kriterien erfasst, die das fertige Produkt bzw. Projektziel mitbringen soll. Ein Product Backlog ist dabei eine priorisierte Liste, was bedeutet, dass die wichtigsten Merkmale oben stehen und weniger wichtige darunter auftauchen.

Sprint Backlog

Das Sprint Backlog beinhaltet die konkreten To-dos für den kommenden Sprintzyklus und wird durch das Scrum Team im “Sprint Planning” zu Beginn eines Sprints erstellt. Anders als das Product Backlog sind hier also keine Anforderungen definiert, sondern daraus abgeleitete, konkrete Aufgaben. Das Sprint Backlog ist fix - wird also innerhalb eines Sprints nicht mehr verändert.

Sprint

Scrum Teams arbeiten in kurzen Iterationen, den sogenannten Sprints. Dieser Arbeitszyklus dauert zwischen einer und 4 Wochen – meistens sind es 2 – und sollte nicht länger sein, um die Agilität zu garantieren. Am Ende eines Sprints überprüft das Scrum Team in der Sprint Review die erreichten Ergebnisse, stellt die Arbeit Kund:innen und Auftrageber:innen vor und nimmt das gewonnene Feedback mit in die nächste Sprint-Planung.

Product Increment

Das Product Increment ist ein Teilergebnis des eigentlichen Projektziels. Handelt es sich beispielsweise um eine Software, sollte ein Product Increment eine funktionsfähige und vorführbare Teilversion sein. Im Optimalfall kann sogar schon ein Release erfolgen und der Kundenfirma übergeben werden. Ein fertiges Product Increment sollte Ziel jedes einzelnen Sprints sein. Scrum Teams liefern Ergebnisse so schnell es geht - ohne dabei die Qualität zu vernachlässigen.

Scrum Team (Product Owner, Scrum Master, Developer)

Ein Scrum-Team besteht aus bis zu 10 Personen: dem Product Owner (der für der “Produkt”, also das Projektziel zuständig ist), dem Scrum Master (der die Einhaltung der Fristen und Regeln überwacht und eine moderierende Funktion in Meetings hat) und bis zu 8 Developer oder Entwickler:innen, die aktiv am Projekt arbeiten. Viel größer sollte ein Scrum-Team nicht sein, weil sonst die tägliche Kommunikation ein Problem wird.

So funktionieren Projekte mit Kanban

Kanban ist tatsächlich eine “Methode”; das heißt es gibt uns konkrete Werkzeuge an die Hand, um damit zu arbeiten. Das ist in erster Linie das zentrale Kanban-Board. Die Idee ist denkbar einfach: Jede Aufgabe im Projekt wird auf eine Karte geschrieben (jap. “Kanban”), auf ein Board mit verschiedenen Spalten gepackt und je nach aktuellem Status verschoben.

Kanban im Schema: Jede Tafel steht für eine einzelne Aufgabe und wird je nach Status durch die Spalten des Boards bewegt

Quelle: trusted.de

Klassisch sind die Status-Spalten “To do”, “In progress” und “Done”. Aber auch Spalten wie “In Planung”, “Gestoppt”, “Problematisch”, “In Abnahme” und so weiter sind möglich. Da gibt es keine strengen Vorgaben.

So viel zur Theorie; wie läuft das nun in der Praxis?

Planung der Aufgaben

Schritt 1 im Kanban-Modell: Aufgabenplanung. Das Projektziel wird in überschaubare Tasks und Subtasks aufgeteilt. Das macht – ganz klassisch – ein Projektmanager, der auch dafür sorgt, große Aufgaben in kleinere Tasks herunterzubrechen. Jede Aufgabe ist ein Zettel auf dem Board. Das kann ein digitales Board in einer Projektmanagement-Software sein, oder ein Post-it auf einer tatsächlichen Tafel.

Limitierung der Spalten

Kanban-Boards entfalten ihre Power vor allem durch die Begrenzung - klingt komisch, ist aber so! So muss es z.B. für die Spalte “In Progress” eine Obergrenze geben, die von der Teamgröße abhängt. Jedes Teammitglied sollte immer nur an einer einzigen Aufgabe arbeiten und erst, wenn Aufgaben erledigt sind, rutschen neue Tasks aus “To do” nach. Dieses “Pull-Prinzip” sorgt für gleichmäßige Auslastung und vermeidet Überforderung.

Priorisierung von Aufgaben

Ein großer Vorteil von Kanban ist die Möglichkeit zur Priorisierung. Aufgaben können nämlich problemlos kurzerhand in das Kanban-Board übernommen werden. Dafür wird dann halt eine andere Aufgabe kurzzeitig auf Eis gelegt und gestoppt. So können Projektmanager kurzfristig reagieren, ohne dabei die gesamte Planung ändern zu müssen. Kanban-Boards ermöglichen also einen sehr flexiblen Umgang im Aufgaben-Management und sind für Anpassungen und plötzliche Veränderungen wie geschaffen!

Kontrolle und Fortschritt

Kanban-Boards sind offene Bücher: Jedes Teammitglied kann sich selbstständig informieren, den Status aller Aufgaben checken, sehen, welche Aufgaben in Zukunft geplant sind und woran Teammitglieder gerade arbeiten. Statt Status-Meetings und Berichtswesen unterstützt Kanban die Selbstorganisation und spart Teams dadurch eine Menge Zeit. Der Projektfortschritt ist für das gesamte Projekt-Team ersichtlich.

Flexibel bleiben und optimieren!

Kanban-Teams arbeiten agil. Und auch wenn die Methode an sich keine Meeting-Routine vorschreibt, profitieren Kanban-Teams von regelmäßigen Retrospektiven. Ähnlich wie Scrum Teams sollten Kanban-Teams also spätestens zum Projektabschluss Probleme thematisieren, Lösungsvorschläge diskutieren und ihre Erfahrungen austauschen. Fehler macht man bekanntlich ungern zweimal: agile Teams orientieren sich an dieser Maxime!

Du siehst schon: Kanban ist weniger restriktiv, als z.B. Scrum. Das ist auch der Grund dafür, dass Kanban als Methode für viele Projektarten und sogar die Industrie super geeignet ist:

Software- und App-Entwicklung
IT-Operations und Support
Qualitätsmanagement
Marketing- und Vertriebsteams
Marketing und Werbung
Finanzdienstleistungen
Persönliches Zeitmanagement
Produktions und Fertigungs-Industrie
Lagerwirtschaft und Logistik

Wo Kanban und Scrum sich überschneiden

Scrum und Kanban sind beide agil und haben dadurch viele Gemeinsamkeiten. Agiles PM bedeutet z.B. immer: Klare Zielvorgaben, Flexibilität, Fähigkeit zur Veränderung und zur Anpassung an aktuelle Gegebenheiten.

Abgesehen von dieser Grundsatz-Philosophie gibt es einige weitere gemeinsame Merkmale von Scrum und Kanban:

Kurze Arbeitszyklen statt langer Phasen

Statt ausufernder Planung und einer späteren Abschluss-Bewertung versuchen agile Teams die klassischen Projektphasen in jedem Sprint zu durchlaufen. Das hat den Vorteil, dass die Zeiträume überschaubar sind, Anpassungen rechtzeitig wirken können und Korrekturen fast jederzeit möglich sind. Statt später zu sagen “hätten wir es mal so gemacht” können agile Teams schon während des Projektes reagieren.

Weniger Papierkram und Dokumentation

Sowohl Scrum- als auch Kanban-Teams verzichten auf eine allzu ausführliche Dokumentation. Statt Statusberichten nutzen agile Teams kurze, knackige Meetings und dokumentieren nicht alle Schritte akribisch. Das spart Zeit und Ressourcen und lässt agile Teams fokussiert am Projektfortschritt arbeiten.

Selbstorganisation und Eigenverantwortung

Eines der wichtigsten Merkmale agiler Teams und gleichzeitig Gemeinsamkeit von Kanban und Scrum: die Selbstorganisation. Sowohl Scrum als auch Kanban Teams funktionieren nur, wenn alle Beteiligten das richtige Mindset mitbringen. Dazu gehört ein ordentliches Maß an Disziplin, gute Fähigkeiten zur Selbstorganisation und eine hohe Kompetenz in Kommunikation und Teamfähigkeit.

Lean Business

Lean ist nicht nur ein Schlagwort, sondern hat es unter “Lean Management” mittlerweile zu einem eigenen Stand geschafft. Gemeint ist damit eine Fokussierung auf das Wichtige, Vermeidung unnötiger Prozesse und die Ausrichtung auf den Projekterfolg. Agile Teams verzichten auf zeitraubende Prozesse, wenn es direkter und einfacher geht. Trotzdem darf natürlich nie die Qualität der Arbeit darunter leiden. Ein Risiko, das bei beiden Methoden besteht!

Work-in-Progess und Limits

Kanban- und Scrum-Teams limitieren sich. Die einen über klare Grenzen für einzelne Aufgaben-Kategorien, die anderen über das Sprint Backlog. Es bringt nichts, 5 Aufgaben parallel zu bearbeiten, wenn keine davon fertig wird. An diesem Prinzip orientieren sich beide Projektmanagement-Ansätze und ziehen klare Linien, was innerhalb einer bestimmten Zeitspanne erreicht werden soll - und was nicht.

Wo Kanban und Scrum sich unterscheiden

Nun zur eigentlich zentralen Frage: Was sind die Unterschiede zwischen Kanban und Scrum? Wo unterscheiden sich die beiden Methoden und was bedeutet das für dich und deine Projekte? Ein Überblick:

Iteration vs. Kontinuität

Bei Scrum sind Teams darauf fokussiert, in kurzen, abgeschlossenen Zyklen konkrete Projektanforderungen und -ziele umzusetzen. Hier geht es darum, sich auf wesentliche Punkte zu konzentrieren und diese schnellstmöglich umzusetzen, um mit jeder Iteration das “Product” (die Software, die App, etc.) zu erweitern oder zu verbessern.

Kanban ist dagegen auf Langfristigkeit ausgelegt. Der Kanban-Prozess startet nicht alle 2 Wochen neu, sondern läuft von Anfang bis Ende durch. Sein Ziel ist es, nicht möglichst schnell Ergebnisse zu liefern – sondern durch kontinuierliche Arbeit im Kanban-Board Prozesse zu optimieren und “Bottlenecks” zu finden, die den Prozess stören.

Schnelle Releases vs. Produktivität

Scrum Teams arbeiten in kurzen Sprints an einem Product Increment und setzen auf Geschwindigkeit: schnelle Lieferung von echten Ergebnissen, Werten und Produkten. Bei Kanban liegt der Fokus nicht so sehr auf Geschwindigkeit, sondern einer gleichbleibenden Produktivität ohne Engpässe und Leerlaufzeiten.

Scrum ist der Sprinter, Kanban eher Typ ausdauernde Marathonläufer!

Feste Rollen vs. Kein Rollenzwang

Scrum kann nur funktionieren, wenn alle im Team ihre festen Rollen annehmen und alle Rollen verteilt sind:

Der Product Owner hat die Verantwortung über das Produkt/Projektziel
Der Scrum Master hat die Verantwortung über die Prozesse, Fristen und Meetings
Das Team (1 bis 8 Personen) arbeitet aktiv am Projekt

Bei Kanban gibt es keine fixen Rollen und auch keine Notwendigkeit dafür. Das höchste der Gefühle ist hier ein Projektmanager, der das Kanban Board im Auge behält. Und selbst diese Funktion braucht es nicht immer.

Feste Teamgröße vs. Beliebig viele Mitglieder

Scrum-Teams sind naturgemäß auf maximal 10 Personen beschränkt. Mehr als das und die Übersichtlichkeit und die Kommunikation in Meetings leidet.

Kanban hat diese Einschränkung nicht. Die Teamgröße hat nur Auswirkungen darauf, wie viele Tasks gleichzeitig bearbeitet werden können. Das Kanban-Board sorgt auch bei großen Teamgrößen für den nötigen Durchblick – und kann auf der anderen Seite auch Einzelkämpfer:innen helfen, produktiver zu arbeiten.

Fixe Meetingtermine vs. Meetings nach Bedarf

In Scrum ist klar geregelt, wann Meetings stattfinden, wie lange sie dauern und was dort besprochen wird:

Meeting	Termin	Dauer	Inhalt
Daily Scrum	Täglich	max. 15 Minuten	Fortschritt, Probleme
Sprint Review	am Ende des Sprints	1 - 4 Stunden	Ergebnisse des Sprints
Sprint Retrospective	am Ende des Sprints	variabel	Learnings aus dem Sprint, Prozesse

Auch Kanban-Teams sollten sich regelmäßig austauschen; z.B., wenn neue Aufgaben auf das Board kommen oder geplant werden wollen, wenn es irgendwo Probleme gibt, etc. Im Gegensatz zu Scrum ist die Meeting-Struktur in Kanban aber viel flexibler. Außerdem sind Kanban-Boards transparent: Jedes Teammitglied kann sich in kürzester Zeit selbst einen Überblick über anstehende Aufgaben und deren Status geben.

Methode vs. Framework

Ich habe es ja weiter oben schon 1-2 mal angerissen: Kanban ist eine Methode, Scrum ein Framework. Doch was heißt das eigentlich?

Nun, eine Methode ist eine klar beschriebene Vorgehensweise oder besser gesagt Technik. Im Fall von Kanban ist damit die Nutzung eines Kanban-Boards mit einzelnen Aufgabenkarten gemeint. Kanban ist also eine konkrete Praktik, bei der gilt: “tue a, dann b, dann c”.

Ganz so einfach ist es mit Scrum nicht, weil es keine Technik, sondern ein komplexes Rahmenwerk ist. Scrum gibt zwar definierte Rollen und auch einige Techniken vor, also beispielsweise die Meetingroutine mit Daily Scrums, das Sprint Planning, die Nutzung eines Product Backlogs usw. usf. Aber innerhalb dieses Rahmens sind Scrum Teams frei und können selbst entscheiden, wie sie mit einzelnen Aufgaben und Prozessen umgehen.

Das heißt: Es ist jederzeit möglich, Scrum als Projektrahmen und Kanban als konkrete Projektmethode zu nutzen und somit beides zu machen.

Komplexe Projekte vs. “Was gerade ansteht”

Scrum eignet sich für die Organisation komplexer Projekte in dynamischen Märkten und Branchen. Für Kanban spielt der Inhalt von Projekten keine besonders große Rolle. Das zeigt schon die Geschichte: ursprünglich kam Kanban in Toyota-Fabriken in der Auslastungssteuerung der Produktion zum Einsatz - heute ist Kanban in so ziemlich allen Branchen anzutreffen.

Aufwand vs. Quantität

Ein wichtiges Kriterium in der Arbeit von Scrum Teams ist die Aufwandsschätzung. Logisch, wenn ein Sprint 2 Wochen dauert, muss das Team wissen, was es an Anforderungen in dieser Zeit umsetzen kann. Eine realistische Aufwandschätzung spielt also eine entscheidende Rolle. Im Gegensatz dazu liefert ein Kanban Board keine qualitativen Angaben zum Arbeitsaufwand oder Umfang einer Aufgabe.

Auch hier finden wir also wieder den Unterschied zwischen Geschwindigkeit (Scrum) und Produktivität (Kanban).

Sprint Planning vs. kurzfristige Änderungen

Scrum Teams planen jeden Sprint vor und nehmen während der Sprint-Phase üblicherweise keine Änderungen vor. Eine Stärke von Kanban Boards: Teams sind hier freier. Wenn neue Aufgaben reinsegeln oder sich die Priorität eines Tasks ändert, ist das kein Problem. Dann werden gestartete Aufgaben niedriger Wichtigkeit kurzerhand gestoppt und dafür eben die dringlichen Dinge erledigt.

Das bedeutet nicht, dass Scrum Teams nicht flexibel wären - nur steht mit der Sprint Planung eine feste Agenda, die auch abgearbeitet wird.

Scrumban: The best of both worlds

Trotz dieser Unterschiede zwischen den beiden Methoden lassen sie sich trotzdem gut kombinieren. Das Ergebnis heißt dann “Scrumban”.

“Aha”, wirst du jetzt sagen, “es gibt sie also doch, die eierlegende Wollmilchsau.” Und tatsächlich könnte man das so sehen. Scrumban vereint – wie der Name vermuten lässt – die Vorteile von Kanban und Scrum zu einem Hybridmodell. Gleichzeitig sollen die Nachteile ausgeglichen werden.

Aus Scrum übernimmt der Hybrid …

… den Projektaufbau in Sprints und deren Zyklen,
… die klar definierten Ziele und die Aufwandsschätzung im Team,
… die fixe Meetingroutine und die Daily Scrums.

Aus Kanban kommen dann noch hinzu:

Das flexible Aufgabenmanagement im zentralen Kanban-Board,
Die “Work-in-Progress”-Methode und die hohe Produktivität.

Und so sieht dann der Projektablauf mit Scrumban aus:

Sprint-Planung mit Triggerfunktion

Scrumban-Teams sind in der Sprint-Planung flexibler als reine Scrum-Teams. Statt zu sagen “ein Sprint dauert 2 Wochen” nutzt das Team klare Leistungsindikatoren, um den nächsten Sprint zu planen. So ein Planungsauslöser oder “Trigger” kann beispielsweise der verbliebende Umfang des Product Backlogs sein oder die noch zu erledigenden Aufgaben im aktuellen Sprint Backlog. Heißt: Ist so und so viel erledigt, startet die Planung für den nächsten Sprint bzw. die Planung der nächsten Tasks. Ist also absehbar, dass das Team früher fertig wird, kann auch der nächste Sprint samt Planung vorgezogen werden.

Kanban-Board und WIP-Limits

Die Arbeit wird dann über ein klassisches Kanban-Board erledigt. Teammitglieder ziehen und verschieben hier selbstständig Aufgaben durch die jeweiligen Status-Spalten. Außerdem gibt es (wie im Work-in-Progress-Prinzip) üblich, Limits für aktive Aufgaben. Wie bei Kanban gilt also: Alle im Team arbeiten immer nur an jeweils einer Aufgabe parallel.

Arbeitssperre und Triage

Scrum-Teams haben häufig ein Problem: sie werden nicht fertig, weil es im Grunde immer noch Verbesserungspotenzial gibt oder Kund:innen ständig neue Anforderungen formulieren. Scrumban-Teams haben ein radikales Mittel gegen diesen “Optimierungswahn”. In der Endphase eines Sprints oder Projektes wird eine Arbeitssperre verhängt: neue Anforderungen gelangen ab jetzt nicht mehr in das Product Backlog. Die noch übrigen Aufgaben werden dann je nach Wichtigkeit oder Dringlichkeit selektiert (“Triage”). Eine Arbeitssperre kann auch verhängt werden, wenn du als Projektmanager merkst, dass dein Team mit den gesetzten Zielen nicht fertig wird und sich nun auf die wirklich wichtigen Tasks konzentrieren sollte.

Planning Buckets

Scrumban-Teams planen nicht nur einzelne Projekte und Sprints, sondern haben auch eine Methode gefunden, eine langfristige Planung miteinzubeziehen. Das funktioniert über sogenannte “Planning Buckets” im Kanban-Style: in der ersten Spalte stehen übergeordnete Ziele und Ideen, die das Team im gesamten Jahr erreichen möchte (z.B. Umsatzsteigerung um 15 %). In der zweiten Spalte stehen dann die Ziele für das Halbjahr (3 Projekte mit Umsatzsteigerung von 7%). In der letzten Spalte stehen dann konkrete Angaben für einen Zeitraum von 3 Monaten.

Damit versucht Scrumban die Nachteile von Kanban auszugleichen: statt fehlender Zeitplanung erfolgt die Arbeit also in eng gestaffelten Sprints mit klaren Zielen und Anforderungen inklusive Aufwandsschätzung. Gleichzeitig muss die Planung nicht nur für ein Projekt erfolgen (wie in Scrum), sondern kann mit einer Jahresplanung einen großen Rahmen setzen.

Ursprünglich entwickelt, um Teams den Übergang zwischen Scrum und Kanban zu erleichtern, ist Scrumban mittlerweile etabliert. Wieso nicht dabei bleiben, wenn es gut funktioniert?

Allerdings gilt hier das gleiche wie für alle agilen Methoden - die Umsetzung verlangt von allen Beteiligten ein passendes Mindset, einen sehr hohen Kommunikationsaufwand und Eigenverantwortung.

Weitere agile Methoden und für wen sie geeignet sind

Neben Scrum, Kanban und Scrumban gibt es eine ganze Reihe weiterer agiler Ansätze und Methoden. Einige davon sind nur für klar beschriebene Anwendungsbereiche, etwa das Produktdesign, geeignet. Andere, wie die Crystal Family sind deutlich breiter aufgestellt und für viele Teams eine Option.

Wenn du also nach meinem Beitrag denkst: “Ich will agil arbeiten, aber mir gefällt weder Scrum noch Kanban” dann findest du hier ein paar Alternativen. Ach, und wenn du es noch genauer wissen willst: In meinem ausführlichen Guide zum Thema “Agiles Projektmanagement” widme ich mich jeder Methode ein wenig ausführlicher:

Design Thinking (Produktentwicklung, Neue Technologien)

Design Thinking ist ein spezielles Verfahren, das vor allem für die Entwicklung von Produkten und Technologien zur Anwendung kommt. Ähnlich wie Scrum arbeitet das Team in einem iterativen Prozess - allerdings nochmal deutlich komprimierter und durchgetakteter, mit 5 verschiedenen Entwicklungsphasen. Im Vordergrund steht die Entwicklung von echter Innovation, nah am Kundenbedürfnis.

Design Sprint (Design Thinking + Scrum)

Der Design Sprint ist im Grunde eine Kombination von Elementen aus dem Design Thinking und Scrum: Die einzelnen Entwicklungsphasen des Design Thinkings werden innerhalb eines Sprints von einer Woche durchlaufen. Das soll die Entwicklungszeit nochmal verkürzen und dadurch Kosten sparen.

Extreme Programming (Software-Entwicklung, Programmierung)

Wie der Name schon verrät, dreht sich bei Extreme Programming alles um die Software-Entwicklung. Ziel sind schnelle Releases und eine kurze Entwicklungszeit. Hierfür arbeiten Programmierer immer zu zweit nach dem 4-Augen-Prinzip: einer codet, der andere kontrolliert die geschriebenen Zeilen. So sollen die Kosten und Zeitaufwände niedrig gehalten werden.

Lean Start-up (Innovationen, Produktentwicklung, Firmengründung)

Lean Start-up ist eine agile Methode, die speziell in der Entwicklung von Produkten und neuen Unternehmen (Start-ups) zum Einsatz kommt. Durch kurze Entwicklungszyklen, Produkttests und Kundenbefragungen können Teams und Unternehmen früh erkennen, ob sich bestimmte Technologien lohnen und marktreif sind. So lassen sich unnötige Investments und Risiken vermeiden.

DSDM (Breites Anwendungsgebiet, Große Teams)

Keine neue Casting-Show, sondern “Dynamic System Development Method”. DSDM beruht auf 8 Prinzipien, mit denen Teams unter hohem Zeitdruck und begrenztem Budget dennoch konkurrenzfähige Produkte und Technologien entwickeln können. Trotz Ähnlichkeiten zu Scrum und Co. ist DSDM für ein breiteres Anwendungsgebiet ausgelegt und eignet sich auch für größere Teams.

Crystal Family (Grundsätzliche Projektarbeit)

Eigentlich keine klar abgegrenzte Methode, sondern eine ganze Sammlung (“Familie”) an agilen und halbagilen Methoden und Ansätzen. Mit den 4 Grundsätzen “Prioritäten”, “Kommunikation”, “Optimierung” und “Automatisierte Tests” gibt Crystal keine klaren Prozesse oder Schritte vor, sondern richtet sich in erster Linie an die generelle Arbeitsweise eines Projektteams.

Änderungshistorie

21.05.2024

Kanban vs. Scrum - Ratgeber

trusted hat den großen Kanban vs. Scrum-Ratgeber erstellt. Unser Redakteur Phillip zeigt dir hier alles, was du zum Thema wissen musst! Du hast Fragen oder hast Fehler oder Missverständnisse entdeckt? Dann melde dich doch direkt bei uns unter [email protected]!

Phillip Roth

trusted-Experte für Projekte & Kommunikation