Agiles ProjektmanagementSo funktioniert Scrum

Scrum und Methoden des agilen Projektmanagements basieren auf einfachen Regeln, definierten Rollen und täglichen Abstimmungen im Team. So funktioniert flexibles Projektmanagement mit Scrum.

Scrum bricht mit den Regeln des Projektmanagements

Viele Projekte scheitern. Es wird viel geplant und dokumentiert, aber die Ziele werden am Ende nicht erreicht. Scrum und andere Methoden des agilen Projektmanagements versprechen Abhilfe. Der Kerngedanke: Wenn alle ausgefeilten Methoden, Werkzeuge und Vorgehensweisen im klassischen Projektmanagement nicht zu den erwünschten Erfolgen führen, dann lasst das doch einfach sein. Vertraut darauf, dass ein erfahrenes Projektteam es schon irgendwie schaukeln wird, wenn es die Freiheiten dazu hat, wenn der Projektfortschritt für alle immer transparent ist und wenn sich die Projektmitarbeiter täglich abstimmen.

Agiles Projektmanagement

Agiles Projektmanagement umfasst unterschiedliche Methoden, die vor allem auf Flexibilität und Anpassung setzen. Statt ausführlicher und umfangreicher Planung zu Beginn eines Projekts werden das adaptive Planen sowie die schnelle Abstimmung im Team unterstützt. Agiles Projektmanagement hat insbesondere bei der Softwareentwicklung an Bedeutung gewonnen.

Scrum setzt auf Selbstorganisation

In einem Scrum-Projekt sollen wenige und einfache Regeln gelten, die maßgeblich dafür sind, dass das Projektteam die gemeinsamen Ziele erreicht. Entscheidend ist, dass ein Team beim agilen Projektmanagement sich selbst organisieren kann und auch darf und dass es interdisziplinär zusammengesetzt ist, sodass unterschiedliche Kompetenzen zusammenkommen.

Scrum

Scrum bezeichnet eine Vorgehensweise bei Entwicklungsprojekten für das Produktmanagement und beim Projektmanagement. Der Begriff stammt aus dem Rugby, wo Scrum einen dichten Haufen von Spielern meint, die sich um das Spielgerät scharen (deutsch: Gedränge). Dieses Bild wird auf das Projektmanagement übertragen. Scrum soll ausdrücken, worum es beim Projektmanagement vor allem gehen soll: Flexibilität, Dynamik und tägliche Meetings, in denen die Projektmitarbeiter ihre Aufgaben abstimmen.

Ursprünglich war Scrum ein Vorgehensmodell bei der Softwareentwicklung. Die Vorgehensweise und die damit verbundenen Methoden und Werkzeuge wurden auf andere Entwicklungsprojekte und allgemein auf das Projektmanagement übertragen. Daraus entwickelte sich der Begriff agiles Projektmanagement als Abgrenzung zum klassischen Projektmanagement.

Scrum-Rollen und damit verbundene Aufgaben

Es gibt bei Scrum drei Rollen:

  • der Produkteigner (Product Owner)
  • der Scrum-Master
  • das Mitglied im Projektteam

Produkteigner

Der Produkteigner vertritt die Anwender des Produkts oder die Stakeholder des Projekts. Das sind alle, die betroffen sind und ein Interesse am Erfolg des Projekts haben. Wenn eine neue Software oder IT-Lösung im Unternehmen eingeführt wird, sind das die Nutzer, denn sie wollen reibungslos mit ihren Programmen arbeiten. Bei Produkten sind es die Produktmanager, die als Stimme der Kunden auftreten. Der Produkteigner sollte wissen, was die Kunden haben wollen. Aber auch das Marketing, der Vertrieb und der Kundendienst können Anforderungen an das Projektteam stellen.

Scrum-Master (Project-Master)

Der Scrum-Master trägt die Verantwortung für den Scrum-Prozess. Der Scrum-Master ist Moderator und Unterstützer für das Projektteam. Er beseitigt Hindernisse und fördert die gute Zusammenarbeit im Team. Er beschafft die notwendigen Ressourcen und ist Ansprechpartner für Außenstehende. Er hilft dem Team bei methodischen Problemen und stellt sicher, dass die Regeln des agilen Projektmanagements eingehalten werden.

Projektteam

Ein Scrum-Team sollte zwischen fünf und zehn Mitarbeitern umfassen. Die Teammitglieder organisieren alle Aufgaben selbst. Es gibt im Team keine Hierarchie. Jeder hat dieselben Rechte und Pflichten, aber durchaus unterschiedliche Kompetenzen. Alle Fachbereiche, die zur Lösung beitragen, sollten vertreten sein. Wichtig ist, dass alle Teammitglieder aus eigenem Antrieb dabei sind. Sie sollten sich ihre Projekte selbst aussuchen können. Das setzt Vertrauen des Managements und Verantwortungsbewusstsein der Mitarbeiter voraus.

So läuft der Scrum-Prozess ab

Neben den Rollen ist es vor allem der Prozess, der kennzeichnend ist für Scrum. Am Anfang steht eine Produkt-Vision; eine Idee des Produkts, die der Auftraggeber des Projekts vorantreiben will und die auch den Anwendern einen Nutzen bringt. Eine solche grobe Vorstellung vom Produkt oder der Lösung, die im Scrum-Projekt erarbeitet werden soll, ist der Auftrag. Die Produkt-Vision wird in Story Cards überführt, die aus Sicht des Anwenders einzelne Elemente, Merkmale und Funktionen des Produkts beschreiben.

Mit dieser Grundlage startet ein agiles Projekt nach Scrum. Dann umfasst der Scrum-Prozess folgende Schritte:

1. Product Backlog anlegen und pflegen

Aus den Anforderungen des Produkteigners und den Story Cards wird ein sogenanntes Product Backlog zusammengestellt. Das ist eine Sammlung sämtlicher Funktionen und Merkmale, die das Produkt haben soll. Am Anfang ist diese Zusammenstellung noch grob, doch im Projektverlauf wird sie immer genauer.

Im Product Backlog werden Prioritäten vergeben. Eine hohe Priorität erhalten die Elemente und Funktionen die am wichtigsten sind und eine hohe Zufriedenheit der Anwender sicherstellen. Andere Anforderungen sind nicht so wichtig, können aussortiert werden, werden mit anderen zusammengelegt, sind technisch nicht realisierbar oder werden verschoben. Sie werden dann bei der Überarbeitung oder bei der Erweiterung des Produkts behandelt.

2. Im Sprint Planning das Sprint Backlog erstellen

Agiles Projektmanagement mit Scrum ist ein iterativer Prozess, der sich aus mehreren Sprints zusammensetzt, bis das gewünschte Produkt fertiggestellt ist. Der Sprint ist der Kern eines Scrum-Projekts. Er ist eine fest vorgegebene Zeitdauer (Time Box) von maximal einem Monat.

Im Sprint Planning werden die Aufgaben für den als nächstes anstehenden Sprint geplant und das Sprint-Ziel formuliert. Sie ergeben sich aus den Einträgen auf dem Product Backlog und den Prioritäten. Mit dem Sprint Planning wird geklärt:

  • Was wird im nächsten Sprint entwickelt, erstellt oder durchgeführt?
  • Wie werden die entsprechenden Aufgaben und Arbeiten erledigt?

Das Scrum-Team erstellt daraus ein Sprint Backlog. Das ist eine Auswahl der Product-Backlog‐Einträge für den nächsten Sprint ergänzt um den Umsetzungsplan. Außerdem ist klar, woran sichtbar ist, ob die Aufgabe erledigt und das Teil-Produkt (Inkrement) des Sprints erstellt ist. Die sogenannte „Definition of Done“ wird formuliert.

Eine einzelne Aufgabe, die dann zu erledigen ist, wird Ticket genannt. Alle Tickets sind im sogenannten Sprint Backlog aufgeführt. Das ist gewissermaßen der Maßnahmenplan und der Arbeitsvorrat für das Entwickler-Team für den nächsten Sprint. Jedes Teammitglied übernimmt eigenverantwortlich einzelne Tickets (Verpflichtungserklärung). Im Sprint arbeiten die Teammitglieder an ihren Aufgaben, den Tickets, bis diese fertig sind und das „Done“ erreicht ist.

3. Im Daily Scrum den Arbeitsfortschritt besprechen

Während des täglichen, 15-minütigen Treffens, dem sogenannten Daily Scrum, berichtet jeder der Reihe nach: Was er seit dem letzten Daily Scrum gemacht hat, was er bis zum nächsten Daily Scrum tun wird und was ihn bei seiner Arbeit behindert. Dabei haben alle das Sprint-Ziel im Blick und prüfen, ob es noch erreicht werden kann. Der Scrum-Master muss die Hindernisse aufgreifen und helfen, dass sie beseitigt werden. In einem Sprint-Burndown-Chart wird sichtbar gemacht, wie das Projekt voranschreitet.

4. Im Sprint Review die Sprint-Ergebnisse prüfen und abnehmen

Jeder Sprint wird durch ein Sprint Review Meeting abgeschlossen. Das Team stellt die Ergebnisse und die Teil-Produkte dem Produkteigner vor. Er prüft, ob sie den Kriterien entsprechen, die mit der Definition of Done festgelegt wurden. Ist das der Fall, nimmt er die Sprint-Ergebnisse ab. Der Eintrag im Sprint Backlog ist damit abgehakt. Gleichzeitig werden die Einträge im Product Backlog aktualisiert oder angepasst.

Mit den Ergebnissen aus dem Sprint Review und mit dem überarbeiteten Product Backlog kann der nächste Sprint starten. Der Prozess beginnt wieder mit Schritt 2. Es folgen so viele Sprints, bis das Produkt entwickelt und das Projekt abgeschlossen ist.

5. Mit einer Sprint Retrospective die Zusammenarbeit besprechen

In gesonderten Treffen zwischen einem Sprint Review und dem nächsten Sprint Planning können die Teammitglieder besprechen, wie der Sprint in Bezug auf die Zusammenarbeit der beteiligten Personen, Abläufe, Kommunikation und Werkzeuge verlief. Sie halten fest, was für den nächsten Sprint verbessert werden sollte. Die Erkenntnisse sollten für zukünftige Scrum-Projekte genutzt werden; so wird ein Lernprozess unterstützt.

Alle Schritte im Scrum-Prozess sind in der folgenden Abbildung zusammengefasst.

© www.business-wissen.de
Scrum-Prozess und Sprint im Überblick

Das Kanban-Board zeigt den Projektfortschritt

Damit alle Projektmitarbeiter eine Übersicht über den Projektstand und den Verlauf haben, werden bei Scrum alle Tickets eines Sprint Backlogs auf einer Tafel festgehalten (Task-Board). Dort wird sichtbar, was noch ansteht, was gerade in Bearbeitung ist und was schon fertig ist. Das Sprint Backlog, der Aufgabenplan, hängt also für alle sichtbar an der Wand. Mit der Task-Board kann der Projektablauf transparent gesteuert werden. Sie wird dann Kanban-Board genannt.

Nach dem Kanban-Prinzip werden nur so viele Tickets für die Bearbeitung freigegeben, wie vom Projektteam bearbeitet werden können. Geht es an einer Stelle nicht voran, stauen sich dort die Tickets. Es wird schnell sichtbar, wo der Engpass liegt und was getan werden kann. Eilige Tickets können vorgezogen werden. So steuert das Team die Aufgabenverteilung und den Arbeitsfluss völlig selbstständig mit dem Kanban-Board als Wandtafel.

Kanban-Board als detailliertes Sprint-Task-Board

Zeit- und Kosten-Kontrolle mit dem Burndown-Chart

Für das Projektcontrolling und die Budgetüberwachung in einem Sprint wird bei Scrum ein Burndown-Chart eingesetzt. Es ist eine einfache Abbildung, die sichtbar macht, ob das Projekt im ursprünglich vereinbarten Zeit- und Kostenrahmen bleibt oder ob Budget oder Zeitplan angepasst werden müssen. Durch die täglichen Treffen können der Budgetverbrauch und der Projektfortschritt sehr aktuell geführt und Korrekturmaßnahmen sehr schnell eingeleitet werden.

Burndown-Chart für das Controlling im Scrum-Sprint

Scrum als Folge der Lean-Philosophie

Schon vor über dreißig Jahren wurden erste Erfahrungen mit agilen Formen des Projektmanagements gemacht. Es ging zunächst darum, Produkte schneller und kundenorientierter zu entwickeln. Die Ziele waren, weniger Bürokratie und Planung und stattdessen engere Zusammenarbeit und häufigere Abstimmungen zwischen den Mitarbeitern im Produktentwicklungsteam. Die sollten vor allem direkt mit den Kunden sprechen.

Hirotaka Takeuchi und Ikujiro Nonaka zeigten in einem Beitrag der Harvard Business Review (1986), dass kleine, vernetzte und interdisziplinäre Teams die besten Resultate erzielen, wenn es darum geht, schnell neue Produkte zu entwickeln, die den besten Kundennutzen bringen. Sie bezeichnen dieses Vorgehen schon als Scrum. Unternehmen, die damals Erfahrungen damit gesammelt hatten, waren Honda, Xerox, Canon, HP und IBM.

Dass der Wunsch nach weniger Bürokratie und Normen einherging mit der „Lean-Welle“ Ende der 1980er Jahr ist nicht zufällig. Mehr Autonomie für den Einzelnen, Teamarbeit, einfache und klare Regeln und mehr Kundenorientierung kamen in Mode. Methoden des Total Quality Managements und der bedarfsorientierten Produktionslogistik (Kanban) waren die Vorbilder. Daraus sind schließlich die Konzepte und Methoden für die Produktentwicklung hervorgegangen, die seither unter dem Begriff „agiles Projektmanagement“ zusammengefasst werden.

Dazu im Management-Handbuch

Ähnliche Artikel

Gesundheitstipps