In meiner frühen Kanban-Wahrnehmung waren Scrum und Kanban erbitterte Feinde. Das lag unter anderem daran, dass ich als erstes Kanban-Buch das Buch „Scrumban“ von Corey Ladas gelesen habe. Darin ist bei mir vor allem der Satz „the time has come and gone for .. fixed length iterations“ hängen geblieben – stellvertretend für eine Reihe von Relativierungen der Selbstorganisation des Teams.

Die Selbstorganisation ist für mich mit der Kern von Agil, der Sprint in Scrum ist für mich als geschützter Raum eine Möglichkeit, Fehler zu machen und kreativ zusein. Schon damit war das für mich ein frontaler Angriff auf den Geist von Agil. Seitdem habe ich mehr über Scrum und Kanban gelesen und diskutiert, insbesondere das Buch von David Anderson.

Und für mich kristallisiert sich eine Synergie heraus, die gerade aus den verschiedenen Gesichtspunkten von Scrum und Kanban entsteht. Da ist einmal das Verständnis vom Prozess. Der Scrum-Prozess versteht sich als ein Teil der Rahmenbedingungen, in denen das Team arbeitet und innerhalb derer es sich organisiert. Das ist notwendig, weil er auch ein Teil des „Vertrags“ des Teams mit seinen Auftraggebern und der übrigen Umwelt ist.

Das bedeutet, die Wurzel von Scrum liegt in der Organisation der Teamaufgaben und der Verfolgung einer erfolgreichen Entwicklung. Es wird ausdrücklich unterschieden zwischen den Aufgaben – die vom Product Owner vorgegeben werden – und dem „wie“, das vom Team selbst organisiert und bestimmt wird. Dazu gehört auch ein das Konzept des Sprint, einer Iteration fester Länge, als geschützter Bereich, innerhalb dessen das Team Freiheiten der Gestaltung garantiert hat. Das braucht man auf jeden Fall, wenn man innovative Lösungen für komplexe Probleme finden will:

• Man geht Umwege und macht Fehler.
• Man muss die Freiheit haben, kreative Methoden zu nutzen.

Das bedeutet immer auch einen Bereich, in dem man das Ergebnis nicht vollständig vorhersagen kann: manchmal dauert es länger, manchmal gibt es gar kein Ergebnis – das ist aber auf der anderen Seite eine unverzichtbare Quelle von Innovation. Bei Kanban gehört die Ausgestaltung des Prozesses dem Team. Wenn man das übersetzt, ist das der Teil des Prozesses, den Scrum unter Selbstorganisation beschreibt, also die innere Organisation der Teamarbeit.

Ein weiterer Unterschied besteht darin, dass bei Kanban die Stabilisierung des Prozesses im Vordergrund steht, Kanban betrachtet vorrangig wiederholbare Aufgabentypen (David Anderson beschreibt in seinem Hauptbeispiel ein reines Maintenance-Team). In diesem Licht haben Scrum und Kanban komplementäre Stärken. Wir haben erst angefangen zu lernen, wie man diese intelligent kombinieren kann, ohne dass durch den Prozessgedanken die Innovation und Kreativität unter die Räder kommt. Was bisher schon deutlich geworden ist: Kanban oder Elemente von Kanban kann man in verschiedenen Projekttypen und Formen nutzen:

• Ein Team kann seine Arbeit während eines Sprints damit organisieren. In Scrum gibt es schon das Taskboard zur Visualisierung als ein zentrales Werkzeug für die Teamorganisation, mit Kanban haben wir eine lange Liste ausgefeilter Ideen, wie man diese Visualisierung für die Optimierung der Arbeit nutzbar machen kann:
• Eine Sprache für die kleinteilige Organisation im Sprint
• Verschiedene differenzierte Formen, wie man aus dem Taskboard einen optimierten „information radiator“ machen kann:
  • Taskboard mit verschiedenen Prozessstufen
  • Formale work-in-progress limits
  • Swimlanes: Differenzierung verschiedener Arbeitsfelder
  • Farben und andere Auszeichnungen von Tasks in Bearbeitung
• Wenn ein Team mit vielen externen Abhängigkeiten umgehen muss, werden Commitments für diese Items schwierig: wie kann man die Fertigstellung einer Arbeit garantieren, die von einem unzuverlässigen Lieferanten abhängig ist? Hier hilft es, die eigentlichen Entwicklungsaufgaben und die Integrationsaufgaben separat zu verfolgen und evtl. zwei Boards zu führen oder verschiedene Swimlanes anzulegen.
• Für die Bearbeitung von Bugs gilt auch: Wenn man sie in einer eigenen Swimlane führt, kann man transparent machen, wie der Fortschritt ist und wie viel Kapazität darauf verwendet wird.
• Reine Wartungsteams werden wenig Nutzen von abgrenzbaren Sprints spüren, da alle Aufgaben unvorhersehbar auflaufen und die Sprintplanung wenig oder keinen Nutzen bringt. Sie werden eher geneigt sein, eine Retrospektive-Kadenz einführen und ganz auf Kanban setzen.

Kanban kennt ähnlich wie Lean Software Development Rezepte einen Satz von Regeln, es sind im Kern sechs – also etwas abgespeckte – Prinzipien:

• Fokussiere auf Qualität
• Reduziere unfertige Arbeiten (work in progress, WIP)
• Liefere oft
• Gleiche Erwartungen mit dem Durchsatz ab
• Priorisiere
• Bekämpfe Quellen von Variabilität um die Vorhersagbarkeit zu verbessern.

Wenn man diese Prinzipien für die Arbeit des Teams im Sprint anwendet, sind sie noch keine Gegensätze zu Scrum-Prinzipien, sondern können sich gut mit Scrum-Prinzipien ergänzen. Ich finde das Scrumban-Buch immer noch zu polemisch, aber ich habe angefangen, meinen Frieden damit zu schliessen und Nutzen darin zu suchen. Ich finde die Argumentation, man hätte bei der Einführung von Kanban weniger Widerstände, immer noch gefährlich: es kann dazu führen, dass man sich um die harten (und wichtigen) Probleme herumdrückt.

Aber ich empfehle meinen Teams trotzdem, sich diesen Werkzeugkasten anzueignen. Weise angewendet, kann er viel nutzen und einem Team einige Hilfen geben, wie es seine Arbeit, seine Sprints, besser organisiert. Es kann helfen, bessere Resultate zu erzielen und daran wird das Team letztlich gemessen: verlässlich und effektiv Anforderungen in fertige Software zu konvertieren.