Scrum oder Kanban: welche Methode ist die Richtige für mein Projekt?

Ist die Entscheidung für Agilität im Unternehmen einmal gefallen, so stellt sich recht schnell die Frage 'Und wie kriege ich das jetzt umgesetzt?' oder 'Wie erreiche ich all die versprochenen Vorteile wie Offenheit, Schnelligkeit, Transparenz und Respekt?'. Der nächste Schritt ist dann, sich für eine agile Methode zu entscheiden.

Denn Agilität ist nur ein Oberbegriff für eine Art zu Denken, eine Weise zu Arbeiten und eine innere Einstellung. Es gibt verschiedene Möglichkeiten, diese in die praktische Arbeit umzusetzen. Die beiden bekanntesten agilen Methoden sind Scrum und Kanban (oft wird auch eine Mischung zwischen beiden praktiziert). Ziemlich viele Vorhaben innerhalb eines Unternehmens können mit diesen beiden Methoden umgesetzt werden. So sehr sich die beiden Vorgehensweisen auch ähneln - Boards, Dailys, Teams - bei der Frage, welche Methode die richtige für ein Projekt ist, gibt es einige Eigenschaften, die berücksichtigt werden sollten. Zunächst gilt es zu verstehen, was Scrum und Kanban überhaupt sind.

Scrum ist eine Methode zur Entwicklung von Neuem, z. B. physischen Produkten, Dienstleistungen, neuen Prozessen, eines Events, ... . Die wichtigsten Prinzipien sind dabei das Vorgehen in Iterationen und das Erarbeiten des Ergebnisses in Inkrementen. Dazu kommt eine enge Zusammenarbeit mit den Stakeholdern und das Arbeiten in kleinen Teams, die ständig miteinander kommunizieren und ihre Arbeit visuell und transparent koordinieren. Das Hauptaugenmerk von Kanban hingegegen ist nicht nur das Produkt, sondern die Optimierung des Prozesses. Ein Team arbeitet kontinuierlich an einer Reihe von Aufgaben. In Kanban soll Multitasking vermieden und Bottlenecks aufgedeckt werden. Dabei werden Tools wie Visualisierung und Work in Progress (WiP) Limits genutzt.

Ein gemeinsames Prinzip ist die Fokussierung, um eine möglichst hohe Produktivität und Effektivität sicherzustellen. In Scrum erfolgt das über das Timeboxing in Sprints. Zu Beginn einer jeden Iteration erarbeitet sich das Team ein nachhaltiges und relativ konstantes Arbeitsvolumen (da Sprints immer gleich lang sind), das nachfolgend abgearbeitet wird. Der Fokus liegt dann immer auf der Entwicklung dieses Inkrements. In Kanban erfolgt durch das Setzen eines (WiP-) Limits die Begrenzung des Workloads auf wenige Aufgaben. Beide Methoden verhindern sowohl in Kanban- als auch in Scrum-Teams, dass sich die Mitarbeiter in zu vielen Aufgaben verzetteln und den Überblick über das Wichtigste verlieren. Auch Visualisierung wird als wertvolle Technik in beiden Methoden genutzt. Ein gemeinsames Board sorgt dafür, dass Aufgaben immer sichtbar sind und Teammitglieder sich einfach und effektiv koordinieren können. In Kanban kommt dem Board zusätzlich noch die Funktion zu, Bottlenecks aufzudecken und den WiP zu überwachen. Die optimale Gestaltung des Prozesses wird mit einem Board einfach erarbeitet. Natürlich verschwimmen die Eigenschaften, so kann man auch in Scrum ein Bottleneck entdecken und den Prozess optimieren usw..

Unterschiedlich hingegen wird die zeitliche Strukturierung in beiden Methoden behandelt: Während Scrum in festgesetzten Sprints arbeitet, gibt es in Kanban einen kontinuierlichen Flow. In Kanban gibt es keine Regeln, die in Planungs-, Arbeitsphasen und Möglichkeiten zur Reflektion unterteilt. Dementsprechend wird in Kanban auch kontinuierlich geliefert, sobald eine Aufgabe den Prozess durchlaufen hat, während in Scrum lediglich am Ende jedes Sprints ein Inkrement fertig gestellt ist. Ein wichtiger weiterer Unterschied ist die Teamzusammensetzung. In Scrum sind explizit drei Rollen mit definierten Aufgabengebieten und Verantwortlichkeiten festgelegt. Kanban trifft darüber keine Aussagen. Man bekommt schon aus diesen wenigen Beispielen einen guten Eindruck davon, dass Kanban viel mehr Freiheiten lässt und es dem Team ermöglicht, eigene Regeln aufzustellen, z. B. einen Kanban Master zu wählen oder eigene Retrospektiven einzurichten. So verschwimmen auch hier die Grenzen zwischen Scrum und Kanban in der Realität oft. Diese Auflistung ist natürlich längst nicht vollständig.

Zum Abschluss möchten wir Ihnen einige Fragen mit an die Hand geben, die Sie sich bei Ihrer Entscheidung für eine der beiden agilen Methoden stellen sollten:

• Was ist das Ziel Ihres agilen Vorhabens? Soll ein Produkt entwickelt werden? Oder soll mithilfe von agilen Methoden Transparenz und Wissensaustausch in einer bestehenden Service-Abteilung etabliert werden? Für Ersteres wäre Scrum vorzuziehen, Letzeres kann besser mit Kanban erreicht werden.
• Wie viel Prozent Ihrer Arbeitsleistung können Ihre Mitarbeiter in dem agilen Projekt aufwenden? Scrum erfordert aufgrund seiner Meetingstruktur einen recht hohen Zeitaufwand, während ein Kanban-Projekt auch mit weniger zeitlichem Einsatz funktioniert.
• Wie komplex ist ihr Produkt? Kleinere, unkomplizierte Projekte können mit Kanban wunderbar funktionieren. Größere, komplexe Produkte benötigen jedoch einen höheren Planungs- und Koordinationsaufwand sowie regelmäßige Synchronisation und Feedback. Hier ist Scrum eventuell die bessere Wahl.
• In welchem Lebenszyklus befindet sich ihr Produkt? Wartungsarbeiten sind gut mit Kanban zu bearbeiten. In der Entwicklungsphase, wo es viele Unbekannte gibt, kann Scrum helfen, mit der Unsicherheit umzugehen.
• Wie veränderungsbereit ist ihre Organisation? Wieviel Unterstützung bekommt das Team? Kanban lässt sich relativ leicht und ohne größere Veränderung der Teamumgebung einführen. Scrum hingegen erfordert Cross-Funktionalität, regelmäßigere Meetings, Stakeholder, die erreichbar sind. Das Team benötigt einen höheren Unterstützungsgrad aus dem Unternehmensumfeld.
• Haben Sie ein Team? Wenn ja, wie sieht ihr derzeitiges Team aus? Besteht es nur aus Experten, so ist die Bildung eines Scrum-Teams schwierig, kann aber gemacht werden. Haben Sie die Möglichkeit, zusätzliches Wissen aus anderen Bereichen in Ihr Team zu integrieren? Ist Ihr Ziel auch Teambuilding? Ein Nebeneffekt der engen Zusammenarbeit in Scrum ist auch eine starke Teamidentifikation, die in Kanban natürlich auch passieren kann, jedoch nicht so klar gesteuert wird.
  
  Dies sind eine Reihe von Beispielfragen, die Ihnen helfen können, sich für die für Sie richtige Methode zu entscheiden. Und nicht vergessen: Keine der beiden Methoden ist besser als die andere, sie verfolgen nur leicht unterschiedliche Zwecke.
  
  

Über die Autoren:

Volker Schmidt arbeitet als Agile Coach bei Cegeka Deutschland und begleitet Unternehmen, insbesondere das Management, bei der agilen Transition. Er ist zertifizierter Scrum Master und verfügt über langjährige Erfahrungen im agilen Projektmanagement und der Führung von agilen Teams. Xing-Profil

Caroline Schmidt arbeitet in der agilen Beratung und begleitet Unternehmen täglich in ihrer agilen Transition. Ihre persönlichen Interessen liegen besonders auf agile Leadership und der agilen Organisationsentwicklung / Skalierung. Sie besitzt einen Bachelor und Master Abschluss der WHU Otto Beisheim School of Management in Internationalem Management und hat im Rahmen dessen Auslandserfahrung in London, Mailand und Tunis gesammelt, die ihr im täglichen Umgang mit einer Vielzahl unterschiedlicher Persönlichkeiten zugute kommt. Sie ist Autorin verschiedener Artikel zum Thema Leadership, agiler Skalierung und Arbeitsorganisation. Xing-Profil

Vielleicht auch interessant: