Kayenta

Scrumban – Patentrezept für agiles Projektmanagement?

Scrumban – Patentrezept für agiles Projektmanagement?
Scrumban - das Beste aus Scrum und Kanban!

In Scrumban steckt das Beste von Scrum und Kanban.

Passt das agile Rahmenwerk mit der Methode zur Prozessoptimierung zusammen wie der Deckel zum Topf?

Die Antwort ist: ja. Denn beide verfolgen das Ziel, Kunden Produkte, Funktionen oder Services mit Geschwindigkeit und Flexibilität bereitzustellen.

Was muss der agile Meisterkoch beachten, wenn er Zutaten von Scrum und Kanban zusammenmischt?

Überblick: Scrum

Der Product Owner sammelt Anforderungen in Form von User Stories in einem Product Backlog. Diese sortiert er nach Priorität. In zeitlichen Intervallen, Sprints, entwickeln Scrum Master und Entwicklerteam aus den User Storys Liefergegenstände und liefern diese aus, wenn sie die Definition of Done erfüllen. Sprints dauern in der Regel vier Wochen.

Auch kürzere Zeiträume sind möglich, denn das gesamte Team definiert, wie viel Zeit zur Verfügung steht, um die geplanten Arbeiten zu erledigen. Anhand von Aufwandsschätzungen, zum Beispiel mit Planning Poker, wird ermittelt, welchen Zeitbedarf die Entwicklung einer Story besitzt und in welchem Sprint sie abgearbeitet werden kann.

Sind die für einen Sprint geplanten Arbeiten erledigt, ist es üblich – und in Absprache mit dem Product Owner – weitere User Storys zu ziehen. Unerledigte Storys wandern zurück in das Backlog. Entwicklerteam, Scrum Master und manchmal auch der Product Owner tauschen sich über den Fortschritt ihrer Arbeiten in täglichen Meetings aus. Sie treffen sich zusätzlich in Retrospektiven, um die Art und Weise ihrer Zusammenarbeit zu reflektieren.

Aus den Diskussionen leiten sie Lessons Learned ab, um von Sprint zu Sprint ihre Arbeitsweise zu optimieren. Im Entwicklerteam werden keine speziellen Rollen wie Architekt, Programmierer oder Tester zugeordnet. Jeder macht das, was er am besten kann. In der agilen Welt ist es üblich, dass Kunden jederzeit Anforderungen generieren können. Sobald das geschieht, formuliert der Product Owner daraus User Storys, fügt diese ins Backlog ein und priorisiert sie.
 

Überblick: Kanban

„Wer frei ist, zieht eine neue Karte.“ So könnte man das Pull-Prinzip skizzieren, das erstmals an den Fließbändern des japanischen Autokonzerns Toyota nach dem Zweiten Weltkrieg zum Einsatz kam.

Kerngedanke der Methode zur Prozessoptimierung war, den kontinuierlichen Materialfluss durch alle Fertigungseinheiten hindurch sicherzustellen, um eine ökonomische Auslastung aller Produktionsstufen zu gewährleisten. Kanban wurde von der Softwareindustrie adaptiert. Hier verfolgt die Methode das Ziel, die Fertigstellung eines Softwareproduktes planbar und vorhersehbar zu gestalten.

Dabei gilt die Erkenntnis: Wenn Arbeit sichtbar wird, lässt sie sich am besten organisieren. Die Funktion des Visualisierens übernimmt das Kanban-Board, welches als Tabelle strukturiert ist. Die Anzahl der Spalten und deren Inhalte kann für den jeweiligen Zweck angepasst werden. In der Praxis hat sich eine kompakte Darstellung bewährt, mit den drei Spalten: Aufgaben, in Arbeit und erledigt. Kanban folgt dem Pull-Prinzip.

Erst wenn die Arbeit erledigt ist, „zieht“ sich die Ressource (z. B. Entwickler oder Tester) eigenständig die nächste Aufgabe. So wird vermieden, dass Staus im Entwicklungsprozess entstehen. Die Kapazität des Teams regelt die Kenngröße WiP (Work-in-Progress). Sie drückt die Arbeitsmenge aus, die ein Projektteam in einem Entwicklungsabschnitt leisten kann. Die Entscheidung über die Höhe des WiP-Limits trifft das Team selbstständig.
 

Scrumban

So oder so ähnlich könnte sich ein Dialog auf dem Flur eines fiktiven Softwareunternehmens anhören:

Projektleiter: „Klar nutzen wir Scrum. Auch das Kanban-Board hilft uns sehr. Was aber ist Scrumban? Ein Mix von beiden, oder?“
Coach: „Genau! Es ist das Beste aus beiden Welten. Scrum liefert Daily, Sprint, Artefakte und andere Elemente. Von Kanban kommen Fertigungskarten und Pinwand. So wird Arbeit in einem Prozess sichtbar und kann besser gesteuert werden.“

Projektleiter: „Wow. Was für eine mächtige Allianz. Wo hilft Scrumban?
Coach: „Wenn Teams auf Anfragen von außen reagieren müssen. In einem Kundencenter oder Helpdesk zum Beispiel. Also: Kunde generiert Anforderung, Anforderung entspricht Kanban Karte. Diese wird in einem Sprint abgearbeitet. Mehrere parallel gehen auch.“

Projektleiter: „Warum sollte ich Scrumban nutzen?“
Coach: „Das Pull-Prinzip sorgt dafür, dass Arbeit kontinuierlich fließt. Sobald eine Arbeitskarte erledigt ist, zieht sich das Team die nächste.“

Projektleiter: „Genial. So können sie sicher sein, dass das Wichtigste auch fertig wird.“
Coach: „Ja. Dann nimmt der Product Owner bereits während des Sprints fertiggestellte Storys ab – natürlich nur, wenn die Definition of Done erfüllt ist – und liefert sie aus.“

Projektleiter: „Ohne das Sprintende abzuwarten?“
Coach: „Klar! So reduziert er Lieferzeiten. Aber das ist noch nicht alles. Es gibt weitere Vorteile.“

Projektleiter: „Dachte ich mir. Schießen Sie los!“
Coach: „Durch den kontinuierlichen Durchfluss vermeidet das Team Überlastung und Staus. Die Gleichmäßigkeit lässt Prognosen zu, wie viel Fertigungszeiten zu kalkulieren wären. So können Ressourcen besser geplant werden. Das hat positive Auswirkungen auf die Entwicklungskosten. Die Einsparungen zahlen sich für die Kunden aus.“

Projektleiter: „Das klingt sehr gut. Scrumban probiere ich aus.“
 

Scrumban-Board

Es gibt keine definierte Struktur, wie ein Board bei Scrumban aussehen muss. In der Praxis hat sich diese Spalteneinteilung bewährt:

  • Backlog: Hier finden alle User Storys Platz, die als Arbeitskarten dienen. Der Product Owner hat sie nach Priorität sortiert.
  • Analyse: Das Team zieht eine Arbeitskarte, die den Arbeitsauftrag darstellt, aus dem Backlog. Nun wird dieser analysiert. Möglicherweise fehlen Informationen von Stakeholdern, die noch beschafft werden müssen.
  • Entwicklung: Die User Storys werden realisiert.
  • Testen: Die aus den User Storys entwickelten Einträge werden für die Qualitätsüberwachung vorbereitet und anschließend getestet.
  • Done: Hier erfolgt die Freigabe der neuen Funktion oder des Service, wenn sie den Kriterien der Definition of Done entsprechen. Die Freigabe erfolgt schriftlich.

Zusammenfassung

  • Der Begriff Scrumban setzt sich aus Scrum und Kanban zusammen.
  • Scrumban unterstützt unter anderem Wartungsprojekte oder verteilte Teams, die an der Einführung und an Tests neuer Produkte arbeiten.
  • Die agile Managementmethode nutzt Sprints, Dailys oder Retrospektiven von Scrum und Whiteboards und WiP-Limits von Kanban.
  • WiP-Limits sorgen für eine stabile Ressourcenplanung. Das hilft, Geld zu sparen.
  • Sobald die als User Story formulierte Funktion oder der Service realisiert und abgenommen wurde, kann sie an den Kunden (auch vor Sprintende) ausgeliefert werden.
  • Scrumban definiert keine Rollenverteilung. Die Rollen werden nach Bedarf etabliert.

Über den Autor

Werner Plewa
Projektmanager

Experte für berufliche Weiterbildung und Personalentwicklung. Kontaktanfrage gerne auch bei LinkedIn:


Weitere Artikel

Agiles Manifest und Scrum Guide

Wozu braucht es ein agile Grundsatzerklärung, in der Werte und Prinzipien manifestiert sind – wozu eine praktische Anleitung in einem Leitfaden?

Viele Kollegen im Projektmanagement arbeiten seit Jahren nach agilen Prinzipien, ohne sie jedoch so zu bezeichnen. Was das Agile Manifest und der Scrum Guide beinhalten und wie Sie beide Dokumente für Ihre tägliche Arbeit nutzen können, lesen Sie in diesem Beitrag.

Daily Scrum Meeting - Stand-Up Meeting im agilen Projektmanagement

Das Daily Scrum Meeting findet täglich statt. Für den reibungslosen Ablauf ist der Scrum Master verantwortlich. Für das Team und für den Scrum Master ist die Anwesenheit Pflicht.

Lesen Sie, welche Faktoren das Daily Scrum Meeting kennzeichnen. Und was Sie beachten sollten, damit es erfolgreich verläuft.

Scrum: Product Backlog – Organisation im agilen Projekt

In einem agilen Projekt (z.B. in Scrum) enthält das Product Backlog alle Anforderungen des Projekts und wird durch den Product Owner angelegt, gepflegt und geändert.

Im Gegensatz zum maritimen Logbuch eines Kapitäns, der wichtige Ereignisse rückwirkend dokumentiert, schaut der Product Owner mit seinem Backlog in die Zukunft.

Er beschreibt Kundenwünsche, Anforderungen und Aufgaben, die noch zu erledigen sind, um ein neues Produkt oder Service zu entwickeln.

Die priorisierte Liste nimmt fortwährend neue Einträge auf, kann sich aber auch von alten befreien. Warum das Product Backlog ein wertvolles Werkzeug für den Product Owner ist und wie er dieses dementsprechend pflegt, lesen Sie im folgenden Beitrag.

Kanban Board – Arbeit sichtbar machen

KANBAN ist Trend im Projektmanagement – obwohl das erste Kanban-System bereits 1947 von Talichi Ohno, einem Toyota-Ingenieur, entwickelt wurde. Sein Ziel war es, die Fertigungseffizienz zu verbessern. Alter Wein in neuen Schläuchen? Nein, denn Kanban hat sich in vielfältigen Anwendungsgebieten und in unterschiedlichen Branchen weiterentwickelt. Besonders im IT-Bereich stiftet Kanban Nutzen. Dort sorgt Kanban für Transparenz über alle Entwicklungsstufen. Profitieren auch Sie von der Methode des schlanken Auftragsflusses. Wie Sie Kanban in Ihrem Projekt einsetzen, erfahren Sie in diesem Beitrag.

Kayenta Logo
KAYENTA® Training und Beratung
Abendrothsweg 73
20251 Hamburg
Telefon.: +49 40 370 80 155
E-Mail: kontakt@kayenta.de
KAYENTA Training Projektmanagement hat 4,69 von 5 Sternen 1685 Bewertungen auf ProvenExpert.com
© 2023 KAYENTA® Training und Beratung | Impressum | Datenschutz | AGB | Telefon.: +49 40 370 80 155