Ich habe mich aus den Debatten weitgehend herausgehalten, die Scrum mit Kanban vergleichen, und welche die beiden Techniken als Rivalen darstellen möchten. Ich habe Mattias Skarin und Henrik Kniberg aktiv ermuntert, die in Ihrem Buch „Scrum and Kanban - make the best of both" einen sehr guten Job beim Analysieren und Vergleichen gemacht haben!

Ich denke, dass ich einige Einsichten hinzufügen kann, die Henrik und Mattias nicht behandelt haben - Einsichten, die mir gekommen sind, während ich in den vergangenen neun Monaten die Welt bereist habe, um mit Teams und agilen Coaches auf 5 Kontinenten von kleinen innovativen Start-up-Unternehmen bis zu den größten Industrie- und Technologiekonzernen der Welt zu arbeiten.

Auf einer Ebene wird Scrum als gänzlich festgeschriebene Software-Entwicklungs-Lebenszyklus-Methode vorgestellt - Sprints, Scrums, Sprint-Planung, Retrospektiven, Demos usw. Die Führung der Scrum-Community ist bestrebt, darauf hinzuweisen, dass Scrum mehr ist als das: es ist ein Framework, um Änderungen und emergentes Verhalten in Organisationen zu provozieren.

Kanban ist keine Projektmanagement oder SW-Entwicklungs-Lebenszyklus-Methode. Es ist ein Ansatz für Änderungsmanagement - ein Framework um Änderungen in einer Organisation zu katalysieren. So unterscheidet es sich von Scrum, in dem es nicht als ein Prozess verwendet werden kann, um die Arbeit zu erledigen. Es muss auf einen existierenden Prozess angewendet werden. Dieser existierende Prozess kann Scrum oder gleichfalls jede andere Lebenszyklus-Methode sein, mit der Sie vertraut sind, oder etwas, das gar keinen Namen trägt - ein ad hoc Prozess. Als Framework für Änderungen jedoch kann man Kanban und Scrum als Alternativen vergleichen.

Zu diesem Aspekt der Verwendung als Frameworks für Veränderung, kann ich der existierenden Literatur etwas hinzufügen, da Kniberg und Skarin diesen Aspekt nicht behandelt haben.

Änderungskatalysator

Kanban verwendet die WIP-Grenze (WIP steht hier für Work in Progress, Anm. des Übersetzers) als Kontrollmechanismus, um Gespräche über Änderungen zu provozieren. Die WIP-Grenze zu missachten und Probleme nicht zu besprechen, führt zu Stagnation und Misserfolgen bei Verbesserungen. Veränderungsdiskussionen sind das Ziel, wenn Visualisierung, Messungen, explizite Verfahrensweisen und Modelle wie Lean, die Theory-of-Constraints (Engpasstheorie) und die Lehren von W. Edwards Deming einem Team erlauben, seine Probleme wissenschaftlich zu analysieren und Lösungen vorzuschlagen.

Scrum verwendet Verpflichtung (commitment) als Kontrollmechanismus. Verpflichtung geschieht auf zwei Ebenen: auf der persönlichen, täglichen Ebene - das wird durch das Daily Scrum und die drei Fragen verstärkt „was hast du gestern für uns getan?", „was wirst du heute für uns tun?" und „hindert dich irgendetwas daran, heute diese Verpflichtung zu erfüllen?"; die zweite Verpflichtung geschieht auf der Teamebene, dem Sprint-Commitment, dem Versprechen, etwas Bestimmtes zu einem bestimmten Datum zu liefern. Diese Verpflichtung nicht zu erfüllen sollte zu einer Diskussion über diesen Fehler führen, die eine Prozessverbesserung provozieren sollte. Wir könnten die Effektivität dieses Ansatzes diskutieren, aber lassen Sie uns annehmen, dass er funktioniert.

Also verwendet Kanban eine WIP-Grenze als Änderungsagent und Scrum verwendet Verpflichtungen. Das ist ein grundsätzlicher Unterschied in der Herangehensweise.

Evolution, aber nicht Revolution

Ken Schwaber hat über die „harten Begriffe in Scrum" gesprochen, wie Scrum (Gedränge), ScrumMaster, Sprint und so weiter. Scrum ist als Schockbehandlung einer Organisation angelegt. Es beinhaltet oft, dass Menschen neue Jobbezeichnungen, neue Rollen und neue Verantwortlichkeiten bekommen, und wird meist gemanagt eingeführt mit Schulungen und einem definierten Datum, an dem zu der neuen Methode gewechselt wird. Scrum einzuführen bedeutet eine Revolution. Es rüttelt die soziale Hierarchie einer Organisation auf und beeinflusst (positiv wie negativ) das professionelle Selbstbewusstsein und die Egos der Teammitarbeiter. Nicht jeder Projektleiter schätzt es, wenn ihm gesagt wird, dass er umschulen und eine neue Stellenbezeichnung annehmen muss! Für manche Organisationen wird dies die richtige Vorgehensweise sein - sie benötigen die Schockbehandlung, um eine Katastrophe zu vermeiden. Für andere ist das einzige Resultat gestiegener emotionaler Widerstand bei den Mitarbeitern und die Unterstützung passiv aggressiven Verhaltens.

Kanban ist als Antithese zu dem Scrum-Änderungsansatz entworfen. Mit Kanban startet man mit dem Prozess, den man jetzt hat. Man „kanbanisiert" ihn durch die Aufzeichnung des Wertstroms (Value-Stream-Mapping), seine Visualisierung, und die Begrenzung von Work-in-Progress  um ein Pull-System zu etablieren. Existierende Rollen, Verantwortlichkeiten, Stellenbezeichnungen und Praktiken bleiben erhalten. Die einzigen Veränderungen betreffen die Schnittstellen zu Partnern stromauf und stromab, wie den Businessverantwortlichen und dem Systembetrieb. Werden hier Änderungen gemacht, so geschieht das ausdrücklich, um zu vermeiden, dass die soziale Hierarchie aufgerüttelt oder eine emotional defensive Reaktion der betroffenen Menschen hervorgerufen wird.

Kanban provoziert evolutionäre Veränderung. Am Anfang bedeutet das Prozessoptimierung - Kaizen - aber allmählich, während die Organisation in ihren Fähigkeiten reift, führt es zu größeren, geführten Änderungen - Kaikaku. Man kann beobachten, dass fortschreitende Kaizen-Ereignisse zu verbesserter organisatorischer Reife und Fähigkeit führen und damit dramatischere Kaikaku-artige Änderungen ermöglichen.

Scrum wird also in genau gegensätzlicher Weise eingeführt als Kanban. Kanban ist weich weich und Scrum ist eine harte Schockbehandlung!

Übereinstimmung mit einem Prozess

Während Scrum als ein Startpunkt und ein Framework beworben wird, das Änderungen provozieren soll, gibt es einen wachsenden Markt in der Überprüfung von Praktiken und Assessments. Deren bekanntester Vertreter ist der von Jeff Sutherland gutgeheißene Nokia Test. Diese Tests bestimmen, ob Ihr Team Scrum befolgt. Wenn nicht, sagt man, das Team ist „Scrum-But" und Ken Schwaber hat es sich angewöhnt, Anwender von nicht-konformem Scrum mit dem heimtückischen Begriff „Scrum-Butts" (Scrum-Hintern) zu bezeichnen. Der Effekt dieser Konformitätstests ist, von Innovationen und der Abweichung von der Lehrbuch-Definition abzuschrecken. Das Nettoergebnis ist Verwirrung, da auf der einen Seite die Führung der Community den Anwendern sagt, dass Scrum emergentes Verhalten in ihren Organisationen katalysiert, während die gleiche Führung einen Test verschreibt, der angelegt ist, jene zu bestrafen, die von der Standard-Definition abweichen.

Kanban wurde als Ansatz entwickelt, der einen existierenden Prozess sich verändern und entfalten lässt, unabhängig davon, welcher Prozess dies zu Beginn war. Es ist daher unmöglich, einen Konformitätstest für Kanban zu entwickeln. Kanban verwendet fünf Kerneigenschaften, um das emergente Verhalten der Prozess-Entfaltung zu katalysieren. Diese fünf Eigenschaften sind: visualisiere den Workflow; begrenze Work-in-Progress; messe den Durchfluss; mache Prozess-Regeln explizit; verwende Modelle, um Verbesserungsmöglichkeiten zu evaluieren. Diese fünf stellen die Praktiken dar, die vorhanden sein müssen, damit der Kanban-Ansatz zur Veränderung funktioniert. Der Prozess eines Teams für Softwareentwicklung und Projektmanagement wird immer einzigartig sein, und über die Zeit wird er getailort und hinsichtlich des Wertstroms, Risikoprofils, der Skills und Fähigkeiten des Teams, den Kundenwünschen, Flaschenhälsen und Quellen der Variabilität, die das Team betreffen, optimiert werden. Es kann keinen Test für Konformität geben. Jede Messung, die angewendet wird, sollte messen, ob ein besseres ökonomisches und soziologisches Ergebnis durch die Enführung des Kanban-Ansatzes erreicht wurde.

Container versus Ganzes System

Es gibt eine Reihe anderer Eigenschaften, welche sich bei Kanban verwendenden Teams ausbilden, die sich von Praktiken in Scrum-Teams unterscheiden. Diese emergenten Unterschiede sind hauptsächlich ein Seiteneffekt davon, dass man nicht den „Container"-Ansatz von Scrum verfolgt. Scrum benutzt einen Container, bekannt als Sprint, der als Timebox eine Ladung Entwicklungsarbeit umschließt und eine Einmischung von Außen erschwert. Idealerweise sollte es keine Einmischung geben. Scrum versucht, wie eine gute Softwarearchitektur, die Schnittstellen des Containers zu minimieren, um eine lose Kopplung zu erreichen. Der gewünschte Effekt ist, die Aktivität im Container - die Entwicklung im Sprint - so vorhersehbar wie möglich zu machen, um die Sprint-Verpflichtung zu erfüllen.

Kanban benutzt keinen solchen Container, stattdessen fördert es eine Sicht auf das ganze System. Eine Reihe von Mechanismen vereinfacht die Koordination der Elemente im ganzen System. Die Kombination von Visualisierung und einem WIP-begrenzten Pull-System beispielsweise ermöglicht eine sehr einfache Schnittstelle zu den Businessverantwortlichen. Im Ergebnis brauchen viele Organisationen, die Kanban einführen, nicht das Konzept des einzelnen Product Owners von Scrum und können leicht mit mehreren konkurrierenden Businessverantwortlichen fertig werden, die an Warteschlangen-Nachfüll-Meetings (queue replenishment meetings) teilnehmen.

Es hat sich gezeigt, dass Kanban Stand-up-Meetings effektiv mit 50 oder mehr Personen durchgeführt werden können. Der Grund dafür ist, dass dem Team implizit vertraut wird, die Arbeit zu machen, die in der Visualisierung des Workflow zu sehen ist. Es ist nicht nötig, das Stand-up zu verwenden, um die persönliche Verpflichtung zu verstärken, daher kann sich das Stand-up auf die Arbeit anstatt auf die Menschen konzentrieren. Teams werden eher die Arbeitstickets durchgehen als die Teammitglieder. Die drei Fragen werden obsolet. Reifere Kanban Teams reduzieren die Diskussion auf die Arbeit, die blockiert oder fehlerhaft ist, und fokussieren sich nur auf die Ausnahmen anstatt auf die Arbeit, die normal voranschreitet.

Wie man auch beobachtet hat, haben Organisationen, die Kanban verwende, kleinere Teams verschmolzen, um die reduzierten Koordinationskosten auszunutzen und ihren Bestand an Arbeitskräften besser zu nutzen. Man trifft durchaus auf Teams von 20 bis 30, manchmal sogar 50 Personen, die häufig aus mehreren (früheren) Scrum-Teams, oder aus einer Mischung von Scrum- und nicht agilen Teams zusammengesetzt werden. Die Workflow-Visualisierung beinhaltet häufig mehrere Zeilen (oder Swimlanes), um unterschiedliche Entwicklungsströme zu repräsentieren. Einige Teammitglieder können einer Swimlane fest zugeordnet werden, die zuständig und verantwortlich für die Arbeit in dieser Swimlane sind, während andere zwischen Zeilen springen dürfen, um mehr Manpower oder Spezialskills zur Verfügung zu stellen. Das Ergebnis ist ein effektiverer und effizienterer Einsatz der vorhandenen Menschen, was zu höherem Durchsatz und kürzeren Durchlaufzeiten führt.

Abschließende Gedanken

Ich glaube, dass wir gerade erst beginnen, die Unterschiede zwischen Scrum und Kanban zu verstehen. Ich glaube, dass unser Verständnis wachsen wird, je mehr emergente Eigenschaften von Kanban-Organisationen als sich wiederholende Muster im Feld beobachtet werden. Kanban unterscheidet sich von Scrum. Wo wir noch lernen, ist, wie die Einführung von Kanban in eine Organisation, die Scrum verwendet, diese Organisation, ihre Kultur und Methoden verändert. Ich glaube, dass Kanban mit den Mechanismen von Scrum kompatibel ist. Es ist kompatibel mit Scrum, der Projektmanagement-Methode. Scrum mit WIP und Visualisierung anzureichern, wird helfen, die Effektivität der Sprint-Verpflichtung zu verbessern. Es führt jedoch auch die WIP-Grenze als Mechanismus ein, um inkrementelle Änderungen zu katalysieren. Scrum Teams, die diesen Ansatz verwenden, werden Scrumban Teams genannt. Die WIP-Grenze vermeidet die Notwendigkeit, die Änderungen durch Verpflichtungen voranzutreiben, reduziert jede dysfunktionale Abhängigkeit von Heldeneinsätzen, und verbessert insgesamt das Systemdenken, wenn man über potenzielle Verbesserungen nachdenkt. Scrumban wird die Scrum-Philosophie und das -Framework durch den Kanban-Ansatz ersetzen. Es mag auf der praktischen Ebene noch etwa wie Scrum aussehen, aber auf der kulturellen Ebene wird es Kanban sein - weich weiche Evolution anstelle von Schockbehandlung und Revolution.

Wenn Sie überlegen, ob Scrum oder Kanban für Sie und Ihr Unternehmen das Richtige ist, bedenken Sie die Kultur und den Reifegrad. Wenn Ihre Organisation einen niedrigen Reifegrad, begrenzte Fähigkeiten im Risikomanagement, Änderungsmanagement und der Entscheidungsfindung hat, von Spezialisierung und Verteidigungshaltung durchsetzt ist, dann ist Kanban vermutlich die bessere Wahl. Wenn auf der anderen Seite Ihre Organisation einen hohen Reifegrad hat und in der Lage ist, Risiken einzuschätzen, Prozessalternativen abzuwägen, gute Qualitätsentscheidungen zu treffen und Änderungen mit großen Auswirkungen elegant zu managen, dann ist Scrum für Sie wohl die richtige Wahl. Wenn Sie vor einem Ereignis stehen, dass die Auslöschung Ihres Unternehmens bedeuten könnte und Sie nicht die Zeit haben, die Evolution Ihre magische Wirkung auf Ihre Organisations-Performance entfalten zu lassen, dann ist eine Scrum-Revolution das Risiko vielleicht wert.