Kanban- und Scrum-Boards: Agile Methoden in der Medizintechnik

Kanban- und Scrum-Boards in der Medizintechnik

Tausende Aufgaben gleichzeitig erledigen. Ständig dabei unterbrochen werden. Unklare Prioritäten. Wenn Ihnen das bekannt vorkommt, dann erfahren Sie in diesem Blogbeitrag wie Sie mit Kanban-Boards und Scrum-Boards dem Chaos Herr werden können – sowohl auf Ihrem Schreibtisch als auch im kompletten Team.



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.

Todo-Boards

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 – Trennung von Priorisierung und Ausführung

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.

Pull-Prinzip und WIP-Limittierung – Konzentration statt Multitasking

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.

One-Piece-Flow – immer eins nach dem anderen

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.

Synchronisierung im Team

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.

First things first – Priorisierung ist essentiell

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.

Scrum-Boards – User Stories für maximalen Kundennutzen

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.

WIP-Limittierung auf der Ebene von User Stories

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.

Optische Qualitätskontrolle von Scrum-Boards

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.

Vielleicht auch interessant für Sie...