Kanban vs Scrum: Definitionen, Framework und Rollen

Kanban oder Scrum?

Agile, Lean, Scrum und Kanban: Alle diese Begriffe beschreiben recht ähnliche Ansätze für Projektmanagement-Methoden und werden oft synonym verwendet.

Scrum-Zeremonien werden manchmal als „Agile-Zeremonien“ bezeichnet und Kanban Boards werden mitunter für Scrum verwendet, daher kann es zu Beginn schwierig sein, die methodischen Begriffe von Kanban und Scrum auseinanderzuhalten.

Wir, das Team von Digital Leadership, möchten Sie daher in diesem Artikel durch die Techniken von Kanban und Scrum führen und die wichtigsten Informationen vermitteln. Sie werden die Rollen der Techniken außerhalb der Softwareentwicklung kennenlernen, ebenso wie den Agile-Prozess und seine Bedeutung für Projektmanager. Darüber hinaus erfahren Sie, wie Sie die beste Technik für eine dauerhafte Verbesserung in Ihrem Unternehmen auswählen und zugleich immer das Kundenfeedback einbeziehen.

Kanban vs Scrum: Definitionen

Was ist Kanban?

Kanban wurde ursprünglich vom Japaner Taiichi Ōno, einem Wirtschaftsingenieur bei Toyota entwickelt, um einen effizienteren Produktionsprozess zu schaffen. Im Jahr 2010 zeigte David J. Anderson in seinem Buch „Kanban: Evolutionäres Change Management für IT-Organisationen“, wie man die Kanban-Methode auch auf die Softwareentwicklung anwenden kann.

Kanban funktioniert ähnlich wie ein Fließband: Einzelne Aufgaben werden auf einem Kanban Board dargestellt – eine tafelähnliche Ansicht mit Spalten. Die Aufgaben werden dann durch die verschiedenen Spalten bewegt, bis sie vollständig sind. Sowohl Kanban als auch Scrum haben einen Backlog priorisierter Aufgaben. Anstatt die Arbeit in Sprints aufzuteilen, wählen Kanban-Teams jedoch immer die Aufgabe im Backlog, die die höchste Priorität hat.

Kanban Board

Die Hauptfunktion der Kanban-Methode ist das Kanban Board. Ähnliche wie bei einem Herstellungsprozess, bei dem Produkte auf einem Fließband aus Einzelteilen hergestellt werden, durchlaufen Kanban Tasks eine Reihe von Spalten, bis sie vollständig sind.

Ein Beispiel des Workflows eines Kanban Board:

Jede Aufgabe in Ihrem Backlog erfordert Entwicklung im Backend, dann Entwicklung im Frontend und das Testing. Abschließend folgt der Release.

Auf Ihrem Kanban Board finden sich alle Aufgaben, die dann von einer Spalte zur nächsten bewegt werden, bis alle Schritte vollständig sind.

Work in Progress Limit

Eine weitere wichtige Funktion von Kanban ist das Work in Progress (WIP) Limit. So kann es zum Beispiel sein, dass Ihr Backend-Team viel schneller arbeitet als das Frontend-Team. Das würde dazu führen, dass das Frontend-Team mit vielen offenen Tasks dastehen würde, während das Backend-Team nichts mehr zu tun hat.

Die WIP-Limits begrenzen die Anzahl der Tasks, die sich gleichzeitig in einer Spalte befinden dürfen. Wenn das WIP-Limit eines Teams erreicht ist, ist das ein Signal, dass das Team vielleicht überlastet ist.

In diesen Fällen können andere Mitglieder des Teams helfen, die Anzahl der offenen Tasks zu reduzieren. Trotzdem ist das Erreichen des WIP-Limits gewöhnlich ein Zeichen dafür, dass die Arbeit im Team nicht gleichmäßig verteilt ist.

Wenn wir an unser Beispiel zurückdenken, könnte die Lösung wie folgt aussehen: Ausstatten des kreuzfunktionalen Teams mit mehr Frontend- und weniger Backend-Entwicklern, um einen gleichmäßigeren Arbeitsfluss zu erreichen.

Auch wenn Kanban die Scrum-spezifischen rückblickenden Zeremonien fehlen, folgt Kanban doch dem Grundprinzip der kontinuierlichen Verbesserung.

Teams müssen mithilfe der Kanban Boards schrittweise nach Möglichkeiten zur Verbesserung der Workflows, zum Beseitigen von Blockaden und Optimieren ihrer Prozesse suchen.

Was ist Scrum?

Scrum ist eine Agile-Methodik, die dazu verwendet wird, Tasks in kleinere und leichter erreichbare Aufgaben aufzuspalten, die innerhalb einer kurzen Zeit erreicht werden können (gewöhnlich zwei bis vier Wochen). Zur Planung und Ausführung dieses Prozesses stützt sich Scrum auf drei bestimmte Rollen:

1. Product Owner
2. Scrum Master
3. Teammitglieder

Weiterführender Artikel: Scrum – die bessere Methode zur Produktentwicklung

Das Agile-Projektmanagement befürwortet ein kollaboratives, schrittweises Vorgehen bei der Softwareentwicklung. Scrum ist eine Methodik, die häufig verwendet wird, um eine Agile-Philosophie praktisch umzusetzen.

Der Scrum-Ansatz stellt Frameworks bereit, die Project Sponsors und Softwareentwickler zur Zusammenarbeit nutzen können, während sie Agile-Prinzipien folgen. Scrum wurde von Ken Schwaber und Jeff Sutherland entwickelt, die beide Mitglieder der Agile Alliance waren.

Scrum-Tools (etwa das Scrum Board) helfen Teams, einen Agile-Ansatz zu verfolgen, während zugleich sichergestellt wird, dass alle Teammitglieder in einem gleichmäßigen Tempo arbeiten. Ein Scrum Board kann Aufschluss geben, ob das Ergebnis dem entspricht, was die Projektsponsoren vorgeben, und kann zudem dafür sorgen, dass sich das Scrum-Team während des Projektes verbessert.

Werfen wir nun einen genaueren Blick auf die drei Hauptrollen in Scrum-Teams:

Product Owner

Der Product Owner repräsentiert alle Stakeholder des Projektes. Er ist während des gesamten Entwicklungsprozesses verfügbar, um Fragen zu beantworten, vollständige Tasks zu prüfen und die Anforderungen zu priorisieren.

Eine Einbindung des Product Owner in den Entwicklungsprozess hilft dem Team, die Vorgaben des Agile-Ansatzes für eine effektive Zusammenarbeit einzuhalten.

Scrum Master

Der Scrum Master leitet das Entwicklungsteam. Er stellt sicher, dass sich jeder auf seine Arbeit konzentrieren kann und führt Scrum Meetings durch.

Ähnlich wie ein Projektmanager leitet ein Scrum Master die Scrum-Teams und stellt so einen reibungslosen Ablauf des Workflows sicher. Zugleich achtet er darauf, dass die Scrum-Prozesse und Rollen eingehalten werden.

Entwicklungsteam

Ein Entwicklungsteam ist eine Gruppe aus drei bis neun Entwicklern, die für alle Tasks zuständig ist, die vom Produkt Owner festgelegt und priorisiert werden. Das Team arbeitet mit einem priorisierten Product Backlog (Liste aller Projektvorgaben), die aus User Stories bestehen.

User Stories erläutern nicht, was zu tun ist, sondern beschreiben aus Sicht der Nutzer, welche Anforderungen an das Produkt gestellt werden.

Die User Stories folgen immer einem bestimmten Format: [Wer] möchte [was] und [warum] ist das wichtig?

Während des Entwicklungsprozesses wird die Arbeit in Schritten (genannt: Sprints) ausgeführt. Diese Sprints dauern zwischen einer Woche und einem Monat. Während dieser Zeiträume konzentriert sich das Scrum-Team auf bestimmte, geplante Aufgaben. Das Scrum Board zeigt währenddessen den Stand des aktuellen Sprints.

Diese Tasks werden im Planning umrissen, in dem die Teams die Tasks für die User Stories ermitteln und planen, welche davon voraussichtlich während des Sprints abgeschlossen werden können.

Während des Sprints führen die Scrum-Teams täglich Scrum Meetings durch, in denen jedes Teammitglied die folgenden drei Fragen beantworten muss:

1. Woran haben Sie gestern gearbeitet?
2. Woran werden Sie heute arbeiten?
3. Gibt es irgendwelche Probleme, die Sie daran hindern, Ihre Tasks abzuschließen?

Weiterführender Artikel: Scrum – die bessere Methode zur Produktentwicklung

Am Ende jedes Sprints führt das Team zwei Meetings durch. Das erste ist der Sprint Review, bei dem das Team alle während des Sprints abgeschlossenen Tasks dem Product Owner zur Genehmigung vorlegt.

Das zweite Meeting ist der Sprint Retrospective, bei dem das Scrum-Team den Planungsprozess analysiert, um zukünftige Sprints zu verbessern.

Zu diesem Zweck beantwortet jedes Teammitglied die folgenden drei Fragen:

1. Was hat in diesem Sprint gut funktioniert?
2. Was hätte besser laufen können?
3. Was sollten wir beim nächsten Sprint anders machen?

Kanban oder Scrum: Framework

Kanban vs. Scrum: Rollen

Framework	Scrum	Kanban
Servant Leadership	Scrum Master (zu Anfang)	Keine Rollen erforderlich
Product Responsibility	Product Owner	Existierende Rollen werden übernommen
Teams	3 bis 9 Teammitglieder, kollaborativ	Keine feste Anzahl an Teammitgliedern, kreuzfunktional oder spezialisiert

Kanban Vs Scrum: Meetings

Framework	Scrum	Kanban
Timebox	Daily Standup Meetings	Keine Richtlinien
Exchange	Team Retrospective	Keine Richtlinien
Steering (Kunde & Stakeholder)	Review Meeting nach jedem Sprint	Keine Richtlinien
Team Forecast	Vor jedem Sprint	Keine Richtlinien, aber regelmäßige Meetings sind erforderlich

Kanban vs. Scrum: Artefakte

Framework	Scrum	Kanban
Liste mit Anforderungen	Product-Backlog	Backlog
Supply cycle	Sprint	Hängt von der Turnaround-Zeit ab
Board	Sprint Backlog, Scrum Board ist optional	Kanban Board (dauerhaft: wird erst gelöscht, wenn das Projekt vorbei ist)
Delivery	Potenziell lieferbares Produktinkrement	Verarbeitete Tickets
Metrics	Velocity	Lead-Time, Cycle-Time, WIP

Was bedeutet Agility?

Im Vergleich mit Scrum und Kanban sind Agile-Frameworks eher eine Philosophie als eine Methodik zum Managen von Prozessen.

Der Begriff „Agile“ wurde zum ersten Mal 2011 von der „Agile Alliance“, einer Gruppe von 17 Softwareentwicklern, geprägt. Innerhalb von nur zwei Tagen verfassten die Entwickler das „Agile Manifesto“ („das Agile-Maifest“), eine Sammlung von Prinzipien, die ein stetiges Voranschreiten sowie eine Zusammenarbeit bei der Prozessdokumentation und Vertragsverhandlungen fördern sollten.

Vor der Veröffentlichung des Agile Manifesto wurde bei den meisten Softwareentwicklungsprojekten nach dem sogenannten Wasserfallmodell vorgegangen. Bei dieser Methode müssen alle Anforderungen für Projekte festgelegt sein, bevor die Entwicklung beginnt.

Zugleich verpflichten sich die Entwicklerteams beim Wasserfallmodell, eine bestimmte Anzahl an Task innerhalb einer bestimmten Zeitspanne zu erledigen. Feedback von Sponsoren und die Änderung von Prioritäten werden unbeachtet gelassen. Das Wasserfallmodell brachte jedoch verschiedene Probleme mit sich:

Wenn während des Entwicklungsprozesses Schwierigkeiten auftraten, konnten diese nur schwer gelöst werden, da das ganze Team sich von vorneherein auf ein bestimmtes Arbeitspensum festgelegt hatte.

Zudem ist es so, dass die Teammitglieder während des Projektes nur sehr wenig Rückmeldung von den Project Sponsors erhalten, da die Projektanforderungen im Vorhinein festgelegt sind. Das liegt daran, dass das Entwicklungsteam in einem Silo arbeitet, sodass die Project Sponsors kein Deliverable zu Gesicht bekommen, bis der Entwicklungsprozess abgeschlossen ist. Das wiederum kann dazu führen, dass die Project Sponsors nicht mit dem Endprodukt nicht zufrieden sind.

Als Antwort auf diese Probleme führte die Agile Alliance einen neuen, besseren Entwicklungsansatz ein, bei dem die Teams während des Entwicklungsprozesses mit den Project Sponsors zusammenarbeiten. Dabei sammeln die Teams Anforderungen und programmieren iterativ, was zu einem stetigen Arbeitsfluss und ständigem Feedback führt. Der Business-Value wird durch die gute und häufige Kommunikation mit den Sponsors erhöht.

Die Agile-Methode ermöglicht es den Entwicklern, jedes Problem, das während der Entwicklung auftaucht, zu lösen. Zugleich erhalten die Sponsors damit einen Überblick über das gesamte Projekt und können Bedenken äußern, bevor es zu spät ist.

Scrum und Kanban außerhalb der Softwareentwicklung

Auch wenn Scrum und Kanban ihre Wurzeln in der Softwareentwicklung haben, können die Ideen und Frameworks beider Methoden in vielen verschiedenen Bereichen angewendet werden.

So eignen sich Kanban-Teams auch sehr gut für das Content-Marketing. Die meisten Workflows im Content-Marketing beginnen mit einem Backlog an Ideen (dem Redaktionskalender), der von einem Content-Marketing-Manager geplant wurde.

Von dort aus gehen die Ideen vermutlich an einen SEO-Spezialisten, dann an einen Content-Writer, einen Redakteur und dann einen Designer, bevor sie schließlich veröffentlicht werden.

Kanban kann auch für Personalteams während einer Einstellungsphase genutzt werden, wenn verschiedene Teammitglieder zu bestimmten Zeiten unterschiedliche Aufgaben erledigen müssen (einige von der Abteilung, andere vom Manager). Die Kanban-Methodik vereinfacht die Zusammenarbeit während des gesamten Prozesses erheblich.

Scrum ist ebenfalls in vielen Bereichen nutzbar, zum Beispiel für ein Designteam, das an der Neugestaltung einer Website arbeitet. Dazu ein Beispiel: Stellen Sie sich vor, dass Sie binnen sechs Monaten eine neue Website erstellen wollen. Für ein solches Projekt sind zahlreiche Aufgaben zu erledigen, zum Beispiel das Aktualisieren:

• von Elementen, etwa der Navigationsbuttons, anderer Buttons und der CTA-Banner
• der in den einzelnen Blogeinträgen und auf den Landingpages verwendeten Bilder
• des Layouts aller Landingpages
• des Styleguides des Unternehmens mit den neuen Richtlinien

Wegen des vermutlich knappen Zeitrahmens und der Zusammenarbeit des Designteams mit anderen Teams, wie dem Entwicklungsteam, dem Vertriebsteam, dem Produktteam und dem Marketingteam, ist Scrum möglicherweise die optimale Lösung zum Managen eines solchen Projektes.

Weiterführender Artikel: Scrum – die bessere Methode zur Produktentwicklung

Für die meisten großen und komplexen Projekte (unabhängig vom Umfang der Arbeit) ist die klare Struktur von Scrum oft von Vorteil. Für Workflows, die von Input oder der Bearbeitung durch mehrere Personen abhängen, sind Kanban-Teams am besten geeignet.

Kanban oder Scrum für das Projektmanagement: Was ist die beste Wahl für Ihr Unternehmen?

Sowohl für Kanban als auch Scrum sind inzwischen viele Tools verfügbar. Die Tools haben dabei ganz unterschiedliche Prioritäten und Fortschrittsbegrenzungen.

Einige davon wurden speziell für Scrum entwickelt und bieten daher viele Funktionen für Scrum-spezifische Zeremonien, etwa das Sprint Planning, und verwenden Scrum-Begriffe wie „User-Stories“ und „Sprints“.

Scrum-spezifische Tools funktionieren gewöhnlich gut, wenn Ihr Team nur nach der Scrum-Methode arbeitet. Wenn Sie jedoch Scrum und Kanban zugleich nutzen wollen, können die Scrum-Tools schnell an Effektivität verlieren und schwieriger zu nutzen sein.

Kanban-Tools bieten Teams, die mit beiden Methoden arbeiten wollen, mehr Flexibilität, was jedoch von den einzelnen Task-Vorgaben abhängt.

Natürlich sind Kanban-Tools speziell für Kanban entwickelt und daher optimal für seine Methoden geeignet. Zugleich eignen sie sich aber auch für Scrum, daher nutzen viele Teams ein Kanban Board für Scrum (das wird oft als „ScrumBan“ bezeichnet).

Ein Kanban Board kann mit der Spalte „Product Backlog“ beginnen, in der alle offenen User Stories aufgelistet sind. Product Owner können in dieser Spalte arbeiten, die für das Projekt notwendigen User Stories erstellen und sie durch das Anordnen der Tiles priorisieren. Für das Sprint Planning zieht das Entwicklungsteam dann alle User Stories in die Spalte „Sprint Plan“, um einen Ablauf für den anstehenden Sprint zu erstellen. Falls notwendig, können auch Schätzungen und Checklisten hinzugefügt werden, mit denen die User Stories in einzelne Tasks aufgeteilt werden.

Wenn das Entwicklungsteam an einer User Story arbeitet, können die Teammitglieder die Karte in die Spalte „In Progress“ verschieben. Zusätzlich kann eine Spalte „Blocked“ erstellt werden, um User Stories aufzunehmen, die wegen eines Hindernisses nicht vervollständigt werden können. Das Hindernis muss dann vom Scrum Master beseitigt werden.

Abschließend können Sie die Spalte „Completed“ oder „Approved“ einfügen, in die User Stories gelangen, die dem Product Owner zur Genehmigung vorgelegt werden müssen. Sobald die User Stories genehmigt wurden, kann die jeweilige Karte in die Spalte „Done“ des Sprint verschoben werden, in der die User Story vervollständigt wurde.

Kanban-Tools sind flexibel und werden auch einfach von interessierten Parteien außerhalb des Teams verstanden. Project Managers, Project Sponsors und Team Managers können auf dem Board jederzeit auf einen Blick den Fortschritt erkennen. Für die Teams ist es ebenfalls vorteilhaft, wenn sie einen Überblick über das Gesamtprojekt haben, denn so bedarf es weniger Meetings zum Projektstatus. Zugleich haben die Teammitglieder die Möglichkeit, den Fortschritt entsprechend zu prüfen und nachzuverfolgen.

Bauen Sie Agile-Teams auf und erstellen Sie Agile-Prozesse

Im Kern geht es bei der Agile-Methode um dauerhafte Verbesserung. Der Fokus der Agile Alliance lag auf Zusammenarbeit, Flexibilität und schrittweiser Verbesserung. Es kann aber sein, dass dies nicht die Ziele Ihres Teams sind – und das ist völlig in Ordnung.

Manchmal hört man Leute sagen:

„Wenn Sie X tun, sind Sie nicht agile.“

Dabei vergessen diese Personen jedoch, dass Agilität kein regelbasiertes System ist, sondern aus bestimmten Prinzipien besteht.

Jedes Team kann diese Prinzipien so anwenden, wie sie am besten für das Team funktionieren – das gilt, solange der Projektplan (kontinuierliche Verbesserung) der Hauptschwerpunkt bleibt.

Wir von Digital Leadership raten daher an, sich bei der Prüfung verschiedener Agile-Methoden weniger auf die Theorien, sondern mehr auf die Problemlösung zu konzentrieren. Fragen Sie sich: Was erschwert die Teamarbeit und verzögert den Fortschritt? Welcher Ansatz kann verwendet werden, um dieses Problem zu lösen und einen reibungsloser ablaufenden Arbeitsprozess sicherzustellen? Sie können auch Software-Tools, etwa Jira, verwenden, um Ihre Agile-Methode zu unterstützen.

Letztendlich sind Definitionen und Prozesse nur Beschreibungen. Das Agile Manifesto erklärt dazu, dass die Arbeit an der eigentlichen Software (oder das Endergebnis) viel wichtiger ist, als der Weg, der Sie dorthin führt.

Fazit

Um die richtige Methode für Ihr Unternehmen zu finden, sollten Sie sich folgende Fragen stellen:

Wie viel Struktur benötigt das Team? Scrum basiert auf detaillierten, klar festgelegten Regeln und Prozessen. Im Vergleich zu Scrum ist Kanban viel flexibler.

Ist das Team auf andere Teams/Projekte angewiesen? Die detaillierten Planungsprozesse von Scrum sind effizient, wenn Ihre Arbeit größtenteils von Einzelpersonen und Teams außerhalb Ihres Scrum-Teams abhängt. Der Kanban-Workflow ist besser, wenn Ihr Team alle Arbeiten selbst erledigen kann.

Hängen Ihre Tasks von anderen Tasks ab? Scrum Boards und Scheduling funktioniert am besten, wenn einige Tasks in Ihrem Backlog vervollständigt werden, bevor die anderen begonnen werden. Kanban verlangt dagegen, dass jeder Task isoliert von den anderen vervollständigt wird.

Im Ergebnis ist keine Methode besser als die andere. Die richtige Wahl für Ihr Team hängt von Ihrer Unternehmensstruktur, den Vorlieben Ihres Teams und den Besonderheiten Ihrer Arbeits- und Projektziele ab.

Weiterführende Artikel

Wenn Ihnen dieser Artikel gefallen hat, interessiert Sie vielleicht auch:

Innovationsstrategie und innovative Geschäftsstrategien

Scrum – die bessere Methode zur Produktentwicklung

Was sind Kundenbeziehungen im Business Model Canvas?

Was sind die Kundensegmente in Ihrem Business Model Canvas?

Vertriebskanäle im Business Model Canvas

Kundenorientierung: So entwickeln Sie eine kundenzentrierte Strategie

Customer-Jobs-to-be-done-(JTBD)-Frameworks, Beispiele und Statements

Wertschöpfung: Definition, Modell, Grundsätze und Bedeutung