Agiles Projektmanagement, Scrum vs. Kanban der ultimative Vergleich

Wie unterscheidet sich agiles Projektmanagement von traditionellen Methoden (z.B. Wasserfall)

Grundsätzlich basiert auch das Agile Projektmanagement auf dem Prozess aus Anforderungen sammeln, analysieren und strukturieren, Entwicklung, Testing, Veröffentlichung und Wartung. Der große Unterschied zu nicht agilen Methoden liegt insgesamt darin, dass die einzelnen Pakete für diesen Ablauf in agilen Prozessen wesentlich kleiner sind und nicht direkt das gesamte Projekt in einem Lauf abgeschlossen wird. Zusätzliche unterscheidet sich agiles Projektmanagement auch noch in der Umsetzung der Entwicklung sowohl von den nicht agilen Methoden als auch untereinander voneinander.

Das Agile Manifesto

Zusammengefasst wurden die Grundsätze dafür im agilen Manifest im Jahr 2001. Dabei werden drei zentrale Aussagen in den Mittelpunkt gestellt. An erster Stelle steht bei der agilen Entwicklung die Personen und nicht die Prozesse oder Mittel. Des Weiteren ist funktionierende Software wesentlich wichtiger ist als gut dokumentierte Software. Zusätzlich ist es wichtiger Software zu entwickeln, die dem Kunden von Nutzen ist als nur strikt den Vertrag mit dem Kunden zu erfüllen. Daher abgeleitet ist auch die letzte Anforderung festgehalten worden. Es ist wichtiger auf Änderungen zu reagieren, als schlicht und ergreifend den Plan zu befolgen. Zusätzlich dazu gehören auch die 12 Grundsätze der agilen Softwareentwicklung.

Agiles Projektmanagement – Was ist Scrum?

Die wohl am weit verbreitete Methode der agilen Softwareentwicklung ist Scrum. Die drei Säulen der Scrum Methode sind Transparenz, Überprüfung und Anpassung. Es muss jedem beteiligten jeder Zeit möglich sein die benötigten Informationen wie z.B. den Status einzelner Tickets abrufen zu können. Des Weiteren müssen die Anforderungen und Umsetzung immer wieder überprüft werden. Folgend wird die hohe Flexibilität benötigt, da Anforderungen oder Umsetzungen nach der Überprüfung auch immer wieder angepasst werden können. Insgesamt ist es vor allem wichtig, dass alle Stakeholder die identische Definition von dem Begriff „done“ besitzen, damit keine Fehlkommunikation und Asynchronitäten in der Abstimmung entstehen.

Team Management im Scrum Prozess

Bei dieser Methode werden die Teams ganz nach dem agilen Prinzip in 3 Gruppen unterteilt – Entwicklung, Product Owner, Scrum Master. In den Software Entwicklungsteam sollten im besten Fall 3-9 Personen sein, welche alle gleichgestellt sind und keiner der Gruppe die Führung übernimmt. Dieses Team ist gemeinsam für die Architektur, Entwicklung und gleichzeitig auch das Testing verantwortlich. Der Product Owner be- steht aus einer Person und ist für das gesamte Produkt verantwortlich. Während des Sprints ist seine Aufgabe außerdem in enger Abstimmung mit dem Entwicklungsteam Probleme zu identifizieren und für die Suche nach einer möglichen Lösung zu kommunizieren. Folgend gibt es noch den Scrum Master, welcher sowohl als Scrum Coach, als auch als Kommunikator nach außen dient. Er ist im Unternehmen mit anderen Scrum Mastern vernetzt und kann Probleme bis hin zum Management eskalieren.

Planung im Scrum Prozess

Die Arbeitspakete werden bei der Scrum Methode in Form von Sprints agil definiert. Am Anfang jedes Sprints legt der Product Owner fest, welche Ziele der Sprint erreichen soll und was in dem Sprint geschafft werden soll. Diese Definition nimmt er vor, indem er die wichtigsten Tickets aus dem Backlog priorisiert und für den Sprint vorschlägt. Folgend ermittelt das Entwicklungsteam die Aufwände der Aufgaben und erstellt einen Plan zur Umsetzung dieser Aufgaben. Das Team fungiert dabei vollkommen autonom und wird nicht von äußeren Faktoren beeinflusst. Ein Sprint ist immer auf einen festen Zeitraum beschränkt und das Entwicklungsteam ist auch dafür verantwortlich nur so viele Tickets in den Sprint mit aufzunehmen, welche auch bis zum Enddatum des Sprints erledigt werden können, um ein funktionsfähiges Produkt auszuliefern. Sie geben also zum Start des Sprints ihr Wort darauf, dass sie am Ende das initial vom Produkt Management definierte Ziel in Form von Aufgaben im Sprint erreichen.

Aufgaben des Product Owners im Scrum Prozess

Das Backlog, aus dem die Tickets kommen wird vom Product Owner gepflegt und enthält nicht nur neue Anforderungen, sondern auch Bugs und Verbesserungsvorschläge. Nur der Product Owner ist für das Backlog verantwortlich und er kann in Vorbereitung für den Sprint zur Schätzung von Aufgaben das Entwicklungsteam um Rat fragen. Damit eine Aufgabe in einen Sprint gehen kann, muss sie zwingend eine Schätzung haben. Der Sprint ist eine zeitlich und Ressourcen limitierte Umgebung, für welche man zur Einhaltung des Ziels möglichst genau planen muss, damit kein zu hoher Workload erzeugt wird und somit das Ziel nicht erreicht werden kann. Während des laufenden Sprints ist der Product Owner für das einheitliche Verständnis der Tickets und die Vorbereitung des nächsten verantwortlich. Er unterstützt das Team auch bei Problemen und kann diese in Richtung Scrum Master kommunizieren.

Aufgaben des Product Owners im Scrum Prozess

Der Scrum Master ist während des Sprints in einer Coaching Funktion eingebunden. Zu seinen wichtigsten Aufgaben gehört auf der einen Seite, die kontinuierliche Schulung des Teams zur optimalen Umsetzung von Scrum, als auch die Kommunikation und Abstimmung im Unternehmen. Somit hat der Scrum Master eine Managementfunktion und ist auch für die Kommunikation von Problemen außerhalb des Teams mit dem Management oder anderen Teams im Unternehmen zuständig.

Aufgaben des Entwicklungsteams im Scrum Prozess

Hingegen konzentriert sich das Entwicklungsteam ohne Blick auf die Umwelt rein auf den Sprint und die Ablieferung einer getesteten, funktionierenden Version der Software am Ende des Sprints. Diese Ablieferung am Ende des Sprints wird auch Sprint Review genannt und ist ein zusammenkommen aller Stakeholder des Sprints, um gemeinsam das Ergebnis zu betrachten, um Probleme im Sprint zu analysieren und zu erarbeiten wie man solchen Schwierigkeiten zukünftig aus dem Weg gehen kann. Während des Sprints gibt es ein tägliches Treffen aller Stakeholder zur Abstimmung. In diesem Treffen informieren die Entwickler über ihre aktuellen Aufgaben und deren Fortschritt. Zusätzlich können in diesem Treffen auch Probleme oder Schwierigkeiten bei Aufgaben im Team angebracht werden und andere Team Mitglieder um Rat gefragt werden. Dieses Treffen sollte nur ein paar Minuten dauern und eine Möglichst kompakte Zusammenfassung bieten.

Agiles Projektmanagement – Was ist Kanban?

Eine weitere ähnliche Methode der Software Entwicklung ist Kanban. Diese Methode wurde nach dem Lean Prinzip erstmals in den 50er Jahren am Fließband von Toyota entwickelt und angewendet. Zielsetzung der damals von Toyota entwickelten Methode war es einen möglichst effizienten und rund laufenden Workflow für die Produktion von Autos herzustellen. Bei der Entwicklung wurde besonders darauf geachtet, dass möglichst alle Prozesse höchst optimiert waren und mögliche Verschwendungen identifiziert und beseitigt wurden. Dabei war einer der zentralen Ziele, dass die Produktionsrate mit der Abnahme Rate der Autos übereinstimmt und nur so viel Material wie aktuell benötigt gelagert wurde. Damit diese Rechnung aufging, war es besonders wichtig, dass am Ende der Produktionsstraße fertige Autos vom Band rollen. Da ein produziertes Auto nach der Produktion nicht direkt für den Kunden verfügbar ist, sondern gelagert, transportiert und ausgeliefert werden muss. Ziel war es somit nicht in möglichst kurzer Zeit möglichst viele Autos zu produzieren, sondern viel eher die Geschwindigkeit des gesamten Prozesses synchron zu halten und somit den kompletten Prozess möglichst effizient zu gestalten.

Planung im Kanban Prozess – das Kanban Board

Das Wort Kanban ist aufgrund seiner Entwicklung in Japan auch ein japanisches Wort, welches eine große Relevanz für agiles Projektmanagement hat. Übersetzt bedeutet dieses Wort Schild oder Karte. Da Kanban auf nach den Lean Prinzipen funktioniert. In einem Lean Prozess werden Karten genutzt, um visuell darzustellen, dass ein System in der Lage ist den Prozess für ein Objekt zu starten. Alle Karten werden beim Kanban in einem Board abgebildet, welches mehrere Spalten besitzt. Dieses Board kann sowohl ein Whiteboard im Raum sein, als auch ein online System mit digitalen Karten. Auch hier gibt es eine Spalte Backlog, für Karten, die bisher nicht eingeplant wurde und auf eine Schätzung und Umsetzung warten. Neben der Spalte Backlog bestehen meist noch 4-5 weitere Spalten, welche relativ flexibel festgelegt werden können, wobei eine typische Aufstellung von Spalten Backlog, Estimation, Planning, Design, Develop, Approved, Closed sein kann. Jede Karte hat eine User Story und beschreibt somit eine Verbesserung oder Funktionsanfrage. Außerdem kann jede Karte immer nur in einer Spalte des Kanban Boards stehen. Die Karten wandern nun in dem Prozess von dem Backlog (in Europa meist die Spalte ganz links) über die einzelnen Spalten der Planung und Entwicklung bis hin zur Live Stellung und Abnahme (in Europa meist die Spalte ganz rechts). Jedes Team Mitglied ist dabei in der Lage die einzelnen Karten durch diesen Prozess zu schieben.

Optimierung im Kanban Prozess

Genau deshalb ist einer der Wichtigsten Regulierungen im Kanban, die Anzahl der Karten, welche sich in Progress befinden zu limitieren, da ansonsten endlos viele Karten in Bearbeitung genommen werden können. Sollte eine Limitierung nicht stattfinden, können sich die Bearbeiter nicht auf einzelne Karten fokussieren und würden bei dem ständigen Springen zwischen mehreren Karten einen enormen Produktivitätsverlust erleiden. Allerdings muss man auch bei der Limitierung der Karten in Progress ein gesundes Mittelmaß finden. Einer der wichtigsten Parameter ist die Anzahl der Mitglieder im Team. Bei der Ermittlung eines passenden Wertes sollte man an dem langsamsten/zeitintensivsten Schritt im Prozess das Limit der Karten auf die mindestens die Anzahl der Teammitglieder, plus einen geringen Puffer, setzen. Auf Basis dieser Limitierung kann man nun die maximale Anzahl an Karten für die anderen Schritte linear zum Zeitaufwand dieser setzen. Sollten man also theoretisch versuchen immer nur eine Karte in Progress zu lassen, um nahezu keinen Wechsel zwischen den Aufgaben zu haben, kann es zu einem Stau kommen, sobald ein Prozess länger dauert als ein anderer. Somit ist es bei Setzen der Limits ebenso wichtig zu beachten, dass keine Staus entstehen. Ebenso kann es passieren, dass ein Limit notgedrungen überschritten werden muss. In diesem Fall ist es besonders wichtig, diese Überschreitung des Limits aggressiv zu kommunizieren und den Zeitraum der Überschreitung so gering wie mögliche zu halten.

Littles Law im Controlling der Softwareentwicklung

Somit ist ein zentraler Wert des Controllings Littles Law, welche von einem stabilen System ausgeht. Mit diesem Gesetz kann man die Durchlaufzeit/Verweildauer von Objekten in einem Wartesystem berechnen. Dabei gilt auf die Software Entwicklung bezogen Durchlaufzeit = Arbeiten in Progress / Durchsatz.15 Als Arbeiten in Progress werden bei Kanban Tickets gesehen, welche aktuell von Entwicklern bearbeitet werden, als Durchsatz jene Tickets, welche in einer festgelegten Zeiteinheit z.B. pro Tag das System verlassen. Anhand dieser einfachen mathematischen Formel kann man sehr deutlich sehen, dass man die Durchlaufzeit von Tickets entweder optimieren kann, indem man weniger Aufgaben gleichzeitig bearbeitet oder den Durchsatz der Tickets erhöht. Diese Formel kann man auch folgendermaßen umstellen, um den Durchsatz aus dem System zu erhalten Durchsatz = Arbeiten in Progress / Durchlaufzeit. Hierbei wird deutlich, dass wieder entweder die Arbeiten in Progress oder die Durchlaufzeit verringert werden können, um den Durchsatz zu optimieren.16 Logischerweise macht es keinen Sinn sowohl die Arbeiten in Progress, als auch den Durchsatz zu verringern, da in einem stabilen System die Durchlaufzeit linear abhängig von den Arbeiten in Progress ist. Die Herausforderung besteht somit darin die Arbeiten in Progress zu erhöhen, bei konstanter Durchlaufzeit oder die Durchlaufzeit zu verringern und dabei gleichzeitig die Arbeiten in Progress konstant zu halten.

In der Praxis der Software Entwicklung ist der am besten zu optimierende Wert die Durchlaufzeit. Die Durchlaufzeit enthält den gesamten Weg einer Aufgabe von der Sammlung der Anforderung über die Konzipierung und Umsetzung bis hin zur Umsetzung und Auslieferung von Aufgaben an den Kunden. In diesem langen Prozess einer Aufgabe finden sich die besten Stellen zur Optimierung der Durchlaufzeit und somit auch des Durchsatzes.

Vergleich der Kanban und Scrum Methoden.

Sowohl Scrum als auch Kanban funktionieren nach agilen Prinzipien. Dabei ist Scrum ein sehr detailliertes Framework, hingegen Kanban viel mehr ein Prozess Management Tool ist und deutlich mehr Interpretationsspielraum bietet.Kanban bietet im Vergleich zu Scrum keine fest definierten Zeiträume, in denen Tickets geplant und abgeschlossen werden sollten. Dadurch ist es für die Entwickler deutlich freundlicher aufgestellt, bietet aber für Projektmanager einer schlechteren Möglichkeit der Planung, wann Projekte und Aufgaben abgeschlossen werden. Zusätzlich gibt es bei Kanban keine festen Rollen und die Aufgabenverteilung ist wesentlich dynamischer auf- gestellt, wodurch auch der Arbeitsaufwand nur für das gesamte Team geschätzt werden kann und nicht für jede einzelne Person im Sprint geplant werden kann.

Zusammengefasst kann man das Beste aus beiden Methoden erreichen, wenn man die beiden Methoden miteinander kombiniert, indem man die Vorteile aus beiden agilen Methoden vereint. Somit kann man beispielsweise die Planungsmöglichkeiten aus dem Scrum Framework nutzen und Aufgaben in Sprints zusammenfassen und Planen während man in der Umsetzung auf Basis eines Kanban Boards die einzelnen Schritte sauber Visualisierung und auch limitiert. Durch diese Kombination erreicht man ein Maximum an Planungsmöglichkeiten und zusätzlich eine sich stetig optimierenden Prozess mit einer ho- hen Effizienz in der Umsetzung.