Welcher Typ von „agile“ bist Du?
Verstehe die Schlüsselargumente, um zwischen Kanban und Scrum zu unterscheiden und finde eine Grundlage, wie du dich für eine Methode entscheiden kannst.
Zusammenfassend kann man sagen, dass es sich um zwei unterschiedliche Strategien dreht, ein agiles System umzusetzen. Ein agiles System kann sein, Entwicklung von Software, ein Projekt, aber auch Fertigung. Klar abgrenzbar in der Organisation dadurch, dass es einen Anfang und ein Ende gibt und es sich vor allem um eine individualisierte Leistung handelt. Kanban ist eine dauerhafte, fliessende, Methode und Scrum wiederum ist ein kurzfristig, in Sprints, strukturiertes Vorgehensmodell.
Beide Modelle orientieren sich an den Prinzipien und Leitlinien des agilen Manifests – beide sind also agile Methoden. Agile beschreibt die Möglichkeit Prozesse der Software Entwicklung und des Betriebs von (z.B.:) Software zu automatisieren und zu integrieren. Beide Methoden – Kanban & Scrum – bieten die Möglichkeit der agilen Umsetzung, also sind beides agile Methoden. Beide unterscheiden sich aber in ihrem im Umgang mit der Auflösung von Komplexität in der Anforderung und Umsetzung.
Grundsätzlich ist es einfach die Unterschiede zwischen Kanban und Scrum als Vorgehensweisen darzustellen, aber das ist eine nicht zielführende Betrachtungsweise. Auch wenn die Vorgehensweisen sich unterscheiden, die Grundlagen sind fast ident. Beide Handlungsvorlagen unterstützen die Umsetzung von besseren Produkten und Leistungen mit weniger Problemen, aka Kopfweh.
Agile ist ein strukturierter und integrativer Ansatz im Projekt Management und in der Produkt Entwicklung. Agile beachtet die Verletzlichkeit – Einflüsse und Rahmenbedingungen – bei der Produkt Entwicklung und bietet eine Methode für sich selbst organisierende Teams auf Änderungen zu antworten und zu reagieren, möglichst ohne die endgültige Umsetzung zu gefährden. Heutzutage ist der agile Ansatz und die Verwendung agiler Methoden, kein Wettbewerbsvorteil mehr. Kaum jemand mehr leistet sich den Luxus und entwickelt über Jahre, oder auch nur Monate, ein Produkt in einer reinen Laborumgebung. Das heisst, es ist vor allem wichtig, dass die erste Version auch wirklich die wichtigsten Erwartungen und Versprechungen erfüllt.
Kanban ist eine Methode, um vor allem die Tätigkeiten zu visualisieren, darzustellen. Es werden konkret die Anzahl der in Bearbeitung befindlichen Objekte, Artefakte und Arbeitsabschnitte definiert, um damit die Effizienz, oder den Durchsatz, zu steigern. Kanban Teams orientieren sich daran die Durchlaufzeit zu minimieren. Verwendet wird dazu eine Kanban Tafel und diese wird laufend optimiert, um einen unterbrechungsfreien Arbeitsfluss und stetigen Arbeitsfluss zu gewährleisten.
Scrum Teams verplichten sich funktionierende Software in festgelegten Intervallen – Sprints – auszuliefern. Das Ziel bei Scrum vor allem ist es aus Rückmeldungen zu lernen und die (nächste) Umsetzung zu optimieren. Scrum Teams haben bestimmte, definierte, Rollen, erstellen bestimmte, spezielle, Artefakte, und halten regelmäßig Veranstaltungen, definierte Zeremonien, ab, um in einer stetigen Vorwärtsbewegung zu bleiben. Eine Definition von Scrum findet sich im „The Scrum Guide“
| Kanban | Scrum | |
| Regelmäßigkeit/ wiederkehrende Veranstaltungen | Dauerhafter Fluss – Veranstaltungen sind rein anlassbezogen | Sprints – Besprechungen mit einer vorgegebenen Dauer und vorgegebenen Intervall (zB.: alle zwei Wochen) |
| Release Methode | Kontinuierliche Auslieferung | Nur jeweils am Ende eines Sprints |
| Rollen | Keine | Product Owner, Scrum Master, Development Team |
| Schlüssel-/ Messparameter | Entwicklungszeit, Durchlaufzeit, WIP (work in progess) | Geschwindigkeit |
| Veränderungsgedanke | Änderung kann immer auftreten | Teams dürfen während eines Sprints keine Änderungen vornehmen |
Scrum – ein strukturierter agiler Ansatz
Mit der Scrum Methode verpflichtet sich das Team eine (Wert-)Steigerung, Verbesserung, der bestehenden Arbeit bis zum Ende eines Sprints umzusetzen. Scrum basiert auf der Erfahrung der Team Mitglieder und konzentriert sich auf kleinteilige Verbesserung des Werk(-stücks), um auch vor allem den Kunden besser, detaillierter, über den aktuellen Status zu informieren.
Scrum Regelmäßigkeit
Scrum (Projekte) gehen schnell von statten – Sprints von zwei bis vier Wochen sind die Regel und geben ein definiertes Start- und Enddatum vor. Der kurze Zeitrahmen erzwingt, dass komplexe Anforderungen in weniger komplexe Teilanforderungen heruntergebrochen werden müssen. Die Grundbedingung für eine Teilanforderung ist, dass diese in der vorab definierten Sprintperiode umgesetzt werden kann. Diese Vorgehensweise wird durch Erfahrung im Team unterstützt und als Konsequenz institutionalisiert, verankert, diese Methode das Lernen in der Gruppe. Die Schlüsselfrage für den Entwurf und die Gliederung in Teilanforderungen ist, kann das Team brauchbaren Code in dieser Geschwindigkeit liefern?
Um Sprints zu organisieren, zu steuern und auch Wissen daraus abzuleiten – institutionalisiertes Lernen – gibt es regelmäßige Veranstaltungen, aka Zeremonien. Ein Sprint wird eingeleitet von einem Sprint Planning, nach seiner Beendigung folgen ein Sprint Review und eine Retrospektive. Während eines Sprints gibt es Sprint Standup Besprechungen. Alle Scrum Zeremonien sollten regelmäßig stattfinden und nicht zum reinen Selbstzweck stattfinden, sondern Sprint orientiert abgehalten werden.
Release Methode
Eigentlich ist nur mit Ende eines Sprints eine Veröffentlichung, Release, nach der Scrum Methode möglich. Es hat sich aber auch eine ad-hoc Veröffentlichungen eingebürgert. Generell vereinbart und definiert das Team im Rahmen eines Sprints die Ziele – Sprint Goals. Bestätigung über die Erreichung und Erfüllung der Ziele – qualitative und quantitative Attribute – werden in dem dafür vorgesehen Sprint Review Meeting festgestellt, oder auch nicht. Mit einer Bestätigung der Erfüllung der Ziele im Sprint Review Meeting kann eine Veröffentlichung erfolgen.
Scrum Rollen
- Product Owner
Dieser vertritt den Kunden und seine Anforderungen gegenüber der Entwicklung. Er verwaltet den Backlog – Arbeitspakete abgeleitet aus den Teilanforderungen – und arbeitet maßgeblich an der Priorisierung der Inhalte und Arbeitspakte mit dem Entwicklungsteam zusammen. - Scrum Master
Koordination aller Aktionen, um dem Team ein Arbeiten nach den Scrum Prinzipien zu ermöglichen. - Entwickler Team
Entscheiden mit dem Produkt Owner, was und in welcher Reihenfolge umgesetzt wird. Liefern definierte Artefakte und zeigen gemeinsame Zuständigkeit.
Eine Frage stellt sich nun doch, wer leitet so ein Scrum Team? – Niemand ist die verblüffende Antwort. Scrum Teams sind selbst organisiert und jeder ist gleich, auch wenn es verschiedene Verantwortlichkeiten gibt. Das Team hat ein gemeinsames Ziel, das es zu erfüllen gilt – die Kundenzufriedenheit und -nutzen zu steigern.
Schlüsselparameter
Geschwindigkeit wird in der Scrum Methode dargestellt, als die Anzahl der Story Points in einem Sprint. Das ist der zentrale Wert für den Scrum Teams leben und an denen sie gemessen werden können. Diese Punktezahl (vgl.: Story Points/ Sprint), die in vergangenen Sprints erreicht wurden, sind Grundlage für die Übernahme neuer Backlogs (vgl.: Arbeitspakte aus Teilanforderungen). Das Team muss sich die Anzahl der umzusetzenden Story Points auch zutrauen, sonst sollte es nicht zusagen.
Veränderungsgedanke
Teams sollten sich bemühen nicht den Fokus während eines Sprints zu verlieren, oder zu ändern. Auch Scrum Teams bekommen Rückmeldung und können dabei erfahren, dass das Artefakt, an dem sie arbeiten, nicht die Relevanz für den Kunden besitzt, wie sie sich das vorgestellt haben. In so einem Fall sollte eine neuerliche Priorisierung stattfinden, um vor allem die für den Kunden Wert darstellenden Artefakte dann zu liefern. Im Rahmen von Scrum/ Sprint Retrospektiven (vgl.: regelmäßige Veranstaltung) sollten Scrum Teams einen Modus finden, wie solche Änderungen in Zukunft zumindest beschränkt, wenn nicht sogar unterbunden werden können. Damit das Risiko, nicht zur definierten Zeit liefern zu können, verringert wird.
Kanban – dauerhafte Verbesserung und flexible Prozesse
Kanban steht dafür die Arbeit zu visualisieren, die Nebenläufigkeiten von den selben Tätigkeiten einzuschränken und vor allem Aufgaben zuerst zu beenden bevor eine neue begonnen wird.
Kanban ist zum Beispiel für Teams, die mit einer großen Anzahl an einkommenden Anforderungen leben müssen, die sich in Priorität und Aufwand unterscheiden. Kanban erlaubt eine konstante Information und Übersicht über den aktuellen Zustand aller Objekte.
Regelmäßigkeit
Kanban basiert auf einer Struktur des dauerhaften Arbeitsflusses. Das bedingt, dass Teams flink auf Änderungen reagieren können und müssen. Ein Kanban Team muss aber vor allem auch zur Veränderungen bereit sein. Deswegen ist der Team orientierte Ansatz vielleicht irreführend bezügliche der Einführung. Sinn gibt ein Top Down Ansatz, bei dem das Management selbst das erste Team ist, dass nach der Kanban Methode anfängt sich zur organisieren und strukturiert arbeitet. Arbeitspakete (vgl.: Cards) werden auch auf einer Kanban Tafel organisiert. Der Arbeitsfluss wird durch den Spaltenwechsel von links nach rechts dargestellt. Jede Spalte ist eine Stufen, ein Verarbeitungsschritt, weiter – es ist eher ein Wasserfall, als Stufen, da in der Regel der Vorgang von links oben nach rechts unten läuft. Um die Übersicht zu bewahren startet man meinstens mit den Stufen, Planung, Bearbeitung, Abnahme, Blockiert und Erledigt. Diese Stufen lassen sich über jedes bestehende Vorgehensmodell und Projektmanagement darüberlegen. Das ist eine der Stärken von Kanban – eine Einführung ist keine einmalige Änderung, sondern die Änderung passiert laufend im Betrieb.
Die Stufen können je nach Aufgabe und Team angepasst werden.
Release Methode
Bei Kanban werden Updates zum Zeitpunkt der Fertigstellung veröffentlicht. Die reguläre Durchlaufzeit ist bekannt, kann aber abweichen und mittels Priorisierung gesteuert werden. Im Gegensatz zu Scrum muss ein Kanban Team nicht warten, wenn es ein Arbeitspaket fertigstellt ist, bis der im Sprint Review festgelegte Meilenstein als erreicht bezeichnet wird.
Kanban Rollen
Kanban sieht keine vordefinierten Rollen vor. Das Team ist eigenverantwortlich die Kanban Tafel zu organisieren und aktuell zu halten. In Kanban gibt es in der Form keine Schlüsselrollen, weil sich an der Tätigkeit an sich nichts ändert. Der Grad der Autonomie wird durch Kanban gefördert – Delegation von Verantwortung und Entscheidung.
Schlüsselparamter
Die Entwicklungszeit und die Durchlaufzeit sind in Kanban die wichtigen Messgrößen. Ziel ist es die reguläre durchschnittliche Durchlaufzeit – vom Start bis zum Ende gemessen – zu senken. Die Durchlaufzeit zu senken ist das Ergebnis eines erfolgreichen Kanban getriebenen Teams.
Ein weiterer Parameter ist die Anzahl der „Work Items“ pro Status. Dargestellt werden diese Work Items Status übergreifend in einem sogenannten kumulativen Fluss Diagramm (vgl.: CFD – cummulative flow diagram). Solche CFDs helfen Flaschenhälse, Ressourcenengpässe, bei der Abarbeitung, zu erkennen.
Um Ressourcen und Abläufe zu steuern und Stauungen, Flaschenhälse, zu vermeiden, werden sogenannte WIPs verwendet. WIP (vgl.: work in progress) – weiter oben habe ich das Nebenläufigkeiten der selben Tätigkeit im selben Statusabschnitt genannt. Damit wird explizit die Ressourcenauslastung beschränkt. Ein WIP kann aber genauso zur Bildung von Zwischen- und Pufferlagern verwendet werden, wenn eine unterschiedliche Arbeitstaktung anliegt. (Anm.: die Taktung sollte dann in weiterer Folge aber auch synchronisiert werden). WIPs können auch zur Ressourcenauslastung und -verteilung verwendet werden.
Veränderungsgedanke
Ein Änderung des Arbeitsablaufs (vgl.: Workflow) kann mit der Kanban Methode immer auftreten und umgesetzt werden. Arbeitsaufträge können laufend im Status umgesetzt und neu priorisiert werden. Über die Veränderung, Anpassung, von WIP Grenzen in einzelnen Ablaufschritten kann auf veränderte Teamkapazitäten schnell reagiert werden. Kanban hat eine hohe Flexibilität zum Inhalt. Kanban kann nicht nur auf Team- und Gruppenebene eingesetzt werden. Kanban lässt sich über Aggregation und Abstraktion an so ziemliche jede Unternehmensstruktur und -größe anpassen.