Agiles Projektmanagement: Bedeutung, Entwicklung, Elemen ... / 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 verwaltet und ordnet die Reihenfolge der anstehenden Arbeitspakete und hat dadurch maßgeblichen Einfluss auf das Projekt. Änderungen von außen können jederzeit vom Product Owner in das Product Backlog eingepflegt werden.

Das Product Backlog wird priorisiert, das bedeutet, die wichtigsten Arbeitspakete liegen zuoberst, während Arbeitspakete, die in der Zukunft liegen, weiter unten ihren Platz finden. Wichtig im Sinne von Scrum bedeutet, dass grundsätzlich eine frühe Wertschöpfung generiert werden soll. Diese Entscheidung trifft allein der Product Owner.

Hierbei kommt ein weiterer wichtiger Punkt ins Spiel, nämlich die "Planung auf Sichtweite". Im Gegensatz zum klassischen Projektmanagement, in dem alle Arbeitsschritte so weit wie möglich vorgeplant sein sollten, nimmt im agilen Projektmanagement die Detaillierungstiefe einzelner Arbeitspakete im Product Backlog nach unten hin ab. Wir kennen das grobe Ziel, aber die Arbeitspakete, die weiter in der Zukunft liegen, sind eher vage beschrieben, da sie sich ja noch ändern können.

Dies soll verhindern, dass wir unnötig Arbeit investieren in Tätigkeiten, bei denen es sich im Laufe des Projektes herausstellt, dass sie gar nicht nötig sind. Diese einfache Struktur bringt einen gewaltigen Vorteil mit sich: Änderungen werden so nicht mehr als Störung betrachtet, sondern sind als ganz normal im Prozess integriert. Pläne ändern sich, das Ziel bleibt gleich.

7.2.2 Bearbeiterteam

Während der Product Owner somit für das WAS verantwortlich ist, ist unser Bearbeiterteam für das WIE zuständig. Hierbei kommt das Prinzip der Selbstorganisation ins Spiel. Die Bearbeiterteams und der Product Owner treffen sich am Beginn eines Sprints und besprechen gemeinsam, was in den kommenden Wochen zu tun ist. Hier werden...