Scrum oder Kanban – oder beides?
Die Antwort lautet wie so oft: Es kommt darauf an! Sowohl Scrum als auch Kanban sind agile Frameworks. Das Ziel beider Werkzeuge ist es, einen Rahmen zu definieren, in dem Teams möglichst effektiv arbeiten können. Aber es sind eben unterschiedliche Tools, die je nach Kontext, Teamstruktur oder der Art der zu bewältigenden Aufgaben besser oder schlechter geeignet sind. Sie verwenden zum Kochen ja auch einmal Töpfe und das andere Mal Pfannen. Und es gibt sogar Situationen, wo sie beide einsetzen oder beides kombinieren. Aber egal ob Topf oder Pfanne, letztendlich wird das Werkzeug nicht allein entscheidend sein, ob Ihr Essen hinterher lecker schmeckt.
Im Rahmen dieses Artikels zu Kanban vs Scrum möchte ich Ihnen nicht noch einmal vorbeten, was Scrum ist oder wie genau Kanban funktioniert, nein, ich möchte Ihnen die wichtigsten Unterschiede und Gemeinsamkeiten kurz vorstellen. Ihnen Entscheidungshilfen für Ihr Ansinnen mitgeben und auf Kombinationsmöglichkeiten der beiden Werkzeuge hinweisen.
Hauptsache agil
Rund 50 Prozent der deutschen Unternehmen setzen mittlerweile auf agile Methoden. Wie einer Studie der Bitkom Research aus dem September 2019 zu entnehmen ist, setzen ein Großteil der Unternehmen auf Scrum. Die Gründe hierfür sind meist einheitlich. Sie empfinden agile Methoden als schneller, flexibler und somit erfolgreicher. Knapp 40 Prozent der befragten Unternehmen gaben an, dass Ihre Mitarbeiter durch die gesteigerte Verantwortung und Selbstorganisation motivierter wären. Darüber hinaus ermöglichen agile Vorgehensweisen – gemäß der Studie – eine einfachere Zusammenarbeit mit IT-Freiberuflern, die nach wie vor rund ein Viertel der gesamt anfallenden Arbeiten in IT-Projekten übernehmen. Aber nur rund 17 % der Befragten verwenden Kanban. Ich persönlich glaube, dass das Verhältnis Scrum zu Kanban auch auf das Marketing der beiden Varianten zurückzuführen ist. Scrum.org, die Scrum Alliance waren und sind Vorreiter in der Vermarktung von Scrum und haben das Produkt Scrum zu einer hippen Marke werden lassen. Fragen Sie doch einmal in Ihrem beruflichen Umfeld nach, was die Menschen mit „agiler Arbeitsweise“ assoziieren. Ich wette, dass Scrum schneller und häufiger fällt als das Wort Kanban.
Kanban vs Scrum: Wo sich die Methoden gleichen
Beide Frameworks unterstützen agiles Arbeiten und sind per Definition „lean“. Das bedeutet, dass sie sich auf folgende drei Prinzipien des Lean Management stützen:
- Kontinuierliche Verbesserung
- Prozessorientierung und
- Kunden- und Mitarbeiterfokus
Sowohl Kanban als auch Scrum setzen auf einen fortwährenden und erfahrungsbasierten Ansatz der Verbesserung, mit dem Ziel Durchlaufzeiten zu verkürzen und Verschwendung zu minimieren. Dieses Lean-Prinzip basiert auf der traditionellen japanischen Geisteshaltung „Kaizen“ (Kai bedeutet „Veränderung“, Zen heißt übersetzt „zum Guten“). Das bedeutet, dass bei beiden Methoden eine offene Fehlerkultur ein zentrales Element darstellt. Fehler werden nicht als schlecht erachtet, sondern als Startpunkt für Verbesserungen.
Scrum und Kanban setzen bei der Abarbeitung der zu bewältigenden Arbeiten auf das Pull-Prinzip. Grundsätzlich wird bei beiden Methoden davon ausgegangen, dass das Team bestimmt, welche und wie viele Arbeitspakete es in der nächsten Zeit durchführt. Hierfür holt sich das Team selbstständig die Aufgaben aus einem Pool unerledigter Arbeiten. Vergleichen Sie das Prinzip mit einem Drucker. Dieser wird nicht schneller werden, wenn Sie ihn mit mehr Papier füttern.
Wichtig ist an dieser Stelle, dass sich das Team nicht die Aufgaben herauspickt, die ihm am besten gefallen. Ziel sollte es stets sein, die Anforderungen oder Aufgaben mit dem höchstmöglichen Wert für den Kunden priorisiert zu bearbeiten.
Darüber hinaus setzen beide Varianten auf sogenannte WIP („Work in progess“) – Limits. Das bedeutet, dass nur eine bestimmte Anzahl von Arbeitsaufträgen pro Arbeitsabschnitt durchgeführt werden können. Während allerdings in Scrum die Zahl der Arbeitspakete durch die Dauer eines Sprints begrenzt ist, limitiert Kanban die Menge an Arbeitspaketen pro Zustand entlang eines Arbeitsablaufes. Wie in den folgenden beiden Grafiken illustriert, befindet sich beim Zustand „in Arbeit“ ein WIP-Limit von drei (hellbrauner Kreis).
Agile Methoden zeichnen sich durch Ihre Flexibilität aus. Beide Varianten sind nicht nur darauf konditioniert einen Plan exakt einzuhalten, sondern auch Änderungen und Anpassungen im Sinne des Kunden zeitnah vornehmen zu können. Außerdem sind beide Vorgehensweisen bestrebt, den Prozess so zu gestalten, dass es zu schnellen Ergebnissen kommt. Einerseits um den Kunden nahe am Entwicklungsprozess selbst zu halten und andererseits, um zeitnahes Feedback zu erhalten.
Ein weiteres Merkmal agiler Vorgehensweisen ist die Transparenz. Während diese bei Kanban mit der visuellen Darstellung über ein Board erreicht wird, erzeugen kurze Feedbackschleifen, z. B. durch Daily Standup Meetings bei Scrum das gewünschte Ergebnis. Mithilfe der Transparenz gelingt es ebenfalls, Fehler möglichst früh zu erkennen und Stellschrauben im Prozess zu optimieren.
Die wesentlichen Unterschiede der Modelle
Aber selbstverständlich weisen Kanban und Scrum auch Divergenzen auf. So ist Scrum grundsätzlich starrer in seiner Ausprägung als Kanban, da es mehr Regeln beinhaltet und Abläufe detaillierter vorschreibt.
Beginnen wir mit einer zeitlichen Betrachtung. Scrum basiert darauf, dass Iterationen in einem festgelegten Zeitrahmen (sogenannte Timeboxen) erledigt werden. Die Länge der Timeboxen ist zwar initial variierbar, sollte aber über einen längeren Zeitraum konstant bleiben, um eine gewisse Regelmäßigkeit bei den Beteiligten zu etablieren. Denn ein regelmäßiger Rhythmus, bestehend aus Planung, Umsetzung, Auslieferung der erstellten Arbeitsergebnisse und Reflexion der Ergebnisse, schafft Sicherheit. In Kanban finden Sie weder zeitliche Vorgaben noch Timeboxen. Es bleibt also Ihnen überlassen, wann Sie planen, reflektieren, den Prozess verbessern oder ausliefern. Allerdings erweist es sich in der Praxis als nützlich, auch hier einen gewissen Rhythmus zu etablieren.
Die drei Rollen Product Owner, Scrum Master und Entwicklungsteam sind in Scrum fest vorgeschrieben. Kanban sieht hingegen keine bindenden Rollen vor. Allerdings bedeutet dies nicht, dass Sie keine Rollen bei Kanban einsetzen dürfen oder sollen. Es ist sogar notwendig, dass es mindestens eine Person gibt, die die Prinzipien von Kanban verstanden hat und sich für die Einhaltung des Prozesses verantwortlich zeichnet. Gerne wird diese Rolle neuerdings als Flow Master oder Delivery Manager bezeichnet, sie können die Rolle aber auch durch einen Scrum Master, Projektleiter oder ein Produktmanager ausfüllen. Seit 2016 findet man ebenfalls für die Product Owner Rolle äquivalente Bezeichnungen im Kanban Umfeld, diese lauten dann Service Manager oder Product Manager.
Obwohl beide Methoden Veränderungen als die Norm ansehen, gehen Sie doch beide unterschiedlich damit um. Während bei Scrum, die Aufgaben während einer Sprintlänge (1-4 Wochen in der Regel) fix sind, können Änderungen bei Kanban fortlaufend aufgenommen und in der Prozessablauf integriert werden.
Ein weiterer Unterschied findet sich bei der Messung der Produktivität. Bei Scrum schätzt das Team den relativen Aufwand pro Arbeitspaket unter Berücksichtigung der Komplexität und des damit verbundenen Risikos. Dieser Aufwand wird für eine Sprintdauer aufaddiert und ergibt somit eine teamabhängige Geschwindigkeit. Nachdem sich ein Team eingependelt hat, also verlässlich schätzt und ähnliche Durchschnittsgeschwindigkeiten pro Sprint abliefert, wird diese Messgröße für folgende Sprints als Richtwert herangezogen. Allerdings birgt diese Messung auch Gefahren, Teamkonflikte, Krankheiten sowie schlecht beschriebene Anforderungen und daraus resultierende falsche Schätzungen können die Geschwindigkeit stark beeinflussen. In Kanban ist das Schätzen der Abarbeitungsdauer von Arbeitspaketen nicht vorgeschrieben. Die Messung der Produktivität erfolgt in Form einer Zykluszeit („Cycle-Time“). Also der Zeit, die benötigt wird, um ein komplettes Arbeitspaket von Anfang bis Ende abzuschließen.
Scrum + Kanban = Scrumban
Sie kennen nun die wichtigsten Gemeinsamkeiten und Unterschiede von Scrum und Kanban. Vielleicht kam Ihnen beim Lesen ja schon der Gedanke das passendste aus beiden Welten zu kombinieren. Sorry, aber da sind Sie leider nicht der oder die Erste. Unter dem Begriff Scrumban existieren schon seit Mitte dieses Jahrzehnts hybride Modelle, die diesen Ansatz verfolgen.
Das Basiselement von Scrumban stellt eine gewöhnliche Kanbantafel zum Visualisieren der Prozessabläufe dar. Die To-do-Liste des Kanbanboards ist hierbei nach dem Backlog-Prinzip von Scrum geordnet. Das heißt, dass die Einträge mit dem größten Geschäftswert die höchste Priorität besitzen. Im Unterschied zu Scrum gibt es bei Scrumban keine iterativen Sprints. Die Arbeit des Teams erfolgt kontinuierlich unter der Prämisse der Einhaltung der WIP-Grenzen.
Des Weiteren können aus Scrum auch die Rollen in Scrumban übernommen werden. Der Product Owner kümmert sich um die Backlog-Priorisierung, der Scrum Master ist für die Einhaltung des Prozesses notwendig und das Entwicklungsteam für die Umsetzung und Planung. Ebenso ist es sinnvoll Scrum Events wie das Daily-Scrum und die Retrospektive regelmäßig in den Prozess einzubauen. Auch eine wiederkehrende Überprüfung mit den Stakeholdern (Sprint Review) ist in der Regel hilfreich. Die Dauer der einzelnen Zeitfenster und die Frequenz der Treffen sollten im Team abgestimmt werden.
Bleibt die Frage, wann der Einsatz von Scrumban sinnvoll sein kann. In erster Linie bietet sich Scrumban für Arbeitsgruppen an, die regelmäßig und schnell Fehler beheben und kommunizieren müssen. Für derartige Arbeiten ist ein zweiwöchiger Scrum-Zyklus mit anschließendem Reporting zu langwierig und unflexibel.
Ebenfalls interessant kann Scrumban für Teams sein, die stark von Dritten abhängig sind. Oft basieren Vereinbarungen mit Zulieferern oder externen Dienstleistern auf Verträgen, die nicht mit einem internen Sprintzyklus synchronisiert sind. Dies hat zur Folge, dass das Team vielmals nur sehr schwer genaue Abschätzungen treffen kann, bis wann eine Arbeit erledigt ist. Die Erwartungshaltung von Scrum ist aber eine klare und verbindliche Zusage des Entwicklungsteams, was es gedenkt in den nächsten zwei Wochen fertigzustellen. Wie sie sich vorstellen können, ist dies in solch einem Kontext nahezu unmöglich.
Wann Scrum, wann Kanban?
1. Analysieren Sie Ihr Team
Ist Ihre Mannschaft eher weniger flexibel und braucht sie einen klaren Leitfaden mit festgelegten Timeboxen? Sollte Ihr Team Phasen haben, in denen es ungestört arbeiten soll? Dann würde ich zu Scrum raten, da die Aufgaben für zwei Wochen fest fixiert werden und Störungen von außen nicht betrachtet werden sollten.
2. Analysieren Sie Ihr Umfeld und Ihre Abläufe
Teams, die weniger definierte Arbeitsabläufe haben, die Arbeit sequenziell beginnen und beenden und häufig Aufgaben neu priorisieren müssen, um sich ändernden Anforderungen gerecht zu werden, sind mit Kanban besser aufgehoben. Voraussetzung hierfür ist, dass die Aufgaben nicht zu umfangreich sind, da ansonsten ebenfalls eine Neupriorisierung unmöglich wird.
Scrum hingegen eignet sich für Vorhaben mit einer gewissen Planungssicherheit, zumindest einer Sicherheit für die Dauer eines Sprints. Fordert Ihr Kunde eine regelmäßige Einbeziehung, empfehle ich Ihnen ebenfalls Scrum, da er regelmäßig zu jedem Sprintende den realen Fortschritt präsentiert bekommt.
3. Unternehmensstrategie berücksichtigen
Mal schnell Scrum einführen wird nicht funktionieren. Damit sich Scrum in einem Unternehmen etabliert braucht es Zeit und vor allen Dingen auch die Unterstützung und den Willen des Managements in Richtung Selbstorganisation zu marschieren. Wenn die Organisation Agilität aber erst einmal vorsichtig ausprobieren will und keine grundlegenden organisatorischen Veränderungen wünscht, ist ein Einstieg mit Kanban wohl die bessere Strategie.
