Wie bereits aus unserem Blog Post zum Thema “Kanban, Scrum oder beides?” hervorgeht, ist eine Kombination aus agilen Methoden und “Lean” Praktiken vorstellbar. Sie ergänzen sich und erweitern das Handlungsrepertoire für Verbesserungen. Im vorliegenden Blog geht es darum, die statische Sicht auf Frameworks und Werkzeuge zu lockern und eine angemessene, dynamische Sichtweise zu entwickeln. Dies wird anhand von Scrumban – eine Scrum/Kanban Mischform – beispielhaft dargelegt. Dreh- und Angelpunkt ist die kontinuierliche Verbesserung, die die Grundlage für dauerhaften, wirtschaftlichen Erfolg darstellt.

Produktlebenszyklus und kontinuierliche Verbesserung

Ein kontinuierlicher Verbesserungsprozess stellt sicher, dass relevante Umfeldänderungen angemessene Berücksichtigung finden und sich als Veränderungen in der Arbeitsorganisation und dessen Ablauf niederschlagen. Zur Veranschaulichung des dynamischen Aspekts eines derartigen Verbesserungsprozesses bedienen wir uns nochmals der “Stacey Grafik”. Wie bereits an anderer Stelle besprochen, wird eine hauptsächlich mit komplizierten Aufgaben unter strukturiertem Ablauf arbeitende Softwareentwicklung tendenziell nach Kanban organisiert sein. Für eine Softwareentwicklung mit hauptsächlich komplexen Aufgabenstellungen bietet Scrum viele Vorteile. Betrachten wir den stark vereinfachten Lebenszyklus eines (Software-) Produktes über mehrere Jahre hinweg, so wird klar, dass sich die Aufgabenstellungen zu Beginn einer Produktentwicklung aus dem Bereich „komplex“ hin zu eher „komplizierten“ Fragestellungen entwickeln. Parallel dazu wird sich dann auch Organisation und Ablauf in der Softwareentwicklung verändern. Zu Beginn tritt Scrum in den Vordergrund, während sich im weiteren Verlauf der Stabilisierung Kanban mehr und mehr Platz verschafft. Somit ist der Kontext – hier die Aufgabenstellung als ein wichtiger Teil davon – wesentliches Entscheidungskriterium dafür, wie sich die Organisation der Arbeit innerhalb eines Teams weiterentwickelt.

StaceyDynamic

Veränderung der Arbeitsaufgaben im Zeitablauf. Quelle: Stacey, 1996, eigene Darstellung

Scrumban

Zur Verdeutlichung der Dynamik dienen zwei Beispiele, wie z.B. “Scrumban” entstehen kann. Scrumban ist kein fest stehender Begriff und damit der individuellen Interpretation ausgesetzt. Den kleinsten gemeinsamen Nenner kann man in einer allgemeinen Interpretation von Mischformen aus Scrum und Kanban finden. Auch der Einsatz von Scrum und Kanban auf unterschiedlichen Ebenen im Unternehmen wird gelegentlich so bezeichnet. Corey Ladas schildert in seinem Buch agil erfahrene Teams, die nach Scrum arbeiten und im Zeitablauf einen Standard Scrum Workflow von „TODO, In Progress, DONE“ erweitern und standardisiert abarbeiten. Innerhalb dieses Ablaufs übernehmen sie immer mehr Flow und Lean Prinzipien aus Kanban, wie beispielsweise WIP-Limits, weil sich im Zuge ihrer Verbesserungen die Limitierung gleichzeitig in Arbeit befindlicher Artefakte als vorteilhaft erwiesen hat. Im Zeitablauf empfindet das Team aus mehreren Gründen die Timebox der Iteration als suboptimal. Einerseits, weil User Stories auf ein Maß zurechtgeschnitten werden müssen, die den Kundennutzen nicht mehr erkennen lassen. Andererseits wird dem Team immer deutlicher, dass die Lean Denkweise ein Übermaß an User Stories, die nicht alle gleichzeitig bearbeitet werden können, als “Produktion auf Halde“ bezeichnet (Waste). Die Beseitigung des Sprintpuffers wird zum Antrieb durch Lean. Aus der „Timeboxed“ Iteration wird eine „WIP Limit“ Iteration mit der optimalen Losgröße = 1. „Continuous integration“ wird um „Continuous planning“ und „Continuous deployment“ ergänzt (Ladas, 2008 S.48-53). Scrumban in diesem Sinne ist die Weiterentwicklung von Scrum hauptsächlich um Elemente aus Lean/Kanban, und man bewegt sich im Zeitablauf aus Sicht der Aufgabenstellung vom komplexen hin zum komplizierten Bereich der Stacey Matrix mit evolutionären Verbesserungen.

Ein zweites, mögliches Szenario zur Illustration der Dynamik verläuft ähnlich evolutionär, startet aber bei Kanban. Ein Team hat auf pragmatische Weise (Bestandsschutz, Menschen können besser mitgenommen werden, weniger Regeln, …) einen evolutionären Kanban Softwareentwicklungsprozess etabliert. Sie stellen im Lauf der Zeit fest, dass sie immer mehr Scrum Praktiken einführen (Daily standup, …) und entdecken schließlich dabei auch ihre eigene Mischform zwischen Kanban und Scrum. Eine derartige Mischform, die sich ebenfalls im Lauf der Zeit entwickelt hat, schildert Kniberg in seinem Klassiker „Lean from the Trenches“. Man kann sich vorstellen, dass sich die geschilderten Szenarien nach unterschiedlicher Ausgangslage unter sonst gleichen Bedingungen auf ihrer Reise der Verbesserung immer mehr annähern.

Diese dynamische Sichtweise liefert ein wichtiges Argument gegen eine ex ante Definition eines Softwareentwicklungsprozesses durch Querschnittsteams. Nur die beteiligten Personen selbst können erkennen, welche Artefakte, Rollen und Meetings ihrer speziellen Aufgabenstellung am besten gerecht werden. Alle möglichen und vorstellbaren Kombinationen können je nach Situation ohne Dogmatismus für Verbesserungen sorgen. Die Erosion von vordefinierten Methodensammlungen im Zeitablauf lässt sich ganz allgemein auf einen Nenner bringen: “Mix and match the tools as you need!” (Kniberg & Skarin, 2010, S.10). Das Erreichen von 100% Scrum, Kanban oder SAFe erscheint aus dieser Perspektive uninteressant. Wer die agilen und Lean Werte noch nicht vollständig im Unternehmen integriert und dabei die Mitarbeiter mitgenommen hat, kann sich zum Ziel setzen, z.B. Scrum einzuführen. Erst wer die dahinter wirkenden Prinzipien verstanden und verinnerlicht hat, kann sich gemäß dem Shu-Ha-Ri Prinzip auch über Methodensammlungen in Reinform hinwegsetzen. Ein Prozess wird im Laufe der Zeit (immer wieder neu) „entdeckt“, nicht vorab entworfen. Auch wenn es denn dem einen oder anderen genialen Menschen gelingen könnte, dies vorab zu definieren, hätte er ungeahnte Schwierigkeiten, dies den Projektteilnehmern zu vermitteln (Kniberg, Lean from the Trenches, 2011, S.53, eigene Übersetzung).

Fazit

Während ScrumButs als Missachtungen von bestimmten Scrum Praktiken negativ zu beurteilen sind (immerhin vermeidet man das Lösen des Problems, das durch Scrum erst richtig sichtbar geworden ist), geht es bei einer evolutionären Weiterentwicklung von Scrum zu Scrumban um die im Kontext angemessene Weiterentwicklung mit Lean Software Engineering Praktiken. Dies kann nur dann gelingen, wenn die dahinter liegenden Prinzipien verstanden sind und in ihrer Wirkung abgeschätzt werden. Der Einsatz des gesunden Menschenverstandes hilft, die Tool zentrierte Sichtweise aufzugeben und die Werkzeugkombinationen einzusetzen, die am besten zur Situation passen. Eine Beschränkung der Möglichkeiten auf Kanban und Scrum ist nicht beabsichtigt – im Gegenteil soll der Beitrag dazu anregen, agile und andere Werkzeuge im jeweiligen Licht zu bewerten und entsprechend einzusetzen.

Quellen

Ralph Stacey: Strategic Management and Organisational Dynamics: the challenge of complexity. Pitman 2nd edition, 1996

Corey Ladas: Scrumban. Essays on Kanban Systems for Lean Software Development. Modus Cooperandi Press, 2008

Henrik Kniberg:Lean from the trenches. Managing Large-Scale Projects with Kanban. The Pragmatic Programmers, LLC, 2011

Henrik Kniberg & Mattias Skarin: Kanban and Scrum. Making the most of both. C4Media Inc., 2010

Leave a Comment

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close