Scrumban Lösung für agile Planung

Bevor wir uns an die Scrumban Lösung für agile Planung wagen, möchte ich zuerst einige Grundlagen zu Scrumban erläutern. Eine ausführliche Einleitung über die Ähnlichkeiten und Unterschiede zwischen Scrum, Kanban und Scrumban und die Bedeutung von diesen Faktoren für die agile Planung können Sie hier finden.

Die Scrumban Lösung

Für Unternehmen, die die Notwendigkeit erkennen, zu einer agileren, schlankeren Arbeitsweise überzugehen, ist Scrumban ein einfacher Ansatz – ohne den unnötigen Ballast aus Scrum, den viele Unternehmen nicht benötigen. Es ermöglicht Unternehmen, ihre Arbeit in einer für sie gewohnten Art und Weise fortzusetzen und gleichzeitig bewährte Lean- und Agile-Praktiken, wie sie in Continuous-Flow-Umgebungen praktiziert werden, zu implementieren.

Nach den Grundlagen können wir nun die Elemente von Scrum und Kanban auswählen, die man miteinander kombinieren kann, um so eine Struktur zu definieren, mit der man die Scrumban Lösung für agile Planung erreichen kann. Aus diesem Grund schauen wir uns zuerst das Team, die Rollen und den Ablauf an:

Die Scrumban Lösung und das Team

Die wichtigsten Vorteile des Einsatzes von Scrumban sind:

• höhere Qualität der abgeschlossenen Arbeit und Just-in-time-Entscheidungsfindung
• erhöhte Bearbeitungsgeschwindigkeit
• minimierte Verschwendung
• handlungsfähigere und zufriedenere Teams
• kontinuierlich verbesserte Prozesse

Die Rollen und agile Planung

Drei Rollen wurden identifiziert: Der Scrum Master hatte die Aufgabe, operative Aspekte zu behandeln und Prozesse zu optimieren. Das Team kümmerte sich um die Abarbeitung der täglichen Aufgaben. Und der Product Owner fungierte als Service Manager, der die Priorisierung eingehender Anfragen und die Release-Planung übernahm.

Scrumban Lösung: Der Ablauf

Scrumban ermöglicht es Entwicklungsteams, von festgelegten Planungszeiten auf eine bedarfsgerechte Planung umzustellen. Neue To-Dos könnten regelmäßig in der Produktion festgestellt werden. Im Gegensatz zu Scrum zwingt Scrumban die Produktteams nicht dazu, den Sprintumfang auf 1 bis 4 Wochen zu begrenzen, sodass die Erfüllungsphase so lange andauern kann, wie es für das gewünchte Endergebnis erforderlich ist. Für die meisten Unternehmen ist das Ende der Entwicklung erst der eigentliche Anfang des Lebenszyklus.

Für Entwicklungsteams, die mit Scrum vertraut sind und einen Continuous-Flow-Ansatz verfolgen, ist der Übergang von der Produktentwicklung zur Pflege mit Scrumban einfacher.

Scrumban Lösung: Die Arbeitskarte

Ein zentrales Element in Kanban ist die Arbeitskarte, die die Beschreibung des zu erledigenden Auftrags enthält. Diese Karte wird vom Team in den „FLOW“ gezogen, der sich in verschiedene „Stadien“ bewegt. Auf meine Anregung hin initiierten wir einen Scrumban-Prozess mit einem leicht modifizierten Bug-Tracking-System: Die Fehler, die in das System eingegeben wurden, erforderten spezifische Zusatzinformationen wie bspw. Programmversion, Branche, Herkunftsregion etc. Diese wurden für die nachfolgende Priorisierung verwendet.

Scrumban Lösung: Der Workflow

Unser Scrumban-Board (hier können Sie mehr von den Teamhood-Hauptfunktionen erfahren) enthielt eine Backlog-Liste, die alle Fehler bzw. Arbeitskarten umfasste. Diese Karten würden vom Team in die Phase „In Progress“ gezogen. 

Für die Einhaltung des Workflows war das Team in seiner Gesamtheit verantwortlich. Ich konnte beobachten, dass die Teammitglieder anfingen, sich gegenseitig zu ermutigten und zu coachen, so dass jeder im Team nach und nach seine persönlichen Kompetenzen ausbauen konnte. Eine Arbeitskarte wurden auf „Done“ gesetzt, sobald sie die intern festgelegten Kriterien der Definiton of Done erfüllte.

Scrumban Lösung und die Verbesserung

Das Team startete mit einem Sprint von zwei Wochen. Der Auftragsbestand der Arbeitskarten wurde bei jeder Sprint-Planung überprüft und priorisiert. Basierend auf den typischen Bearbeitungszeiten wurden die Arbeitskarten eingeplant, die bis zum Ende des Sprints erledigt werden sollten. Am Ende des Sprints wurde eine verifizierte Version erstellt, die den Endkunden zur Verfügung gestellt werden konnte.

Im Laufe der Zeit erkannten wir, dass sich die Priorisierung von Elementen innerhalb einzelner Sprints oftmals verschob, so dass wir uns entschieden, die Sprintdauer auf eine Woche zu reduzieren. Eine weitere Reduzierung wäre in unserem Falle nicht sinnvoll und möglich gewesen, zumal auch die Generierung eines vollständigen Releases einige Zeit benötigte.

Scrum und Kanban Lösung: agile Planung und die Verbesserung

Kanban betont die ständige Verbesserung des Workflows und die Identifizierung von Engpässen. Wir modifizierten die Stadien des Kanbanboards und definierten eine „To do“-Phase, die die genaue Anzahl von Punkten enthielt, die sich für den Sprint nach dem Filtern der Items aus dem Backlog ergab. Dies half beim Identifizieren der genauen WIP-Grenze des Teams. Eine weitere „In Validation“-Phase wurde definiert, in der eine Arbeitskarte auf die Erfüllung der Kriterien der Definition of Done überprüft wurde.

Der Grund für diese neue Phase lag in der Erkenntnis, dass einige Karten in „Waiting“ hingen, obwohl sie gar keine weiteren Informationen benötigten. Sie warteten lediglich auf die Überprüfung der Kriterien der Definition of Done. Gleichzeitig konnten wir jetzt erkennen, wie lange einzelne Arbeitskarten in den Phasen „Waiting“ oder „In Validation“ blockiert wurden. Und das führte dazu, dass Mitglieder nun mehr Arbeitskarten bearbeiten konnten: wir erhöhten die Gesamtzahl der zu erledigen Aufgaben von 1 pro Teammitglied auf 1,5. Darüber hinaus konnten wir auch den Grund für die Blockaden beheben.

Die Verbesserung im Ablauf mit Scrumban Lösung

Und was bedeutete dies für den Umgang mit den Problemen der Endbenutzer? Der Endbenutzer meldet sich telefonisch mit einem Problem bei der Kundenbetreuung. Diese dokumentiert das Problem inklusive spezifischer Details im Bug-Tracking-System. Aus dem Eintrag entsteht eine Arbeitskarte, die den beschriebenen Scrumban-Prozess durchläuft. In der Folge entstehen regelmäßig neue Software-Versionen, die dem Endbenutzer regelmäßig als Update zur Verfügung gestellt werden können. Fertig.

Das angepasste Handling von Kundenproblemen

Scrumban Lösung Fazit

Schrittweise konnten die Scrumban-Teams der einzelnen Produktlinien die Anzahl der Fehler reduzieren. Der Unterschied war enorm, denn auch die Anzahl der Anrufe in der Kundenbetreuung reduzierte sich um 50% gegenüber dem Vorjahr. Diese Auswirkungen lassen sich direkt auf die skizzierten Änderungen zurückzuführen. Die im ersten Abschnitt genannten Anforderungen konnte allesamt gelöst werden. Ich würde daher jeder Organisation, die sich mit ähnlichen Szenarien und ähnlichen Anforderungen beschäftigen, ein solches Vorgehen empfehlen.