Kanban vs. Scrum

Als Feedback zu meinem Buch hatte ich die Anmerkung erhalten, dass es doch gut wäre, zu erklären, warum ich in den letzten Kapiteln Kanban empfehle. Eine gute Gelegenheit für diesem Blogpost.

Bevor wir in die Details einsteigen vorab ein Disclaimer: Dies hier basiert auf meinen persönlichen Erfahrungen. 

Was sind Scrum und Kanban?

Lass uns mit einem Blick in Wikipedia einsteigen. Was sagt sie zu den "Methoden" Scrum und Kanban?

Scrum is an agile team collaboration framework commonly used in software development and other industries.

Kanban is a lean method to manage and improve work across human systems.

Und da sieht man schon den größten Unterschied im Selbstverständnis dieser "Methoden". Während Scrum "team collaboration" betont, erwähnt Kanban "work". Scrum fokussiert sich auf das Team und die Menschen, während Kanban die Arbeit in den Mittelpunkt stellt. Das sind zwei fundamental unterschiedliche Dinge und das merkt man in der Praxis auch.

Aufgefallen? Keine der Definitionen sagt etwas von "Projektmanagement".

Mein Hintergrund

Ich arbeite in einer Agentur, die für Kunden Software entwickelt und customized. Diese Tätigkeiten setze ich mit meinem Team (momentan sieben Menschen) um. Die Arbeit ist heterogen: Kleinere Aufgaben (Aufwand unter einem Tag) finden parallel zu größeren Tätigkeiten (50 Tage und mehr) statt. 

Mit diesem Team habe ich in der Vergangenheit über fünf Jahr Scrum "nach Lehrbuch" als Methode benutzt. Wir hatten einen zertifizierten Scrum Master und ich war zertifizierter PO. 

Nach diesen fünf Jahren haben wir auf Kanban gewechselt. Die Gründe dafür werden dir nach dem Lesen des Artikels klar werden.

Wie wir Arbeit kategorisieren können

Wir werden heute viel über Arbeit ("die Stories") reden. Damit du besser verstehst, wie unterschiedlich Arbeit sein kann, lass uns auf die Stacey Matrix schauen.

Wir sehen auf der X-Achse eine Einteilung der Arbeit in "klar" und "unklar". Hier ist Erfahrung das Thema. Haben wir die Art der Arbeit schon einmal gemacht? Kennen wir bereits Lösungen?

Auf der Y-Achse ist die Klarheit der Anforderung abgetragen. Ist sie klar formuliert oder gibt es eine große Unsicherheit?

Mit der Stacey Matrix hast du ein Tool an der Hand mit dem du mal deine Stories der letzten Wochen durchgehen kannst. Liegst du eher im Bereich von "Einfach", ist eine Methode wie Scrum oder Kanban nett, aber nicht nötig.

Je weiter du nach rechts oben kommst, desto effektiver kann es sein, eine Methode anzuwenden. Welche? Lass uns dafür in die nächsten Kapitel schauen.

Wann Scrum seine Stärken hat

Neben vielen Kleinigkeiten gibt es für mich ein paar herausragende Punkte, die entscheidend sind, damit Scrum funktioniert. Diese sind für mich:

• Ihr benötigt ein Umfeld, in dem alle Beteiligten - ja, alle, nicht nur das Scrum Team - verstanden haben, dass es eine Unsicherheit gibt über das Produkt, das entwickelt werden soll. Mit der Methode Scrum kann dann diese Unsicherheit gemanaged werden kann (durch Iteration - Feedback - Adaption - Iteration)
• Ihr müsst euch zu einem Inkrement committen können und es muss ausgeschlossen sein, dass Störer euch dazu zwingen, euer Commitment zu brechen.

Was meine ich damit? Zu oft habe ich gesehen und gelesen, dass z.B. das Management oder weitere Dritte zwar das Wort Scrum lieben, aber herzlich wenig Ahnung davon haben, was es wirklich bedeutet Scrum anzuwenden und warum sie Scrum anwenden. Um das zu verstehen, schau einfach mal die Memes von @FakeScrumStats an.

Eine der wichtigsten Elemente in Scrum ist der Sprint. Um diesen erfolgreich zu gestalten ist die Planung des Sprints elementar. Dazu wenden Teams verschiedene Methoden an, um zu schauen, ob sie die nächsten Aufgaben (Stories) richtig verstanden haben, ob diese gut vorbereitet sind und wie groß sie sind. Die Idee (die eine gute ist!) ist es, zumindest für einen überschaubaren Zeitraum (den Sprint) Stabilität in die Ungewissheit zu bringen und dann, nach Ende des Sprints, in ein Feedback-Zyklus zu kommen. Danach, aufgrund der gewachsenen Erfahrung und des Feedbacks, kann der Plan angepasst werden. Dies soll - so die Theorie - dazu führen, im unsicheren oder unbekannten Umfeld (s. Stacey Matrix oben) permanent die "richtige" Arbeit zu machen.

Und hier kommt das größte Problem von Scrum zum Vorschein. Was passiert, wenn im Sprint etwas ungeplantes hinzukommt? Anforderungen, die doch nicht so klar waren? Support? Etwas ist doch wichtiger als im Planning gedacht? Von außen wird dem Team etwas anderes "aufgedrückt"? Dann ist das Rückgrat von Scrum - der Sprint - gebrochen. 

Ich habe in meiner Praxis erlebt, dass wir angefangen haben, X% unserer "Kapazität" für unbekanntes zu reservieren. Ich habe erlebt, dass X% nie gepasst hat. Das sorgt dafür, dass ein Sprint sich sehr unbefriedigend und unproduktiv anfühlt und auch ist.

Daher ist für mich Scrum in wenigen Fällen wirklich geeignet. In meinen Augen muss die Arbeit, damit Scrum seine Stärken ausspielt, homogen sein. Alle Teammitglieder arbeiten an einem Produkt. Jeder im Unternehmen versteht den Rhythmus des Sprint Zyklus. Es gibt eine Produktvision und für jeden Sprint kann anhand der Vision ein Sprint-Ziel definiert werden das mehr ist als "Alle Stories sollen fertig werden". Jeder im Unternehmen versteht, dass eine Störung des Team das Team nur langsamer macht.

Als uns damals klar wurde, dass unsere Arbeit die obigen Bedingungen nicht (mehr) erfüllt, war uns klar, dass wir uns einer anderen - für unsere Situation besser geeigneten - Methode zuwenden müssen.

Wann Kanban seine Stärken hat

Kanban hat seinen Fokus auf das Managen der Arbeit. Kanban kenn kein Team und kennt auch keine ausdifferenzierten Rollen. Kanban wird oft auch als Change Management Methode bezeichnet und das ist richtig.

In Kanban akzeptieren wir, dass Arbeit sich permanent ändern kann. Sie kann wichtiger oder unwichtiger werden. Sie kann groß oder klein sein. Sie kann einfach oder komplex sein. Wir optimieren in Kanban unser System auf genau diese Erkenntnis. Wir passen uns an, weil die Welt sich permanent verändert. 

Wenn wir uns den Kern von Kanban ansehen, dann geht es darum den Fluss ("Flow") unserer Stationen zu optimieren. Eine Erklärung, was Flow bedeutet und welche Prinzipien in Systemen gelten, in denen Elemente fließen, findest du auf meiner Flow Physics Seite. Es geht hier um den Staffellauf, Little's Law, Flaschenhälse und Einschränkungen und "Work in Progress".

In unser Situation, die ich oben skizziert habe, ist Kanban deutlich besser geeignet um gute Software schnell zu liefern. Wir managen die Arbeit, nicht die Menschen. Wir praktizieren Kaizen - den permanenten Verbesserungsprozess - um in kleinen Schritten unser System an die Umwelt und die Herausforderungen anzupassen - Agil im Sinne von Flexibel.

Wenn du mehr über Kanban lesen willst, dann empfehle ich dir meinen Kanban Starter Guide und aufbauend darauf den Kanban Advanced Guide.

Was du jetzt tun kannst

Wenn du überlegst, welche Methode für dich geeignet ist, dann schau auf eure Arbeit. Was stellt ihr her? Wie stabil seid ihr und ist euer Umfeld geeignet, um einen Sprint stabil zu halten? Wo steht ihr in der Stacey Matrix?

Ich behaupte, für sehr viele von euch ist Kanban die bessere Wahl, da ihr permanent auf die Veränderung eurer Umwelt reagieren müsst und wenig Chancen auf einen stabilen Sprint habt. 

Ich behaupte weiterhin, dass viele von euch Scrum machen, weil es das bekanntere System ist und weil es aufgrund des Scrum-Guides klare Regeln gibt, was ein Team wann zu tun hat. Ebenso ist es - in der Hardcore Variante - im Management beliebt weil Scrum Mechanismen bietet, ein Team zu kontrollieren und zu gängeln. 

Und insgesamt ist kann ich jedem empfehlen über das Konzept von Shuhari zu lesen und nachzudenken. Vielleicht seid ihr in der Shu-Phase, vielleicht aber auch bei Ri? Es gibt oft genug Momente, wo man eine Methode verlässt - sei es im Kampfsport oder beim agile Arbeiten.