Agiler Adventskalender: Scrum oder Kanban?

Der Nikolaus hat heute eine ganz besondere Frage im Gepäck:

Soll ich mit meinem Team Scrum oder Kanban machen? Woran kann ich das erkennen?

Scrum oder Kanban?

Die passendste Antwort auf diese Frage lautet: „Es kommt drauf an.“

Ich möchte hier auch keine religiösen Grabenkriege aufmachen – denn genau an dieser Frage scheiden sich oft die Geister – sondern freue mich auf Kommentare und auf einen Diskurs darüber.

Meine Meinung möchte ich dennoch kurz und knapp darstellen.

Kanban

Vereinfacht gesagt kann man Kanban in der Wissensarbeit immer anwenden, weil es eine Methode ist, um Wissensarbeit zu managen. Du betreibst Wissensarbeit? Kanban ist also anwendbar.

Hier will ich auch mit einem Missverständnis aufräumen, das besagt, dass Kanban nicht für die Erstellung komplexer Produkte anwendbar sei. Das ist schlicht nicht korrekt, hält sich aber leider hartnäckig.

Scrum

Scrum ist laut Scrum Guide „ein leichtgewichtiges Rahmenwerk, welches Menschen, Teams und Organisationen hilft, Wert durch adaptive Lösungen für komplexe Probleme zu generieren.“ 

2017 war hier noch von Produktentwicklung die Rede und das Wort „leichtgewichtig“ hat gefehlt. Insofern nehme ich hier eine Annäherung von Kanban und Scrum wahr, was die Abgrenzung nicht leichter macht. Scrum löst sich etwas aus seinen Fesseln.

Kriterien für die Entscheidungsfindung

Für mich sind für die Entscheidung einige wesentliche Kriterien von Bedeutung, die am Ende ein Gesamtbild geben; hier eine Auswahl:

1. In welchem Umfeld arbeitet das Team? Gibt es einen Change-Prozess? Ist dieser eher evolutionär – alles bleibt erstmal wie es ist – oder wird das System revolutioniert? Im ersten Fall ergibt Kanban mehr Sinn, da es Rollen und Prozesse erstmal respektiert. Im Letzteren kann Scrum Anwendung finden, das einer Revolution des Setups gleich kommt.
2. Was ist das Ziel? Will ich den Arbeitsfluss optimieren, greife ich eher zu Kanban, habe ich ein „herausforderndes, komplexes Grüne-Wiese-Produkt“ das in Sprints ablaufen soll, kann ich auch mit Scrum arbeiten.
3. Wie groß ist mein Team? Die Personenklarheit wurde 2020 im Scrum Guide aufgehoben, jetzt spricht man von einem „kleinen Team von Menschen“. Ergo: Habe ich ein „großes Team“, sollte ich eher auf Kanban gehen.
4. Wie sieht meine tägliche Arbeit aus? Arbeite ich klar an einem Produkt mit Features oder mache ich hauptsächlich Maintenance und fixe Bugs? Im letzteren Fall spricht auch vieles dafür, mit Kanban zu arbeiten, da der Scrum-Prozess hier Schwierigkeiten machen kann und es vielleicht Sprintabbrüche hagelt.
5. Wie soll Inspect & Adapt stattfinden? Bevorzugt das Team es, dies ritualisiert von Sprint zu Sprint zu gestalten, ist Scrum wählbar. Sollen (auch umfangreiche) Änderungen jederzeit möglich sein, ist Kanban geeigneter, da ich den Sprint „nicht störe“.

Die beste Wahl?

Vereinfacht gesagt ist Scrum – wenn man kein Produkt entwickelt – nicht immer die beste Wahl und Kanban hat hier oft Vorteile. Das bedeutet aber nicht, dass Scrum hier nicht anwendbar wäre … genauso wenig wie es bedeutet, dass bei der Produktentwicklung Kanban keine Anwendung findet.

Meiner Meinung nach wird aber zu oft reflexartig mit Scrum gearbeitet – das kennt man halt – und Kanban vernachlässigt.

Im Endeffekt muss man sich mit dem Team auf ein Anfangs-Setup verständigen und die Bereitschaft haben, bei Scheitern das Setup zu verändern.

Nur bitte macht kein Scrum oder Kanban, weil „ihr es machen müsst“. Denn das scheitert leider immer.