Cartoon: Was du nicht hören willst

Die Idee, Scrum und Kanban miteinander zu verbinden, ist nicht neu. Eine Zeit lang schien das sogar der neue heiße Scheiß zu sein. Ich habe jedoch nie verstanden, warum man darum so ein großes Gerede machen sollte. Hat man nicht automatisch eine Verbindung zu Kanban, wenn man Scrum ernsthaft betreibt?

Meine Probleme mit der Diskussion um eine mögliche Verbindung von Scrum und Kanban beginnen schon damit, dass hier zwei Dinge miteinander verglichen werden, die kaum vergleichbar sind. Scrum ist ein Rahmenwerk, das uns dabei helfen soll, das agile Prinzip von iterativem Lernen aus Erfahrung zu leben. Kanban hingegen ist eine Sammlung von Prinzipien, die uns dabei helfen sollen, einen optimierten Arbeitsfluss zu erreichen.

Kanban beschränkt sich eben nicht auf die stark vereinfachte Methode, eine Aufgabe erst dann anzufangen, wenn eine andere abgeschlossen ist. Das ist nur ein kleiner Baustein von allem, was wir bedenken und beachten müssen, wenn wir behaupten wollen, die Sache ernst zu nehmen. Nach Kanban vorzugehen, bedeutet nicht, einer Methode mit vorgegebenen Regeln und Rollen zu folgen, wie das bei Scrum der Fall ist, sondern sein Handeln an bestimmten Prinzipien auszurichten. Die passenden Regeln und Rollen muss sich jedes Team bzw. jede Organisation selbst erarbeiten.

Nun komme ich zu dem Punkt, an dem ich feststelle, dass ich eine Methode mit einer Sammlung von Prinzipien verbinden möchte. Soweit – so gut. Als nächstes sollte ich mir vielleicht die Frage stellen, welchen Prinzipien Scrum eigentlich folgt, und da lande ich natürlich zunächst bei der »iterativen empirischen Prozesssteuerung«, also dem kontinuierlichen Lernen aus Erfahrung. Kanban spricht davon, dass eine »kontinuierliche evolutionäre Verbesserung« angestrebt wird.

Ist das irgendwie das Gleiche?

Wir können zumindest sagen, dass diese beiden Aussagen sehr eng beieinander liegen und in eine sehr ähnliche Richtung gehen. Die stetige evolutionäre Verbesserung (also kleine aufeinander aufbauende Schritte) ist am passendsten als direkte Folge des kontinuierlichen Lernens zu verstehen.

Hier findet Ihr eine Übersicht von Videos zu diesem und anderen Themen

Kanban besteht aus drei grundlegenden Prinzipien, von denen die »evolutionäre Verbesserung« eines ist, und (je nach Literatur) fünf bis sieben »Praktiken«, wobei diese auch nicht mehr als Grundsätze sind. Die beiden übrigen Grundprinzipien lauten:

Beginne dort, wo du dich gerade befindest

und

Respektiere bestehende Rollen, Prozesse und Verantwortlichkeiten.

Zumindest die zweite steht in direktem Gegensatz zu Scrum, wo ich ganz bewusst nicht die bestehenden Rollen nutze, sondern neue schaffe. Diese Sicht ist allerdings nur auf die Teamebene beschränkt, die Scrum nicht verlässt. Kanban hingegen ist weit größer zu verstehen und sollte die gesamte Leistungserbringung umfassen. Die Sicht auf ein einzelnes Team ist zu klein, weil alles, was vorher und nachher passiert, ebenso Bedeutung hat. Wenn ich das in meine Überlegungen mit einbeziehe, ist der Gegensatz nicht mehr ganz so groß. Wohlgemerkt: wir sprechen hier nicht von skalierten Systemen wie LeSS oder SAFe.

Sehr viel einfacher wird die Betrachtung der Praktiken, die Kanban uns empfiehlt, z.B.:

Miss und steuere den Fluss der Arbeit

oder

Begrenze Work in Progress

oder

Mache die Regeln des Prozesses explizit und sichtbar

Das ist weder ein Gegensatz noch eine Gemeinsamkeit zu Scrum. Das sind einfache Prinzipien, nach denen jede Form einer Zusammenarbeit ausgerichtet sein sollte. Diese Punkte in einem Team nicht zu beachten, ist höchst fahrlässig, und dabei ist es vollkommen unerheblich, ob wir über Scrum oder was-weiß-ich sprechen.

Etabliere Feedback-Zyklen

Nun, genau das ist die Essenz von Scrum, nicht wahr? Das ganze Framework dient dazu, Feedback-Zyklen zu etablieren und zu formalisieren.

Fördere Leadership auf allen Ebenen.

Hier bewegen wir uns natürlich ganz stark Richtung Selbstorganisation, was ebenfalls auf Agilität im allgemeinen einzahlt. Ein agiles Vorgehen ist ohne weitreichende Selbstorganisation kaum denkbar, unabhängig davon, ob wir über Scrum, Kanban oder irgendetwas Selbstgebautes sprechen.

Ihr seht also, dass Kanban im Detail – in seinen Praktiken – viele Grundlagen für Scrum oder eine beliebige andere Agile Methode enthält, was uns wieder zu unserer Eingangsfrage zurück führt: Was zur Hölle ist Scrumban eigentlich?

Wie üblich in der agilen Welt ist auch dieser Begriff nicht eindeutig definiert, bzw. wir finden eine Vielzahl unterschiedlichster Definitionen. Ich betrachte es gern so, dass ich erst dann von Scrumban spreche, wenn mir der Burndown-Chart zumindest teilweise weniger wichtig ist als die Durchlaufzeit. Das umfasst für mich besonders die Mischformen, wenn in einem Team sowohl Entwicklungs- als auch Maintenance-Projekte laufen. In diesem Fall verfolge ich zwei unterschiedliche Ziele: zum einen möchte ich meine Entwicklung planen, wobei mich eher interessiert, was mein nächster Schritt ist und ob ich kontinuierlich voran komme, zum anderen habe ich ein Betriebsthema, in dem ich sicherstellen muss, dass Servicevereinbarungen eingehalten werden.

Vor einem solchen Hintergrund spreche ich von Scrumban. Die ganzen anderen oben beschriebenen Punkte sind ganz einfach natürliche Bestandteile einer jeden gesunden Entwicklungsumgebung. Wenn Ihr das in Euren Unternehmen noch nicht erreicht habt, dann werdet Ihr mit Sicherheit in der einen oder anderen Form daran arbeiten.

Konzentrieren wir uns also auf diesen Fall der Mischform, dem wir an allen Ecken und Enden begegnen, nachdem die Trennung von Entwicklung und Betrieb in vielen Organisationen Geschichte ist. Oft kümmern wir uns nicht bewusst um Betriebsthemen. Wenn sie hereinkommen, werden sie mit eingetaktet. Dringliche Bugs kommen schnell dran, kritische werden wahrscheinlich sofort erledigt.

Wenn das nicht viel ist – wenn der Anteil der Betriebsthemen gering ist, würde ich es genau so machen. Dann würde ich nicht viel Energie darin investieren, Durchlaufzeiten zu optimieren. Wir würden uns im Team darauf einigen, diese Anforderungen regelmäßig und ohne endlos lange Vorlaufzeiten einzutakten, und damit wäre das Thema erledigt.

Dazu müssen wir uns aber sicher sein, dass der Anteil der Betriebsthemen tatsächlich gering ist. Meine Empfehlung ist also, einmal das Backlog durchzupflügen und zu zählen, wo das Team steht. Unser Bauchgefühl trügt uns meistens.

Kommt Ihr bei unter 25% Betriebsthemen an, belasst es einfach dabei. Ist der Anteil jedoch größer, würde ich damit beginnen, mir die Durchlaufzeiten vergleichbarer Anforderungen zu betrachten. Sind die konstant oder schwanken die extrem? Sind die im Rahmen der Erwartungen der Organisation? Sind diese Erwartungen überhaupt bekannt oder vereinbart?

Kurz gesagt: Bei einem hohen Anteil an Betriebsthemen beginnen wir damit, uns Kanban-typische Fragen zu stellen. Auf diese Fragen folgen teaminterne Vereinbarungen und dann – wenn nicht bereits geschehen – nach außen sichtbare Vereinbarungen in Form von SLA’s.

Kernaussage: Viele Elemente von Kanban beschreiben ganz allgemein Dinge, die uns im Agilen Vorgehen sowieso wichtig sein sollten. Der Begriff »Scrumban« wird erst relevant, wenn in einem Team Entwicklungs- und Maintenance-Themen zusammenkommen.

Folgt mir auf twitter, um keine neuen Beiträge zu verpassen.

twitterrssyoutube
Facebooktwitterredditpinterestlinkedintumblr