Articles, Blog

Scrum vs Kanban – agile Projektmanagement-Methoden im Vergleich

August 22, 2019


Tausende Aufgaben gleichzeitig erledigen. Ständig dabei unterbrochen werden. Unklare Prioritäten. Wenn Ihnen das bekannt vorkommt, dann sehen
Sie hier im Video wie Sie mit Kanban-Boards und Scrum-Boards diesem Chaos Herr werden
können – sowohl auf Ihrem Schreibtisch als auch im kompletten Team. Hallo und herzlich willkommen zu einer neuen
Folge der Reihe Business-Chirurgie, dem Kanal hier bei YouTube, bei dem es um Highspeed
und Disruptionen in der Medizintechnik geht. Wir beschäftigen uns heute mit Kanban-Boards
und mit Scrum-Boards und mit der Frage wie diese auch in der Medizintechnik sinnvoll
eingesetzt werden können, um einzelne Aufgaben Schritt für Schritt ausführen zu können
und einen größtmöglichen Kundennutzen in möglichst kurzer Zeit erreichen zu können. Wir fangen einmal an mit einer Art von Board,
für die es eigentlich bisher noch gar keinen richtigen Namen gab, die aber vielleicht in
Ihrem Unternehmen auch stattfinden. Das sind einfache Todo-Boards. Es gibt ganz viele Aufgaben die letztendlich
alle irgendwo parallel und ungesteuert im Unternehmen ab. Jeder Mitarbeiter hat eine eigene Reihenfolge. So sieht es dann aus, dass letztendlich überhaupt
nicht absehbar ist, wo hier ein echter Kundennutzen entstehen kann. Kanban-Boards können nun dabei helfen, indem
sie eine bestimmte Reihenfolge in diese Aufgaben bringen. Indem nämlich eine Trennung stattfindet zwischen
der Priorisierung der einzelnen Aufgaben und der eigentlichen Durchführung. Das sieht dann so aus, dass es hier eine Spalte
gibt mit den Aufgaben die durchgeführt werden sollen – die sogenannte Todo-Spalte. In diese Spalte kommen erst einmal alle einzelnen
Aufgaben rein. Eine weitere Spalte ist die Spalte “In Progress”. In diese Spalte kommen all die Aufgaben hinein,
die zur Zeit wirklich bearbeitet werden. Jetzt kommen wir auch schon zur ersten großen
Regel bei Kanban-Boards: Es gilt das sogenannte “Pull-Prinzip”. Das Pull-Prinzip sagt aus, dass Aufgaben nun
nicht mehr – so wie das vielleicht vorher üblich war – in die Gruppe der Entwickler
hineingeschoben wird, sondern dass sich die einzelnen Entwickler Aufgaben selbständig
aus der Todo-Liste ziehen. Eine zweite Regel ist die sogenannte WIP-Limitierung,
WIP ist dabei eine Abkürzung für Work in Progress oder Work in Process. Die Regel besagt, dass die Anzahl der Aufgaben
die gleichzeitig in einer Spalte ausgeführt werden dürfen hart und exakt limitiert wird. Das wird typischerweise durch einen Marker
über der entsprechenden Spalte am Board angezeigt. Als Beispiel bedeutet eine (2) über der Spalte
“In Progress”, dass maximal 2 Aufgaben gleichzeitig bearbeitet werden dürfen. Ein Entwickler kann nun also damit beginnen,
sich eine der Aufgaben aus der Todo-Spalte selbständig in die Spalte In Progress zu
ziehen, typischerweise startend mit dem ersten Task. Solange er oder sie sich zu 100% darauf konzentrieren
kann, wird nun genau diese eine Aufgabe bearbeitet und keine weitere parallele Aufgabe gezogen. Manchmal kommt es natürlich vor, dass es
zu leichten Abstimmungsschwierigkeiten kommt oder dass für diesen Task noch etwas von
außerhalb der Gruppe erledigt werden muss und es kommt zu expliziten Wartezeiten. In diesem Fall darf dann ein weiterer Task
gezogen werden. Wenn es auch hier wieder zu Wartezeiten kommt,
dann greift allerdings die Regel, dass der Work in Progress limitiert ist. Wenn also an keiner der beiden Aufgaben gearbeitet
werden kann, weil zum Beispiel auf einen externen Zulieferer gewartet werden muss oder ähnliches,
dann ist das letztendlich die Aufgabe die erst einmal gelöst werden muss: nämlich
die Blockaden der einzelnen Task zu identifizieren, zu analysieren, und aufzulösen. Bevor das nicht getan ist lohnt es sich gar
nicht eine neue Aufgabe zu ziehen, weil gar keine freien Entwickler und kein Fokus vorhanden
sind, die sich um die Abarbeitung kümmern könnten. Es gibt noch eine dritte Spalte, die Spalte
“Done”. Diese ist dafür da, damit eine komplett abgearbeitete
Aufgabe von “In Progress” in “Done” wandern. Sie sehen hier schon, dass Tasks sich auf
dem Board durchaus auch überholen dürfen. Das ist in einem Kanban-Board überhaupt nicht
schlimm, es kann auch sein, dass ein neuer Task gezogen aus “Todo” in “In Progress” gezogen
wird, dann ein bereits begonnener und nun beendeter Task aus “In Progress” in “Done”
und dann der erste Task ebenfalls aus “In Progress” in “Done”. Spalten dürfen dabei zwischendurch auch leer
sein. So wandert nun ein Task nach dem anderen geordnet
durch das komplette Kanban-Board. Was dabei entsteht hat auch einen Namen: Der
sogenannte “One Piece Flow”. Das Ziel ist, dass idealerweise nur ein Task
nach der anderen unterbrechungsfrei durch das komplette Board wandern. Das Kanban-Board in der Form wie wir sie bisher
kennengelernt haben ist dafür geeignet, für einzelne Personen eine gute Grundlage zu schaffen
um Aufgaben zu strukturieren und sich auf diese zu fokussieren. Kanban-Boards sind darüber hinaus auch in
der Lage, mehrere Teammitglieder miteinander zu synchronisieren. Dafür können wir zum Beispiel die Spalte
“In Progress” auftrennen in zwei Unterspalten “Develop” und “Test”. Für jede dieser beiden Spalten kann dann
wieder eine WIP-Limitierung definiert werden, in unserem Fall dürfen sich in beiden Spalten
jeweils maximal 2 Tasks befinden. Wenn der “One Piece Flow” erst einmal realisiert
ist, dann geht es um die Fragestellung, wie denn nun mit einer erhöhten Flussgeschwindigkeit
ein optimaler Kundennutzen erzeugt werden kann. Dafür gibt es die Regel “First things first”. Die wichtigsten Aufgaben sollen als erstes
erledigt werden. Dies ist nun bereits ein fließender Übergang
vom Kanban-Board zum Scrum-Board. Im Scrum-Board gibt es vor der Todo-Spalte
– teilweise auch synonym dazu – noch ein sogenanntes Backlog. In diesem Backlog stehen sogenannte “User
Stories”, die mehrere Tasks logisch zusammenfassen. Wie kann man nun User-Stories, die typischerweise
eine Dauer von mehreren Tagen oder sogar einer Woche haben, auf einzelne Tasks mit einer
typischen Durchlaufzeit von wenigen Stunden oder maximal einem Tag herunterbrechen? User Stories können dafür genutzt werden,
um Aufgaben zu clustern und zusammenzufassen. Beispielsweise kann die erste User Story erst
dann einen echten Kundennutzen erzeugen, wenn alle zugehörigen Tasks fertig entwickelt
und getestet sind. Auch die nachfolgenden User Stories erzeugen
erst dann einen Wert, wenn ihre entsprechenden Tasks vollständig abgearbeitet sind. Auch auf dieser Ebene gilt nun wieder das
Prinzip der WIP-Limittierung: Idealerweise fängt man die erste User Story an, startet
den ersten Task, beendet ihn vollständig und beginnt erst dann mit dem nächsten Task. Und erst wenn alle Tasks der ersten User Story
komplett abgearbeitet sind beginnt man mit der zweiten User Story und geht dort nach
dem gleichen Prinzip vor. Diese Vorgehensweise ist gerade am Anfang
schwierig einzuhalten, gerade auch in der Zusammenarbeit in einem kompletten Team. Das Einhalten der Prinzipien und Regeln stiftet
jedoch einen erheblichen Nutzen und Mehrwert für das Tem, denn dadurch kann frühestmöglich
echter Kundennutzen für den Endanwender erzeugt werden. Während der Abarbeitung von User Stories
und Tasks kann es auch vorkommen, dass an einzelnden Aufgaben nicht gearbeitet werden
kann und diese durch die WIP-Limitierung den kompletten Arbeitsablauf des Teams blockieren. Solche Blockierungen können nun ebenfalls
visualisiert werden über einen Blocker: Identifiezieren und visualisieren Sie dabei die Ursache für
den Blocker, seit wann dieser existiert – so dass das Team immer wieder sehen kann wie
lange der Task bereits an dieser Stelle festhängt -, welchen Aktionen sind geplant um die Blockade
zu beheben, und wer ist als Treiber für die Auflösung des Blockers verantwortlich. Sie sehen hier bereits die typische Form die
sich auf einem Scrum-Board automatisch ausbildet, nämlich eine Dreiecksform. Die User Stories von oben nach unten abgearbeitet,
die Tasks von links nach rechts und es wird immer an den bereits gestarteten Aufgaben
gearbeitet wird um diese möglichst schnell zu Ende zu bringen, um möglichst schnell
einen Wert zu erzeugen und den Kunden zufrieden zu stellen. Ich hoffe Ihnen hat es heute genau so viel
Spaß gemacht wie mir. Wenn auch Sie mehr darüber erfahren wollen
wie auch Sie in Ihrem Medizintechnik-Unternehmen Highspeed-Projekte voranbringen können, wie
Sie Disruptionen in der medizintechnik treiben können, dann abonnieren Sie gleich heute
diesen Kanal. Wenn Sie bereits mit Scrum-Boards, mit Kanban-Boards
oder mit anderen Formen der Visualisierung gearbeitet haben, dann hinterlassen Sie Ihre
Erfahrungen gerne in den Kommentarfeldern. Kommen Sie mit anderen Zuschauern in die Diskussion,
damit wir gemeinsam die Medizintechnik noch besser voranbringen können. Ich bedanke mich, bis zum nächsten mal, tschüss
– Ihr Frank Lange.

You Might Also Like

10 Comments

  • Reply Frank Lange TV March 20, 2017 at 10:27 am

    Das Thema Kanban- und Scrum-Boards in der Medizintechnik gibt's auch zum Nachhören im Podcast https://soundcloud.com/franklangefocus/kanban-scrum-boards-in-der-medizintechnik

  • Reply Frank Lange TV April 11, 2017 at 8:08 am

    Zum Nachlesen gibt es die Inhalte des Videos auch in meinem Blog http://www.franklange.eu/kanban-und-scrum-boards-agile-methoden-in-der-medizintechnik/.

  • Reply Maja Könninger March 8, 2018 at 8:31 am

    Hallo Herr Lange, ein gut erklärtes, informatives Video zur Umsetzung der Kanban-Methode. Auch bei Zenkit, einem Karlsruher Start-up, das eine Projektmanagement-Lösung entwickelt hat, wenden wir Kanban an. Was mir zusätzlich hilft, meinen Arbeitsalltag zu strukturieren, ist die Erstellung von Kanban-Boards mittels Online-Tools. Optimalerweise sind diese auch offline nutzbar, um maximale Flexibilität zu erhalten.
    Auch auf unserem Blog lässt sich ein Artikel zu Kanban und den verschiedenen Anwendungsmöglichkeiten finden: https://blog.zenkit.com/kanban-explained-what-youve-always-wanted-to-know-1cc585e33e9e
    Über Ihr Feedback freue ich mich sehr.

  • Reply Roman Wagner October 18, 2018 at 7:53 pm

    Danke für das kostenlose Video und die damit verbundene Mühe. Sehr gut??

  • Reply Markus W November 4, 2018 at 5:37 pm

    schlecht erklärt. wenn – wie im Beispiel – die beiden Todos auf einen externen Zulieferer warten – warum sollten dann die internen Ressourcen ausgeschlpft sein und kein dritter Task nachgezogen werden?

  • Reply Aaronym March 8, 2019 at 10:21 pm

    Super gemacht! Danke!

  • Reply Tobi April 6, 2019 at 5:58 pm

    Danke für den Input.

  • Reply Gruppentherapie mit McWuragu April 25, 2019 at 1:17 pm

    Beide Boards sind Kanbanboards die hier vorgestellt wurden!!!
    Denn ein Scrum Board gibt es so nicht. Oft verwenden Scrum Teams Taskboard, wo das Backlogitem in Tasks wären der Sprintplanung zerlegt wird. Kanban definiert sich nicht über die Struktur eines Board. Das Board selbst spiegelt nur einen Prozess wieder und kann mehr als nur eine "Progress" Spalte enthalten. (Siehe das Pizza Spiel für Kanban Trainings)
    Scrum ist ein Framework, welches feste Iterationen vorschreibt, 3 klare Rollen hat und mehre Artefakte so wie Zeremonien vorgibt. Kanban setzt auf die Core Pratices z.B. Visualzieflow, Limit work in Progress, Manage the flow, Make Polices explicit, Implement Feedback loops, Improve Collaboratively und Evolve experimentally. Wer Kanban nur auf das Board reduziert hat Kanban nicht verstanden.
    Der Kern Unterschied zwischen Scrum und Kanban ist der, Scrum fokussiert die kontinuierliche Entwickelung von Kundenwert und dem Lernen und Kanban hingegen fokussiert ein optimieren des Flow für einen bekannte Wertschöpfungskette.

  • Reply Ron Bee April 27, 2019 at 9:51 am

    Kennen Sie JIRA? Dort bzw. im agilen Team- und Projektmanagement werden Stories anders definiert (siehe auch das Video des "Gurus" Dan Chuparkoff https://youtu.be/TsG3OWTDAFY), nämlich so, wie Sie hier die "Tasks" definieren. Eine Story dauert wenige Stunden bis maximal 2-3 Tage und ist eine klare und geschlossene Aufgabenstellung, die von 1 Mitarbeiter bearbeitet wird. Stories werden wiederum in Epics zusammengefasst, welche wiederum ein Ziel bzw. eine Kundenanforderung darstellen (eigentlich das, was Sie hier als Story bezeichnen). Insofern bin ich nun etwas verwirrt, was Ihr Video angeht. Was sagen Sie dazu?

  • Reply André Werner June 3, 2019 at 6:59 am

    Danke für das Video. Frage: Ist das WIP Limit angesetzt auf die ganze Gruppe von Personen, welche daran arbeiten? oder auf die einzelne Person? Es liegt sicherlich auch daran, wie "klein" oder "groß" die jeweiligen Tasks sind.

  • Leave a Reply