Scrumban in der Softwarewartung

“Scrumban? Ist das nicht ein Prozess-Gimmick, das eher in der Theorie als in der realen, praktischen Geschäftswelt funktioniert?” – Das war meine erster Gedanke als ich zum ersten Mal von Scrumban hörte. Inzwischen habe ich Scrumban im Detail mit seiner enormen Wirkung kennengelernt. Gerne möchte ich Ihnen beschreiben, wie ich Scrumban in einer Organisation implementieren durfte und wie Scrumban dabei hilft, die Softwarewartung und -pflege nachhaltig zu verbessern.

Die konkrete Herausforderung

“Probleme werden nicht durch neue Informationen gelöst, sondern durch das Arrangieren von dem, was wir seit langem wissen.”

Viele Organisationen, die Produkte für den B2B- und B2C-Bereich entwickeln, hantieren mit erweiterten Produktgarantien von 3 bis zu 7 Jahren. Dies führt regelmäßig zu sehr umfangreichen Wartungsarbeiten, bei denen Bugfixes und Upgrades über alle Produktlinien hinweg entwickelt und zur Verfügung gestellt werden müssen. Solche Szenarien sind bestimmt allen bekannt, die in Produktentwicklungsorganisationen agieren. In Organisationen, in denen das Wasserfall-Modell verwendetet wird, wird häufig ein Prozess wie dieser für die Wartung und Pflege von Softwareprodukten genutzt:

1. Ein Endbenutzer meldet sich telefonisch mit einem Problem bei der Kundenbetreuung. Ab diesem Zeitpunkt beginnt die Uhr zu ticken und Kosten fallen an; ausgedrückt in X Euro / min.
2. Wird das Problem des Endbenutzers telefonisch gelöst, fallen keine weiteren Aktivitäten an.
3. Wird das Problem nicht gelöst, erwartet der Endbenutzer eine nachträgliche Lösung.
4. Ab diesem Zeitpunkt steigen die die Kosten exponentiell an. Spätestens jetzt wird das Problem in der Kundendatenbank dokumentiert.
5. Durch ein Profiling der Anrufe wird das Problem verschiedenen Teams zugewiesen. Häufig funktioniert diese Zuordnung nicht korrekt und der Bearbeitungsaufwand steigt.
6. Die Kosten steigen so lange an, bis das Problem final gelöst wird.
7. Der Service Manager bündelt verschiedene Problemlösungen, schnürt ein Upgrade und stellt dieses allen Endbenutzern zur Verfügung. Oftmals erfolgt die Bereitstellung von Upgrades ohne einen zugrunde liegenden Zeitplan.

Das Handling von Kundenproblemen

Vielleicht kommt Ihnen der beschriebene Ablauf bekannt vor? Mein Auftraggeber wollte seinen Ablauf verbessern, die Strukturen optimieren und agiler arbeiten. Folgende Anforderungen konnten wir ableiten:

• Wie lässt sich bei der Wartung und Pflege von Produktlinien eine Struktur entwickeln, die agile Prozesse nutzt?
• Wie kann die neue Struktur in die allgemein vorhandene Unternehmensstruktur integriert werden?
• Wie lasen sich der Bearbeitungsaufwand und die damit einhergehenden Kosten signifikant senken?
• Wie lassen sich Schwachstellen im Ablauf mit Metriken identifizieren?

Die Scrumban Grundlagen

“Ich kann niemandem irgendetwas beibringen. Ich kann sie nur zum Denken anregen.” – Socrates

Bevor wir uns an die Lösung wagen, möchte ich zuerst einige Grundlagen zu Scrumban erläutern. Es ist wichtig, die verschiedenen Vor- und Nachteile zu kennen, denn dadurch finden wir eventuell schon einige Lösungen für die genannten Anforderungen.

Scrum

Scrum ist ein Framework, das drei Artefakte – das Product Backlog, das Sprint Backlog und das Product Increment – kennt, fünf Events – das Sprint Planning, das Sprint Review, die Sprint Retrospektive, das Daily Standup und den Sprint – definiert, und drei Rollen – den Product Owner, den Scrum Master und das Scrum Team – festlegt. Vorteile:

• Teams verwenden Iterationen, um Ergebnisse auf Produktebene bereitzustellen.
• Der Umfang der Iterationen wird vom Team definiert.
• Am Ende der Iterationen wird das Ergebnis von allen Stakeholdern überprüft.
• Die Prioritäten und Backlog-Items können während des Sprints geändert werden.
• Das Team kann die Velocity ermitteln und der Releaseplan lässt sich weitestgehend vorhersagen.

Nachteile:

• Der Scrum-Prozess ist nicht für den Fall optimiert, dass regelmäßig Elemente ähnlicher Größe in einem Backlog verwaltet werden.
• Schätzungen des Teams von Aufgaben mit unterschiedlichem Umfang können relativ ungenau sein.
• Scrum ermöglicht das Hinzufügen / Entfernen von Elementen aus dem Backlog, wodurch Versionen möglich werden, in denen wichtige Items fehlen können.

Kanban

Kanban ist ein Framework mit einer Reihe von Prozessen, die es erlauben, Arbeitsabläufe zu verwalten und zu verbessern. Die sechs Kernpraktiken von Kanban, das ursprünglich in der japanischen Automobilindustrie zum Einsatz kam, sind:

1. Die Visualisierung des Workflows: Der Ablauf sollte für alle Beteiligten sichtbar sein. Dies geschieht mittels Kanbanboard (entweder physisch oder elektronisch).
2. Die Limitierung der Arbeit – das sogenannte WIP (Work in Progress): Kanban implementiert ein ‘Pull-System’, in dem Teammitglieder zuerst eine Aufgabe erledigen müssen, bevor eine neue Aufgabe begonnen wird.
3. Die Verwaltung des Ablaufs: Der Arbeitsablauf wird verwaltet, indem Arbeitselemente und deren Status in jeder Phase hervorgehoben werden.
4. Die explizite Formulierung von Prozessrichtlinien: Jede Phase hat explizite Richtlinien und diese Richtlinien sollten hervorgehoben werden, so dass sie allen Beteiligten jederzeit bekannt sind.
5. Die Implementierung von Feedback-Schleifen: Feedback-Schleifen sind in Kanban-Prozessen unerlässlich. Durch sie erfolgt die Überprüfung von Status-Informationen, Messwerten und Abläufen.
6. Die verbesserte Zusammenarbeit und ein schrittweises Ausprobieren (begleitet durch wissenschaftliche Methoden): Kanban erwartet eine ständige Verbesserung durch kleine Änderungen, die dem Team helfen, seine Produktivität zu maximieren und eine hohe Leistung zu gewährleisten.

Vorteile:

• Verschwendung wird mit Kanban reduziert.
• Da nur die Aspekte ausgewählt werden, an denen das Team arbeiten kann, werden unnötige Elemente entfernt.
• Wenn Aufgaben mit gleichbleibender Geschwindigkeit realisiert werden, lassen sich konstante Freigaben – also Releases – daraus ableiten.

Nachteile:

• Wenn Aufgaben unterschiedlich groß ausfallen, führt dies zu Verzögerungen.
• Kanban lebt von seiner Flexibilität auf niedrigem (Tages-)Niveau, so dass eine mittel- oder langfristige Planung paralleler Projekte damit nicht optimal unterstützt wird.
• Der Kanban-Prozess erfordert eine stabile Produktionsumgebung, in der alle abhängigen Parteien mit derselben konstanten Geschwindigkeit arbeiten. Dies ist oftmals nicht in allen Projekten praktikabel.

Die Scrumban Lösung

“Do. Or do not. There is no try.” – Yoda, The Empire Strikes Back

Nach den Grundlagen können wir nun die Elemente von Scrum und Kanban auswählen, die wir miteinander kombinieren wollen, um so eine Struktur zu definieren, mit der wir unsere Ziele erreichen. Dazu schauen wir uns das Team, die Rollen und den Ablauf an:

Das Team

Bis dato handelte es sich um funktionsübergreifend zusammengestellte Mannschaft, bei der alle benötigten Kompetenzen durch einzelne Teammitglieder abgedeckt wurden. Nach Rücksprache mit allen Fachexperten und den Product Owners entschieden wir uns, für jede Produktlinie Teams mit 9 Mitgliedern aufzubauen. Jedes Team wurde ermutigt, sein Wissen in der Breite zu erhöhen, so dass jedes Teammitglied jedes Anliegen handhaben konnte. Engpässe, die durch die mangelnde Verfügbarkeit einzelner Mitarbeiter mit besonderen Kompetenzen entstanden, sollten so beseitigt werden.

Die Rollen

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.

Der Ablauf

Das Workflow-Setup für Scrumban

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.

Der Workflow

Unser Scrumbanboard enthielt eine Backlog-Liste, die alle Fehler bzw. Arbeitskarten umfasste. Diese Karten würden vom Team in die Phase “In Progress” gezogen. Die Kriterien für den ‘Pull’ waren:

• Die Arbeitskarte, die sich in der Phase “Working” befindet, wird durch das Teammitglied, das sich um die Erledigung der Aufgabe kümmert,  auf “Done” gesetzt.
• Die Arbeitskarte wird in die Phase “Waiting” verschoben, so lange bis benötigte Informationen von externen Quellen (Stakeholder) geliefert werden, sofern
• sich nicht mehr Karten in “Waiting” befinden als es Teammitglieder gibt.

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. Anschließend wurde sie vom entsprechenden Mitarbeiter unterschrieben. Nach und nach ließen sich Bearbeitungszeiten für typische Arbeitskarten vorhersagen. Das versetzte das Team in die Lage, den Durchsatz der gesamten Arbeitskarten zu prognostizieren und in der Folge konnte der Product Owner, der als Service Manager fungierte, die Releases in festgelegten Zeitintervallen planen.

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.

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 neue Struktur

Die komplette Struktur sah nun wie folgt aus:

Die Verbesserung im Ablauf

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

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.

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Hier finden Sie den Beitrag von Saugata Das im Original. Mit Zustimmung von Saugata Das übersetzen wir verschiedene Beiträge von ihm hier in unserem Blog vom Englischen ins Deutsche.

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.