Das Kanban-System für agile Softwareentwicklung erklärt

Kanban ist ein agiler Ansatz, der je nach Kontext, in dem er angewendet wird, alternativ als Methodik, System, Rahmenwerk oder Workflow-Managementmethode beschrieben wird. Das Kanban-System ist besonders im Bereich der Softwareentwicklung beliebt und wurde entwickelt, um die Effizienz von Produktionsprozessen und die Endqualität der produzierten Produkte zu verbessern.

Das Kanban-System für agile Softwareentwicklung steht hier im Mittelpunkt. Sie erhalten eine Einführung in Kanban, seine Geschichte seit seiner Entstehung in den Montagehallen des Nachkriegsunternehmens Toyota und seine spätere Verbreitung als beliebter Softwareentwicklungsprozess.

Außerdem werden wir die wichtigsten Konzepte und Elemente des Kanban-Systems erläutern und auf dessen praktische Umsetzung in Softwareentwicklungsprojekten und -teams eingehen.

Was genau ist das Kanban-System?

Im Kern ist Kanban ein Just-in-Time-Produktionsprozess (JIT), der darauf ausgelegt ist, den Fluss der Rohstoffe und Komponenten zu optimieren, die für die Herstellung eines Endprodukts verwendet werden. In der Softwareentwicklung optimiert das Kanban-System den Fluss der laufenden Arbeiten (Work in Progress, WIP) entsprechend der Kapazität des Entwicklungsteams.

Ein weiterer wichtiger Pfeiler von Kanban ist, dass es sich um ein „Pull“- und kein „Push“-System handelt. Das bedeutet, dass Arbeit in das System gezogen wird, sobald zuvor zugewiesene Arbeit abgeschlossen ist, anstatt dass neue Aufgaben in den Arbeitsablauf geschoben werden, sobald sie erstellt werden. Die Bedeutung der Umkehrung von „Push“ zu „Pull“ besteht darin, dass die Produktion eine Folge der Kundennachfrage ist und mit dieser korreliert, wodurch das Potenzial für Verschwendung verringert wird.

Das Kernkonzept von Kanban besteht darin, den Produktionsprozess so schlank und frei von „Unordnung” wie möglich zu halten:

• Verbessert die Organisation.
• Behält den Fokus.
• Steigert die Produktivität durch Aufrechterhaltung eines konsistenten „Flusses” der Aufgaben, die zum Endprodukt führen.
• Verbessert die Priorisierung von Aufgaben und lässt gleichzeitig Raum für Flexibilität und die Fähigkeit, schnell auf Veränderungen zu reagieren.
• Fördert die Zusammenarbeit im Team.
• Fördert Führungsqualitäten in allen Funktionen und auf allen Hierarchieebenen.

Kanban ist ein sehr visuelles System. Der Produktions- oder Entwicklungsprozess wird in einzelne Aufgaben unterteilt, die jeweils durch eine (in der Regel farbenfrohe und oft farbcodierte) Karte dargestellt werden. Der Name des Systems leitet sich von seinem Visualisierungsmechanismus ab, wobei „kan“ auf Japanisch „Signal“ und „ban“ „Karte“ bedeutet.

Einem Kanban-Team werden so viele Aufgaben zugewiesen, wie für seine Kapazität als optimal erachtet werden. Die Teammitglieder nehmen diese Aufgaben dann nacheinander in Angriff und führen sie so schnell wie möglich durch verschiedene Phasen der Fertigstellung (die je nach Projekt oder Organisation variieren können), von „Zu erledigen“ bis „Erledigt“, bevor sie mit der nächsten Aufgabe beginnen.

Alle Aufgabenkarten werden in der Spalte „To Do“ eines Kanban-Boards platziert, das später noch genauer beschrieben wird, und dann im Laufe ihrer Bearbeitung durch die Spalten verschoben, die verschiedene Fertigstellungsstadien darstellen. Durch diese Visualisierung des Arbeitsablaufs wird sehr schnell deutlich, ob Engpässe den Fortschritt der Aufgaben behindern, sodass diese beseitigt werden können.

Die Visualisierung des Aufgabenrückstands und des Arbeitsablaufs durch Kanban ist wie eine Form der Gamification, die auf Produktivität und Teamarbeit angewendet wird.

Eine kurze Geschichte des Kanban-Systems

Das Kanban-System entstand Ende der 1940er Jahre in den Fabrikhallen des japanischen Automobilriesen Toyota. Toyota ließ sich dabei vom Just-in-Time-Ansatz inspirieren, der zu dieser Zeit bereits in japanischen Supermärkten umgesetzt wurde. Diese hatten ihre Lagerverwaltung durch den Einsatz eines Kartensystems zwischen Verkaufsraum und Lager sowie zwischen Lager und Lieferanten optimiert.

Wenn ein Produkt in den Regalen des Supermarkts zur Neige ging, wurde eine Kanban-Karte mit der Aufforderung, x Stück nachzuliefern, an das Geschäft geschickt. Das Geschäft füllte dann seine eigenen Vorräte auf, indem es eine Kanban-Karte an den Lieferanten schickte.

Toyota war beeindruckt davon, wie Supermärkte das Kanban-System einsetzten, um ihre Lagerverwaltung effizienter zu gestalten, indem sie die Überbestände in den Filialen und Lagern zu jedem Zeitpunkt minimierten. Und dass diese Effizienzsteigerungen erzielt wurden, ohne die Fähigkeit der Supermärkte zu beeinträchtigen, stets die Bedürfnisse ihrer Kunden zu erfüllen.

Die gleiche Technik wurde in den Fabriken von Toyota eingeführt, als das Unternehmen angesichts des wirtschaftlichen Abschwungs in Japan nach einem Wettbewerbsvorteil gegenüber westlichen Konkurrenten suchte. Das funktionierte und inspirierte andere japanische Hersteller, was dazu beitrug, das Land wieder auf den Weg des Wirtschaftswachstums zu bringen.

Das Kanban-System, das Toyota zu einem der größten Automobilhersteller der Welt und Japan zu einem Zentrum für effiziente Innovationen in der Fertigung gemacht hat, erlangte jedoch erst mit der Veröffentlichung des Buches „Toyota Production System (TPS)” von Taiichi Ohno, Produktionsleiter bei Toyota, im Jahr 1978 internationale Aufmerksamkeit. Ein Großteil der Weltwirtschaft basiert heute auf den JIT-Lieferkettenprinzipien, die zuerst von japanischen Supermärkten eingeführt und von Toyota in seinem Produktionssystem verfeinert wurden.

Ohno dokumentierte, wie Toyota Kanban einsetzte, um eine kontinuierliche Verbesserung der Prozesse (im japanischen Wort „Kaizen” treffend zusammengefasst ) und die Vermeidung von Verschwendung („Muza”) zu erreichen. Dadurch gewann das System zunehmend an Bedeutung. Es veranlasste auch das International Motor Vehicle Program, zwischen 1985 und 1991 eine umfassende Studie über das System durchzuführen, die dazu führte, dass Toyotas Methodik zur Lean Production wurde.

Kanban und Lean haben natürlich auch den Ansatz für die digitale und physische Produktion nachhaltig beeinflusst und sind heute in der agilen Softwareentwicklung äußerst beliebt.

Kanbans Ziele, Werte, Prinzipien, Praktiken

Kanban wurde durch David J. Andersons 2007 erschienenes Buch „Kanban: Successful Evolutionary Change for Your Technology Business” als agiles Softwareentwicklungssystem formalisiert. Das System gewann innerhalb der IT-Branche schnell an Bedeutung, sodass Anderson 2011 die Lean Kanban University (LKU) gründete.

Andersons Formalisierung der„Kanban-Methode”der Softwareentwicklung legt Agenden, Werte und Prinzipien als philosophischen Rahmen für die vorgeschriebenen Praktiken fest.

Kanban hat drei Ziele, die es Kanban-Coaches laut Anderson ermöglichen, die Vorurteile der Methode anzunehmen und transparent zu machen. Diese sind:

• Nachhaltigkeit
• Serviceorientierung
• Überlebensfähigkeit

Kanban basiert auf neun Werten, darunter auch der grundlegende Wert des gegenseitigen Respekts zwischen Teammitgliedern und Projektbeteiligten. Die Werte fassen zusammen, warum die Prinzipien und Praktiken von Kanban existieren, und lauten wie folgt:

• Transparenz
• Gleichgewicht
• Zusammenarbeit
• Kundenorientierung
• Fluss
• Führung
• Verstehen
• Vereinbarung
• Respekt

Die sechs Prinzipien von Kanban lassen sich in zwei Untergruppen einteilen:

1. Die Prinzipien des Veränderungsmanagements
2. Die Grundsätze der Leistungserbringung

Jede Untergruppe enthält drei Grundsätze:

Die Prinzipien des Veränderungsmanagements

• Beginnen Sie mit dem, was Sie jetzt tun.
• Stimmen Sie zu, Verbesserungen durch evolutionäre Veränderungen anzustreben.
• Fördern Sie Führungsqualitäten auf allen Ebenen.

Die Grundsätze der Leistungserbringung

• Verstehen Sie die Bedürfnisse und Erwartungen Ihrer Kunden und konzentrieren Sie sich darauf.
• Verwalten Sie die Arbeit; lassen Sie die Menschen sich selbst darum herum organisieren.
• Entwickeln Sie Richtlinien, um die Ergebnisse für Kunden und Unternehmen zu verbessern.

Und die sechs Kanban-Praktiken, die jeder, der ein Projekt mit dieser Methode leitet, umsetzen sollte, sind:

1. Visualisierung des Arbeitsablaufs
2. Begrenzung der laufenden Arbeiten (WIP)
3. Flussmanagement
4. Prozessrichtlinien explizit machen
5. Implementierung von Feedback-Schleifen
6. Gemeinsam verbessern, experimentell weiterentwickeln

Kanban-Teamrollen

Während bestimmte Rollen innerhalb des Entwicklungsteams und deren Verantwortlichkeiten, z. B. Scrum Master und Product Owner, für andere agile Frameworks und Systeme von zentraler Bedeutung sind, ist dies bei Kanban nicht der Fall. Auch wenn sie für Kanban weit weniger wichtig sind, wurden dennoch zwei „Rollen” innerhalb eines Teams definiert:

• Service Delivery Manager (SDM)/Flow Manager
• Serviceanforderungsmanager (SRM)

Service Delivery Manager (SDM)/Flow Manager

Die beiden Bezeichnungen SDM und Flow Manager werden synonym verwendet und stehen für Aufgaben, die ein Mitglied des Kanban-Teams übernimmt, und nicht für eine eigenständige Berufsbezeichnung. Die Rolle des SDM weist einige Ähnlichkeiten mit der eines Scrum Masters auf, da die Person, die diese Rolle in einem Kanban-Team ausübt, dafür verantwortlich ist, den Aufgabenfluss aufrechtzuerhalten und sicherzustellen, dass die Teammitglieder die Teamkadenz (z. B. regelmäßige Besprechungen usw.) gewissenhaft einhalten.

Zu den Aufgaben des SDM würden voraussichtlich gehören:

• Überwachung des Kanban-Boards und Sicherstellung, dass Aufgaben reibungslos ablaufen und nicht in Engpässen stecken bleiben.
• Wenn eine Aufgabe nicht im erwarteten Tempo vorankommt, sprechen Sie mit dem Verantwortlichen darüber, um zu prüfen, ob es einen Engpass gibt, und bieten Sie Ihre Hilfe an.
• Stellen Sie sicher, dass die vereinbarten Teamrichtlinien und -praktiken von den Teammitgliedern befolgt werden. Dies ist besonders wichtig, wenn die Mitglieder noch keine Erfahrung mit der Arbeit mit einem Kanban-System haben.
• Verantwortlich für die Terminplanung und Teilnahme an allen täglichen und Lieferplanungs-Kanban-Meetings.

Die Rolle des Service Delivery Managers umfasst zusätzlich die Verantwortung, das Kanban-Team bei seinem Streben nach kontinuierlicher Verbesserung, der sogenannten Kaizen-Strategie, zu unterstützen. Die skalierte Kanban-SaaS-Plattform Kanbanise trägt der Tatsache Rechnung, dass das Konzept der „kontinuierlichen Verbesserung“ ein solides Rahmenwerk erfordert, damit es nicht zu abstrakt wird und praktisch bedeutungslos ist. Kanbanize schlägt vor, dass die Aufgaben des SDM im Hinblick auf die kontinuierliche Verbesserung Folgendes umfassen könnten:

• Daten über die Arbeitsaufgaben auf dem Kanban-Board sammeln und mit dem Team besprechen
• Fragen stellen, bis das Team die wahre Ursache für ein bestimmtes Problem identifiziert hat.
• Sicherstellen, dass Fehler nicht mehr als einmal wiederholt werden
• Wenn die Person über ausreichende Erfahrung verfügt, schulen Sie die Teammitglieder in Lean & Kanban.

Serviceanforderungsmanager (SRM)

Wenn die Rolle des Service Delivery Managers in Kanban Anklänge an die Rolle des Scrum Masters in einem Scrum-Team hat, gibt es ähnliche Parallelen zwischen der Rolle des Product Owners und dem Service Request Manager (SRM) in Kanban. Diese Ähnlichkeiten beruhen auf der parallelen Verantwortung, die Bedürfnisse und Erwartungen des Kunden und der Endnutzer zu verstehen.

SDM ist auch fast immer eine Aufgabe, für die ein Kanban-Teammitglied zusätzlich zu seiner Kernaufgabe Verantwortung übernimmt, und keine eigenständige Position. In einem Blogbeitrag aus dem Jahr 2016 mit dem Titel Neue Rollen im Kanbanunterschied Anderson sorgfältig zwischen der SRM-Rolle und der des Product Owners in Scrum:

„Das Ziel besteht darin, die Rolle des Product Owners als Risikomanager und Moderator neu zu positionieren: als jemand, der für die Richtlinien des Systems verantwortlich ist, die den Rahmen für Entscheidungen bilden, und gleichzeitig den Entscheidungsmechanismus moderiert. Diese Rolle ist wertvoller, transparent und offen für Kontrollen und befreit uns vom Risiko des „Helden-Product Owners“, der auf magische Weise versteht, wo der beste Geschäftswert zu finden ist. Diese gehobene Position im Risikomanagement und in der Richtlinienverantwortung verbessert die Unternehmensführung, erhöht die Konsistenz der Prozesse und verringert das mit einer einzelnen Person verbundene Personalrisiko.“

Wenn die SRM-Rolle existiert, sollte die Person, die sie ausübt, über dem Workflow stehen und für„die Nachschubbesprechung verantwortlich seinund eine Rolle bei der Strategieüberprüfung und Risikoprüfung spielen“.

Wie fügt sich das Kanban-System in den agilen Ansatz der Softwareentwicklung ein?

Kanban kann als System oder Rahmenwerk unter dem weit gefassten Begriff der agilen Softwareentwicklung eingesetzt werden. Es besteht eine natürliche Kompatibilität, da sowohl Agile als auch Kanban darauf ausgelegt sind, Teams dabei zu helfen, ein optimales Gleichgewicht zwischen Disziplin und Anpassungsfähigkeit zu finden, um den Marktanforderungen möglichst effektiv gerecht zu werden.

Es gibt eine konzeptionelle Debatte darüber, ob Kanban „agil” ist oder nicht. Das ist keine Debatte, auf die wir hier eingehen wollen, und sie interessiert uns auch nicht sonderlich. Kanban wird allgemein als eine von mehreren agilen Methoden oder Systemen anerkannt, die alle dem Kernwert folgen, anpassungsfähiger und reaktionsschneller auf Veränderungen zu reagieren, um eine höhere Teameffizienz und eine höhere Qualität der Ergebnisse zu erreichen.

Obwohl David Anderson Kanban als Softwareentwicklungssystem populär gemacht hat, lehnt er die Interpretation als Softwareentwicklungsprozess ab. Er zieht es vor, Kanban allgemeiner als Methode zum Verwalten, Entwerfen und Verbessern von Flusssystemen für Wissensarbeit zu definieren, um einen besseren Mehrwert für Kunden zu schaffen.

Kanban und DevOps

Die Kanban-Methode wird auch als kompatibel und komplementär zu DevOps angesehen. Das ist möglich, weil DevOps wie Agile eine Kultur oder Denkweise ist, während Kanban eine Methode, ein Rahmenwerk oder ein System ist. Auch hier gibt es Spekulationen und Debatten zu diesem Thema, aber am einfachsten lässt sich DevOps als eine Erweiterung des Agile-Ansatzes auf „ein neues Publikum“ beschreiben – den IT-Betrieb.

DevOps vereint Entwicklungs- und Betriebsteams zu einem einzigen agilen Softwareentwicklungsteam mit einem gemeinsamen Ziel: bessere Software, die den Anwendern einen Mehrwert bietet. Und gemeinsame Verantwortung für die Verwirklichung dieses Ziels.

Kanban ist eines der Systeme, mit denen ein Softwareentwicklungsteam die Effizienz der Wertschöpfung visualisieren und verbessern kann. Als System/Methode arbeitet Kanban mit der Agile- und DevOps-Kultur/Denkweise zusammen.

Kanban und Lean Development – und die Beziehung zu Agile

Kanban ist natürlich historisch eng mit dem Lean-Management-Ansatz zur Wertschöpfung verbunden, da beide ihre Wurzeln im Toyota-Produktionssystem haben. Lean-Organisationen oder Softwareentwicklungsteams versuchen, Aktivitäten zu identifizieren und zu eliminieren, die vom Kunden oder Endnutzer nicht geschätzt werden.

Kanban entwickelte sich als eine Methode, die zuerst von Toyota und dann von anderen Lean-Organisationen eingesetzt wurde, um Verschwendung, Variabilität und Inflexibilität zu reduzieren. Aus diesem Grund teilt es die Lean-Vorgabe einer Mentalität der kontinuierlichen Verbesserung und flexibler Arbeitsprozesse, die alle Teammitglieder dazu ermutigt, neue Ideen und Vorschläge einzubringen, mit dem Ziel, dass sich die Organisation im Laufe der Zeit verbessert. Befreit von nicht wertschöpfenden Aufgaben konzentrieren sich die Mitarbeiter mehr auf das, was für die Kunden wichtig ist.

Agile und Lean teilen viele der gleichen Grundwerte und Prinzipien, und das Agile Manifest wurde stark von Lean beeinflusst. Agile zielt darauf ab, funktionierende Software so schnell wie möglich zu liefern, und tut dies, indem es auf der iterativen Entwicklung von Mehrwert schaffenden Inkrementen für funktionierende Software besteht. Bei Lean steigern Teams die Geschwindigkeit durch das Management des Flusses, in der Regel durch die Begrenzung der laufenden Arbeiten.

Als System oder Methode basiert Kanban sowohl auf Lean als auch auf Agile.

Scrum vs. Kanban

Scrum und Kanban sind alternative agile Methoden oder Systeme, die einfach unterschiedliche Wege vorschreiben, die ihre eigenen Routinen und Rituale haben, aber dasselbe Ziel verfolgen. Kurz gesagt arbeitet ein Scrum-Team in einer Reihe von Sprints mit einem klar definierten Anfang und Ende. Im Gegensatz dazu ist Kanban ein kontinuierlicher Prozess, sodass es keinen Sprint-Backlog gibt.

Quelle: Atlassian

Beide Methoden sind in der modernen Softwareentwicklung beliebt und haben ihre jeweiligen Stärken und Schwächen. Eine Hybridmethode, die Elemente aus Scrum und Kanban kombiniert, Scrumban, wird von Softwareentwicklungsteams tatsächlich häufiger verwendet als Kanban als eigenständiges System.

Implementierung des Kanban-Systems

Die Implementierung von Kanban umfasst die Festlegung von Schritten und Vorgehensweisen, die die sechs Praktiken der Methode unterstützen:

1. Visualisierung des Arbeitsablaufs
2. Begrenzung der laufenden Arbeiten (WIP)
3. Flussmanagement
4. Prozessrichtlinien explizit machen
5. Implementierung von Feedback-Schleifen
6. Gemeinsam verbessern, experimentell weiterentwickeln

Quelle: OpenSource.com

Das Kanban-Board und die Karten

Das Kanban-Board ist für die meisten Praktiken des Systems von zentraler Bedeutung, insbesondere für die Visualisierung der Arbeit, die Begrenzung der laufenden Arbeiten (WIP) und die Steuerung des Arbeitsflusses. Ein Kanban-Board kann physisch sein, wird jedoch von Softwareentwicklungsteams meist digital genutzt, insbesondere wenn die Teammitglieder ganz oder teilweise remote arbeiten.

Die Arbeit in Form von Aufgaben (oft als User Stories für agile Entwicklungsteams definiert) wird auf das Kanban-Board gezogen und durch eine farbige Karte visuell dargestellt. Die Anzahl der auf das Kanban-Board gezogenen Aufgaben sollte der Kapazität des Entwicklungsteams entsprechen und den WIP entsprechend begrenzen.

Die Boards sind in Spalten unterteilt, die verschiedene Phasen der Aufgabenbearbeitung darstellen. Die einfachste Kanban-Board-Struktur hat nur drei Spalten:

1. Zu tun
2. In Bearbeitung
3. Vollständig

Oft gibt es jedoch noch weitere, die die Eigenschaften und die Komplexität des jeweiligen Projekts berücksichtigen. Ein komplexeres und typischeres Beispiel für ein Kanban-Board könnte wie dieses Beispiel von Microsoft aussehen:

Ein Kanban-Board kann auch Schwimmbahnen enthalten, bei denen es sich um horizontale Linien handelt, die die vertikalen Spalten unterteilen. Schwimmbahnen werden verwendet, um Aufgabenkarten systematischer zu gruppieren, wenn eine praktische Notwendigkeit zur Unterscheidung besteht. Sie können verwendet werden, um teamübergreifende Abhängigkeiten aufzuzeigen oder Aufgaben aufzuteilen, die voraussichtlich mehr oder weniger Zeit in Anspruch nehmen, sodass auf einen Blick leichter zwischen einem möglichen Engpass und einem natürlich längeren Zyklus unterschieden werden kann.

Warum die Definition von „fertig“ in Kanban entscheidend für die Wertschöpfung ist

Eines der wichtigsten Elemente für eine erfolgreiche Umsetzung der Kanban-Methode, definiert als Wertschöpfung für den Endkunden/Anwender, ist die „Definition of Done“.

Der Wert von Kanban liegt darin, die Voraussetzungen für einen effizienten Ablauf hochwertiger Arbeit zu schaffen und diesen zu verwalten. Die effektive Verfolgung des Fortschritts von Aufgaben ist von zentraler Bedeutung, um den Arbeitsfluss aufrechtzuerhalten. Und um den Fortschritt einer Aufgabe effektiv messen zu können, muss man zunächst einmal genau wissen, wann sie beendet ist – also was die „Definition von Fertigstellung” ist.

Bei Wissensarbeitsprojekten, insbesondere bei agilen Wissensarbeitsprojekten, ist selten klar, wie der endgültige Status des Projekts aussehen wird. Die Teammitglieder beginnen mit der Arbeit an Aufgaben oder User Stories, deren endgültige Details noch unklar sind.

Einzelne Aufgaben benötigen jedoch eine Definition von „fertig“, um ihr Ende zu klassifizieren und das Risiko zu vermeiden, dass sie auf unbestimmte Zeit „in Bearbeitung“ bleiben, was zu Verschwendung führt und Wert zerstört. Um dies zu vermeiden, müssen Akzeptanzkriterien festgelegt werden, wie z. B. Checklisten zur „Definition von fertig“ für einzelne Aufgaben und Prozesse.

Beispielsweise durch die Erstellung expliziter Richtlinien dafür, was es bedeutet, dass eine User Story vollständig spezifiziert und getestet ist, bevor sie in die Produktion freigegeben wird, wodurch die Wahrscheinlichkeit von Fehlern oder dem Ausbleiben eines Mehrwerts verringert wird. Die Erstellung expliziter Richtlinien für Arbeitsprozesse ist natürlich eine der sechs Kanban-Praktiken.

Die Definition von „fertig“ kann auf einem Kanban-Board durch Hinzufügen von „Ausstiegskriterien“ zu den Spalten, die die Arbeitsphasen darstellen, visualisiert werden. Wenn eine Kanban-Karte in eine Phase mit definierten Ausstiegskriterien eintritt, können diese als Checklisten auf dem Arbeitselement visualisiert werden. Die Karte kann dann erst dann in die nächste Arbeitsphase übergehen, wenn die Ausstiegs- oder Akzeptanzkriterien für die aktuelle Phase abgehakt wurden.

Begrenzung der laufenden Arbeiten (WIP) – Planung und Schätzung in Kanban

Kanban geht zwar nicht im Detail darauf ein, wie genau Planung und Schätzung erfolgen sollten, sondern überlässt dies den Teams selbst, doch die Frage „Wie lange wird das dauern?“ ist dennoch wichtig. Genaue Lieferprognosen sichern das Vertrauen und die Zufriedenheit der Kunden.

Die Schätzung kann ein Reibungspunkt für die agile Softwareentwicklung sein, da dieser Ansatz von Natur aus eine detaillierte Vorausplanung von User Stories und Arbeitsprodukten ablehnt. Projektträger haben jedoch oft immer noch ein Budget und eine Frist. Per Definition sind agile Schätzungen nicht exakt, müssen aber dennoch in Kanban vorgenommen werden, wenn die laufenden Arbeiten effektiv begrenzt werden sollen.

Eine Kanban-Roadmap kann für die übergeordnete Planung und Einschätzung verwendet werden. Sie sollte sich eher auf Ziele, Themen und Strategien für eine mittelfristige Vision stützen als auf einen detaillierten Plan für neue Funktionen. Bevor User Stories oder andere Arbeitselemente zum Kanban-Board hinzugefügt werden, empfiehlt die Kanban-Methode, diese anhand datengestützter, wahrscheinlichkeitsbasierter Zukunftsprognosen auf der Grundlage historischer Leistungsdaten einzuschätzen.

Kumulatives Flussdiagramm

Kumulative Flussdiagramme (CMDs), auch als Burn-up-Charts bezeichnet, sind ein wichtiges Kanban-Tool für datengesteuertes, probabilistisches Workflow-Management und die fortlaufende Schätzung von Arbeitsaufgaben. Sie sind eine visuelle Kennzahl, die Teams nicht nur dabei hilft, die Stabilität des Workflows zu analysieren, sondern auch Zyklus- und Durchlaufzeiten, Durchsatz und laufende Arbeiten zu messen und zu visualisieren.

Sie gelten auch als die beste Methode zur Vorhersage und Einschätzung des Projektabschlusses, da sie während des gesamten Projekts Daten sammeln und visualisieren. Historische CMDs aus früheren Projekten liefern außerdem Leistungsdaten, die bei ersten Schätzungen herangezogen werden können.

CMDs unterstützen auch die Kanban-Praxis der kontinuierlichen, kollaborativen Verbesserung, indem sie hervorheben, was gut funktioniert und was Aufmerksamkeit erfordert.

Kanban-Meetings und -Rhythmen

Von kurzen täglichen Teambesprechungen bis hin zu strategischen Überprüfungen mit externen Stakeholdern – Kanban-Meetings sorgen dafür, dass miteinander verbundene Kanban-Systeme effizient funktionieren. Die sieben Kernmeetings, die in der Kanban-Methode definiert sind, dienen dazu, durch Zusammenarbeit und persönliche Verantwortung die Qualität zu sichern, einen reibungslosen Arbeitsablauf zu gewährleisten, Problembereiche zu identifizieren und die Kundenzufriedenheit zu bewerten.

Es gibt sieben empfohlene Kanban-Meetings, die in zwei „Kadenzzyklen“ unterteilt sind – wobei dieser Begriff ein „Netzwerk“ von Meetings bezeichnet. Sie sind zentraler Bestandteil der Kanban-Praxis der Feedbackschleifen und sollen die notwendige bidirektionale Kommunikation zwischen den Stakeholdern und innerhalb des Kernteams der Softwareentwicklung fördern.

Die beiden Kanban-Kadenzzeiten sind:

1. Kadenz auf Teamebene
2. Serviceorientierte Kadenz

Kanban-Meetings auf Teamebene

Quelle: Kanbanize

Die Kadenz auf Teamebene besteht aus drei Besprechungen:

1. Team-Kanban-Meeting – Tägliches Meeting
2. Team-Nachschubbesprechung
3. Team-Rückblick

Team-Kanban-Meeting

Das Team-Kanban-Meeting ist eine kurze tägliche Besprechung, die aus Effizienzgründen auf eine Dauer von 15 Minuten begrenzt werden sollte. Es bietet dem Team die Möglichkeit, sich abzustimmen und auf den bevorstehenden Tag zu konzentrieren. Eine beliebte Form des täglichen Meetings besteht darin, dass alle Teammitglieder drei Fragen stellen und beantworten:

• Was hindert uns daran?
• Wie läuft die Arbeit?
• Was können wir verbessern?

Bei der täglichen Besprechung werden Engpässe identifiziert, damit Lösungen gefunden werden können. Diese Besprechung dient auch dazu, zu beurteilen, ob die WIP-Limits eingehalten werden.

Team-Nachschubbesprechung

Das Team-Nachschub-Meeting findet wöchentlich oder alle zwei Wochen statt und dauert empfohlen 30 Minuten. Es dient dazu, sicherzustellen, dass das Team die richtige Anzahl an Arbeitsaufgaben in Bearbeitung hat und sich zur Erledigung dieser Aufgaben verpflichten kann.

Team-Rückblick-Meeting

Team-Retrospektiven, die auch als Nachschubbesprechungen bezeichnet werden können, sollten etwa 30 Minuten dauern und je nach Projektzykluslänge alle zwei Wochen bis einmal im Monat stattfinden. Der Schwerpunkt liegt dabei darauf, wie das Team seine Arbeit verwaltet und was verbessert werden kann, beispielsweise in Bezug auf Prozessrichtlinien.

Quelle: Nave – Dashboards für Kanban-Teams

Serviceorientierte Kadenzbesprechungen

Der serviceorientierte Rhythmus besteht aus vier Treffen:

1. Workflow-Nachschubbesprechung
2. Überprüfung der Leistungserbringung/Workflow-Besprechung
3. Flow-Überprüfung
4. Risikoprüfung/Blockierung-Clustering

Quelle: Kanbanize

Nachschubbesprechung

Ebenfalls alle zwei Wochen bis einmal im Monat stattfindend und mit einer empfohlenen Dauer von 30 Minuten, werden hier neue Arbeitsaufgaben zum Kanban-Board hinzugefügt. Das bedeutet, dass Produktverantwortliche und alle anderen Personen, die an der Projektleitung beteiligt sind, aber nicht täglich mit dem Entwicklungsteam zusammenarbeiten, an dem Meeting teilnehmen sollten.

Bei der Entscheidung über neue Arbeitsaufgaben sollten deren Serviceklasse, Liefertermine, strategische Ziele und die für deren Erledigung erforderlichen Fähigkeiten der Teammitglieder berücksichtigt werden.

Überprüfung der Leistungserbringung/Workflow-Besprechung

Die Service Delivery Review ist eine kundenorientierte Überprüfung, die ebenfalls alle zwei Wochen oder einmal im Monat stattfindet und 30 Minuten dauert. Sie dient dazu, den Wert zu analysieren, den das Softwareentwicklungsteam dem Kunden mit seiner Arbeit liefert. An der Besprechung sollten sowohl der Kunde als auch der Service Delivery Manager und alle anderen relevanten Stakeholder teilnehmen, die nicht zum Entwicklungsteam gehören.

Das Meeting dient dazu, die zu Beginn des Projekts festgelegten datengestützten Kennzahlen wie gewünschte Zykluszeiten, Konsistenz der Vorlaufzeiten und Lieferquoten zu bewerten. Die Transparenz und die Möglichkeit, auf Kundenanliegen einzugehen, die dieses Meeting bietet, sollten dazu beitragen, Vertrauen beim Kunden aufzubauen.

Flow-Überprüfung

Als Teil des Workflow-Meetings konzentriert sich die Flow-Überprüfung auf die internen Fähigkeiten und Kapazitäten des Teams. Ihr Ziel ist es, den Prozessablauf zu verstehen und zu überwachen sowie Probleme wie bevorstehende Engpässe und Möglichkeiten zu deren Beseitigung zu identifizieren.

Risikoprüfung/Blockierung-Clustering

Dieses 1-2-stündige Meeting findet in der Regel alle zwei Wochen oder einmal im Monat statt und dient der Untersuchung von Engpässen und Hindernissen, die ein Risiko für die Lieferung darstellen könnten. Historische Fehler sollten analysiert und ihre Ursachen behoben werden. An dem Meeting sollten alle Teammitglieder und Stakeholder teilnehmen, die mit aktuellen und kürzlich aufgetretenen Hindernissen vertraut sind. Die Aufmerksamkeit sollte auf Hinderniscluster auf Team- oder Abteilungsebene gelenkt werden.

Kanban-Meetings mit Blick auf das große Ganze

Das Kanban-System empfiehlt zwei weitere Meetings, die einen größeren Überblick bieten und über den beiden Kadenzzyklen angesiedelt sind:

1. Betriebsüberprüfung
2. Strategieüberprüfung

Betriebsüberprüfung

Dieses etwa zweistündige Meeting, das in der Regel monatlich stattfindet, ist wie eine Makroversion der Service Delivery Review und bringt miteinander verbundene interne Teams und Systeme zusammen. Es kann eine Abteilung oder sogar ein ganzes kleines Unternehmen umfassen. Der Grund dafür ist, dass effiziente Teams durch Ineffizienzen an anderer Stelle in einer Organisation, wie z. B. bei der Ressourcenplanung oder Abhängigkeiten von einem weniger effizienten Team, behindert werden können.

Manager aus verschiedenen Abteilungen, Bereichen oder Systemen arbeiten zusammen, um Effizienzsteigerungen zu erzielen, die dem gesamten Unternehmen zugutekommen, beispielsweise durch die Nutzung ungenutzter Kapazitäten innerhalb der Organisation, um die Durchlaufzeiten zu verbessern.

Strategieüberprüfung

Die Strategieüberprüfung, die in der Regel vierteljährlich stattfindet und bis zu einem halben Tag dauert, ist die höchste Ebene der Kanban-Sitzungen. Sie dient dazu, die Strategie auf der Grundlage von Kundenfeedback und etwaigen Änderungen externer Faktoren wie Märkte und Verbraucher-/Nutzerverhalten anzupassen.

Der Kernpunkt der Strategieüberprüfung besteht darin, dass es kaum eine Rolle spielt, wie schnell und effizient sich ein Fahrzeug bewegt, wenn es in die falsche Richtung fährt. Die Festlegung und Anpassung allgemeiner strategischer Ziele und Ausrichtungen sollte in die Kanban-Roadmap einfließen und in tägliche, wöchentliche und monatliche Ziele umgesetzt werden, die während der Lieferplanungs- und Workflow-Nachschubbesprechungen behandelt werden.

Die Teilnehmer sollten aus einem breiteren Kreis von Stakeholdern stammen und können Führungskräfte, Produktverantwortliche, leitende Mitglieder des Entwicklungsteams und relevante Vertreter aus kundenorientierten Abteilungen wie Vertrieb und Marketing umfassen.

Vor- und Nachteile von Kanban

Wie jede andere Methodik, jedes andere Framework oder jedes andere System, das in der Softwareentwicklung verwendet wird, hat auch die Kanban-Methode ihre Vor- und Nachteile. Diese lassen sich kurz wie folgt zusammenfassen:

Vorteile von Kanban

Einfache Bedienung/geringe Einstiegshürden: Eine der größten Stärken von Kanban ist die Tatsache, dass es dank seiner Einfachheit und der Verwendung von Visualisierungen auch für Teammitglieder ohne Vorkenntnisse sehr schnell zu erlernen ist.

Flexibilität: Im Mittelpunkt von Kanban als agiler Methode steht die inhärente Flexibilität, die es Teams ermöglicht, sich schnell an Veränderungen anzupassen und Prozesse im Streben nach kontinuierlicher Verbesserung und Wertschöpfung anzupassen.

 Zusammenarbeit: Kanban ist in hohem Maße auf Zusammenarbeit ausgerichtet und fördert Teamarbeit und kollektive Verantwortung für die Gesamteffizienz und die Schaffung von Mehrwert.

Einführung eines Prozesses: Der Fokus von Kanban auf kontinuierliche Lieferung steigert die Produktivität, insbesondere bei längeren Projektzyklen.

Kanban-Nachteile

 Kann zu mangelnder Konzentration führen: Da Kanban keine strengen Verantwortlichkeiten festlegt, kann dies dazu führen, dass Teams und Einzelpersonen abgelenkt werden.

 Komplexität des Kanban-Boards: Es mag wie ein Widerspruch zu Kanbans bekannter Stärke in Sachen Einfachheit klingen, aber auf der Ebene des Kanban-Boards kann es schnell sehr komplex werden, wenn man nicht aufpasst, was die Teammitglieder verwirren kann.

Fehlende Zeitvorgaben:Einige Kunden und Projektmanager stören sich daran, dass Kanban im Gegensatz zu anderen agilen Ansätzen wie Scrum keine strengen Zeitvorgaben vorsieht.

Spannungen bei der iterativen Softwareentwicklung: Die iterative Entwicklung ist eine Säule der meisten agilen Softwareentwicklungssysteme, aber auf Ticketebene kein integraler Bestandteil von Kanban. Dies ist einer der Hauptgründe, warum Elemente von Kanban oft mit anderen Ansätzen wie Scrum kombiniert werden.

Schlussfolgerung

Wir hoffen, dass Ihnen dieser Blog einen guten Überblick über die Kanban-Methode gegeben hat. Sie sollten nun verstehen, warum sie entweder als eigenständiges System oder durch die gezielte Auswahl einzelner Elemente wie dem Kanban-Board in Kombination mit anderen Ansätzen ein so beliebter Bestandteil des Ökosystems für das Projektmanagement in der Softwareentwicklung ist.