Welche Methode ist besser? Scrum oder Kanban, Lean oder Agile, Scrumban oder Kanrum? In diesem Beitrag gibt es endlich eine passende Antwort.
Wir werden immer wieder gefragt, ob Methode A nicht besser als Methode B sei. Hier im Teamwork-Blog habe ich schon mehrere Beiträge dazu geschrieben /siehe 1, 2, 3, 4/. Die Frage lässt sich ohne Kenntnis der Problemlage nicht beantworten.
Nehmen wir an, Sie überlegen, ob Sie Scrum oder Kanban nutzen wollen, um in ihrem Team ein neues Produkt zu entwickeln. Wenn ich bei Google nach "Scrum Kanban Vergleich" suche, bekomme ich mehrere Millionen Treffer aufgelistet.
Die meisten Artikel finde ich nicht gut: Sie listen viele Details auf und beziehen sich auf den Methode selbst. In einem Artikel wird als erster Unterschied folgendes aufgeführt: "Scrum schreibt einen festen Zeitrahmen für Iterationen vor, bei Kanban sind sie optional." Das ist nur auf den ersten Blick richtig, weil es bei Scrum Sprints gibt und bei Kanban nicht. Auf den zweiten Blick stimmt es aber nicht. Beide Arbeitsweisen nutzen eine Taktung, um zu prüfen, wo das Team steht.
Wenn es konkret um den Vergleich von Scrum und Kanban geht, finde ich das Minibuch von Henrik Kniberg und Mattias Skarin gut, von dem es auch eine Version in deutscher Sprache und eine Kurzfassung gibt. Ich konnte das aber nur bewerten, weil mir die Autoren etwas sagen und weil ich mich in beiden Bereichen ein bisschen auskenne.
Wie findet nun jemand eine Antwort, wenn er sich nicht auskennt und auch nicht weiß, wer die Experten sind?
Wenn Sie sich mit neuen Arbeitsweisen auseinandersetzen, könnten Sie zum Beispiel Umfragen nutzen. Aber was sagt Ihnen das, wenn Scrum am weitesten verbreitet ist und Kanban am schnellsten wächst? Und dann lernen Sie noch, dass die scrum.org einen Leitfaden für Kanban für Scrum-Teams veröffentlicht hat.
Sie könnten nun die Historie der Arbeitsweisen verfolgen. Im Jahr 1993 hat Jeff Sutherland bei Easel des erste Scrum-Team aufgebaut, 2006 hat David Anderson bei Corbis das erste Kanban-Team aufgebaut. Aber das hilft leider auch nicht bei der Entscheidung.
Es ist besser statt der Chronologie der Ideengeschichte zu folgen. Ideen entstehen und verändern sich ständig. Wie biologische Arten entstehen durch Selektion und Anpassung neue Konzepte und sie entwickeln ein Eigenleben.
Hier folgt eine kurze Ideengeschichte zu Lean, Scrum, Agile und Kanban.
Scrum und Kanban bauen beide auf Lean Thinking und den Erfahrungen bei Toyota auf (/5/ und /6, S. ix/). Die Ideen bei Toyota wurden eigentlich nach dem 2. Weltkrieg aus den USA importiert. Dort gab es ein Ausbildungsprogramm für Firmen, deren Mitarbeiter zum Militärdienst eingezogen wurden. Dieses Programm sollte dabei helfen, schnell neue Mitarbeiter anzulernen, Konflikte zu vermeiden und Arbeitsabläufe zu optimieren.
Hier sind wir an einem Punkt, der für das Grundverständnis von Lean sehr wichtig ist. Wie können Sie eine industrielle Produktion organisieren, wenn erfahrene Mitarbeiter und Material fehlen? Sie müssen mit den Leuten und dem Material auskommen, was zur Verfügung steht. Der Supervisor war dafür verantwortlich, dass neue Mitarbeiter angelernt, Konflikte vermieden und ständig etwas verbessert wurde.
Mit dem Anlernen konnte man sich nicht ewig Zeit lassen. Deswegen musste man ein Verfahren entwickeln, dass erwiesenermaßen funktionierte. Um Arbeitsgänge zu vermitteln wurden sog. Job Breakdown Sheets erstellt. Diese zeigten nicht alle Schritte, sondern nur die wesentlichen auf. Auch für die Verbesserung wurden die wesentlichen Schritte (wenn auch etwas anders) notiert. Bei Toyota wurde daraus standardisierte Arbeit und Value Stream Mapping.
Um die Wirksamkeit des Ausbildungsprogramms zu zeigen, mussten die Firmen Zahlen berichten. Welche Zahlen werden wohl während des Krieges wichtig gewesen sein?
Dieses Wissen gerät nach dem Krieg in den USA in Vergessenheit. Erst die MIT-Studie hat in den 1980er-Jahren dieses Wissen wieder systematisch erfasst (ohne allerdings die Ursprünge zu erwähnen).
In Japan war dieses Wissen sehr willkommen, um die am Boden liegende Wirtschaft nach dem 2. Weltkrieg wieder aufzubauen. Toyota hat viele Dinge verfeinert. Das ursprüngliche Vorgehen bei der Verbesserung sah 4 Schritte vor, von denen der 2. Schritt hieß "Hinterfrage jedes Detail". Bei Toyota hat man sich die Frage gestellt, ob es bestimmte Arten von Details gibt, die man zuerst hinterfragen sollte. So kam man auf 7 Arten von Verschwendung (Transport, Lagerhaltung, Bewegung, Wartezeiten, Überproduktion, Überbearbeitung und Fehler). Dabei entstand auf der Begriff des Arbeitsflusses (engl. flow). Kaizen bedeutete, täglich viele kleine Dinge zu ändern. Große Sprünge waren während des Krieges nicht möglich. Es gab nicht mehr Geld und man konnte keine neuen Maschinen kaufen. Sie wurden einfach nicht produziert.
Es entstanden Techniken wie Kanban, um den Bestand an zu lagernden Teilen gering zu halten. David Anderson hat die Prinzipien von Kanban für die Fertigung später für die Aufgabenbearbeitung in einem Wartungsteam genutzt /7/.
Anfang des 19. Jahrhunderst wurde in der preussischen Armee die Auftragstaktik entwickelt. Es dauerte eine Weile, bis sie sich durchgesetzt hat. Aber ihr Nutzen war nachweislich erfolgreicher als die sog. Normaltaktik. Bei der Normaltaktik gibt ein Offizier den Untergebenen detaillierte Anweisungen, wie sie sich zu verhalten haben. Bei der Auftragstaktik gibt ein Offizier klare Aufträge und den Rahmen vor, überlässt die Ausführung den Untergebenen. Dadurch dass diese den Sinn verstehen, können die Untergebenen bei Veränderungen ihr Verhalten anpassen, um trotzdem das Ziel des ursprünglichen Auftrags zu erreichen.
John Boyd zählt zu den besten US-amerikanischen Kampfpiloten des 20. Jahrhunderts. Jeff Sutherland, einer der Väter von Scrum und selbst Kampfpilot, wurde stark von Boyds Ideen geprägt. Insbesondere seine OODA-Loop hatte es ihm angetan. Feedback zur Situation und zu den eigenen Handlungen hilft dabei, komplexe Probleme zu lösen.
Erst kam Scrum, danach das Agile Manifest (und danach Kanban). Agil ist wie Arbeiten nach Lean Prinzipien aber ergänzt um Feedback von Kunden. Der Name Agile kam von einem bestimmten Buch /8/.
Welche Konzepte können wir aus dieser Ideengeschichte festhalten?
Darf ich Ihnen nun einige Fragen stellen, bevor Sie sich für Scrum oder Kanban entscheiden:
Bei der Methodenauswahl kann die Ideengeschichte helfen, die wesentlichen Begriffe zu verstehen. Das empirische Arbeiten hilft Ihnen dabei, Ihre eigenen Ideen zu überprüfen.
Gegenfrage: Welches Problem wollen Sie lösen?
Wir werden immer wieder gefragt, ob Methode A nicht besser als Methode B sei. Hier im Teamwork-Blog habe ich schon mehrere Beiträge dazu geschrieben /siehe 1, 2, 3, 4/. Die Frage lässt sich ohne Kenntnis der Problemlage nicht beantworten.
Nehmen wir an, Sie überlegen, ob Sie Scrum oder Kanban nutzen wollen, um in ihrem Team ein neues Produkt zu entwickeln. Wenn ich bei Google nach "Scrum Kanban Vergleich" suche, bekomme ich mehrere Millionen Treffer aufgelistet.
Die meisten Artikel finde ich nicht gut: Sie listen viele Details auf und beziehen sich auf den Methode selbst. In einem Artikel wird als erster Unterschied folgendes aufgeführt: "Scrum schreibt einen festen Zeitrahmen für Iterationen vor, bei Kanban sind sie optional." Das ist nur auf den ersten Blick richtig, weil es bei Scrum Sprints gibt und bei Kanban nicht. Auf den zweiten Blick stimmt es aber nicht. Beide Arbeitsweisen nutzen eine Taktung, um zu prüfen, wo das Team steht.
Wenn es konkret um den Vergleich von Scrum und Kanban geht, finde ich das Minibuch von Henrik Kniberg und Mattias Skarin gut, von dem es auch eine Version in deutscher Sprache und eine Kurzfassung gibt. Ich konnte das aber nur bewerten, weil mir die Autoren etwas sagen und weil ich mich in beiden Bereichen ein bisschen auskenne.
Wie findet nun jemand eine Antwort, wenn er sich nicht auskennt und auch nicht weiß, wer die Experten sind?
Wie sind die Methoden GENAU entstanden?
Wenn Sie sich mit neuen Arbeitsweisen auseinandersetzen, könnten Sie zum Beispiel Umfragen nutzen. Aber was sagt Ihnen das, wenn Scrum am weitesten verbreitet ist und Kanban am schnellsten wächst? Und dann lernen Sie noch, dass die scrum.org einen Leitfaden für Kanban für Scrum-Teams veröffentlicht hat.
Sie könnten nun die Historie der Arbeitsweisen verfolgen. Im Jahr 1993 hat Jeff Sutherland bei Easel des erste Scrum-Team aufgebaut, 2006 hat David Anderson bei Corbis das erste Kanban-Team aufgebaut. Aber das hilft leider auch nicht bei der Entscheidung.
Es ist besser statt der Chronologie der Ideengeschichte zu folgen. Ideen entstehen und verändern sich ständig. Wie biologische Arten entstehen durch Selektion und Anpassung neue Konzepte und sie entwickeln ein Eigenleben.
Hier folgt eine kurze Ideengeschichte zu Lean, Scrum, Agile und Kanban.
Im 2. Weltkrieg fehlen Fachkräfte
Scrum und Kanban bauen beide auf Lean Thinking und den Erfahrungen bei Toyota auf (/5/ und /6, S. ix/). Die Ideen bei Toyota wurden eigentlich nach dem 2. Weltkrieg aus den USA importiert. Dort gab es ein Ausbildungsprogramm für Firmen, deren Mitarbeiter zum Militärdienst eingezogen wurden. Dieses Programm sollte dabei helfen, schnell neue Mitarbeiter anzulernen, Konflikte zu vermeiden und Arbeitsabläufe zu optimieren.
Hier sind wir an einem Punkt, der für das Grundverständnis von Lean sehr wichtig ist. Wie können Sie eine industrielle Produktion organisieren, wenn erfahrene Mitarbeiter und Material fehlen? Sie müssen mit den Leuten und dem Material auskommen, was zur Verfügung steht. Der Supervisor war dafür verantwortlich, dass neue Mitarbeiter angelernt, Konflikte vermieden und ständig etwas verbessert wurde.
Mit dem Anlernen konnte man sich nicht ewig Zeit lassen. Deswegen musste man ein Verfahren entwickeln, dass erwiesenermaßen funktionierte. Um Arbeitsgänge zu vermitteln wurden sog. Job Breakdown Sheets erstellt. Diese zeigten nicht alle Schritte, sondern nur die wesentlichen auf. Auch für die Verbesserung wurden die wesentlichen Schritte (wenn auch etwas anders) notiert. Bei Toyota wurde daraus standardisierte Arbeit und Value Stream Mapping.
Um die Wirksamkeit des Ausbildungsprogramms zu zeigen, mussten die Firmen Zahlen berichten. Welche Zahlen werden wohl während des Krieges wichtig gewesen sein?
- Können die nötigen Mengen geliefert werden?
- Kann der Materialverbrauch gesenkt werden, um mehr Geräte zu liefern?
- Kann die Zeit für die Produktion gesenkt werden?
Dieses Wissen gerät nach dem Krieg in den USA in Vergessenheit. Erst die MIT-Studie hat in den 1980er-Jahren dieses Wissen wieder systematisch erfasst (ohne allerdings die Ursprünge zu erwähnen).
In Japan war dieses Wissen sehr willkommen, um die am Boden liegende Wirtschaft nach dem 2. Weltkrieg wieder aufzubauen. Toyota hat viele Dinge verfeinert. Das ursprüngliche Vorgehen bei der Verbesserung sah 4 Schritte vor, von denen der 2. Schritt hieß "Hinterfrage jedes Detail". Bei Toyota hat man sich die Frage gestellt, ob es bestimmte Arten von Details gibt, die man zuerst hinterfragen sollte. So kam man auf 7 Arten von Verschwendung (Transport, Lagerhaltung, Bewegung, Wartezeiten, Überproduktion, Überbearbeitung und Fehler). Dabei entstand auf der Begriff des Arbeitsflusses (engl. flow). Kaizen bedeutete, täglich viele kleine Dinge zu ändern. Große Sprünge waren während des Krieges nicht möglich. Es gab nicht mehr Geld und man konnte keine neuen Maschinen kaufen. Sie wurden einfach nicht produziert.
Es entstanden Techniken wie Kanban, um den Bestand an zu lagernden Teilen gering zu halten. David Anderson hat die Prinzipien von Kanban für die Fertigung später für die Aufgabenbearbeitung in einem Wartungsteam genutzt /7/.
Auftragstaktik und Feedback
Anfang des 19. Jahrhunderst wurde in der preussischen Armee die Auftragstaktik entwickelt. Es dauerte eine Weile, bis sie sich durchgesetzt hat. Aber ihr Nutzen war nachweislich erfolgreicher als die sog. Normaltaktik. Bei der Normaltaktik gibt ein Offizier den Untergebenen detaillierte Anweisungen, wie sie sich zu verhalten haben. Bei der Auftragstaktik gibt ein Offizier klare Aufträge und den Rahmen vor, überlässt die Ausführung den Untergebenen. Dadurch dass diese den Sinn verstehen, können die Untergebenen bei Veränderungen ihr Verhalten anpassen, um trotzdem das Ziel des ursprünglichen Auftrags zu erreichen.
John Boyd zählt zu den besten US-amerikanischen Kampfpiloten des 20. Jahrhunderts. Jeff Sutherland, einer der Väter von Scrum und selbst Kampfpilot, wurde stark von Boyds Ideen geprägt. Insbesondere seine OODA-Loop hatte es ihm angetan. Feedback zur Situation und zu den eigenen Handlungen hilft dabei, komplexe Probleme zu lösen.
Agile ist Lean mit Feedback
Erst kam Scrum, danach das Agile Manifest (und danach Kanban). Agil ist wie Arbeiten nach Lean Prinzipien aber ergänzt um Feedback von Kunden. Der Name Agile kam von einem bestimmten Buch /8/.
Zwischenstand
Welche Konzepte können wir aus dieser Ideengeschichte festhalten?
- Der Supervisor sorgt dafür, dass sein Team gut arbeiten kann. Er ist ein Fachexperte, der eine neue Rolle übernommen hat. Er hat kein Budget. Er hat nicht die Macht, Leute einzustellen oder zu feuern. Er kümmert sich um die Einarbeitung neuer Leute. Er vermeidet proaktiv Konflikte und er kümmert sich um ständige Verbesserung. Das sind alles Dinge, die er in 3 Seminare von jeweils 10 Stunden lernen kann. Hier kann man den späteren Scrum Master erkennen.
- Ein Offizier definiert Aufträge und den Rahmen, der zur Zielerreichung zur Verfügung steht. Die konkrete Ausführung überlässt er seinen gut ausgebildeten Soldaten. Hier ist der spätere Product Owner zu erkennen.
- In der Kriegssituation gab es sehr konkrete Erwartungen, welche militärischen und zivilen Güter einzelne Firmen zu liefern hatten. Es gab Erwartungen an Lieferzeiten, Mengen und die Qualität. Daraus nehmen wir den Blick auf die Produktion aus Kundensicht und die Takt-Time bei Lean Thinking.
- Um die Produktion zu verbessern, mussten alle Arbeitsabläufe ständig hinterfragt und verbessert werden. Hier sind die 7 Verschwendungsquellen, das Prinzip des Arbeitsflusses sowie die Katas und Daily Kaizens von Toyota zu erkennen. Auch im Daily Scrum überlegt sich das Team täglich, ob es Dinge verbessern kann.
- In unsicheren Situationen braucht man ständig kleine Experimente und Feedback dazu. Die Zeitabstände, in denen man sich Feedback organisiert, müssen zu aktuellen Lage passen. Je unsicherer, desto häufiger. Da erkennen wir die Taktung bei Scrum und Kanban.
Für welche Arbeitsweise entscheiden Sie sich?
Darf ich Ihnen nun einige Fragen stellen, bevor Sie sich für Scrum oder Kanban entscheiden:
- Ist Ihnen klar, welche Produkte oder Dienstleistungen die Gesellschaft und andere Stakeholder von Ihnen erwarten? Ändern sich diese Erwartungen?
- Können Sie diese Produkte oder Dienstleistungen liefern?
- Haben Sie genug Leute, die Ihnen beim Erstellen und Liefern helfen? Sind sie gut ausgebildet? Ändern sich die technischen Mittel, die Sie nutzen?
- Reichen die Mittel, die Ihnen zur Verfügung stehen, um zu liefern?
- Ist die Lage absehbar? Wissen Sie, was in den nächsten Monaten auf Sie zukommt?
Bei der Methodenauswahl kann die Ideengeschichte helfen, die wesentlichen Begriffe zu verstehen. Das empirische Arbeiten hilft Ihnen dabei, Ihre eigenen Ideen zu überprüfen.
Anmerkungen
- /1/ Jan Fischbach: Methoden sind wie Spiele, Teamworkblog, erschienen am 09. August 2013, abrufbar unter http://www.teamworkblog.de/2013/08/methoden-sind-wie-spiele.html
- /2/ Jan Fischbach: Welche Methode ist besser? - Was ein Team tun kann, wenn es aus 2 Methoden auswählen muss, Teamworkblog, erschienen am 13. August 2013, abrufbar unter http://www.teamworkblog.de/2013/08/welche-methode-ist-besser-was-ein-team.html
- /3/ Jan Fischbach: Welche Methode ist besser? - Was ein Team tun kann, wenn es aus 2 Methoden auswählen muss (Teil 2), Teamworkblog, erschienen am 14. August 2013, abrufbar unter http://www.teamworkblog.de/2013/08/welche-methode-ist-besser-was-ein-team_14.html
- /4/ Jan Fischbach: Muss ich mich an Regeln von Methoden halten?, Teamworkblog, erschienen am 04. April 2014, abrufbar unter http://www.teamworkblog.de/2014/04/muss-ich-mich-regeln-von-methoden-halten.html
- /5/ Jeff Sutherland: Origins of Scrum, Blogbeitrag vom 5. Juli 2007, abrufbar unter https://www.scruminc.com/origins-of-scrum/
- /6/ Kniberg, Henrik, and Mattias Skarin. Kanban and Scrum-making the most of both. Lulu. com, 2010.
- /7/ Anderson, David J.: Kanban : Evolutionäres Change Management für IT-Organisationen. Heidelberg: dpunkt.verlag, 2011.
- /8/ Goldman, Steven L.: Agile Competitors and Virtual Organizations : Strategies for Enriching the Customer. New York: Van Nostrand Reinhold, 1995.
Hallo Jan. Gelungener Artikel! Du hast die Unterschiede sehr deutlich gemacht. Ich nutze für meine Projekte sowohl Kanban als auch Scrum. Hast du schon von der Methode Scrumban gehört? Diese vereint die Vorteile beider Methoden. Ich habe hier einen Artikel für deine Leser, der vielleicht noch weitere Informationen gibt. Ich freue mich über jedes Feedback!
AntwortenLöschenhttps://zenkit.com/de/blog/kanban-oder-scrum/