Direkt zum Hauptbereich

Lean, Scrum, Agile und Kanban im Vergleich (so, dass man es versteht)

Welche Methode ist besser? Scrum oder Kanban, Lean oder Agile, Scrumban oder Kanrum? In diesem Beitrag gibt es endlich eine passende Antwort.

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? 
Vor allem die Prozesseffizienz (Zeit für die reine Bearbeitung in Bezug zur gesamten Zeit von Anfang bis Ende) wurde zu einer wichtigen Kennzahl. Und die Unternehmen lieferten beeindruckende Zahlen. Insgesamt wurden in der Zeit von 1940 bis 1945 1,7 Mio. Menschen in mehr als 16.000 Werken ausgebildet.

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.
Jeff Sutherland und David Anderson nennen noch weitere Quellen, die ihre Arbeitsweisen geprägt haben. Aber wir lassen es im Moment dabei.

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?
Wenn Sie auf eine oder mehrere Fragen mit "nein" antworten, frage ich Sie: "Was tun Sie nun?" Spielt es angesichts dieser Fragen eine Rolle, ob die Menge der Arbeit über eine gemeinsame Besprechung oder mit Hilfe eine Zahl über eine Spalte auf einem Board begrenzt wird? Spielt es eine Rolle, ob Ihr Team ein Burndown-Chart oder ein Flussdiagramm verwendet? Ist es wirklich wichtig, ob bei der einen Arbeitsweise das Schätzen Pflicht ist und bei der anderen nicht?

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


Kommentare

  1. 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!
    https://zenkit.com/de/blog/kanban-oder-scrum/

    AntwortenLöschen

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Kategorien in Outlook - für das Team nutzen

Kennen Sie die Kategorien in Outlook? Nutzen Sie diese? Wenn ja wofür? Wenn ich diese Fragen im Seminar stelle, sehe ich oft hochgezogene Augenbrauen. Kaum jemand weiß, was man eigentlich mit diesen Kategorien machen kann und wofür sie nützlich sind. Dieser Blogartikel stellt sie Ihnen vor.

Rebellieren für den Wandel: die 8 Regeln des totalen Stillstandes von Prof. Dr. Peter Kruse

In einem legendärem Vortrag skizzierte Peter Kruse 8 Regeln des totalen Stillstands. Ihm zufolge wurden die Regeln entwickelt, um Managern und Führungskräften dabei zu helfen, Bereiche mit potenziellem Widerstand gegen Veränderungen zu erkennen und Menschen auf strukturierte Weise durch den Veränderungsprozess zu führen.

Pragmatisch oder nur “Quick and Dirty”?

“Wir müssen aber pragmatisch vorgehen”, drängt der Kollege. Hm… Im Wörterbuch finde ich für “pragmatisch” in etwa: sachbezogenes, praktisches Handeln. Klingt gut. Leider zeigt sich in meinen Erfahrungen, dass pragmatisch für viele doch eher “quick and dirty” bedeutet. Es soll schnell fertig werden. Aber auf welche oder wessen Kosten? Wo ist die Grenze? Warum steht “praktisch” im Konflikt mit einem langfristigen “Nützlich”? Muss das sein?

Und jetzt alle zusammen! Teams - OneNote - Aufgaben - To Do

Ein Meeting jagt das nächste. Sich da nicht zu verzetteln, wird  im Zeitalter virtueller Besprechungen  noch anspruchsvoller. Kein Wunder, dass  im Zusammenhang mit Microsoft 365  zwei Fragen besonders häufig auftauchen: Wie dokumentiert man Besprechungen gut? Was hilft, offene Aufgaben nachzuhalten? Eine gute Lösung: Das in MS Teams integrierte OneNote-Notizbuch als gemeinsame Plattform auch für den Aufgabenüberblick zu nutzen.

E-Mail-Vorlagen gemeinsam nutzen (Outlook)

Mittlerweile wird praktisch alle Routine-Korrespondenz in Outlook erledigt. Was liegt da näher, als ein gutes Set von Vorlagen zu erstellen und diese gemeinsam in Team zu nutzen? Leider hat Microsoft vor diesen – an sich simplen – Wunsch einige Hürden gebaut.

Das Ubongo Flow Game

Spiele bieten eine gute Gelegenheit, zeitliche Erfahrungen zu verdichten und gemeinsam zu lernen. Karl Scotland und Sallyann Freudenberg haben im Mai 2014 das Lego Flow Game veröffentlicht. Wir haben die Spielidee übernommen, aber das Spielmaterial gewechselt. Statt Legosteinen benutzen wir Material aus Grzegorz Rejchtmans Ubongo-Spiel. Hier präsentieren wir die Anleitung für das Ubongo Flow Game.

Outlook-Aufgabenliste: bitte nicht die Aufgaben des ganzen Teams!

Am Tag der Arbeit kommt eine Lösung, nach der ich schon so oft gefragt wurde: Wie schaffe ich es, dass meine Outlook-Aufgabenliste nur meine eigenen Aufgaben anzeigt und nicht auch die E-Mails, die meine Kollegen gekennzeichnet haben oder Aufgaben, die einfach in einem gemeinsamen Postfach stehen?

Nie wieder Ärger mit Besprechungsserien in Outlook

Erstellen auch Sie Besprechungsserien in Outlook? Ärgern auch Sie sich manchmal darüber, wenn Sie etwas zu ändern haben? Falls nicht, versenden Sie entweder keine wiederkehrenden Outlook-Besprechungen (Serienterminen). Oder Sie ändern nie etwas daran. Dann ist dieser Artikel nichts für Sie. Lesen Sie aber bitte weiter, falls Sie sich schon immer mal gefragt haben, ob es eine Lösung gibt? 

Wie schreibt man ein Fachbuch mit vielen Autor:innen?

Was gibt es zu beachten, wenn viele Menschen gemeinsam ein Buch schreiben? Was ist wichtiger: das Team oder die Technik? Wir geben einen Einblick in unsere Arbeit für das Buch „Agile Verwaltung 2024“.