Nicht die stärkste oder intelligenteste der Spezies überlebt, sondern diejenige, die Veränderungen gegenüber am anpassungsfähigsten ist.
Charles Darwin
Darwinistisch betrachtet gilt diese Aussage nicht nur für Spezies aus der Natur, sondern auch für Methoden und/oder Technologien oder?
Kanban ist eine agile Methode, die immer häufiger in Softwareentwicklungsabteilungen anzutreffen ist. Umsteiger sind nicht nur von traditionellen Wasserfall-Modellen zu beobachten, sondern auch von IT-Abteilungen die zuvor das in der agilen Welt verbreitete Scrum einsetzen. Wobei schon fast der Eindruck entstehen könnte, Kanban ist der Nachfolger von Scrum. Weit gefehlt!
Woran liegt es nun, dass die Kanban-Methode sich immer weiterer Beliebtheit erfreut?
Der große Unterschied zu anderen Modellen / Methoden ist, dass es sehr wenig Vorgaben bzw. Regeln oder Vorschriften bei Kanban gibt. Kanban kommt mit einigen wenigen sogenannten Prinzipien aus.
Die zentralen Prinzipien sind:
- Visualisiere den Workflow
- Limitiere den Work in Progress
- Pull statt Push
- Kontinuierliche Verbesserung (Kaizen)
1. Visualisiere den Workflow
Dieses Prinzip ist sehr leicht umsetzbar. Zuerst wird auf hoher Flugebene definiert, welche Stationen im Entwicklungsprozess anzutreffen sind. In der Regel wird man immer so etwas wie eine Spezifikation, Entwicklung, eine Testphase und eine Produktivsetzung wiederfinden.
Im Anschluss wird jede Anforderung (im folgenden Tickets genannt), die diesen Prozess durchläuft, einer der oben festgelegten Phasen zugeordnet. Das ganze wird an einem sogenannten Kanban-Board realisiert, was z.B. eine einfache Pinwand sein kann (siehe Abbildung).
Diese Tickets werden in kurzen Besprechungen am Kanban-Board meist auf täglicher Basis entsprechend des Fortschritts in die nächste Phase geschoben.
Ziel dieses Prinzips ist es, Engpässe im Workflow aufzudecken und auf dieser Basis Lösungen für die Engpässe zu erarbeiten.
Interessanter Nebeneffekt ist, dass sich die Teammitglieder plötzlich intensiver über das, was noch zu tun ist, austauschen. Weiterhin entstehen Vereinbarungen zwischen den Teammitgliedern, wann ein Ticket tatsächlich eine Phase abgeschlossen hat (in anderen Modellen werden diese Vereinbarungen auch Richtlinien genannt).
2. Limitiere Work in Progress (WIP-Limit)
Für jede Phase wird ein Wert bestimmt, der die maximal zulässige Ticketanzahl für diese Phase bestimmt. Es kann also kein neues Ticket einer Phase hinzugefügt werden, bei der das definierte Limit dieser Phase erreicht ist.
Damit wird das Ziel verfolgt, weniger Multitasking durch die Mitarbeiter stattfinden zu lassen. Der durch ständige Wechsel zwischen verschiedenen Tickets erzeugte Mehraufwand wird auch als „Waste“ bezeichnet und durch WIP-Limits vermieden.
Positive Nebeneffekte sind höhere Qualität, Wissensverteilung und erhöhte Zusammenarbeit im Team.
3. Pull statt Push
Pull bedeutet, dass die Arbeit vom vorhergehenden Prozessschritt nicht zugeschoben wird, sondern aktiv „gezogen“ wird. Ein neues Ticket wird allerdings nur dann gezogen, wenn das Ticket im vorhergehenden Prozessschritt fertiggestellt wurde und im jeweiligen Prozessschritt Kapazitäten vorhanden sind.
Ziel: Schutz vor Überlastung
Nebeneffekt: Förderung der Selbstorganisation und Mitabeitermotivation.
Eine sehr schöne Visualisierung des Pull-Prinzip in Verbindung mit WIP-Limits, ist auf der Seite von Hendrik Kniberg zu sehen.
4. Kontinuierliche Verbesserung (Kaizen)
Es spielt keine Rolle für welche Prozessschritte man sich zu Beginn entschieden hat oder wie die WIP-Limits definiert wurden. Entscheidend sind die ständigen Überprüfungen und Verbesserungsmaßnahmen (Kai=Veränderung; Zen=zum Besseren). Dies wird in der Regel in kleinen Schritten vollzogen.
Das Ziel der kontinuierlichen Verbesserung wird durch regelmäßig durchgeführte Retrospektiven und durch z.B. Messen der Durchlaufzeit (Leadtime) der Tickets unterstützt.
Insbesondere der letze Punkt macht ein Kanban-System aus. Die fortlaufenden Verbesserungsmaßnahmen machen das System so adaptiv und auch so erfolgreich. Die Maßnahmen werden mit dem Team entwickelt und werden nicht wie in vielen anderen Modellen, den Mitarbeitern auferlegt.
Nicht nur die vielen kleinen Erfolgserlebnisse geben dem System recht, sondern auch die kleinen Schritte ermöglichen Änderungen bei denen die Widerstände nicht so stark ausfallen, wie in stark reglementierten Vorgehensmodellen.
Der Punkt ist doch, dass bei den meisten anderen Vorgehensmodellen wie dem Wasserfall, RUP, V-Modell XT oder auch CMMI oder ITIL sehr viel investiert wird, um die Prozesse und Richtlinien für das Unternehmen zu definieren. Die Einführung dauert nicht selten mehrere Monate und wird dann nicht mal durchgängig verstanden und gelebt. Neue Rollen und Verantwortlichkeiten werden geschaffen und führen zu vielen Missverständnissen und wenig Teamarbeit.
Scrum aber insbesondere Kanban besitzen hingegen deutlich weniger Regeln und diese Methoden sind einfacher zu verstehen.
Heißt das jetzt das die meisten Prozesse und Regeln die im V-Modell XP, RUP, usw. vorgegeben werden überflüssig sind? Natürlich nicht, ihre Entstehung und ihre weniger gute Adaptivität bzw. Flexibilität erschweren jedoch den nachhaltigen Erfolg.
Von innen entwickelte Prozesse und Regeln werden besser institutionalisiert und erzeugen bei den Mitarbeitern eher die Bereitschaft Anpassungen vorzunehmen, um Verbesserungen herbei zu führen. Eine Kaizen-Kultur im Team oder sogar im Unternehmen zu etablieren, ist sicherlich die schwierigste Aufgabe. Kanban bietet mit dem Ansatz der oben geschilderten Prinzipien sehr gute Werkzeuge, um genau diese Kultur zu schaffen.
Mein Fazit: Die agilen Methoden sind gegenüber traditionellen Methoden noch sehr jung und müssen sich über langfristige Zeiträume in Unternehmen noch beweisen. Dennoch zeigt sich nach 10 Jahren agilen Manifest und inzwischen 6 Jahren Kanban in der Softwareentwicklung ein klarer Trend ab. Der Großteil der Unternehmen die von herkömmlichen Methoden auf adaptive / agile Methoden in der Softwareentwicklung gewechselt haben, konnten signifikante Projekterfolge verbuchen und ich bin mir sicher, diese Methoden werden sich auch zukünftig durchsetzen – um es darwinistisch auszudrücken – nur diese Methoden werden überleben.
War dieser Beitrag hilfreich?
Weitere Beiträge
von
31.3.2021 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.