Kanban, Scrum oder beides? | Novatec

Die bestehenden Blogs der Kategorie „Agile“ sind der Einführung der agilen Frameworks Kanban und Scrum gewidmet. Wie man bereits aus dem Fazit des Posts „Scrum, eine Einführung“ vermutet, haben diese Frameworks unterschiedliche Einsatzschwerpunkte und Anwendungsbereiche. Vielfach wird berichtet, beispielsweise Kanban oder Scrum erfolgreich im Unternehmen etabliert zu haben. Aber was sind genau Kriterien, anhand derer die Einführung als erfolgreich oder nicht zu bezeichnen sind? Das Ziel des Beitrags ist es, die Voraussetzungen und damit auch Erfolgskriterien für den Einsatz von Kanban und Scrum näher zu beleuchten.

Kanban und Scrum

Grundsätzlich muss unterschieden werden zwischen dem ursprünglichen Konzept „Kanban“ aus der Automobilfertigung und der Übertragung des Konzepts in die Softwareentwicklung. Aus dem ursprünglichen Ansatz wurde durch Anreicherung aus „Lean Production“, „Lean Development“ und der Engpasstheorie ein Framework der Softwareentwicklung. Kanban wird auch durch laufend weitere Anpassungen immer ähnlicher dem agilen Produktentwicklungs-Framework Scrum, weist aber nach wie vor deutlich weniger Regularien auf. Dies kann sich je nach organisatorischem Kontext als Vor- oder Nachteil erweisen. Sowohl Scrum als auch Kanban haben das Ziel, unnötige Arbeit zu vermeiden und unterstützen damit das Konzept der „Lean Production“. Während bei Kanban die Signalkarten verdeutlichen, wann „auf Halde“ produziert wird, unterstützt Scrum u.a. durch kurze Feedbackzyklen die Entwicklung des „richtigen“ Produkts. Durch das „Pull-Prinzip“ begrenzen beide die Anzahl der Arbeitspakete, an denen gleichzeitig gearbeitet wird und nutzen die empirische Prozesssteuerung, um Verbesserungen anstoßen zu können. Parallelen weisen Kanban und Scrum auch darin auf, bestehende Probleme sichtbar zu machen, tragen aber zu deren Lösung nicht entscheidend bei.

Aufgabenstrukturierung im „Stacey Diagramm“

Aufgrund der angesprochenen Ähnlichkeiten stellt sich immer häufiger die Frage, welches der Werkzeuge – hier z.B. Kanban oder Scrum – für einen Verbesserungsprozess zum Einsatz gelangen soll. Als Entscheidungshilfe für die Auswahl kann das so genannte „Stacey Diagramm“ wertvolle Unterstützung leisten. Es dient in diesem Kontext dazu, anhand bestimmter Dimensionen die Aufgabenstellungen in der Softwareentwicklung zu charakterisieren:

Quelle: nach Stacey 1996, eigene Darstellung

Eine Einteilung der Aufgaben erfolgt in die vier Bereiche „einfach“, „kompliziert“, „komplex“ und „chaotisch“. Grob kann die Einteilung anhand der folgenden Tabelle erfolgen:

Einfach	Kompliziert	Komplex	Chaotisch
Eine Aufgabe gilt als einfach, wenn die relevanten Dinge zu ihrer Erledigung bekannt oder weitgehend bekannt sind	Eine Aufgabe gilt als kompliziert, wenn von den relevanten Dingen zur Erledigung der Arbeit mehr bekannt als unbekannt ist.	Eine Aufgabe ist als komplex zu bezeichnen, wenn für die Aufgabenerledigung mehr unbekannt als bekannt ist.	Eine Aufgabe gilt als chaotisch, wenn sehr wenig über sie bekannt ist

Die Strukturierung der Aufgaben nimmt in der Tabelle von „einfach“ bis „chaotisch“ ab. Unterschieden wird einerseits danach, wie hoch die Sicherheit hinsichtlich der verwendeten Technologie beschrieben werden kann, zum anderen wie stark in der Organisation die Einigkeit herrscht, was genau erstellt werden soll. Simple, immer gleich bleibende Aufgaben hinsichtlich funktionaler Anforderungen und Technologie haben auch aus humanen Gesichtspunkten eine natürliche Tendenz zur Automatisierung und bleiben hier außer Betracht. Gilt es, regelmäßig stark strukturierte Aufgaben anhand einer etablierten Architektur mit fest definierten Schnittstellen umzusetzen, wird von komplizierten Aufgaben gesprochen. Komplexe Aufgabenstellungen sind durch eine geringe Planbarkeit gekennzeichnet.

Kanban und Scrum mit „Stacey“

Kanban setzt auf einen generell beherrschten oder beherrschbaren Softwareprozess auf, um diesen einem kontinuierlichen Verbesserungsprozess zu unterziehen. Die Softwareentwicklung ist damit so weit strukturiert, dass man sich im eher kompliziert markierten Teil der Stacey Matrix befindet. Erfolgsgeschichten für den Einsatz von Kanban finden sich deshalb vermehrt in der „bedingt kreativen“ Softwareentwicklung. Hier sind definierte Architekturen und standardisierte Softwareentwicklung vorhanden, die zu lösenden Aufgaben sind kompliziert aber nicht komplex.

Auf Ebene der Gesamtorganisation lässt sich mittels Kanban im Produktportfoliomanagement ein Verbesserungsprozess etablieren, indem der Workflow genauer betrachtet wird. Vielfach ist sich die Geschäftsleitung nicht bewusst, an wie vielen „Baustellen“ gleichzeitig gearbeitet wird. Erfolg verspricht Kanban, wenn eine verbesserte Koordination innerhalb eines Workflows in der Softwareentwicklung notwendig erscheint. Engpässe werden sichtbar gemacht und deren Ausmaß ermittelt, gemäß dem Motto der Engpasstheorie „es gibt immer einen limitierenden Faktor“. Wurde ein Engpass lokalisiert und behoben, tritt ein neuer an seine Stelle. Mittels Kanban und dessen „Pull“ Mechanismus werden Probleme sichtbar gemacht, ohne die bestehende Organisation und deren Ablauf zunächst in Frage zu stellen. Dies kann Widerstände im Management oder bei Mitarbeitern bei der Einführung minimieren.

Ebenfalls erfolgversprechend ist Kanban in organisatorischen Teilbereichen, die den Softwarebetrieb sicherstellen müssen. Dies betrifft Software, die sich im Pflege- oder Wartungsstadium befindet. Zusätzliche Vorteile werden mittels der späten Priorisierungsmöglichkeit beim Einsatz von Kanban bei dringend zu behebenden, betrieblichen Störungen erzielt sowie bei der Minimierung von Durchlaufzeiten der Aufgaben. Die ihrem Wesen nach ungeplanten und meist in weniger als einem Tag zu behebenden Aufgaben im Betrieb machen das Praktizieren von reinem Scrum eher ungeeignet, wenn für neue Aufgaben ein Planning Meeting erfolgen und auf ein Sprintende gewartet werden muss.

Scrum legt seinen Aufgabenschwerpunkt in den komplexen Bereich der Stacey Matrix, in dem der überwiegende Teil der Softwareentwicklung angesiedelt ist. Es liegt in der Natur der Sache, dass komplexe Aufgaben schwer oder gar nicht planbar sind. Durch Scrum lässt sich zwar nicht besser planen – dies gibt die Aufgabenstellung nicht her – aber man macht sich dies bewusst und verwendet dafür nur so viel Zeit, wie unbedingt notwendig. Wer nicht genau sagen kann, was erstellt werden soll, kann nicht durch den Einsatz einer bestimmten Methodik einen exakten Plan verlangen, auch wenn dafür manchmal „Experten“ eingekauft werden. Komplexe Aufgabenstellungen können aber durch den Einsatz von Scrum mit interdisziplinären Teams und kurzen Planungs- und Feedbackzyklen ideal dazu genutzt werden, das richtige Produkt mit überschaubarem Mitteleinsatz zu erstellen.

Fazit

Kanban ist empfehlenswert, wenn als Ziel ein Verbesserungsprozess für hauptsächlich einfache bis komplizierte Aufgabenstellungen etabliert werden soll. Der Einsatzschwerpunkt von Scrum konzentriert sich eher auf den komplexen Bereich der Stacey Matrix. Mit Scrum lässt sich der chaotische Bereich so weit strukturieren, dass er in den komplexen Bereich wandert. Sowohl Scrum als auch Kanban zielen darauf ab, die Produktivität zu erhöhen. Kanban legt dabei eher den Fokus auf die Effizienz, um eine Optimierung hinsichtlich des Durchflusses anhand eines bestehenden Prozesses innerhalb der arbeitsteiligen (Software-) Organisation zu erreichen. Scrum legt den Schwerpunkt neben der Effizienz auch auf die Effektivität. Wie bereits zwischen den Zeilen zu lesen ist, wird noch detaillierter zu betrachten sein, ob und unter welchen Rahmenbedingungen eine Kombination dieser Frameworks als besonders lukrativ betrachtet werden kann (z.B. „Scrumban“).