Agiles ProjektmanagementSo funktioniert Scrum

© karashaev - Fotolia.com
Scrum und Methoden des agilen Projektmanagements setzen vor allem auf Flexibilität statt auf starre Regeln und aufwendige Dokumentation. So funktioniert das Projektmanagement mit Scrum.
erschienen: 27.06.2014
(17 Bewertungen)

Scrum bricht mit den Regeln des Projektmanagements

Viele Projekte scheitern. Die zu Beginn gefassten Ziele werden nicht erreicht. Es wird viel geplant und dokumentiert, aber wenig 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.

StichwortAgiles 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.

StichwortScrum

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

Er 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. Er sollte wissen, was die Kunden schätzen. Aber auch das Marketing, der Vertrieb und der Kundendienst können spezifische Anforderungen artikulieren.

Scrum-Master (Project-Master)

Er ist vor allem Moderator und Dienstleister für das Projektteam. Er sorgt dafür, dass Hindernisse im Umfeld des Teams beseitigt werden. 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 Mitarbeiten umfassen. Sie 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 der Manager und Verantwortungsbewusstsein der Mitarbeiter voraus.

So läuft der Prozess mit Scrum ab

Neben den Rollen ist es vor allem der Prozess, der kennzeichnend ist für Scrum. Am Anfang steht dabei 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. Mit diesem Auslöser startet ein Projekt nach Scrum mit den folgenden Schritten:

  1. Anforderungen in Story Cards

    Aus dieser ersten, aber anschaulichen und verständlichen Vision lassen sich die einzelnen Elemente und Merkmale des Produkts ableiten, die zu entwickeln sind. Das sind die konkreten Anforderungen und einzelne Funktionalitäten, die in sogenannten Story Cards in den Worten der Anwender formuliert werden – nicht im Jargon der Techniker. Damit wird auch sichtbar, welche Ressourcen das Projekt braucht (Qualifikationen im Projektteam und grober Aufwand für die Umsetzung).
  2. Arbeitspakete im Produkt-Backlog

    Aus diesen Anforderungen des Produkteigners wird ein sogenanntes Produkt-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.
  3. Prioritäten

    Im nächsten Schritt werden Prioritäten vergeben. Welche Elemente und Funktionen sind am wichtigsten im Sinne von: Das sichert die Zufriedenheit der Anwender essenziell. 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.
  4. Sprint-Planung

    In einer ersten Besprechung zur Sprint-Planung werden die Rahmenbedingungen abgesteckt: Wo und wann kann sich das Team täglich treffen? Wie soll der allgemeine Aufbau des Produkts oder des Projektergebnisses aussehen? Was sind die Teilziele für die entsprechende Funktion und Aufgabe? Was sind die Meilensteine? In welche Teilaufgaben, sogenannte Sprints, lässt sich das Projekt untergliedern? Auf welche Details oder Besonderheiten ist zu achten? Welche Konventionen und Schnittstellen sind einzuhalten? Diese Fragen werden geklärt, und die Antworten darauf sind dann die Spielregeln und die Struktur für das weitere Vorgehen.
  5. Aufgaben im Sprint-Backlog

    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 Arbeitszyklus, der sogenannte Sprint. Jedes Teammitglied übernimmt eigenverantwortlich einzelne Ticket (Verpflichtungserklärung).
  6. Arbeitsprozesse im Sprint

    Im Sprint arbeiten die Teammitglieder an ihren Aufgaben, den Tickets. Hier werden Teillösungen gemäß dem Sprint-Backlog (Aufgabenplan) entwickelt.
  7. Besprechungen im Scrum

    Während des täglichen, 15-minütigen Treffens, dem sogenannten Scrum, berichtet jeder der Reihe nach: Was er seit dem letzten Scrum gemacht hat, was er bis zum nächsten Scrum tun wird und was ihn bei seiner Arbeit behindert. Der Scrum-Master muss diese Hindernisse aufgreifen und helfen, dass sie beseitigt werden. In einem Sprint-Burndown-Chart wird sichtbar gemacht, wie das Projekt voranschreitet.
  8. Fortschrittskontrolle im Sprint Review Meeting

    Jeder Sprint wird durch ein Sprint Review Meeting abgeschlossen. Das Team stelle die Ergebnisse dem Produkteigner vor. Er muss sie akzeptieren und abnehmen. In gesonderten Treffen können auch die Teammitglieder ihre Zusammenarbeit überprüfen und festhalten, was intern verbessert werden sollte. Die Erkenntnisse sollten für zukünftige Scrum-Projekte genutzt werden; so wird ein Lernprozess unterstützt.
  9. Projektabschluss

    Sind alle Sprints durchlaufen, wird das fertige Produkt an den Produkteigner geliefert. Das Projekt kann abgeschlossen werden.

Das Kanban-Board zeigt den Projektfortschritt

Damit alle Projektmitarbeiter eine Übersicht über den Projektstand und den Verlauf haben, werden bei Scrum alle Tickets 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 auch 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
Kanban-Board als detailliertes Sprint-Task-Board

Zeit- und Kosten-Kontrolle mit dem Burndown-Chart

Für das Projektcontrolling 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 in der einfachen Variante
Burndown-Chart in der einfachen Variante

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 einher ging 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.

Probleme und Konflikte durch Scrum

Manche Mitarbeiter kommen mit dieser Philosophie für Projektmanagement und Produkt- oder Softwareentwicklung nicht zurecht. Denn hier kann sich niemand mehr verstecken. Die Leistung jedes einzelnen Teammitglieds wird sehr schnell sichtbar und bewertbar. Die vorgebrachten und die tatsächlichen Gründe für Verzögerungen im Arbeitsablauf werden in täglichen Besprechungen offensichtlich. Wenn der Kollege seine Aufgabe nicht erledigt, kommen die anderen nicht voran. Darüber wird offen und direkt gesprochen.

Dabei bleibt es nicht immer auf der sachlichen Ebene. Manche kommen mit der direkten Kritik nicht zurecht. Es kommt zu Konflikten. Das Team fällt auseinander. Einzelne Mitarbeiter verlassen das Team und manchmal sogar das Unternehmen. Zumindest wird die Kommunikation erschwert. Die Mitglieder im Team sprechen nicht genug miteinander. Sie sind nicht mehr bereit, Probleme und Aufgaben anzugehen, damit alle vorankommen. Teilaufgaben werden hin und her geschoben.

Andere Konflikt- und Reibungspotenziale ergeben sich dann, wenn einzelne Mitarbeiter das Projektteam dominieren. Sie setzen ihre Interessen und Meinungen durch, ohne dass diese im Sinne des Projekterfolgs richtig sein müssen. Hier gibt es zu wenig Korrekturmöglichkeiten, da das Team ja selbstbestimmt arbeiten soll und auch der Scrum-Master nicht eingreifen darf.

Auch Projektleiter tun sich oft schwer. Haben sie beim klassischen Projektmanagement eine zentrale Rolle und Führungsfunktion und laufen bei ihnen alle Fäden zusammen, so weist ihnen das agile Projektmanagement nur eine Moderatorenfunktion zu. Sie fühlen sich in ihrer Bedeutung zurückgesetzt. Projektmanagement ist kein Feld mehr, auf dem man sich für den nächsten Karriereschritt empfehlen kann.

Besonders kritisch ist, wenn das Top-Management im Unternehmen nicht hinter diesem radikalen Paradigmenwechsel steht. Es muss darauf vertrauen, dass die Projektteams selbstverantwortlich arbeiten und dass am Ende das rauskommt, was sie erwarten. Ein solcher Vertrauensvorschuss für die Mitarbeiter und ein so hohes Maß an Autonomie, das passt nicht zu jeder Unternehmenskultur und auch nicht zu jeder Führungspersönlichkeit.

Scrum eignet sich nicht immer

Agiles Projektmanagement setzt demnach eine ganz andere Sichtweise auf die Projektorganisation eines Unternehmens voraus. Ohne eine entsprechende Organisationskultur, die auf Vertrauen, Eigeninitiative und Verantwortungsbewusstsein setzt, und ohne die Mitarbeiter, die neben der Fachkompetenz auch soziale und methodische Qualifikationen brauchen, wird sich ein Unternehmen mit diesen Konzepten schwer tun.

Zudem sind agile Methoden auf solche Projekte ausgerichtet, in denen es um die Entwicklung von Produkten oder Dienstleistungen geht oder um die Einführung einer Technologie. Projekte zur Organisationsentwicklung, zum Change Management oder für die Personalentwicklung haben meist kein genau spezifiziertes Ergebnis, das ein Produkteigner abnehmen könnte. Hier lassen sich allenfalls Teilaufgaben mit den agilen Methoden bearbeiten.

Manchmal sind es auch nur die organisatorischen Rahmenbedingungen, die agiles Projektmanagement erschweren. Das kann beispielsweise sein:

  • Das Projektteam ist räumlich getrennt und kann sich nicht täglich treffen.
  • Spezialisten stehen nur für eine begrenzte Zeit oder in eingeschränktem Umfang zur Verfügung.
  • Die Kundenanforderungen bleiben unklar; der Produkteigner kann die Anforderungen nicht genau artikulieren.

Erfolge erzielen mit Scrum

Wer diese Barrieren überwindet, eine förderliche Organisationskultur schafft und die Mitarbeiter dafür gewinnen kann, der erntet mit dem agilen Projektmanagement besondere Früchte. Wie beim schlanken Management wird bei der agilen Vorgehensweise die Qualität der Ergebnisse verbessert, und es werden weniger Ressourcen. Alle fokussieren sich auf das Wesentliche. Die Produktivität steigt, aber auch die Zufriedenheit der Kunden und der Stakeholder. Die ständige und regelmäßige Kommunikation fördert die Transparenz. Engpässe werden schnell erkannt und können beseitigt werden. So kommt das Projekt insgesamt schneller voran.

Auch die Projektmitarbeiter selbst können von dieser Vorgehensweise profitieren. Ihnen macht diese Form des Projektmanagements mehr Spaß, und sie können sehr viel mehr lernen und ihr Wissen erweitern. Am meisten schätzten die Mitarbeiter, dass sie im Projekt flexibler sind. Auch wenn sich die Ziele und die Anforderungen der Auftraggeber ändern, so kann das Projektteam vergleichsweise schnell und einfach seine Arbeiten und den Fortschritt anpassen. Sie sind agil.

Scrum im Management-Handbuch
weiter »
(17 Bewertungen)  Artikel bewerten

Über den Autor
Dr. Jürgen Fleig
Anschriftwww.business-wissen.de
Dr. Jürgen Fleig
Bismarckstraße 21
76133 Karlsruhe
Telefon+49 721 183970
E-Mailredaktion@business-wissen.de
Webwww.business-wissen.de
Xingwww.xing.com/profile/Juergen_Fleig3