Agiles ProjektmanagementSo funktioniert Scrum

Scrum als Modell und Methoden des agilen Projektmanagements ersetzen starre Projektpläne durch einfache Regeln und häufige Abstimmungen im Projektteam. Welche Rollen gibt es bei Scrum? Welche Regeln sind wichtig? Und wie läuft ein Scrum-Projekt ab?

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.

Was genau ist Scrum?

Scrum ist ein Modell oder eine Methode des agilen Projektmanagements. Der Begriff stammt aus dem Rugby, wo Scrum einen dichten Haufen von Spielern meint, die sich um das Spielgerät scharen (deutsch: Gedränge). Übertragen auf das agile Projektmanagement bedeutet das für Scrum: Alle Mitarbeiterinnen und Mitarbeiter eines Projekts treffen sich jeden Tag, um über anstehende Aufgaben und den bisherigen Verlauf im Projekt zu sprechen.

Dazu kommen weitere Regeln und Methoden, die dem Projektteam helfen, die Projektziele zu erreichen und den Projektauftrag zu erledigen. Diese Herangehensweise soll die manchmal schwerfällige und unflexible Projektplanung ersetzen und das Projektmanagement agiler machen.

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.

Warum ist man mit Scrum agil?

In einem Scrum-Projekt gelten wenige und einfache Regeln. Sie sind nur dafür da, das Projektteam zu unterstützen, um das gemeinsame Projektziel zu erreichen. Die wichtigste Regel ist, dass ein Team beim agilen Projektmanagement sich selbst organisieren kann und auch darf. Das Projektteam bekommt einen Auftrag und legt mit dem Auftraggeber die Projektziele fest.

Danach kann es agil die eigene Projektarbeit organisieren. Es gibt keinen fertigen Projektplan, den das Projektteam abarbeiten muss. Damit das gelingt und das Projektteam selbstständig, selbstverantwortlich und kompetent arbeiten kann, ist es hilfreich, wenn es interdisziplinär zusammengesetzt ist, sodass unterschiedliche Kompetenzen zusammenkommen.

Was sind die Methoden und Regeln von Scrum?

Ein Scrum-Projekt ist dadurch gekennzeichnet, dass die beteiligten Akteure eine Rolle und damit verbundene Aufgaben zugewiesen bekommen. Das wichtigsten Rollen sind: Produkteigner, Scrum-Master und das Projektteam.

Das Projekt selbst läuft dann in mehreren Phasen ab. Eine Phase wird als Projekt-Sprint bezeichnet. In jedem Sprint gibt es die täglichen Meetings, das Daily Scrum.

Schließlich gibt es einige Methoden und Tools, die dabei helfen, die einzelnen Aufgaben und Aktivitäten des Sprints vorzubereiten, durchzuführen und zu prüfen, was nach einem Sprint erreicht wurde. Das sind insbesondere das Product Backlog, das Sprint Backlog, das Kanban-Board, das Sprint Review und das Burndown-Chart. Immer wieder wird die Zusammenarbeit im Team reflektiert. Das ist das Sprint Retrospective.

Im Folgenden werden die Rollen, die Vorgehensweise und die wichtigsten Methoden und Tools beschrieben.

Welche Rollen und Aufgaben gibt es bei Scrum-Projekten?

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. Und 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 Mitarbeiterinnen und Mitarbeitern umfassen. Die Teammitglieder organisieren alle Aufgaben selbst. Es gibt im Team keine Hierarchie. Jeder hat dieselben Rechte und Pflichten, aber 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 Mitarbeitenden voraus.

Neben den Rollen ist es vor allem der Prozess, der kennzeichnend ist für Scrum.

Wie läuft der Scrum-Prozess ab?

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 oder User Stories ü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 Mitarbeiterinnen und Mitarbeiter im Projekt 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

Das Burndown-Chart hilft bei der Zeit- und Kostenkontrolle

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 sind der Budgetverbrauch und der Projektfortschritt immer aktuell und Korrekturmaßnahmen können sehr schnell eingeleitet werden.

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

Hintergrund: Was hat Scrum mit Lean-Management zu tun?

Schon vor rund 40 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.

Zu Beginn wurde Scrum bei der Softwareentwicklung eingesetzt. 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.

Dass der Wunsch nach weniger Bürokratie und Normen einherging mit der „Lean-Welle“ Ende der 1980er-Jahre 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

Excel-Tipps