Agiles Projektmanagement: Bedeutung, Entwicklung, Elemen ... / 7 Die agilen Promis: Kanban und Scrum

Kanban ist eine Methode, die sich mit wenigen Regeln sehr stark am agilen Mindset von Selbstorganisation, Pull-Prinzip und regelmäßigem Feedback orientiert. Scrum übernimmt diese Prinzipien, aber schreibt darüber hinaus kurze Bearbeitungszyklen, sogenannte Sprints vor, in denen unsere agilen Teams ungestört arbeiten können.

7.1 Kanban

Das Wort Kanban steht für die Sichtbarmachung unsichtbarer Prozesse am sog. Kanban-Board und somit für die Möglichkeit zur Planung und Steuerung dieser ansonsten unsichtbaren Prozesse.

Abb. 4: Kanban-Board mit To-do-, Doing-, Done-Spalten

Das Kanban-Board ist ein Werkzeug, das ohne großen Aufwand dafür sorgt, dass Mitarbeiter Selbstorganisation und das Pull-Prinzip implementieren.

Was sich zunächst etwas abstrakt anhört, ist für uns mittlerweile so normal geworden, dass wir die Besonderheit dieses einfachen Tools eventuell gar nicht mehr gebührend anerkennen: Arbeitspakete werden bspw. in Form von Post-ist beschrieben und in der To-Do-Liste gesammelt. Mitarbeiter ziehen sich aus dieser Aufgabenliste ihre Arbeit und bearbeiten diese. Die jeweiligen Arbeitsstände werden dann von den Mitarbeitern über die jeweiligen Arbeitsphasen über das Board bewegt.

Dieses Werkzeug ist so einfach wie genial: Unsichtbare Prozesse werden sichtbar gemacht, alle Prozessbeteiligte können jederzeit den Zustand des Gesamtsystems erkennen und werden so zum Mitdenken und zur Selbstorganisation aufgefordert. Das Kanban-Board beinhaltet so viele radikale Veränderungen, dass allein das Aufhängen dieses Boards bereits nachhaltige und weitreichende Änderungen anregt. Deswegen ist es ganz wichtig, sich das Folgende deutlich zu machen: Die Implementierung agiler Prozesse geht mit einer Veränderung der Firmenkultur einher.

7.2 Scrum

Neben Kanban ist Scrum eine der aktuellen agilen Methoden. Scrum eignet sich gut für Projekte, in denen das Ziel noch unklarer ist als in Kanban. Beispiel: Wir brauchen eine neue Webseite. Wir wissen noch nicht, wie sie aussehen soll, wir fangen mal mit Skizzen an. Im Gegensatz zu Kanban, das kaum Regeln kennt, wartet Scrum mit einem sehr soliden, genau beschriebenen Regelwerk auf – und das ist auch gut so. In Projekten, in denen das Ziel sehr offen ist, bietet Scrum so wenigstens im Prozess Halt und Sicherheit. Genau festgelegte Rollen befolgen eine Abfolge von genau festgelegten Meetings und nutzen genau festgelegte Scrum-Bestandteile, sog. Artefakte. Das soll zu klaren Verantwortlichkeiten ohne Überschneidungen in einem hocheffizienten und dennoch kreativen Prozess führen.

In aller Kürze:

Kleine selbstorganisierte Teams wählen kleine Aufgaben aus einer Liste (Product Backlog), die innerhalb kurzer Zeiträume (Sprints) bearbeitet werden.

Das "Product Backlog" ist also der Speicher aller Aufgaben für unsere Epic. Aufgaben, die unmittelbar anstehen, sind detailliert beschrieben, Aufgaben, die weiter in der Zukunft liegen, werden nur grob angerissen. Das erlaubt Flexibilität bei Änderungen.

Alle Aufgaben werden in ein- bis vierwöchigen Sprints vom Team bearbeitet.

Tägliche kleine Team-Meetings, die sog. "Daily Scrums", dienen zur Abstimmung innerhalb des Bearbeiterteams und zur Aktualisierung des Sprint Backlog.

Auch hier begegnet uns das Kanban-Board als Bestandteil des Sprint Backlog wieder. Das Sprint Backlog besteht aus den User Stories, die sich das Bearbeiterteam für den anstehenden Sprint vorgenommen hat, und einem Kanban-Board. Alle aktuell in Arbeit befindlichen Aufgaben werden daran visualisiert.

Das Kanban-Board ist das Herz des Sprint Backlog. Hier trifft sich das Bearbeiterteam zum täglichen "Daily". Dabei wird das Kanban-Board von den jeweiligen Bearbeitern selbst aktualisiert: Jedes Teammitglied zieht die Karte, an der gerade gearbeitet wird, in die jeweilige Spalte, z. B. von "To-Do" nach "Doing". Dies sorgt für Transparenz, da alle Beteiligten jederzeit das Board einsehen können und somit zeitnah über den Verlauf des Projektes informiert sind.

In regelmäßigen, abschließenden Meetings werden sowohl das Produkt als auch der Prozess beleuchtet. Entspricht das Ergebnis den Erwartungen, so kann es veröffentlicht werden, entspricht es diesen nicht, kann in folgenden Sprints angepasst werden.

Drei klar definierte Scrum-Rollen sorgen dafür, dass es keine formellen Überschneidungen in den Aufgabengebieten der agilen Teams gibt und dass sich die Scrum-Teams in ihren Kompetenzen ergänzen: Product Owner, Scrum Master und das Bearbeiterteam.

Abb. 5: Scrum-Rollen

7.2.1 Product Owner

Alle anstehenden Arbeiten werden von einem Product Owner im Product Backlog verwaltet.

Das Product Backlog ist der Aufgabenspeicher für das Projekt. Hier werden alle Arbeitspakete für das Team beschrieben. Es ist die To-Do-Liste für das Projekt. Diese Liste ist die alleinige Quelle aller zu erledigenden Aufgaben, aus der sich das Bearbeiterteam bedient.

Der Product Owner ist verantwortlich dafür, WAS zu tun ist. Ersteht in engem Kontakt zum Kunden, er kennt das Produkt sehr gut und er beobachtet den Markt, für den das Produkt geschaffen werden soll. Er verwalte...