Scrum vs Kanban: Ein Vergleich agiler Methodologien

Unternehmen müssen agil sein. Unternehmen müssen digitale Dienstleistungen schnell bereitstellen; sie müssen sich an die sich ständig ändernden Bedürfnisse der Kunden anpassen. Lean-Startups sind im Zeitalter von VUCA äußerst angesagt. Die Orientierung als Reaktion auf Verbrauchertrends kann nicht länger auf monolithische und bürokratische Veränderungsprozesse warten. Praktiker im Technologiebereich haben zwei Ansätze priorisiert, Scrum und Kanban, um diese Agilität zu erreichen.

Schauen wir uns die Hauptunterschiede zwischen Scrum und Kanban an. Beachte, dass sie nicht im Gegensatz stehen – es ist weder das eine noch das andere. Tatsächlich kannst du den größten Nutzen erzielen, wenn du sie zusammen einsetzt.

Gedränge

Kanban

Ursprungsgeschichten

Die Art, wie Scrum und Kanban entstanden sind, hebt ihre Unterschiede hervor.

Scrum entstand mit einem HBR-Artikel vom Januar 1986, The New New Product Development Game, geschrieben von Hirotaka Takeuchi und Ikujiro Nonaka. Das Hauptprinzip war, sich von einem sequentiellen Ansatz für die Entwicklung neuer Produkte zu entfernen. Stattdessen sollten Entwickler einen ganzheitlichen, schnellen und flexiblen Prozess annehmen. (Takeuchi und Nonaka entlehnten sich aus dem Rugby, daher der Name Scrum.)

Ken Schwaber und Jeff Sutherland griffen diese Ideen auf und präsentierten Scrum und dessen Anwendbarkeit auf der Object-Oriented Programming, Systems, Languages & Applications (OOPSLA) Konferenz 1995. Im Jahr 2001 nahmen Schwaber und Sutherland an dem berühmten Skigebietstreffen teil, bei dem das Agile Manifesto entworfen wurde. Die beiden verfassten später 2010 den Scrum Guide, der heute als offizieller Scrum Body of Knowledge anerkannt ist.

Kanban entstand Jahrzehnte zuvor, als japanische Ladenbesitzer Schilder in überfüllten Straßen nutzten, um ihre Waren zu bewerben und von der Konkurrenz abzuheben. Der Name Kanban stammt von zwei japanischen Namen, Kan bedeutet 'Schild' und Ban bedeutet 'Tafel'.

1956 entwickelte der junge Toyota-Industrieingenieur Taiichi Ohno ein System, das Papierkarten zur Signalisierung und Nachverfolgung in seiner Fabrik verwendete, und nannte das neue System Kanban. Vorteile wie reduzierte Lagerbestände, verbesserter Durchsatz und eine hohe Transparenz im Prozess trieben diesen Ansatz zum Erfolg voran. Das System wurde 1963 in die gesamte Organisation integriert und Teil des Toyota Production System.

Im Jahr 2004 war David J. Anderson der erste, der Kanban auf IT, Softwareentwicklung und Wissensarbeit anwandte.

Ideologien

Menschen nutzen das Scrum-Framework, um komplexe adaptive Probleme anzugehen und dabei Produkte mit höchstem Wert produktiv und kreativ zu liefern. Scrum basiert auf der empirischen Prozesssteuerungstheorie, die behauptet, dass Wissen aus Erfahrung und Entscheidungsfindung auf Basis des Bekannten stammt. Drei Säulen tragen diesen Ansatz:

• Transparenz. Wesentliche Aspekte des Prozesses müssen für die an den Ergebnissen Beteiligten sichtbar sein.
• Inspektion. Die Beteiligten müssen regelmäßig die Artefakte inspizieren und auf das Ziel hinarbeiten.
• Anpassung. Wenn irgendein Aspekt der Artefakte oder des Fortschritts unbefriedigend ist, müssen Anpassungen so schnell wie möglich vorgenommen werden.

Kanban ist eine Möglichkeit, den Ablauf zu verbessern und Systemverbesserungen durch Visualisierung und Kontrolle von laufenden Arbeiten zu provozieren. Es hat vier grundlegende Prinzipien:

• Fang mit dem an, was du jetzt tust.
• Stimmen Sie zu, evolutionäre Veränderungen anzustreben.
• Respektieren Sie zunächst die aktuellen Rollen, Verantwortlichkeiten und Jobtitel.
• Fördern Sie Führungsqualitäten auf allen Ebenen.

Praktiken

Scrum bezeichnet fünf zeitbasierte Ereignisse zur iterativen und schrittweisen Verwaltung der Produktlieferung, wobei gleichzeitig Möglichkeiten für Feedback maximiert werden. Diese sind:

1. Sprintplanung. Eine achtstündige Sitzung, in der das Team entscheidet, was im kommenden Sprint (aus dem Produktbacklog) geliefert werden soll und wie es vorgeht.
2. Sprint. Ein Zeitraum von einem Monat oder weniger, in dem das Team liefert, was in der Sprint-Planungssitzung vereinbart wurde.
3. Tägliches Gedränge. Eine 15-minütige Zeitbox (allgemein als Daily Stand Up bezeichnet), in der sich das Team während des Sprints täglich trifft, um den Fortschritt zu überprüfen und Blocker zu identifizieren.
4. Sprint-Review. Ein vierstündiges Timebox-Event am Ende des Sprints. Das Team demonstriert das Produkt bzw. die Änderungen den Kunden und sammelt Feedback, was in den Produktrückstand für die Lieferung in den folgenden Sprints aufgenommen werden soll.
5. Sprint-Retrospektive. Eine dreistündige Timebox-Veranstaltung, die nach der Sprint-Überprüfung (und vor der nächsten Sprintplanung) stattfindet. Das Team überprüft seine Arbeit und identifiziert Verbesserungsmöglichkeiten in den folgenden Sprints.

Rollen

Scrum-Framework (Quelle)

Kanban hat sechs Kernpraktiken:

1. Visualisieren Sie den Arbeitsfluss. Verwenden Sie Karten oder Software, um die Prozessaktivitäten auf Schwimmbahnen zu visualisieren.
2. Begrenze Work in Progress (WIP). Ermutige dein Team, zuerst die vorhandenen Arbeiten zu erledigen, bevor sie neue übernehmen. Das Team nimmt neue Arbeit nur dann ein, wenn es die Kapazität hat, sie zu bewältigen.
3. Kontrolliere den Durchfluss. Beobachte die Arbeit, während sie durch die Schwimmwege fließt. Adressiere etwaige Engpässe.
4. Machen Sie Prozessrichtlinien explizit. Zeichnen Sie die Prozessregeln und -richtlinien zum Management des Arbeitsflusses visuell auf.
5. Implementieren Sie Rückkopplungsschleifen. Im gesamten Arbeitsprozess sollten Sie regelmäßige Bewertungen mit dem Team und den Kunden einbauen, um Feedback zu sammeln und einzubeziehen.
6. Verbessert euch gemeinsam, entwickelt euch experimentell. Als Team sucht und integriert Verbesserungsinitiativen, unter anderem durch sichere Experimente.

Kanban-Board (Quelle)

Scrum definiert drei Hauptrollen:

• Product Owner. Die einzige Person, die für die Verwaltung des Produktrückstands verantwortlich ist.
• Scrum Master. Ein dienender Leiter, der dafür verantwortlich ist, dem Team zu helfen, Scrum-Theorie, Praktiken, Regeln und Werte zu verstehen.
• Entwicklungsteam. Selbstorganisierende Gruppe von 3-9 Fachleuten, die für die Lieferung der Produkte verantwortlich sind.

Kanban hat keine festen Rollen. David Anderson befürwortet jedoch zwei Rollen:

• Service Delivery Manager (SDM). Die Person, die den Arbeitsablauf sicherstellt und Veränderungen sowie kontinuierliche Verbesserungen ermöglicht.
• Service Request Manager (SRM). Die Person, die Arbeitspunkte anordnet und priorisiert und die Unternehmensführung mit dem Prozess verbessert.

Metriken

In Scrum ist die Hauptproduktionskennzahl die Geschwindigkeit. Diese beschreibt die Geschwindigkeit des Fortschritts, die das Team liefert, basierend auf der während der Sprintplanung durchgeführten Schätzungen. Das Scrum-Team verwendet die Geschwindigkeit als Indikator dafür, wie viel sie bei jedem Sprint im Produktrückstau liefern, basierend auf dem erforderlichen Aufwand.

Kanban verwendet zwei Hauptmetriken:

• Die Zykluszeit misst, wie viel Zeit eine Aufgabe mit dem Prozess verbringt (also wie lange eine Karte in den WIP-Schwimmspuren bleibt).
• Der Durchsatz misst die Gesamtmenge der in einem bestimmten Zeitraum erbrachten Arbeit (d. h. Anzahl der Karten, die in jedem Zeitraum auf einem bestimmten Kanban-Board geliefert wurden).

Scrum und Kanban zusammen verwenden

Scrum und Kanban können sowohl in Entwicklungsumgebungen als auch im IT-Service-Management zusammen eingesetzt werden. Tatsächlich ist das Scrumban-Framework entstanden. Scrumban nutzt beide Frameworks, um Agilität besser zu fördern und die Fehlen in jedem zu verbessern. Die Nutzung beider Frameworks bietet viele Vorteile, insbesondere aus menschlicher Sicht: Zusammenarbeit und Verbesserung durch Feedback sowie die Fokussierung auf die Bereitstellung von Geschäftswert.

Zusätzliche Ressourcen

Um mehr über Agile und Softwareentwicklung zu erfahren, schauen Sie sich diese BMC-Blogs an:

• Einführung in Agile mit Scrum: 4 Tipps zum Einstieg
• Agile Rollen und Verantwortlichkeiten
• Kundenfeedback: Der Grundstein des agilen Ansatzes
• Der Softwareentwicklungszyklus (SDLC): Eine Einführung
• DevOps-Feedbackschleifen: Eine Einführung

Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.