Scrum und Kanban sind zwei Methoden im agilen Projektmanagement und haben ihre Wurzeln in der Lean Production. Sie legen das Pull-Prinzip (Hol-Prinzip) zugrunde. Die anfallende Arbeit erteilt nicht ein „Supervisor“, sondern die Arbeiter(-gruppen) holen sich ihre Arbeit, um den Produktionsfluss möglichst fließend zu halten. Der Artikel stellt die Grundsätze beider Frameworks vor und gibt Entscheidungshilfen für den Einsatz in Softwareprojekten.
Grundsätze von Kanban
Visualisierung des Arbeitsflusses. Zentraler Punkt von Kanban ist die Optimierung des Prozess- bzw. Arbeitsflusses. Im Zentrum steht das Kanban-Board. Es visualisiert den aktuellen Stand des Projektes mit Kärtchen für eine Aufgabe. Das Board zeigt den Status der jeweiligen Aufgabe sowie deren Anzahl die sich gleichzeitig in einem Status befinden. Begrenze die Anzahl der Aufgaben in Bearbeitung. Fange eine neue Aufgabe nicht an, bevor eine andere erledigt ist.
Konstante Bearbeitung der Aufgaben. Zwischen Beginn und Fertigstellung einer Aufgabe wird die durchschnittliche Bearbeitungszeit gemessen. Diese ist zu verringern und konstant zu halten. Häufen sich Karten in einem Status ist der „Fluss“ zu optimieren durch: Erhöhung der Ressourcen im angestauten Prozessschritt oder Überdenken der Prozessschritte. So reguliert sich das System kontinuierlich selbst.
Grundsätze von Scrum
Im Mittelpunkt von Scrum stehen kleine, selbstorganisierte Teams mit 6±3 Mitgliedern. Das zu entwickelnde Produkt wird in test- und lieferfähige Inkremente zerlegt. Die Projektlaufzeit wird in kleine Iterationen von 1 – 4 Wochen, sogenannte Sprints, aufgeteilt. Am Anfang eines Sprints steht das Sprintplanning, in welchem die Menge an Aufgaben definiert und geschätzt wird. Während des Sprints tauscht sich das Team in einem täglichen Meeting (Daily) über geleistete und zu erledigende Arbeiten sowie über Hindernisse aus. Am Ende eines Sprints wird das Produkt dem Auftraggeber präsentiert und Feedback eingeholt (Sprint Review). Abschließend werden in einer Retrospektive die Projektziele und die Arbeitsweise kritisch beleuchtet und bei Bedarf neu ausgerichtet.
Welches Framework für welchen Zweck?
Welche
agile Methode in einem Projekt zum Einsatz kommt, kann unter anderem an
der Komplexität der Aufgaben beurteilt werden. Bei kleineren, eher
sporadisch auftretenden (Weiter-)Entwicklungen einer bestehenden
Software oder Wartungsarbeiten die keinen kontinuierlichen Arbeitsfluss
sicherstellen, ist Kanban die richtige Wahl. Diese Arbeiten sind klar
umrissen und i.d.R. von geringer Komplexität und zeitlicher Dauer. Scrum
ist in einem Umfeld zu bevorzugen, in dem der Anteil an Nichtwissen im
Bezug auf konkrete fachliche Anforderungen (Was?) und deren technische
Umsetzung (Wie?) größer ist als das Wissen darüber (Stacey Matrix). Der
Endzustand des zu entwickelnden Produktes ist nicht klar definiert, sondern eher als Vision mit Features und/oder Stories umrissen.
Teamgrößen von ein bis zwei Personen sprechen eher für Kanban sowie ein geringes „Setup“ des Frameworks. Kanban erlaubt im Gegensatz zu Scrum flexibel auf neue oder umpriorisierte Anforderungen zu reagieren. Bei Scrum ist der Umfang für die Dauer eines Sprints festgelegt und i.d.R. nicht erweiterbar. Das Team hat sich zu Beginn eines Sprints gemeinsam auf feste Arbeitsinhalte verpflichtet. Neue Anforderungen müssen auf den nächsten Sprint verschoben werden. Kanban kann diese zusätzlichen Arbeitspakete aufnehmen, solange die Kapazitätsgrenze eines Prozessschrittes nicht überschritten wird.
Scrum-Teams sind funktionsübergreifend und benötigen mindestens folgende Rollen: Product Owner, Scrum Master und Entwicklerteam. Das Team handelt selbstorganisiert und eigenverantwortlich. Die Teammitglieder stellen Teaminteressen vor Eigeninteressen und handeln nach dem „Wir“-Prinzip. Sie handeln auf Grundlage des Agilen Manifest für Softwareentwicklung (http://agilemanifesto.org/iso/de/manifesto.html). Die handelnden Personen stehen dem Team dauerhaft zur Verfügung und schätzen die ritualisierte Zusammenarbeit.
Welches Framework für welche Aufgabenstellung geeignet ist entscheidet letztlich das Projektteam selbst. Wobei nichts dagegen spricht, Elemente aus beiden Methoden zu mischen, um das beste Projektergebnis zu erreichen.
