Kanban ist ein agiler Ansatz, der je nach Kontext, in dem er angewandt wird, auch als Methode, System, Framework oder Workflow-Management-Methode bezeichnet wird. Das Kanban-System ist besonders in der Softwareentwicklung beliebt und soll die Effizienz der Produktionsprozesse und die Qualität der Produkte verbessern.
Das Kanban-System für die agile Software-Entwicklung ist hier unser Schwerpunkt. Sie werden erfahren, was Kanban ist, wie es entstand und wie es sich in der Nachkriegszeit an den Fließbändern von Toyota durchsetzte, um anschließend zu einem beliebten Softwareentwicklungsprozess zu werden.
Außerdem werden wir die wichtigsten Konzepte und Elemente des Kanban-Systems erläutern und auf seine praktische Umsetzung in Softwareentwicklungsprojekten bzw. -teams eingehen.
Was genau ist das Kanban-System?
Im Kern ist Kanban ein Just-in-Time-Produktionsverfahren (JIT), das darauf abzielt, den Fluss von Rohstoffen 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) in Abhängigkeit von der Kapazität des Entwicklungsteams.
Ein weiterer wesentlicher Grundpfeiler von Kanban ist, dass es sich um ein „Pull„- und nicht um ein „Push„-System handelt. Das bedeutet, dass Arbeit in das System gezogen wird, sobald zuvor zugewiesene Arbeit abgeschlossen ist. Im Gegensatz dazu werden neue Aufgaben in den Workflow geschoben, sobald sie erstellt werden. Die Umkehrung von „Push“ zu „Pull“ bedeutet, dass die Produktion eine Folge der Kundennachfrage ist und mit dieser korreliert, wodurch das Potenzial für Verschwendung reduziert 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 bei.
- Steigerung der Produktivität durch Aufrechterhaltung eines konsistenten „Flusses“ der Aufgaben, die in das Endprodukt münden.
- Verbessert die Priorisierung von Aufgaben und lässt gleichzeitig Raum für Agilität und die Fähigkeit, schnell auf Veränderungen zu reagieren.
- Fördert die Zusammenarbeit im Team.
- Fördert die Führung in allen Rollen und auf allen Ebenen der Geschäftsleitung.
Kanban ist ein sehr visuelles System. Der Produktions- oder Entwicklungsprozess wird in einzelne Aufgaben unterteilt, die jeweils durch eine (in der Regel bunte und oft farbcodierte) Karte dargestellt werden. Der Name des Systems leitet sich von seinem Visualisierungsmechanismus ab, wobei „kan“ im Japanischen für Signal und „ban“ für Karte steht.
Einem Kanban-Team werden so viele Aufgaben zugewiesen, wie es für seine Kapazität optimal ist. Die Teammitglieder nehmen diese Aufgaben dann eine nach der anderen auf und bringen sie so schnell wie möglich durch die verschiedenen Stadien der Fertigstellung (die je nach Projekt oder Organisation variieren können) von „To Do“ bis „Erledigt„, bevor sie mit der nächsten Aufgabe beginnen.
Alle Aufgabenkarten werden auf der „To Do„-Spalte einer Kanban-Board platziert, auf die später noch näher eingegangen wird, und dann über die Spalten verschoben, die die verschiedenen Erledigungsstufen repräsentieren. Durch diese Art der Visualisierung des Arbeitsablaufs wird sehr schnell deutlich, ob Engpässe den Fortschritt der Aufgaben bei der Erledigung behindern, so dass diese behoben werden können.
Die Kanban-Visualisierung des Aufgabenrückstands und des Arbeitsablaufs ist eine Form der Gamification, angewandt auf Produktivität und Teamarbeit.
Eine kurze Geschichte zum Kanba-System
Das Kanban-System entstand in den späten 1940er Jahren in den Nachkriegsfabriken des japanischen Autogiganten Toyota. Toyota ließ sich von dem Just-in-Time-Konzept inspirieren, das zu dieser Zeit in Japan bereits von Supermärkten eingeführt wurde, die ihre Bestandsverwaltung durch den Einsatz eines Kartensystems zwischen Werkstatt und Lager bzw. Lager und Lieferant optimierten.
Wenn ein Produkt in den Supermarktregalen zur Neige ging, wurde eine Kanban-Karte mit der Aufforderung, eine bestimmte Anzahl von Produkten nachzuliefern, an die Filiale geschickt. Die Filiale füllte ihre eigenen Vorräte auf, indem sie eine Kanban-Karte an den Lieferanten schickte.
Toyota war von der Effizienz beeindruckt, die die Supermärkte mit dem Kanban-System bei der Bestandsverwaltung erzielten. So konnten sie die überschüssigen Bestände in den Filialen und Lagern auf ein Minimum reduzieren. Diese Effizienzsteigerung wurde erreicht, ohne dass der Supermarkt in seiner Fähigkeit beeinträchtigt wurde, die Kundenbedürfnisse stets zu erfüllen.
Die gleiche Technik wurde in den Toyota-Fabriken eingeführt. Das Unternehmen suchte nach einem Wettbewerbsvorteil gegenüber westlichen Konkurrenten, als Japan einen wirtschaftlichen Abschwung erlebte. Es funktionierte, inspirierte andere japanische Hersteller und trug dazu bei, das Land wieder auf den Weg des Wirtschaftswachstums zu bringen.
Doch das Kanban-System, das dazu beitrug, Toyota zu einem der größten Automobilhersteller der Welt und Japan zu einem Zentrum effizienter Innovationen in der Fertigung zu machen, erlangte erst mit der Veröffentlichung des Buches über das Toyota-Produktionssystem (TPS) des Toyota-Produktionsleiters Taiichi Ohno aus dem Jahr 1978 wirklich internationale Aufmerksamkeit. Ein Großteil der Weltwirtschaft funktioniert heute nach den Grundsätzen der Just in Time Lieferkette, die zuerst von japanischen Supermärkten eingeführt und von Toyota in seinem Produktionssystem verfeinert wurde.
Ohnos Dokumentation darüber, wie Toyota Kanban zur kontinuierlichen Verbesserung von Prozessen (im japanischen Wort „kaizen“ zusammengefasst) und zur Vermeidung von Verschwendung („muza„) einsetzte, verschaffte dem System eine große Anhängerschaft. Dies veranlasste auch das International Motor Vehicle Program, zwischen 1985 und 1991 eine umfassende Studie über das System durchzuführen, woraufhin die Toyota-Methode zur Lean Production wurde.
Kanban und Lean haben in der Folge natürlich auch den Ansatz der digitalen und physischen Produktion stark beeinflusst und sind heute in der agilen Softwareentwicklung sehr beliebt.
Agenden, Werte, Grundsätze und Praktiken von Kanban
Kanban wurde erstmal als agiles Softwareentwicklungssystem durch das 2007 erschienene Buch „Kanban: Successful Evolutionary Change for Your Technology Business“ von David J. Anderson formalisiert. Das System gewann in der IT-Branche schnell an Zugkraft, so dass Anderson 2011 die Lean Kanban University (LKU) gründete.
Andersons Formalisierung der „Kanban-Methode“ für die Softwareentwicklung definiert Agenden, Werte und Prinzipien als philosophischen Rahmen für die vorgesehenen Praktiken zur Softwareentwicklung.
Kanban hat drei Agenden, die es laut Anderson den Kanban-Coaches ermöglichen, die Vorurteile der Methode zu akzeptieren und transparent zu machen. Diese sind:
- Nachhaltigkeit
- Service-Orientierung
- Überlebensfähigkeit
Kanban hat neun Werte, die auf dem zugrundeliegenden Wert des gegenseitigen Respekts zwischen Teammitgliedern und Projektbeteiligten beruhen und diesen einschließen. Diese Werte sollen zusammenfassen, warum es die Prinzipien und Praktiken von Kanban gibt, und sie sind:
- Offenheit
- Ausgewogenheit
- Kollaboration
- Kundenfokus
- Workflow
- Führungsqualitäten
- Verständigung
- Vereinbarung
- Respekt
Diese sechs Grundsätze von Kanban sind in zwei Untergruppen aufgeteil:
- Die Änderungsmanagement-Prinzipien
- Die Grundsätze der Leistungserbringung
Zu jeder dieser Untergruppen gehören stets 3 Grundsätze:
Die Änderungsmanagement-Prinzipien
- Beginnen Sie mit dem, was Sie jetzt tun.
- Verbesserung durch evolutionären Wandel anstreben.
- Förderung von Führungsqualitäten auf allen Ebenen.
Die Grundsätze der Leistungserbringung
- Verstehen und konzentrieren Sie sich auf die Bedürfnisse und Erwartungen Ihrer Kunden.
- Managen Sie die Arbeit; lassen Sie Ihre Mitarbeiter sich selbst organisieren.
- Entwickeln Sie Richtlinien, um die Kunden- und Geschäftsergebnisse zu verbessern.
Außerdem gibt es sechs Kanban-Praktiken, die jeder, der ein Projekt nach dieser Methode leitet, umsetzen sollte:
- Visualisierung des Arbeitsablaufs
- Begrenzung der work in progress (WIP)
- Flowstatus steuern
- Explizite Festlegung von Prozessrichtlinien
- Implementierung von Feedback loops
- Gemeinsam verbessern, experimentell weiterentwickeln
Kanban Teamrollen
Während für andere agile Frameworks und Systeme speziell benannte Rollen im Entwicklungsteam und deren Verantwortlichkeiten, z.B. Scrum Master und Product Owner, von zentraler Bedeutung sind, ist dies bei Kanban nicht der Fall. Obwohl sie für Kanban weit weniger wichtig sind, wurden zwei „Rollen“ innerhalb eines Teams definiert:
- Service Delivery Manager (SDM)/Flow Manager
- Service Request Manager (SRM)
Service Delivery Manager (SDM) / Flow Manager
Die beiden Bezeichnungen SDM und Flow Manager sind austauschbar und stehen eher für die Verantwortlichkeiten, die ein Mitglied des Kanban-Teams übernimmt, als für eine eigenständige Stellenbezeichnung. Die SDM-Rolle hat insofern Ähnlichkeiten mit der eines Scrum Masters, als dass die Person, die diese Funktion in einem Kanban-Team ausübt, für die Aufrechterhaltung des Aufgabenflusses verantwortlich ist sowie dafür, dass die Teammitglieder die Teamkadenzen (wie z. B. regelmäßige Meetings usw.) gewissenhaft einhalten.
Zu den Aufgaben des SDM gehören unter anderem:
- Überwachung des Kanban-Boards und Sicherstellung, dass die Aufgaben im Fluss sind und nicht in Engpässen stecken bleiben.
- Wenn eine Aufgabe nicht in der erwarteten Geschwindigkeit erledigt wird, wird die zuständige Person kontaktiert, um zu prüfen, ob es einen Engpass gibt, und um Hilfe anzubieten.
- Die Sicherstellung, dass sich die Teammitglieder an die vereinbarten Richtlinien und Praktiken halten. Dies ist besonders wichtig, wenn die Mitglieder zum ersten Mal mit einem Kanban-System arbeiten.
- Verantwortlich für die Planung und Teilnahme an allen Kanban-Sitzungen zur Tages- und Lieferplanung.
Die Rolle des Service Delivery Managers beinhaltet außerdem die Verantwortung, die kontinuierliche Verbesserung bzw. die Kaizen-Strategie des Kanban-Teams voranzutreiben. Die SaaS-Plattform Kanbanise von Scaled Kanban berücksichtigt die Tatsache, dass das Konzept der „kontinuierlichen Verbesserung“ einen soliden Rahmen benötigt, wenn es nicht zu abstrakt werden soll. Kanbanize empfiehlt, dass die SDM-Verantwortlichkeiten bei der Verfolgung der kontinuierlichen Verbesserung Folgendes umfassen sollten:
- Sammeln von Daten über die Arbeitsaufgaben auf der Kanban-Board und Besprechung dieser Daten mit dem Team
- Fragen zu stellen, bis das Team die wahre Ursache für ein bestimmtes Problem gefunden hat
- Sicherstellen, dass Fehler nicht mehr als einmal wiederholt werden
- Wenn die Person über genügend Fachwissen verfügt, coacht sie die Teammitglieder in Lean und Kanban.
Service Request Manager (SRM)
Wenn die Rolle des Service Delivery Managers in Kanban Ähnlichkeiten mit der Rolle des Scrum Master in einem Scrum-Team aufweist, so gibt es auch Parallelen zwischen der Rolle des Product Owner und dem Service Request Manager (SRM) in Kanban. Diese Ähnlichkeiten beruhen auf der parallelen Verantwortung, die Bedürfnisse und Erwartungen der Kunden und Endnutzer zu verstehen.
Die Rolle des SDM ist auch fast immer eine Rolle, für die ein Kanban-Teammitglied zusätzlich zu seiner Hauptaufgabe Verantwortung übernimmt, anstatt eine eigenständige Position einzunehmen. In einem Blog aus dem Jahr 2016 mit dem Titel „Emerging roles in Kanban“ unterscheidet Anderson die Rolle des SRM sorgfältig von der eines Product Owner in Scrum:
„Das Ziel besteht darin, die Rolle des Product Owners als Risikomanager und Vermittler neu zu positionieren: jemand, der die Regeln für das System festlegt, die den Rahmen für Entscheidungen bilden, und gleichzeitig den Entscheidungsfindungsmechanismus erleichtert. Diese Rolle ist von höherer Bedeutung, sie ist transparent und offen für Überprüfungen und befreit uns von dem Risiko des ‚heroischen Product Owners‘, der auf magische Weise versteht, wo der beste Geschäftswert zu erreichen ist. Diese erhöhte Position des Risikomanagements und des Eigentümers von Richtlinien verbessert die Unternehmensführung, verbessert die Konsistenz der Prozesse und reduziert das Personalrisiko, das mit einer einzelnen Person verbunden ist.“
Sofern die SRM Rolle existiert, sollte die Person, die sie ausfüllt, über dem Arbeitsablauf stehen sowie für „…die Ergänzungsbesprechung verantwortlich sein und eine Rolle bei der Strategieüberprüfung und der Risikobewertung spielen„.
Wie passt das Kanban-System in den agilen Ansatz der Softwareentwicklung?
Kanban kann als System oder Framework unter dem breiten Dach der agilen Softwareentwicklung eingesetzt werden. Es besteht eine natürliche Kompatibilität, da sowohl Agile als auch Kanban darauf abzielen, Teams dabei zu helfen, ein optimales Gleichgewicht zwischen Disziplin und Anpassungsfähigkeit zu finden, um die Anforderungen des Marktes möglichst effektiv zu erfüllen.
Es gibt eine konzeptionelle Debatte darüber, ob Kanban „Agil“ ist oder nicht. Auf diese Debatte wollen wir hier nicht eingehen, und sie interessiert uns auch nicht besonders. Kanban wird allgemein als eine der zahlreichen agilen Methoden oder Systeme akzeptiert. Sie alle verfolgen das zentrale Ziel, auf Veränderungen anpassungsfähiger und reaktionsfähiger zu werden und dadurch die Effizienz des Teams und die Qualität der Ergebnisse zu steigern.
Obwohl Anderson Kanban als Softwareentwicklungssystem populär gemacht hat, lehnt er die Interpretation als Softwareentwicklungsprozess ab. Er zieht es vor, Kanban im weiteren Sinne als eine Methode zur Verwaltung, Gestaltung und Verbesserung von Flow-Systemen für Wissensarbeit zu definieren, um einen besseren Wert für die Verbraucher zu schaffen.
Kanban und DevOps
Die Kanban-Methode wird auch als kompatibel und ergänzend zu DevOps angesehen. Das ist möglich, weil DevOps, wie Agile, eine Kultur oder Denkweise ist, während Kanban eine Methode, ein Rahmen oder ein System ist. Auch hier gibt es Vermutungen und Debatten, aber am einfachsten lässt sich DevOps als Erweiterung des agilen Ansatzes auf ein „neues Publikum“ beschreiben – den IT-Betrieb.DevOps vereint Entwicklungs- und Betriebsteams als ein einziges agiles Softwareentwicklungsteam mit einem gemeinsamen Ziel – bessere Software, die einen höheren Mehrwert für die Benutzer bringt. Außerdem tragen sie gemeinsam die Verantwortung für die Verwirklichung dieses Ziels.
Kanban ist eines der Systeme, die implementiert werden können, um einem Softwareentwicklungsteam dabei zu helfen, die Effizienz bei der Bereitstellung dieses Mehrwerts zu visualisieren und zu verbessern. Als System/Methode arbeitet Kanban mit der Agile- und DevOps-Kultur/Mentalität zusammen.
Kanban & Lean-Entwicklung – und ihre 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 bzw. Softwareentwicklungsteams versuchen, Aktivitäten zu identifizieren und zu eliminieren, die vom Kunden oder Endbenutzer nicht geschätzt werden.
Kanban entwickelte sich als Methode, die zunächst von Toyota und dann von anderen Lean-Organisationen eingesetzt wurde, um Verschwendung, Variabilität und Inflexibilität zu reduzieren. Aus diesem Grund entspricht es der Lean-Methode, die auf kontinuierliche Verbesserung und flexible Arbeitsprozesse setzt und alle Teammitglieder dazu ermutigt, neue Ideen und Vorschläge einzubringen, mit dem Ziel, die Organisation mit der Zeit zu verbessern. Befreit von nicht wertschöpfenden Aufgaben, konzentrieren sich die Mitarbeiter mehr auf das, was für die Kunden wichtig ist.
Agile und Lean haben viele der zugrunde liegenden Werte und Prinzipien gemeinsam, und das Agile Manifest wurde stark von Lean beeinflusst. Agile zielt darauf ab, funktionierende Software so schnell wie möglich auszuliefern, und setzt dabei auf die iterative Entwicklung von wertsteigernden Komponenten der funktionierenden Software. Bei Lean erhöhen die Teams die Geschwindigkeit, indem sie den Arbeitsfluss steuern, in der Regel durch die Begrenzung der in Bearbeitung befindlichen Arbeit.
Als System oder Methode wird Kanban sowohl von Lean als auch von Agile beeinflusst.
Scrum und Kanban
Scrum und Kanban sind alternative agile Methoden oder Systeme, die lediglich unterschiedliche Wege mit eigenen Routinen und Ritualen, aber demselben Ziel vorgeben. Kurz gesagt, ein Scrum-Team arbeitet in einer Reihe von Sprints mit einem klar definierten Anfang und Ende. Im Gegensatz dazu ist Kanban ein kontinuierlicher Prozess, es gibt also kein Sprint Backlog.
Source: Atlassian
Beide Methoden sind in der modernen Softwareentwicklung beliebt und haben ihre jeweiligen Stärken und Schwächen. Eine hybride Methode, die Elemente von Scrum und Kanban kombiniert, Scrumban, wird von Softwareentwicklungsteams sogar noch häufiger verwendet als Kanban als alleinstehendes System.
Implementierung des Kanban-Systems
Die Umsetzung von Kanban beinhaltet die Festlegung von Schritten und Praktiken, die die sechs Praktiken der Methode unterstützen:
- Visualisierung des Arbeitsablaufs
- Begrenzung der unfertigen Arbeit (work in progress, WIP)
- Flowstatus steuern
- Explizite Festlegung von Prozessrichtlinien
- Implementierung von Feedback loops
- Gemeinsam verbessern, experimentell weiterentwickeln
Source: OpenSource.com
Das Kanban-Board und die Kanban-Karten
Das Kanban-Board ist für die meisten Praktiken des Systems von zentraler Bedeutung, vor allem für die Visualisierung der Arbeit, die Begrenzung der laufenden Arbeiten (WIP) und die Steuerung des Workflows. Das Kanban-Board kann physisch sein, wird aber in Software-Entwicklungsteams meist digital verwendet, vor allem, wenn die Teammitglieder zeitweise oder ganz an anderen Orten arbeiten.
Arbeit in Form von Aufgaben (bei agilen Entwicklungsteams oft als User Stories definiert) wird auf das Kanban-Board gezogen und visuell durch farbige Karten 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 Stadien der Fertigstellung einer Aufgabe darstellen. Die einfachste Kanban-Boardstruktur hat nur drei Spalten:
- To do
- In Arbeit
- Erledigt
Oft gibt es aber noch weitere, die den Eigenschaften und der Komplexität des jeweiligen Projekts angepasst sind. Ein komplexeres und typisches Beispiel für eine Kanban-Board könnte so aussehen wie dieses Beispiel von Microsoft:
Ein Kanban-Board kann auch Swimlanes (Element aus Datenflussdiagramm) enthalten, d. h. horizontale Linien, die die vertikalen Spalten unterteilen. Swimlanes werden verwendet, um Aufgabenkarten systematischer zu gruppieren, wenn eine praktische Notwendigkeit zur Differenzierung besteht. Sie können verwendet werden, um teamübergreifende Abhängigkeiten aufzuzeigen oder Aufgaben aufzuteilen, die voraussichtlich mehr oder weniger Zeit in Anspruch nehmen, so dass es einfacher ist, auf einen Blick zwischen einem möglichen Engpass und einem natürlich längeren Zyklus zu unterscheiden.
Warum die Definition von „Erledigt” in Kanban der Schlüssel zur Wertschöpfung ist
Eines der wichtigsten Elemente für eine erfolgreiche Umsetzung der Kanban-Methode, die als Wertschöpfung für den Endkunden/Nutzer definiert ist, ist das Verständnis des Begriffs „Erledigt“.
Der Wert von Kanban besteht darin, die Voraussetzungen für einen effizienten Fluss hochwertiger Arbeit zu schaffen und zu verwalten. Die effektive Verfolgung des Fortschritts von Aufgaben ist von zentraler Bedeutung, um die Arbeit im Fluss zu halten. Und um den Fortschritt einer Aufgabe effektiv zu messen, muss man wissen, wann sie abgeschlossen ist – was die „Definition von Erledigt“ ist.
Bei Wissensarbeitsprojekten, insbesondere bei agilen Wissensarbeitsprojekten, gibt es selten ein klares Bild davon, wie der Endstatus des Projekts aussieht. 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 Erledigt „, um ihr Ende zu klassifizieren, um das Risiko zu vermeiden, dass sie auf unbestimmte Zeit “ in Arbeit “ verbleiben, was zu Verschwendung und Wertverlust führt. Um dies zu vermeiden, müssen Akzeptanzkriterien festgelegt werden, z. B. Checklisten für die „Definition von Erledigt“ sowohl für einzelne Aufgaben als auch für Prozesse.
So können beispielsweise explizite Richtlinien dafür erstellt werden, was es bedeutet, dass eine Benutzergeschichte vollständig spezifiziert und getestet wird, bevor sie für die Produktion freigegeben wird, wodurch die Wahrscheinlichkeit von Fehlern oder einer fehlenden Wertschöpfung verringert wird. Die Erstellung expliziter Richtlinien für Arbeitsprozesse ist natürlich eine der sechs Kanban-Praktiken.
Die „Definition von Erledigt“ kann auf einem Kanban-Board durch das Hinzufügen von „Ausstiegskriterien“ zu den Spalten, die die Arbeitsstufen darstellen, visualisiert werden. Wenn eine Kanban-Karte in eine Phase mit definierten Ausstiegskriterien eintritt, können diese als Checklisten auf dem Arbeitsgegenstand visualisiert werden. Die Karte kann nur dann zur nächsten Arbeitsstufe übergehen, wenn die Ausstiegs- oder Akzeptanzkriterien für die aktuelle Stufe abgehakt wurden.
Begrenzung der Work in Progress (WIP, unfertigen Arbeit) – Planung & Einschätzung in Kanban
Auch wenn Kanban nicht im Detail darauf eingeht, wie genau die Planung und Einschätzung erfolgen sollte, und es den Teams überlässt, dies selbst zu definieren, ist die Frage „Wie lange wird es dauern?“ dennoch wichtig. Genaue Lieferprognosen erhalten das Vertrauen und die Zufriedenheit der Kunden.
Die Schätzung kann ein Reibungspunkt bei der agilen Softwareentwicklung sein, da dieser Ansatz von vornherein eine detaillierte Planung von User Stories und Arbeitsprodukten ablehnt. Projektsponsoren haben jedoch oft ein Budget und eine Frist. Agile Schätzungen sind per definitionem nicht exakt, müssen aber dennoch in Kanban vorgenommen werden, wenn der Work in Progress effektiv begrenzt werden soll.
Eine Kanban-Roadmap kann für die Planung und Schätzung auf hoher Ebene verwendet werden. Sie sollte auf Zielen, Themen und Strategien im Hinblick auf eine mittelfristige Vision basieren und nicht auf einem detaillierten Plan für neue Funktionen. Bevor User Stories oder andere Arbeitsaufgaben dem Kanban-Board hinzugefügt werden, empfiehlt die Kanban-Methode, sie anhand von datengesteuerten, wahrscheinlichkeitsbasierten Zukunftsprognosen auf der Grundlage historischer Leistungsaufzeichnungen abzuschätzen.
Kumulatives Flussdiagramm
Kumulative Flussdiagramme (KFD), auch als Burn-up-Diagramme bezeichnet, sind ein wichtiges Kanban-Werkzeug für datengesteuertes, wahrscheinlichkeitsbasiertes Workflow-Management und die fortlaufende Schätzung von Arbeitsaufgaben. Sie sind eine visuelle Metrik, die den Teams nicht nur hilft, die Stabilität der Arbeitsabläufe 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 Schätzung des Projektabschlusses, da sie Daten während des gesamten Projekts sammeln und visualisieren. Historische KFDs aus früheren Projekten liefern auch die Leistungsnachweise, die bei ersten Schätzungen verwendet werden können.
KFDs unterstützen auch die Kanban-Praxis der kontinuierlichen, kollaborativen Verbesserung, indem sie aufzeigen, was gut funktioniert und worauf zu achten ist.
Kanban-Meetings und -Zyklen
Von kurzen täglichen Teambesprechungen bis hin zu großen Strategiebesprechungen mit externen Interessengruppen, Kanban-Meetings sorgen dafür, dass miteinander verknüpfte Kanban-Systeme effizient funktionieren. Die sieben Kernbesprechungen der Kanban-Methode haben die Aufgabe, die Qualität durch Zusammenarbeit und persönliche Verantwortung zu sichern, den Arbeitsablauf reibungslos zu gestalten, Problembereiche zu identifizieren und die Kundenzufriedenheit zu bewerten.
Es gibt sieben empfehlenswerte Kanban-Meetings, die in zwei „Kadenzen“ unterteilt sind – der Begriff steht für ein „Netzwerk“ von Meetings. Sie sind von zentraler Bedeutung für die Kanban-Praxis der Feedback loops und sollen die notwendige Kommunikation in beide Richtungen zwischen den Beteiligten und innerhalb des Kernteams der Softwareentwicklung fördern.
Die beiden Kanban-Kadenzen sind:
- Teamspezifische Kadenzen
- Service-orientierte Kadenzen
Kanban-Meetings der teamspezifische Kadenz
Source: Kanbanize
Die Kadenz auf Teamebene besteht aus drei Sitzungen:
- Team Kanban Meeting – Daily Meeting
- Team Replenishment Meeting
- Team Retrospective Meeting
Team Kanban Meeting
Das Kanban Teammeeting ist eine kurze tägliche Besprechung, die aus Gründen der Effizienz auf 15 Minuten begrenzt werden sollte. Es bietet dem Team die Möglichkeit, sich abzustimmen und auf den bevorstehenden Tag zu konzentrieren. Ein beliebtes Format für die tägliche Besprechung ist, dass alle Teammitglieder drei Fragen stellen und beantworten:
- Was behindert uns?
- Wie läuft die Arbeit?
- Was können wir verbessern?
Bei der täglichen Besprechung werden Engpässe ermittelt, so können Lösungen angestrebt werden, außerdem wird bei dieser Besprechung geprüft, ob die work-in-progress-Grenzen eingehalten werden.
Team Replenishment Meeting
Das wöchentlich oder zweiwöchentlich je 30 minütig stattfindende „Team Replenishment Meeting“ dient dazu, sicherzustellen, dass das Team über die richtige Anzahl an laufenden Aufgaben verfügt und in der Lage ist, diese Aufgaben zu erledigen.
Team Retrospective Meeting
Retrospektive Teambesprechungen, die auch als „Replenishment Reviews“ bezeichnet werden können, sollten etwa 30 Minuten dauern und je nach Länge des Projektzyklus alle zwei bis vier Wochen stattfinden. Sie konzentrieren sich darauf, wie das Team seine Arbeit bewältigt und was verbessert werden kann, wie z. B. die Prozessrichtlinien.
Source: Nave – dashboards for Kanban teams
Serviceorientierte Kadenztreffen
Die serviceorientierte Kadenz besteht aus vier Sitzungen:
- Workflow Replenishment Meeting
- Service Delivery Review / Workflow Meeting
- Flow Review
- Risk Review / Block Clustering
Source: Kanbanize
Workflow Replenishment Meeting
Ebenfalls alle zwei bis vier Wochen stattfindend und mit einer empfohlenen Dauer von 30 Minuten, werden hier neue Arbeitsaufgaben zum Kanban-Board hinzugefügt. Das bedeutet, dass Product Owner und alle anderen Personen, die an der Projektverwaltung beteiligt sind, aber nicht täglich mit dem Entwicklungsteam zu tun haben, an dieser Besprechung teilnehmen sollten.
Bei der Entscheidung über neue Arbeitsaufgaben sollten die Leistungsklasse, der Liefertermin, die strategischen Ziele und die Fähigkeiten der Teammitglieder berücksichtigt werden, die für die Erledigung der Aufgaben erforderlich sind.
Service Delivery Review / Workflow Meeting
Die kundenorientierte Überprüfung der Leistungserbringung ist ein weiteres 30-minütiges, zwei- oder vierwöchentliches Treffen, bei dem der Wert analysiert wird, den das Softwareentwicklungsteam dem Kunden bietet. An der Besprechung sollten sowohl der Kunde, der Kundendienstleiter als auch alle anderen Beteiligten, die nicht zum Entwicklungsteam gehören, teilnehmen.
Die Besprechung dient der Bewertung datengestützter Kennzahlen, die zu Beginn des Projekts festgelegt wurden, wie z. B. die gewünschten Zykluszeiten, die Beständigkeit der Durchlaufzeiten und die Lieferquoten. Die Transparenz und die Möglichkeit, auf die Bedenken des Kunden einzugehen, die dieses Treffen bietet, sollten dazu beitragen, das Vertrauen des Kunden zu stärken.
Flow Review
Als Unterkategorie des Workflow-Meetings konzentriert sich die Flow Review auf die Fähigkeiten und Kapazitäten des internen Teams. Ziel ist es, den Prozessfluss zu verstehen und zu überwachen, sowie Probleme wie bevorstehende Engpässe und Möglichkeiten zu deren Beseitigung zu erkennen.
Risk Review / Blocker Clustering
Diese in der Regel zwei- bis vierwöchentlich stattfindende 1-2-stündige Besprechung dient der Untersuchung von Lieferengpässen und Blockaden. An der Sitzung sollten alle Teammitglieder und Interessengruppen teilnehmen, die mit den aktuellen und jüngsten Problemen vertraut sind. Die Aufmerksamkeit sollte auf „Blocker-Cluster“ auf Team- oder Abteilungsebene gelenkt werden.
Big Picture Kanban Meetings
Es gibt zwei weitere Meetings, die vom Kanban-System für das „Big Picture“ empfohlen werden und über den beiden Kadenzen stehen:
- Operations Review
- Strategy Review
Operations Review
Diese etwa zweistündige Sitzung, die in der Regel einmal im Monat stattfindet, ist eine Art Makroversion des Service Delivery Review und bringt die miteinander verbundenen internen Teams und Systeme zusammen. Sie kann sich auf eine Abteilung oder sogar ein ganzes kleines Unternehmen erstrecken. Der Grund dafür ist, dass effiziente Teams durch die Ineffizienz anderer Bereiche in einer Organisation, z. B. bei der Ressourcenplanung oder durch Abhängigkeiten von anderen Teams, behindert werden können.
Manager aus verschiedenen Bereichen, Abteilungen oder Systemen arbeiten zusammen, um Effizienzgewinne zu erzielen, die dem Ganzen zugute kommen, z. B. in Bereichen mit ungenutzten Kapazitäten im gesamten Unternehmen, die zur Verbesserung der Durchlaufzeiten genutzt werden können.
Strategy Review
Die in der Regel vierteljährlich stattfindende und bis zu einem halben Tag dauernde Strategiebesprechung ist das Kanban-Meeting auf höchstem Niveau. Sie dient dazu, die Strategie auf der Grundlage des Kundenfeedbacks und etwaiger Änderungen externer Faktoren wie Märkte und Verbraucher-/Nutzerverhalten anzupassen.
Der Kernpunkt der Strategieüberprüfung besteht darin, dass es kaum einen Unterschied macht, wie schnell und effizient sich ein Fahrzeug fortbewegt, wenn es die falsche Richtung einschlägt. Die Festlegung und Anpassung allgemeiner strategischer Ziele und Richtungen sollte in die Kanban-Roadmap aufgenommen werden und in die täglichen, wöchentlichen und monatlichen Ziele einfließen, die in den Besprechungen zur Lieferplanung bzw. zum Workflow-Replenishment behandelt werden.
Die Teilnehmer sollten aus einem größeren Kreis von Stakeholdern kommen und können die Geschäftsleitung, Produktverantwortliche, leitende Mitglieder des Entwicklungsteams und relevante Vertreter von Abteilungen mit Kundenkontakt wie Vertrieb und Marketing umfassen.
Vor- und Nachteile von Kanban
Wie jede Methode, Struktur oder System, das in der Softwareentwicklung eingesetzt wird, hat auch die Kanban-Methode ihre Vor- und Nachteile. Diese können kurz wie folgt zusammengefasst werden:
Kanban-Vorteile
Einfache Anwendung / niedriege Einstiegshürden: Eine der Hauptstärken von Kanban ist die Tatsache, dass die Einfachheit und die Verwendung von Visualisierungen dazu führen, dass auch Teammitglieder, die noch keine Erfahrung mit dem System haben, es sehr schnell erlernen können.
Flexibilität: Ein zentrales Merkmal von Kanban als agile Methodik ist die ihr inneliegende Flexibilität, die es den Teams ermöglicht, sich schnell auf Veränderungen einzustellen und Prozesse anzupassen, um eine kontinuierliche Verbesserung und Wertschöpfung zu erzielen.
Kollaboration: Kanban ist in hohem Maße kollaborativ und fördert Teamarbeit und kollektive Verantwortung für die Gesamteffizienz und die Wertschöpfung.
Etablierung eines Proyesses: Die Ausrichtung von Kanban auf kontinuierliche Lieferung fördert die Produktivität, insbesondere bei längeren Projektzyklen.
Kanban Nachteile
Möglicher Fokussverlust: Da Kanban keine strengen Verantwortlichkeiten vorschreibt, können sich Teams und Einzelpersonen leicht ablenken lassen.
Komplexität des Kanban-Board: Es mag wie ein Widerspruch zu Kanbans angeführter Stärke der Einfachheit klingen, aber auf der Ebene des Kanban-Boards können die Dinge schnell sehr komplex werden und die Teammitglieder durcheinander bringen, wenn nicht sorgfältig vorgegangen wird.
Fehlende Zeitvorgaben: Einige Kunden und Projektmanager sind durch das Fehlen strenger Zeitvorgaben bei Kanban abgeschreckt. Dies steht im Gegensatz zu anderen agilen Ansätzen wie beispielsweise Scrum.
Spannungen mit der iterativen Softwareentwicklung: Die iterative Entwicklung ist ein Grundpfeiler der meisten agilen Softwareentwicklungssysteme, ist aber auf Ticket-Ebene nicht Bestandteil von Kanban. Dies ist einer der Hauptgründe, warum Elemente von Kanban oft mit anderen Ansätzen wie Scrum kombiniert werden.
Fazit
Wir hoffen, dass dieser Blog Ihnen einen guten Überblick über die Kanban-Methode gegeben hat. Sie sollten nun verstehen, warum Kanban – entweder als eigenständiges System oder durch die Kombination einzelner Elemente wie dem Kanban-Board mit anderen Vorgehensweisen – ein so beliebter Teil des Projektmanagement-Ökosystems in der Softwareentwicklung ist.