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:
- Ich biete über die AGILE ACADEMY meinen Kanban-Workshop an
- 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:
- Ich bin ein Extreme Programming und Software Craftsmanship Anhänger.
- 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.
- 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:
- 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.
- 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.