SCRUMBAN: Alles klar (oder doch nicht)?

Du kommst mit Scrum nicht wirklich zu Recht? Kanban ist für Dich nur Todo, Doing, Done? „Scrumban“ hat Dir ein Agile Coach schon Mal zugerufen, aber Du weißt nicht was Du damit anfangen sollst? In diesem Artikel gebe ich eine erste Einordnung.

Agile Ansätze sind für die zunehmend komplexe und unbeständige Welt von hoher Bedeutung. Diese Welt wird oftmals auch als VUCA-Welt (Volatility, Uncertainty, Complexity und Ambiguity) bezeichnet. Um erfolgreich zu bleiben oder (wieder) zu werden ist es wichtig, anpassungsfähig zu sein und auf Veränderungen schnell reagieren zu können.

Auf Teamebene werden dazu seit Jahren Frameworks und Methoden aus der agilen und der Lean-Welt wie Scrum und Kanban genutzt. Oft hört man auch: „Nutz doch das Beste aus beiden Welten und mach einfach Scrumban“.

Beim Stöbern und Suchen wie ich meinen eigenen Horizont erweitern und Neues lernen kann, bin ich bei scrum.org auf die „Professional Scrum™ with Kanban Certification“ gestoßen. Die gibt es erst seit 2018, ist also relativ neu. Das fand ich irgendwie interessant und hab tiefer gegraben. Hier meine vier Key-Learnings:

1) Zu Scrumban gibt es gar nicht so viele Infos. Es ist weniger durchdrungen, als man denkt.

• An Literatur gibt es „den Klassiker“ von Henrik Kniberg: Kanban and Scrum – Making the Most of Both sowie Essays von Corey Ladas: Scrumban (beide von 2009 !). Relativ neu ist Andy Miles: Applying Scrum with Kanban . Letzteres orientiert sich stark am unten beschriebenen Kanban Guide for Scrum Teams und geht wenig darüber hinaus.
• Wenn Du nach Scrumban googlest findest Du erstaunlich wenige und nur oberflächliche Blogeinträge. Probiers mal aus. Und die sind jeweils nur Zusammenfassungen von Scrum und von Kanban und dass man sie auch gemeinsam nutzen kann. Eine tiefergehende Auseinandersetzung was das wirklich bringt und wie man die Arbeit damit startet erfolgt nicht.

2) Die Welt der agilen Frameworks wächst und wächst... . Manche Vordenker, die erst eng zusammengearbeitet haben, geraten dann einander zu Fragen wie „Wer hats erfunden?“ und „Wer hat heute die Deutungshoheit?“.

• In der Scrumwelt bezieht man sich meist auf den Scrum Guide als „Bibel“. Wenn es um Trainings und Zertifizierung geht, ist vielen die konkurrierende Welt von scrum.org und ScrumAlliance bekannt.
• Dass es diese Konkurrenzsituation auch seit 2018/ 2020 in der Kanban Welt gibt, habe ich neu gelernt.
  • Bisher kannte ich „nur“ David J. Andersons Welt der Kanban University. Sein Verständnis von Kanban ist im sog. The official guide to the Kanban Method niedergelegt.
  • Seit ca. 2020 treibt eine Gruppe um Dan Vacanti prokanban.org voran. Sie haben Ihr Verständnis von Kanban im sog. Kanban Guide definiert.

3) Scrumban ist MEHR als: „Es gibt Scrum und Kanban und irgendwie kann man auch beides nutzen und miteinander verwurschteln“.

• Der für bzw. durch scrum.org erdachte Kanban Guide for Scrum Teams gibt einen ersten, schönen Handlungsrahmen. Aus meiner Sicht definitiv eine Empfehlung ihn zu lesen und durchzuarbeiten: Er macht Kanban in der Scrum-Welt greifbar und konkret (Welche Praktiken aus der Kanban-Welt sind in Scrum anwendbar? Welche ganz konkreten Metriken sind sinnvoll?).
• Was mir fehlt: Es ist ein Guide, der aus Sicht von Scrum geschrieben ist, und „Scrum gibt hier den Ton an“. Das heißt alle Rollen, Events und Artefakte aus Scrum „müssen“ auch bei Scrumban angewendet werden. Das mag aber nicht immer sinnvoll sein. Eine kritische Auseinandersetzung diesbezüglich fehlt mir.

4) Meine Folgerungen:

• Für viele Teams mit denen ich arbeiten darf, eignet sich Scrum sehr gut um ihre Probleme zu lösen, für andere eher weniger oder nicht. Mit Kanban auf der anderen Seite habe ich die Erfahrung gemacht, dass der Start oft einfach und schnell ist („Start with what you do now and pursue evolutionary change“). Die Teams bleiben dann aber auf Ihrer Lernreise „stecken“, ala „OK, jetzt haben wir unsere Arbeit auf einem Board visualisiert und wir treffen uns regelmäßig. Was ist dadurch besser geworden?“. Ein Mittelweg aus gewisser Struktur von Scrum (z.B. einem klaren Product Owner und einer Taktung mit definierten Events) und der offenen, evolutionären Verbesserung in Kanban inkl. dem Fokus auf Metriken und dem Lernen daraus kann hier echten Mehrwert schaffen.
• Es gibt noch viele offene Fragen zu beantworten: Wann nutze ich wirklich was? Für welche Ausgangssituation und Probleme macht Scrum Sinn, macht Kanban Sinn, macht Scrumban Sinn? Wie kann ich als Agile Coach meine Kunden hier am Besten an die Hand nehmen, wie kann eine Lernreise aussehen?
• Eigentlich schade, aber zugleich auch eine Chance. Da müsste bzw. sollte man mehr daraus machen 😉.