Scrum vs Kanban vs Scrumban: 6 Tipps

Während die agilen Methoden immer mehr populär werden, ergeben sich manchmal die Fragen, was genau sie bedeuten und wie sie sich voneinander unterscheiden. Deswegen gehen wir weiter mit der Artikelserie über Scrum vs Kanban vs Scrumban, und in diesem Blog-Beitrag vergleichen wir diese drei Methoden, um zu zeigen, wie sie sich in verschiedenen Abmessungen unterscheiden.

Scrum vs Kanban vs Scrumban: Iterationen

Iterationen sind die begrenzten Zeitrahmen. In Scrum arbeiten die Teams in der Regel in 1-4 Wochen Sprints. Die Dauer eines Sprints sollte möglichst stabil bleiben, damit der konsequente Überprüfungsmechanismus geschaffen wird.

Kanban hingegen verfügt über keine vordefinierten Iterationen, sie sind viel flexibler. Stattdessen arbeiten die Teams kontinuierlich, verwenden die Releases, die kürzer als eine Woche sind. Oder größere Iterationen wie Goals.

Scrumban kombiniert die beiden Methoden. Kontinuierliche Arbeit wird zusammen mit kurzen Iterationen für die Planung verwendet, und längere Zyklen – für das Release.

Scrum vs Kanban vs Scrumban: Arbeitsabläufe

Arbeitsabläufe definieren, wie die Aufgaben unter den Teammitgliedern verteilt sind. Das Push-Prinzip bezeichnet, dass die Aufgaben den Teammitgliedern in einer zentralisierten Weise zugewiesen werden. Das Pull-Prinzip bedeutet, dass die Aufgaben von den Teammitgliedern selbst gewählt werden.

Scrum, Kanban und Scrumban sind die agilen Methoden, die Pull-Prinzip verwenden – wobei die Teammitglieder die Aufgaben wählen, die sie bearbeiten möchten.

In Scrum werden die Aufgaben früh von den Teammitgliedern gewählt. Vor jedem Sprint werden die Aufgaben von den Teammitgliedern gewählt oder sie werden an die Tasks gebunden.

Kanban und Scrumban verwenden beide die späte Bindung, wobei die Aufgaben während des Arbeitsprozesses gewählt werden. Sobald die aktuelle Aufgabe abgeschlossen ist, können Teammitglieder frei weitere Aufgaben, die sie bearbeiten möchten, auswählen. Das wird die späte Bindung der Tasks an die Teammitglieder genannt.

Scrum vs Kanban vs Scrumban: Scope Limits

Scope Limits definieren, wie der Arbeitsaufwand in den agilen Methoden beschränkt wird.

In Scrum wird der Arbeitsaufwand mit jedem Sprint begrenzt. Wenn eine Aufgabe innerhalb des Sprints nicht abgeschlossen werden kann, wird sie in der Regel in kleinere Aufgaben aufgeteilt, die dann innerhalb des Sprints erledigt sein können. Z.B., wenn wir ein großes Projekt haben, wird es in so viele kleinere Aufgaben aufgeteilt, dass jede innerhalb des Sprints abgeschlossen wird.

In Kanban und Scrumban definieren die Work-in-Progress-Limits den Umfang der Arbeit. Deshalb, wenn die maximale Anzahl von laufenden Aufgaben drei ist, können die Teammitglieder gleichzeitig mehr Tasks nicht bearbeiten. Dies hilft Teams, die zusätzliche Hilfe zu schaffen, bevor eine Situation problematisch wird.

Man kann auch Scrum, Kanban und Scrumban kombinieren, damit die Arbeit des Teams die beste Qualität erreicht. Aber was für ein Team oder ein Projekt passt, muss nicht unbedingt für andere auch passen. Deswegen ist es wichtig, die Projektmanagement-Tools zu recherchieren. Unsere Lösung – Teamhood Kanban Board, wo man die beliebige Tafel erstellen kann (siehe unten).

Scrum vs Kanban vs Scrumban: Teammitglieder

Im Allgemeinen ist Scrum eine Methodik, wo die Teammitglieder funktionsübergreifend arbeiten können. Obwohl es keine genaue Bedeutung dafür gibt, was funktionsübergreifend bedeutet, sollte das Team die Fähigkeit besitzen, die Arbeit innerhalb jeder Iteration abzuschließen. Da Scrum eine zeitlich begrenzte Methodik ist, kommt es oft vor, dass einige Teammitglieder mit verschiedenen Tasks arbeiten müssen, um die Arbeit während des Sprints abzuschließen. Aber, wie schon oben erwähnt, definiert die Methodik nicht explizit, was funktionsübergreifend bedeutet.

Bei Kanban ist, dagegen, die Spezialisierung der Teammitglieder oder Priorisierung der Tasks bevorzugt. Da die Arbeit durch “Work in Progress” (Aufgaben im Gange/ Laufende Aufgaben) begrenzt ist, kann jeder mit einem anderen Element aus dem Backlog  starten, sobald man mit eigenen Aufgaben fertig ist. Das ermöglicht die Spezialisierung der Teammitglieder.

Bei Scrumban kann das Team entweder spezialisiert, oder funktionsübergreifend sein.

Scrum vs Kanban vs Scrumban: Sitzungen

Scrum verwendet einige Arten von Sitzungen, die immer einem bestimmten Zweck dienen und zu definierten Zeitpunkten im Scrum Prozess stattfinden. Das sind Sprint-Planung, Daily Scrum und die Retrospektive.

Sprint-Planungssitzung erfolgt vor jedem Sprint. Das Team entscheidet, welche Tasks aus dem Produkt-Backlog im kommenden Sprint bearbeitet werden, priorisiert die User-Stories.

Wie der Name andeutet, findet Daily Scrum oder Stand-Up-Sitzung täglich statt, wo jedes Teammitglied kurz darüber berichtet, woran er gerade arbeitet. Daily Scrum dauert nicht länger als 15 Minuten.

Retrospektive stellt den Teamprogress nach jedem Sprint vor. Die Teammitglieder besprechen die Möglichkeiten, den Prozess zu verbessern und zu optimieren.

In Kanban und Scrumban sind die Sitzungen optional. Sie können völlig vermieden oder bei Bedarf vereinbart werden.

Kurze Kaizen-Events können regelmäßig durchgeführt werden, damit man sich besser auf wichtige Dinge konzentrieren könnte. In diesen Sitzungen werden die Probleme untersucht, mögliche Lösungen vorgeschlagen und die Änderungen implementiert.

Scrum vs Kanban vs Scrumban: Kontinuierliche Verbesserung

Agile Vorgehensweisen betonen, wie wichtig die Zusammenarbeit der Projektmitglieder ist. Der kontinuierliche Verbesserungsprozess charakterisiert die stetige Verbesserung der Produkt-, Prozess- und Servicequalität.

Scrum erreicht kontinuierliche Verbesserung durch die Sprint-Retrospektive Sitzung nach dem Sprint, wo die noch offenen Fragen und Probleme geäußert und bewältigt werden.

Bei Kanban und Scrumban ist die kontinuierliche Verbesserung auch nicht optional. Die Idee von Kaizen dient zum diesen Zweck und man sollte auch reguläre kurze Kaizen-Events haben.

Scrum vs Kanban vs Scrumban: Teamhood

Scrum vs Kanban vs Scrumban: Egal, ob Sie ein Projekt zum ersten Mal planen, oder ob Sie es schon seit Jahren getan haben, kann es einige Zeit dauern, bis Sie sich an die neue Projektmanagement-Software gewöhnen.

Deswegen haben wir uns für eine kurze Einführung entschieden, damit Sie schneller mit Scrum, Kanban oder Scrumban mit Teamhood beginnen könnten.

Hier werden die wichtigsten Scrum-Elemente – Board, Sprints, Epics, User Stories vorgestellt und erklärt, wie sie in Teamhood repräsentiert werden. Wir hoffen, dass diese Einführung bei Ihrem ersten Scrum-Projekt mit Teamhood helfen wird.

Zuerst über das Board. In Teamhood finden Sie ein traditionelles Scrum-Board mit Backlog, laufende Aufgaben und Sprints. Die Spalten in der Vorlage repräsentieren den Fortschritt der laufenden Aufgaben und sind in vier Gruppen unterteilt:

Backlog, wo alle Ihre Epics für aktuelle und zukünftige Sprints geplant werden.

In der Spalte Work in Progress werden die laufenden Aufgaben verfolgt.

Output, wo sich die erledigten Aufgaben befinden.

Removed oder “entfernt” – für Aufbewahrung der erledigten Aufgaben.

Jede von diesen Spaltengruppen kann für eine mehr detaillierte Ansicht auch in kleinere Spalten aufgeteilt werden. Es ist sehr wichtig zu wissen, dass Sie das Board nach Ihrem Wunsch gestalten können, d.h., alle Spalten und Spaltengruppen können umbenennt, hinzugefügt oder entfernt werden, damit sie ein für Sie geeignetes Board hätten.

Sprints in Teamhood repräsentieren die Zeilen. Dies wiederum können Sie umbenennen, entfernen oder so viele Sprints, wie Ihr Projekt braucht, hinzufügen.

Nachdem Sie Ihr Board gestaltet haben, müssten Sie mit den Epics und User Stories (einfach gesagt: Aufgaben, Tasks) beginnen. Epics können sehr einfach hinzugefügt werden. Klicken Sie einfach auf das Plus und Sie haben schon eine Aufgabe erstellt, die Sie nach Ihrem Wunsch benennen können. Wenn Sie weiter auf diese Aufgabe oder Kanban Karte klicken, können Sie die Aufgabe bearbeiten, mehr Details oder auch Unteraufgaben, Beschreibungen, User Stories, Dateien, etc. hinzufügen. Sie können auch in Teamhood Kommentare und Tags hinzufügen, damit alle auf dem Laufenden bleiben und sofort Benachrichtigungen erhalten, wenn sich etwas ändert.

Darüber hinaus kann man in Teamhood eine Aufgabe als Vorlage speichern, damit man nicht braucht, jedes Mal dieselbe Aufgabe neu zu beschreiben. Dies ist vor allem sehr hilfreich, wenn Sie an einer eher komplizierten und großen Aufgabe arbeiten. Dann müssen Sie bestimmt Unteraufgaben hinzufügen. Für jede Unnteraufgabe können Sie individuelle Fristen setzen und diese Aufgaben auch unterschiedlichen Teammitgliedern zuweisen. Für die gesamte Aufgabe können Sie selbstverständlich auch Fristen setzen und Sie bekommen dann all dies auf der Zeitleiste visualisiert. Dort können Sie auch ganz leicht die Auslastung der Mitarbeiter verfolgen. Dies bietet Ihnen eine völlige Transparenz Ihrer Prozesse.

Wenn Sie ein neues Projekt in Teamhood erstellen, haben alle Teammitglieder dieselbe Rechte für Bearbeitung des Boards. Ist das für Ihr Projekt wegen unterschiedlichen Rollen der Teammitglieder nicht günstig? Sie können das Board bearbeiten: alle Einstellungen nach Ihrem Wunsch ändern.

Das war nur eine kurze Einführung, wie Sie mit Teamhood Ihr erstes Scrumprojekt planen könnten. Wenn Sie weitere Frage haben, wenden Sie sich bitte an mich, ich kann Ihnen eine kostenlose live Demo anbieten.

Ich hoffe, dass Ihnen unser Artikel über Scrum vs Kanban vs Scrumban gefallen hat.

Möchten Sie sich ein bisschen mit diesen Methoden praktisch beschäftigen? Erstellen Sie jetzt ganz einfach und kostenlos Ihr eigenes Scrumban Board mit Teamhood!