Kanban

So lässt sich die Scrum-Methode in der Softwareentwicklung anwenden

Was ist Kanban?

Kanban ist ein beliebtes Framework zum Implementieren der Agile-Softwareentwicklung. Dazu müssen Kapazitäten in Echtzeit kommuniziert werden und alle Aufgaben müssen völlig transparent sein. Die einzelnen Aufgabenelemente werden auf einem Kanban Board visuell dargestellt, sodass sich die Teammitglieder jederzeit einen Überblick über den Status der Arbeitsschritte verschaffen können.

[CONTINUED]

Kanban is enormously prominent among today's agile software teams, but the kanban methodology of work dates back more than 50 years. In the late 1940s Toyota began optimizing its engineering processes based on the same model that supermarkets were using to stock their shelves. Supermarkets stock just enough product to meet consumer demand, a practice that optimizes the flow between the supermarket and the consumer. Because inventory levels match consumption patterns, the supermarket gains significant efficiency in inventory management by decreasing the amount of excess stock it must hold at any given time. Meanwhile, the supermarket can still ensure that the given product a consumer needs is always in stock.

When Toyota applied this same system to its factory floors, the goal was to better align their massive inventory levels with the actual consumption of materials. To communicate capacity levels in real-time on the factory floor (and to suppliers), workers would pass a card, or "kanban", between teams. When a bin of materials being used on the production line was emptied, a kanban was passed to the warehouse describing what material was needed, the exact amount of this material, and so on. The warehouse would have a new bin of this material waiting, which they would then send to the factory floor, and in turn send their own kanban to the supplier. The supplier would also have a bin of this particular material waiting, which it would ship to the warehouse. While the signaling technology of this process has evolved since the 1940s, this same "just in time" (or JIT) manufacturing process is still at the heart of it.

Kanban für Softwareteams

Agile software development teams today are able to leverage these same JIT principles by matching the amount of work in progress (WIP) to the team's capacity. This gives teams more flexible planning options, faster output, clearer focus, and transparency throughout the development cycle.

Kanban Board | Atlassian agile coach

Während die Kernprinzipien des Framework zeitlos sind und in nahezu jeder Branche angewandt werden können, verzeichnen insbesondere Softwareentwicklungsteams großen Erfolg mit der agilen Methode. Dies liegt zum Teil daran, dass Softwareteams sie ohne großen Aufwand umsetzen können, sobald sie die grundsätzlichen Prinzipien verstanden haben. Im Gegensatz zu der Einführung von Kanban in einer Fertigungshalle, wo dies zu Veränderungen physischer Prozesse und zu einer beträchtlichen Menge an zusätzlichen Materialien führen würde, benötigen Softwareteams als einziges physisches Material ein Board und Karten – und selbst diese können virtuell sein.

Kanbanboards

Bei der Arbeit aller Kanban-Teams steht das Kanban Board im Mittelpunkt, ein Tool zur Visualisierung von Aufgaben und der Optimierung des Workflows im Team. Manche Teams arbeiten gerne mit physischen Boards, doch virtuelle Boards sind ein entscheidender Bestandteil jedes agilen Softwareentwicklungstools für die Nachverfolgbarkeit, eine einfachere Zusammenarbeit und Zugänglichkeit von verschiedenen Standorten aus.

Unabhängig davon, ob das Board eines Teams physisch oder digital ist – seine Funktion ist die Visualisierung der Aufgaben, die Standardisierung des Workflows und die Ermittlung und Beseitigung aller Hindernisse und Probleme durch Abhängigkeiten. Ein einfaches Kanban Board ist in einen Workflow in drei Schritten unterteilt: ToDo, in Bearbeitung, erledigt. Je nach Größe, Struktur und Zielen eines Teams kann der Workflow jedoch an die spezifischen Prozesse jedes beliebigen Teams angepasst werden.

Die Kanban-Methode basiert auf völliger Transparenz der Aufgaben und Mitteilung der Kapazitäten in Echtzeit. Deshalb sollte das Kanban Board eine Stellung als die zentrale Informationsquelle zu den Aufgaben des Teams einnehmen.

Agile Kanban Board | Atlassian agile coach

Kanban-Karten

Die wörtliche Übersetzung von Kanban aus dem Japanischen ist "visuelles Signal". In Kanban-Teams wird jedes Aufgabenelement als eine separate Karte auf dem Board dargestellt.

Die Repräsentation von Aufgaben als Karten auf dem Kanban Board soll zuallererst die Verfolgung des Arbeitsfortschritts entlang des Workflows durch eine klare visuelle Darstellung ermöglichen. Kanban-Karten stellen kritische Informationen zu dem jeweiligen Aufgabenelement in den Vordergrund, sodass das gesamte Team völlige Transparenz darüber erhält, wer für das Aufgabenelement zuständig ist, worum es sich bei der Aufgabe handelt, wie lange die Bearbeitung schätzungsweise dauern wird usw. Karten auf virtuellen Kanban-Boards sind zudem häufig mit Screenshots und anderen technischen Details versehen, die für die zugeordnete Person hilfreich sind. Dadurch, dass die Teammitglieder den Status jedes Aufgabenelements sowie die zugehörigen Details zu jeder Zeit einsehen können, wird eine stärkere Fokussierung, völlige Nachverfolgbarkeit und eine schnelle Ermittlung von Hindernissen und Abhängigkeiten sichergestellt.

The benefits of Kanban

Kanban ist eine der beliebtesten Methoden bei der Softwareentwicklung, die heute von agilen Teams übernommen wird. Kanban bietet verschiedene zusätzliche Vorteile bezüglich Aufgabenplanung und Durchsatz bei Teams jeder Größe.

Flexibilität bei der Planung

A kanban team is only focused on the work that's actively in progress. Once the team completes a work item, they pluck the next work item off the top of the backlog. The product owner is free to reprioritize work in the backlog without disrupting the team, because any changes outside the current work items don't impact the team. As long as the product owner keeps the most important work items on top of the backlog, the development team is assured they are delivering maximum value back to the business. So there's no need for the fixed-length iterations you find in scrum.

PRO TIP:

Savvy product owners always engage the development team when considering changes to the backlog. For example, if user stories 1-6 are in the backlog, user story 6's estimate may be based on the completion of user stories 1-5. It's always a good practice to confirm changes with the engineering team to ensure there are no surprises. 

Shortened time cycles

Cycle time is a key metric for kanban teams. Cycle time is the amount of time it takes for a unit of work to travel through the team’s workflow–from the moment work starts to the moment it ships. By optimizing cycle time, the team can confidently forecast the delivery of future work.

Die Überschneidung von Kompetenzen sorgt für kürzere Durchlaufzeiten. Wenn nur eine Person über eine bestimmte Kompetenz verfügt, kann diese Person einen Engpass im Workflow darstellen. Deshalb nutzen Teams grundlegende Best Practices wie Code-Reviews und Mentoring, um ihr Wissen zu verteilen. Geteilte Kompetenzen bedeuten, dass Teammitglieder heterogene Aufgaben übernehmen und damit die Durchlaufzeit weiter verbessern können. Das bedeutet auch, dass bei einem Aufgabenstau das gesamte Team einspringen kann, um den Prozess wieder reibungslos laufen zu lassen. So wird beispielsweise das Testen nicht nur von QA-Technikern ausgeführt, sondern auch Entwickler können einspringen.

In einem Kanban-Framework ist das gesamte Team für einen reibungslosen Ablauf der Arbeit im gesamten Prozess verantwortlich.

Weniger Engpässe

Multitasking erstickt die Effizienz. Je mehr Aufgabenelemente zu einem bestimmten Zeitpunkt bearbeitet werden, umso mehr Kontextwechsel finden statt. Und diese behindern den Abschluss der Aufgaben. Darum ist eines der Hauptmerkmale von Kanban-Verfahren, die Menge der Work-in-Progress (WIP) einzugrenzen. Work-in-Progress-Grenzen heben Engpässe und Staus im Teamprozess durch fehlende Fokussierung sowie fehlende Mitarbeiter oder Kompetenzen hervor.

For example, a typical software team might have four workflow states: To Do, In Progress, Code Review, and Done. They could choose to set a WIP limit of 2 for the code review state. That might seem like a low limit, but there's good reason for it: developers often prefer to write new code, rather than spend time reviewing someone else's work. A low limit encourages the team to pay special attention to issues in the review state, and to review others work before raising their own code reviews. This ultimately reduces the overall cycle time.

Visuelle Darstellung von Metriken

Zu den zentralen Werten zählt ein starker Fokus auf eine stetige Verbesserung der Teameffizienz und -effektivität bei jeder Wiederholung einer Aufgabe. Diagramme können Teams als visuelle Mechanismen dienen, um sicherzustellen, dass sie sich weiter verbessern. Wenn das Team Daten sehen kann, können Engpässe im Prozess einfacher erkannt (und aus diesem entfernt) werden. Kanban-Teams nutzen dafür hauptsächlich Kontrollcharts und kumulative Flussdiagramme.

In einem Kontrollchart werden die Durchlaufzeit für jeden Vorgang und ein fortlaufender Durchschnitt für das Team dargestellt.

Pro Tip:

The team's goal is to reduce the amount of time an issue takes to move through the entire process. Seeing the average cycle time drop in the control chart is an indicator of success. 

Agile control chart | Atlassian agile coach

In einem kumulativen Flussdiagramm wird die Anzahl der Vorgänge dargestellt, die sich in einem bestimmten Status befinden. Das Team kann schnell Blockaden erkennen, indem es die Anzahl der Vorgänge in einem bestimmten Status beobachtet. Vorgänge in Zwischenstadien, wie z. B. "In Progress" (in Bearbeitung) oder "In Review" (in der Review-Phase) werden noch nicht an Kunden ausgeliefert und eine Blockade in diesen Stadien erhöht die Wahrscheinlichkeit enormer Integrationskonflikte, wenn ein Upstream-Merging der Aufgaben erfolgt. 

Kumulatives Flussdiagramm

Continuous Delivery

We know that continuous integration–the practice of automatically building and testing code incrementally throughout the day–is essential for maintaining quality. Now it's time to meet continuous delivery (CD). CD is the practice of releasing work to customers frequently–even daily or hourly. Kanban and CD beautifully complement each other because both techniques focus on the just-in-time (and one-at-a-time) delivery of value.

The faster a team can deliver innovation to market, the more competitive their product will be in the marketplace. And kanban teams focus on exactly that: optimizing the flow of work out to customers

Scrum im Vergleich zu Kanban

Kanban and scrum share some of the same concepts but have very different approaches. They should not be confused with one another. 

 

SCRUM

KANBAN
Rhythmus

Regelmäßige Sprints mit fester Länge (d. h. 2 Wochen)

 Kontinuierlicher Fluss
Release-Methoden Am Ende jedes Sprints, wenn vom Product Owner genehmigt Continuous Delivery oder nach Ermessen des Teams
Rollen Product Owner, Scrum Master, Entwicklerteam Keine vorhandenen Rollen. Einige Teams nehmen die Hilfe eines Agile Coach in Anspruch.
Zentrale Metriken Velocity Durchlaufzeit
Änderungsphilosophie Teams sollten während des Sprints keine Änderungen an der Sprintprognose vornehmen, da dies die Lernlektionen aus der Schätzung beeinträchtigt. Es kann jederzeit zu Änderungen kommen.

 

Einige Teams vereinen die Ideale von Kanban und Scrum zu "'Scrumban." Sie kombinieren Sprints mit fester Länge und Rollen aus Scrum-Verfahren mit der Fokussierung auf Work-in-Progress-Grenzen und der Durchlaufzeit der Kanban-Methoden. Teams, die agile Methoden gerade einführen, sollten sich jedoch unbedingt für die eine oder andere Methode entscheiden und diese eine Weile beibehalten. Sie können immer noch später auf ausgefallenere Methoden umsteigen. 

Dan Radigan
Dan Radigan

Agile Methoden haben mich sowohl beruflich als auch persönlich stark beeinflusst, da ich gelernt habe, dass durch Agilität die besten Erfahrungen entstehen, sowohl beim Code als auch im Leben allgemein. Meine Leidenschaft sind Technologie, Fotografie und Motorradfahren – gerne in Kombination. Folge mir auf Twitter! @danradigan

Up Next
Wip limits