Scrum vs. Kanban – Der Showdown

Gestern habe ich einen kritischen Beitrag zu Scrum veröffentlicht. Und schon kam die Aussage: „Ich sehe, du bist ein Kanban-Mann!“ Stimmt das?

Hinweis: Das folgende geht raus an alle Agile Coaches, Scrum Master und alle Führungskräfte, die ihr Team agil arbeiten lassen wollen:

Wenn du agiles Arbeiten ermöglichen möchtest, dann lies den kompletten Beitrag.

Wenn es dir nur um Scrum vs. Kanban geht, dann schau, ob jemand anderes was Interessantes schreibt.

Die Fakten:

  1. Ich biete über die AGILE ACADEMY meinen Kanban-Workshop an
  2. Ich bin aus jahrelanger Erfahrung in unterschiedlichen Rollen in verschiedenen Teams, teilweise als Scrum Master, manchmal mit anderen kritisch eingestellt gegenüber Scrum. Link zum Beitrag: https://lnkd.in/ewXM8C6U

Bin ich deshalb ein Kanban Verfechter? – NEIN

Scrum zieht seine Daseinsberechtigung aus dem Unterschied zum klassischen Projektmanagement, Kanban aus der Weiterentwicklung von Lean auf die Software-Entwicklung.

So weit so gut. Scrum und Kanban können sich gegenseitig gut ergänzen. Als PO eines Plattform-Engineering-Teams nutze ich die Kombination zum Beispiel in meinem aktuellen Scrum-Projekt, was für dieses Team Stand heute gut funktioniert.

Und das ist auch der wichtigste Aspekt: Kanban und Scrum sind Werkzeuge von Managern für Manager. Entwickler merken davon nur die Hindernisse, die das Framework/die Methode mitbringt.

Ich bin agile Native und arbeite radikal agil, was für mich drei Dinge bedeutet:

  1. Ich bin ein Extreme Programming und Software Craftsmanship Anhänger.
  2. Für mich ist das wichtigste Prinzip die Sicherstellung des Flows (Arbeitsfluss), was von Lean abgeleitet sowohl bei Kanban als auch bei DevOps die Grundlage bildet.
  3. Für Veränderungen nutze ich Kaizen. Immer. Evolution gewinnt gegen Revolution.

Der zweite und dritte Punkt lässt mich eher zu Kanban tendieren, da mir für agile Software-Entwicklung das Scrum Framework einfach zu viele unnötige Hindernisse, Unterbrechungen und Blockaden bereitstellt. Kurzum: Es ist mir zu bürokratisch und unflexibel.

Aus Entwicklersicht bedeutet das Folgendes:

  1. Ich will mithilfe von CI/CD-Pipelines, Test driven development, Pair Programming und ähnlichen Praktiken kontinuierlich qualitativ hochwertige und sichere Software liefern. Clean Code und Shift Left (Security) sind angesagt.
  2. Ich will jederzeit sicherstellen, dass ich zu jedem Zeitpunkt am wichtigsten Thema für meinen Kunden arbeite. Und ich möchte sicherstellen, dass Blockaden schnell und unbürokratisch beseitigt werden. Kurz: Effektivität und Effizienz.

Die Aufgabenorganisation muss leisten, dass ich so arbeiten kann. Ob sie nun Scrum oder Kanban heißt, ist zweitrangig.

Learn how we helped 100 top brands gain success