Drücken Sie Enter, um das Ergebnis zu sehen oder Esc um abzubrechen.

Scrum ist KANBAN – aber spielt das eine Rolle?

In den letzten Wochen, haben wir uns viel mit den Ideen zu Second Generation Lean Product Development von Don Reinertsen beschäftigt. Seine Ideen sind u.a. die Grundlage, um KANBAN, die von David Anderson ins Leben gerufene Methode, die sich derzeit als Gegenentwurf zu Scrum verkaufen lässt, zu verstehen. Nachdem wir uns intensiv mit den Gedanken von Don Reinertsen auseinandergesetzt hatten und ich im letzten Jahr das Seminar von Anderson besucht hatte, war mir immer weniger klar, wieso Leute der Meinung sind, dass Scrum und KANBAN etwas Unterschiedliches seien. Klar – es gibt ein paar unterschiedliche Best-Practices, aber spätestens, wenn man die Kadenzen in KANBAN-Teams einführt oder auf einem Scrumboard ein zweite Zeile, in der man zwei Projekte voneinander trennt, einführt (Swim-Lanes), heben sich die Unterschiede schnell auf.

 

Wieso also diese Unterschiedlichkeit und der teilweise heftig geführte Schlagabtausch, ob nun „Scrum revolutionär“ und „KANBAN evolutionär“ sei (David Anderson) und wieso war ich selbst anfangs so sehr von KANBAN enttäuscht? Denn ich hatte in KANBAN, mit Ausnahme der Idee der besseren Metriken und der Möglichkeit, nun erklären zu können, wieso Scrum funktioniert, nichts Neues gesehen. Und ich hatte den Nachteil gesehen, dass KANBAN Teams die Möglichkeit lässt, den Wasserfall als Verhinderer von Agilität im Team zu belassen.

Zwei Seiten des U

Unser Teammitglied Sven Winkler, der u.a. die Agile User Group Nürnberg (Agile Monday) mit veranstaltet, hatte dann eine Eingebung: Nachdem er von der Theorie U gehört hatte, einem Themenschwerpunkt in unserer ScrumMaster Pro Ausbildung, zog er den Vergleich, dass KANBAN auf dem linken Ast liegt und Scrum auf dem rechten. Heureka!

 

Na klar! KANBANs Stärke liegt darin  die Arbeit und die Bottlenecks aufzuzeigen. Bevor diese Probleme nicht klar und deutlich vor Augen liegen, verändert man erst einmal nichts. KANBAN beginnt mit der Aufnahme des existierenden Prozesses, zeigt die Value Chain auf und zeigt dann die Bottlenecks. Dadurch entsteht so etwas wie ein Bewusstsein über die Verhältnisse und es werden keinerlei Veränderungen von einem Team verlangt. Erst wenn es selbst merkt, dass ein Prozessschritt nicht weitergeht, dann wird gehandelt. Dann führt man ein Work in Progress Limit ein, dann die Kadenzen und schließlich noch die Retrospektiven.

 

Demgegenüber liegt auf der rechten Seite des Us: die Lösung, die Synthese und die Epiphanie. Scrum geht von der Tatsache aus, zu wissen, welcher Prozess (nämlich der Deming Cycle) zur kontinuierlichen Verbesserung führt und macht von Anfang an klar, dass es gewisse Verantwortungen zu erfüllen gibt. Ausgehend von einem in den 1980ern wissenschaftlich evaluierten und durch Case Studies abgesicherten Bild, wie das Management von Produkten laufen sollten, hatte sich ja eine Methode etabliert, die genau wusste, wie es geht und was es braucht, damit Teams hyper-erfolgreich werden können.

Scrum nutzt Aspekte aus, die selbstverständlich auch klar werden, wenn man lange genug KANBAN macht. Don Reinertsen erwähnte übrigens in unserem Seminar, dass Scrum im Grunde Second Generation Lean Product Development ist.

 

Scrum liefert quasi bereits die Lösung:

Teamzentriertheit, Sichtbarkeit, Best Practises wie z.B. das Taskboard, Kadenzen, regelmäßige Meetings und Lieferungen, Work in Progress Limits on the fly = WIP/pro Sprint = Commitment und ein Backlog.

 

Also die Idee, in Lieferungen anstatt in Aufgaben zu denken.

 

Scrum führt zu Widerstand

Aber, all das liegt auf der Lösungsseite und nicht wie KANBAN auf der Analyseseite. Nimmt man nun das SCARF-Modell von David Rock (Brain@Work), wird sofort klar, wieso Scrum bei vielen Teams und Managern zu Widerstand führt, während KANBAN sich leichter integrieren lässt und anpasst:

 

  1. Scrum Evangelisten gehen zu Teams und sagen: „Ihr müsst anders arbeiten.“ Das führt zu Widerstand, weil man das Team in seinem Status herabsetzt.
  2. Scrum Evangelisten sagen oft: „Ihr seid das Team! Findet heraus, wie ihr arbeiten wollt.“ Das führt zu Unsicherheiten beim Team. KANBAN sagt: „Ändert mal nichts. Wir wertschätzen, was ihr bis jetzt gemacht habt. Findet dann SELBST heraus, was ihr ändern wollt.“
  3. Damit haben sie das Prinzip der Autonomy besser als Scrum Evangelisten geachtet. Denn wieder überlässt man es dem Team zu entscheiden, was zu tun ist.
  4. David Rock behauptet weiter, dass Verbundenheit für Menschen wichtig ist. Mit Scrum stellt man sich zunächst in die „wir sind anders und ihr müsst euch ändern“-Ecke. Das ist nicht gerade ein Thema der Verbundenheit. KANBAN macht auch hier wieder genau das Gegenteil: „Wir sind wie ihr. Wir fragen mal nach, welchen Prozess ihr habt.“ (In der deutschen Organisationsentwicklungsszene nennt man das „Macht Betroffene zu Beteiligten“).
  5. Last but not least: Scrum Evangelisten verletzen das Thema Fairness. Sie zeigten auf, dass die Arbeitsprozesse, die bisher geleistet wurden, nicht gerade perfekt sind, und dass zum Beispiel Manager daran „schuld“ sind. Menschen nehmen das nicht gerade gut auf, wenn sie so „vorgeführt“ werden. Auch hier hat KANBAN, da es sich auf der linken Seite der U-Kurve befindet, noch keinen „Angriff“ gestartet. Es sensibilisiert zunächst und durch den expliziten Satz „Die Betroffenen wissen immer am besten, wie man arbeitet“, macht KANBAN zunächst klar: Ihr seid ok!

 

Gerade für das mittlere Management, die Quelle der Veränderungsresistenz, ist auf den ersten Blick KANBAN zu Anfang die weniger gefährlichere Variante. Viele Consultants nutzen das. Sie machen die Tatsache, dass Scrum den Ruf hat, Dinge zu verändern zu ihrem Verkaufsargument, Indem sie sich gegen Scrum und nicht gegen den Wasserfall aufstellen. Also nicht mehr sagen, wir wollen das traditionelle Management verändern, sondern agile ohne Scrum werden. Sie nutzen eine rhetorisch sehr geschickte Variante der Überzeugung. Sie zeigen auf, dass es ein Schreckensszenario gibt: „Mit Scrum verändert man etwas, da ist auch nicht klar, was mit Ihnen als Manager wird. Bei Scrum, da verändert man zuerst die Rollen und deshalb muss das Management mitziehen.[1]

 

Jetzt werden einige sagen (meine Frau, der ich diese Zeilen vorgelesen habe, hat es sofort gesagt): „Er schreibt gerade gegen Scrum, also gegen das eigene Business.“ Naja, auf den ersten Blick schon. Zumindest wissen jetzt die Leser, wie man KANBAN effektiv gegen Scrum pitcht. Aber eines muss ich an dieser Stelle einfach loswerden: Scrum ist auf der rechten Seite des Us. Scrum ist das Zielmindset: Jurgen Appelos Management 3.0 oder Gary Hamels Management 2.0 [https://www.phoenix.edu/lectures/gary-hamel/management-2.html] sind in Scrum bereits inkludiert. Scrum hat die Ideen von IDEO zur Produktentwicklung aufgenommen und heute reden wir von der Discovery-Phase. Die fundamental anders abläuft, als der damals von einigen eingeforderte Zero Sprint. Sie ist notwendig, weil wir heute verstanden haben, dass man mehr als ein Backlog braucht. Scrum hat aufgedeckt, dass wir in vielen Firmen fundamentale Kenntnis-Defizite haben. Das fängt bei den Entwicklern an, die nicht über agile Entwicklungspraktiken verfügen, geht bei Produktmanagern weiter, die nur Anforderungsmanager sind, und zeigt auf, dass das Management in den Unternehmen nicht damit klar kommt, Umgebungen herzustellen, die für Teams geeignet sind. Scrum hat gemeinsam mit den neuen Entwicklungsmethoden die Zukunft, die Vision aufgezeigt.

 

Don Reinertsens Second Generation Lean Product Development ist, so wie er es sowohl in seinem Buch, als auch in seinem Training darstellt, in KANBAN noch lange nicht aufgegangen. Er spricht davon, Ideen der deutschen Kriegsführung (der Auftragstaktik und des Maneuver Warfare (Bewegungskriegs)) in das Managen der Produktentwicklung aufzunehmen und die Ideen der US Marine Doctrine einzubauen, also: „Less Detailed Planning, Little Status Reporting, React to the Battle, Decentralized Control“, uvm. Damit erzeugt er ein Modell der agilen Organisation, wie wir es bereits von Peter Drucker und Tom Petersen kennen und wie es heute von Gary Hamel vertreten wird. Spannend zu sehen, dass wieder der Krieg der Vater aller Dinge ist: Scrum wurde von US Militär Alumnis entworfen, Second Generation Lean Product Development von einem Ex-Marineoffizier. Könnte es sein, dass Ideen aus Situationen, in denen es darum geht, schnell zu sein und Territorium zu gewinnen, genau die Rezepte an Bord haben, um neue Märkte und neue Produkte zu entwickeln? Es ging immer um das NEW NEW PRODUCT DEVELOPMENT GAME. Lasst uns gemeinsam Unternehmen erschaffen, in denen Menschen sich optimal entfalten können.

 

Second Generation Lean Product Development
Applying the Principles of Flow

am  10. und 11. September 2012 in München

—————
[1] Übrigens denke ich mir solche Argumentationsstrategien nicht aus. Auf der OOP 2011 kam tatsächlich ein Consultant auf mich zu und hat mir genau diese Argumentationskette als seinen Verkaufspitch erklärt. Damals war ich einfach nur betroffen. Ich dachte immer, wir in der agilen Community wollten zusammen den Wasserfall, das Management des 19. Jahrunderts „bekämpfen“. Die Idee, eine Methode, die erwiesenermaßen das Gute will, schlecht zu machen, nur um die eigene Methode zu verkaufen, war mir bis dahin vollkommen fremd. Klar hatte ich gegen KANBAN geschrieben, aber nur weil wir mit Scrum schon um vieles weiter waren als KANBAN. KANBAN war und ist für mich ein Rückschritt.

  • Stefan Braun

    Die Darstellung mit Kanban als analytisches Verfahren und Scrum als ‚fertige‘ Lösung  passt für mein Gefühl ganz gut. 

    Daraus leite ich aber ab, dass Kanban (für mich!) der bessere Weg ist. Es macht Sinn, die eigene Situation zu analysieren und dann gezielt zu verbessern. Dagegen ist es riskant eine fertige Lösung einfach anzuwenden – auch wenn sie natürlich auf Erfahrungen anderer (in einem anderen Umfeld, mit anderen Rahmenbedingungen ;-) beruht. 
    Der Punkt ist doch, dass sich die Welt ändert. Damit ist ein stetiger Wandel der Methodik erforderlich; das gilt ja auch für Scrum. Einen analytischen Ansatz zu verwenden, zu messen und dann gezielt zu verbessern, ist dabei eigentlich unumgänglich. Genau dies ist aber das Grundprinzip von Kanban.

    Veränderung ist immer ein schwieriger Prozess, besonders wenn die Veränderung von aussen kommt. Selbst Veränderungen anzustoßen, daran beteiligt zu sein, macht die Sache viel einfacher – auch, wenn es vielleicht am Anfang etwas länger dauert. Da dies kein einmaliger Vorgang ist, sondern eigentlich ein Dauerzustand, ist diese Lernphase aber um so wichtiger.

    Herzliche Grüße,    Stefan Braun

    P.S.:
    Diesen Satz finde ich übrigens haarsträubend: „Scrum geht von der Tatsache aus, zu wissen, welcher Prozess (nämlich der Deming Cycle) zur kontinuierlichen Verbesserung führt und macht von Anfang an klar, dass es gewisse Verantwortungen zu erfüllen gibt.“  „… von der _Tatsache_ aus, zu _wissen_ …“. Ist das ernst gemeint?

    • bgloger

      Hi Stefan, 
      geht es wirklich um besser oder schlechter? Meines erachtens nicht, sondern es geht darum zu entscheiden, was man erreichen will, und welcher Weg dahin der für den jeweiligen Menschen, das Team, oder das Unternehmen der geeignete ist. Für mich ist das so ein wenig wie die Frage – welches ist die richtige Kampfsport Art: Judo, Karate, Aikido, Boxen, Kickboxing, … Gibt es die richtige? Sicher nicht – aber du kannst nicht gut darin werden mehrere Kampfsportarten zu perfektionieren, wenn du nicht mit der ersten beginnst und sie erlernst. Erst wenn du mit der einen Methode in der Lage bist dich ernsthaft zu verteidigen, macht es Sinn, die nächste zu erlernen.

      Mein Argument war — Scrum ist wissenschaftlich erprobt, fundiert auf natur- und geisteswissenschaftlich getesteten und experimentell überprüfbaren Verfahren und in vielen Fällen bringt es ganz erstaunliche Ergebnisse in sehr kurzer Zeit. 

      Wer sich darauf einlässt wird profitieren. Wer KANBAN macht kommt am Ende – wenn er all das tut, was Scrum als Guideline mitbringt – wieder auf alle Prinzipien zurück, die Scrum (aus meiner Sicht heraus) mitgebracht hat. Denn wenn das nicht so wäre, wäre Scrum als Management-Framework ja nicht erfolgreich. Wie man arbeitet gibt Scrum dabei ja – ebenso wenig vor wie es KANBAN auch nicht tut.

      Es geht nicht um richtig und falsch – es geht um – machen, was funktioniert! 

      • Hi Boris,
        mit besser meinte ich die Entscheidung, welcher Weg der für mich geeignetere ist. Dies bezog sich auf die Aussage (vereinfacht): 
        Kanban = analytisch vs. Scrum = Lösung.

        Damit wollte ich keine generelle Aussage über Scrum oder Kanban machen. Entscheidend dabei ist für mich, dass zu zielgerichteter stetiger Weiterentwicklung eben Analyse notwendig ist – fortwährend.
        Was mich zum Schreiben motiviert hat, war vor allem diese feste Überzeugung, dass Scrum quasi bereits den Zielzustand markiert, den man mit Kanban erst mühsam erreichen muss. Das mag sein, Scrum ist erfolgreich und funktioniert – keine Frage. Aber woher kommt diese feste Überzeugung, dass Scrum die beste Lösung für alle ist? Aber gut, das relativierst du ja in deiner Antwort auch wieder.

        Weitere Fragen: 
        * Kommt man mit Kanban immer zum gleichen Zielszustand (also Scrum)?  Meines Erachtens nicht; man kann aber natürlich.
        * Ist nicht auch der Weg dahin von Bedeutung? Kaum jemand wird bestreiten, dass es ganz schön hart sein kann, Scrum konsequent einzuführen. Vielleicht ist manchmal ein anderer Weg besser, der die Menschen mitnimmt, weil er ihnen verständlich macht, wo ihre Probleme liegen und sie damit in die Lösung einbezieht. Das ist eine Entwicklung die Zeit braucht.

        Gerade der letzte Punkt ist für mich wichtig. Das heißt ja nicht, dass man sich nicht von Scrum oder anderen Ansätzen inspirieren lassen sollte. Wichtig ist aber zu verstehen, _warum_ man etwas macht.

        Eigentlich geht es mir also genau um den zweiten Satz deiner Antwort: „… es geht darum zu entscheiden, was man erreichen will, und welcher Weg dahin der für den jeweiligen Menschen, das Team, oder das Unternehmen der geeignete ist“. Und um den letzten: „… machen, was funktioniert“.

        Damit sind wir schon wieder viel näher beisammen :-)

      • bgloger

        Für uns war und ist Scrum, mal abgesehen von der anfänglichen Begeisterung vor 10 Jahren, nie der „Hammer“ mit dem man alle Probleme löst, oder die Methode, die immer Erfolg bringt – sondern es war immer ein Framework, der sehr schnell die im Unternehmen vorhandenen „Hindernisse“ aufzeigt. 

        Scrum als Organisationsmethode war immer der ideale Zielzustand, der nie erreicht werden kann. Scrum auf der Ebene der Best Practices – nun da haben wir immer versucht Lösungen für die in Unternehmen immer wieder aufkommenden Probleme zu finden. 

        Ich glaube manchmal, es hat was mit dem Menschen selbst zu tun, was „besser“ zieht. Der „Zielzustand“ oder das „von etwas wegbewegen“. Die einen fühlen sich durch die Spannung von Ist und Soll motiviert, die anderen lähmt es. 

        Was mich immer motiviert hat war – „es muss doch besser gehen!“ Es muss doch einen Zustand der theoretisch richtig ist geben. (Wobei ich mir vollkommen klar darüber bin, dass das eine vom mir vorgestellt Konstruktion ist.) 

        Ich finde deine beiden Fragen absolut genial! Ehrlich – genau das hat mich umgetrieben. 

        zu 1. Mit KANBAN kommt man tatsächlich nicht zwangsläufig bei Scrum raus – man könnte „stecken bleiben.“ Das muss für das betroffene System (Team, Organisation,) gar nicht „schlecht“ sein, sondern vollkommen adäquat. Hier finde ich es wiederum gut einen „Benchmark“ zu haben – der war für mich das Agile Manifesto in der Umsetzung von Scrum. Immer im Bewusstsein – es ist eh nicht vollständig erreichbar.

        zu 2. Klar ist der Weg das Ziel – wenn es im Laufe der Veränderung nicht gelingt, Menschen mitzunehmen ist es erst einmal unschön. Auch ich fände es toll, wenn jeder mitmachen würde. Aber ist das realistisch und was bedeutet das genau? Muss überhaupt jeder mitmachen? Ich denke nicht! Und ganz oft hat das auch etwas damit zu tun, wie viel Zeit und Ressourcen man hat. Wie geduldig man ist und – was man bereit ist für das Nicht-erreichen des Zielzustandes zu zahlen. Die Lösungszentrierten Ansätze gehen sogar davon aus – die Probleme zu kennen ist erst einmal gar nicht zielführend – sondern es geht manchmal auch ohne, den Weg über die Analyse. Dann benötige ich aber wieder einen Zielzustand, oder besser – Rahmen, ein Modell, an dem ich Orientierung gewinnen kann. Wenn man Abweichungen nicht als „Fehler“, sondern als „bewusst gewordene Differenz“ begreift, dann kann man immer noch entscheiden, wie es weiter geht. 

        Oder ich gehe rein ziellos vor – geht das überhaupt? Also nur auf – was wäre das nächste, was ich jetzt gerade tun kann? – Aber selbst die absichtslose Absichtlichkeit, die wir aus dem Buddhismus kennen – legt die Absicht als unterliegende Tatsache voraus. 

        Veränderung hin auf etwas braucht m.E. immer auch ein wenig Push! Ganz ohne den Impuls geht es auch nicht. Aber die Dosis muss angepasst sein – auf jeden Fall.

        Es geht also tatsächlich um die ständige Ausrichtung hin auf einen Zielzustand, der ständigen Kurskorrektur, der ständigen Überprüfung – und den einen führt der Weg an X, den anderen an Y vorbei.

      • Das trifft es gut: es muss für die Beteiligten passen. Das sollte immer der Maßstab sein. Natürlich kann man nicht immer jeden mitnehmen; mancher tut sich mit Veränderungen schwer und man muss dann eben helfen – auch durch Vorgaben. Aber wichtig ist, dass nicht zu viel Energie für den Änderungsprozess selbst eingesetzt werden muss, sonst blockiert man sich.
        Zielloses Vorgehen ist wohl meist nicht sinnvoll. Wobei das Ziel – ob mehr Effizienz, Effektivität, oder Qualität – ja oft schon da ist, nur der Weg dahin liegt im Dunkel. Da hilft dann natürlich Erfahrung, die man eben auch durch z.B. Scrum nutzen kann.Veränderung braucht immer einen Push  – praktisch ist das meistens eine wirtschaftliche Notwendigkeit. Und dann geht es um eine Lösung.

        Danke für die interessante Diskussion!

  • Martin Stallmaier

    Wer einen raschen Wechsel erreichen möchte, hat sich selbstverständlich der Herausforderung zu stellen sein Team mit  zu nehmen.

    Einige der angeführten Aussagen und Verhalten von sog „Scrum Evangelisten“ klingen in meinen Ohren wie old school – eben nach comande and control.Nicht wirklich agil – oder täusche ich mich?
    Aber das wichtigste ist doch weg vom Wasserfallsklaventum.

  • ec35

    Leider werden hier Unwahrheiten wie SCRUM ist erfolgreich (in der Tat hat es eine Failure-Rate von 80%) und es ist wissenschaftlich Bewiesen (nein, ist es eben nicht) verbreitet.

    Wenn Sie von wissenschaftlich Bewiesen und erfolgreich reden meinen Sie doch sicherlich Kanban.