Scrumban – Patentrezept für agiles Projektmanagement?

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.

„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.

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.“

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.

• 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.

Aktuellen Kanban Guide hier kostenfrei anfordern!