Guide: Agiles Projektmanagement mit Scrum
Effektiver Prozess mit klarer Struktur: Scrum zählt nicht ohne Grund zu den derzeit bekanntesten und beliebtesten Projektmanagement-Methoden. Durch die agile Vorgehensweise wird Stück für Stück ein funktionierendes Produkt erstellt, bei dem Änderungen und Verbesserungen kontrolliert miteinfließen und so einen kontinuierlichen Fortschritt ermöglichen.
Die Arbeit erfolgt dabei in multidisziplinären Teams, durch die Projekte schneller und effizienter umgesetzt werden können. Regelmäßige Feedbacks und ein eigenes Wertesystem fördern eine enge Zusammenarbeit und machen Scrum mit seiner Flexibilität und Anpassungsfähigkeit auch für Fachgebiete abseits der Softwareentwicklung interessant.
Was ist Scrum und wie ist es entstanden?
Scrum ist ein Framework für agiles Projektmanagement, das vornehmlich in der Softwareentwicklung eingesetzt wird, aber auch im Rahmen der Organisation und bei der Entwicklung innovativer Produkte und Dienstleistungen verwendet wird. Dabei wird ein iterativ-inkrementeller Ansatz verfolgt, das bedeutet, mit jeder zeitlich begrenzten Iteration (den sogenannten Sprints) wird ein fertiges und benutzbares Teilstück des Gesamtproduktes („Iteration“) entwickelt.
Bei den Iterationen handelt es sich normalerweise um kurze Zeitabschnitte, die sich in einem Rahmen zwischen einer Woche und einem Monat bewegen, und innerhalb derer das Team die notwendigen Arbeiten für die Herstellung von funktionsfähigen Elementen erledigt, die anschließend in die Produktion überführt werden. Die beteiligten Teams sind interdisziplinär zusammengesetzt und organisieren sich während des Prozesses selbst, das bedeutet, dass sie auch mehrere Aufgaben übernehmen können.
Richtung und Gesamt-Ziel des Projektes sind bei Scrum zwar vorgegeben, durch die hohe Flexibilität und Anpassungsfähigkeit (z.B. bei kurzfristigen Veränderungen) können die einzelnen Weg-Abschnitte von den Teams aber völlig frei gestaltet werden.
Der Begriff „Scrum“ stammt ursprünglich aus dem Rugby-Sport und bezeichnet den Neustart eines Spieles nach einer kleinen Regelverletzung. Die Anfänge der gleichnamigen Projektmanagement-Methodik lassen sich bis ins Jahr 1986 zurückverfolgen: In Ihrem Artikel „The New New Product Development Game“ (Harvard Business Review) beschreiben die beiden japanischen Professoren Ikujiro Nonaka und Hirotaka Takeuchi einen teambasierten, skalierbaren Ansatz für eine ganzheitliche Produktentwicklung, mit dem Konzerne wie Canon, Fuji oder Honda beeindruckende Ergebnisse erzielen konnten.
Darauf aufbauend beschäftigten sich die US-Softwareentwickler Ken Schwaber und Jeff Sutherland in den frühen 90igern (erst unabhängig voneinander und später gemeinsam) mit der Frage, wie Produkte insgesamt schneller und flexibler entwickelt werden konnten.
2001 erschien mit „Agile Software Development with Scrum“ das erste Buch über Scrum, das aus einer Zusammenarbeit von Ken Schwaber und Mike Beedle entstand. 2003 legte Schwaber als Solist mit „Agile Project Management with Scrum” nach, und bildete im gleichen Jahr auch den ersten zertifizierten Scrum-Master aus. In seinem dritten Buch “The Enterprise and Scrum” befasste er sich dann nicht mehr nur mit der Einführung von Scrum in Development-Teams sondern dem Rollout im kompletten Unternehmen.
Werte und Prinzipien der agilen Softwareentwicklung mit Scrum
Die Zusammenarbeit in einem agilen Projekt ist auch immer eine Frage der Einstellung. Um kontinuierliche Lernprozesse anzustoßen, basiert Scrum auf einem Wertesystem, das zur Übernahme von Verantwortung und eigenständigem mitdenken auffordert.
Die fünf Werte von Scrum sind:
Mut (Courage), sich einem Ziel zu verpflichten, den Risiken und Herausforderungen zu stellen, auf Veränderungen einzulassen und die Konsequenzen für Entscheidungen zu tragen.
Selbstverpflichtung (Commitment), gefasste Pläne umzusetzen und innerhalb einer Iteration das gewünschte Ergebnis zu erzielen. Scrum erteilt die nötigen Befugnisse, damit die jeweiligen Verpflichtungen auch erfüllt werden können.
Offenheit (Openness), die einen transparenten Umgang mit Informationen voraussetzt und diese projektübergreifend für alle Beteiligten sichtbar macht.
Fokus (Focus) der Energie und Erfahrung auf die zu erledigenden Aufgaben, zum Zwecke der Produktivitätssteigerung und dem Erreichen des Projekt-Ziels.
Respekt (Respect) gegenüber den verschiedenen Individuen innerhalb eines Team sowie deren Erfahrungen, persönliche Hintergründe und Standpunkte.
Dabei sollten nicht alle Werte blind verfolgt werden, obwohl sie gleichwohl natürlich alle Ihre Berechtigung haben. Sie stellen lediglich ein Rahmenwerk dar, das von Handlungsmöglichkeiten bis hin zu konkreten Handlungsanweisungen reicht, und tragen so in Kombination zu mehr Erfolg im Team und einer effizienteren Arbeitsweise bei.
Wie funktioniert Projektmanagement mit Scrum?
Die oben genannten Werte besagen, dass eine unzureichende Flexibilität in Bezug auf die Prozesse und die Zeitplanung sowie eine mangelhafte Kommunikation nicht zu einem Erfolg des Projektes führen können. Scrum konzentriert sich hingegen auf den Entwicklungsprozess von Produkten mit dem Ziel einer größtmöglichen Kundenzufriedenheit bei einer maximalen Wertschöpfung und passt sich durch seine agile Vorgehensweise kontinuierlich an Veränderungen an.
Im Vergleich zu anderen Projektmanagement-Framworks ist Scrum ein echtes Leichtgewicht, das lediglich aus
drei Rollen, die in einem zeitlich festgelegten Rahmen (Sprint) agieren
fünf Aktivitäten mit einem festen Zeitrahmen (Timebox)
drei Artefakten
einer Definition of Done
besteht, die wir Ihnen im folgenden Abschnitt noch einmal detailliert erklären.
Rollen
Ein Scrum-Projekt besteht in der Regel aus einem oder mehreren Teams, die sich wiederum jeweils aus den drei Scrum-Rollen zusammensetzen:
Product Owner
Der Product Owner ist in der Scrum die zentrale Anlaufstelle für alle Anliegen, die die Produktentwicklung betreffen. Er übernimmt die fachliche Führung und vertritt die Auftragegeberseite und die Stakeholder. Der Product Owner entscheidet, wie die Funktionalitäten und Eigenschaften des Produktes auszusehen haben und in welcher Reihenfolge sie geschaffen werden.
Er trägt außerdem die Verantwortung hinsichtlich der Qualität und muss dafür sorgen, dass die Arbeiten immer Zeit bestmöglich ausgeführt werden. Der Product Owner arbeitet eng mit dem Scrum Master und dem Entwicklungsteam zusammen und muss jederzeit für Rückfragen zur Verfügung stehen.
Die Hauptaufgaben und Verantwortlichkeiten des Product Owners sind:
Teilnahme an der Planung und den Daily Scrums
Pflege des Product Backlogs
Zusammenarbeit mit den Entwicklungsteams und Stakeholdern
Organisation der wirtschaftlichen Anforderungen
Definition und Überwachung der Akzeptanzkriterien
Gut zu wissen: Der Product Owner wird scherzhaft manchmal auch als SCN („Single Chokable Neck“) bezeichnet. Er allein definiert, welche Projekt-Anforderungen wann und wie abgearbeitet werden. Liefert das Entwicklungsteam auf seine Vorgaben hin schlechte Ergebnisse, ist es daher sein Kopf, der rollt.
Scrum Master
Der Scrum Master ist die vielschichtigste Rolle innerhalb eines Scrum-Teams. Er hilft allen Beteiligten, die Werte, Prinzipien und Praktiken von Scrum anzunehmen und einzuhalten, damit die Dynamik des agilen Prozesses ihnen am Ende nicht um die Ohren fliegt.
Die Rolle des Scrum Masters ist klar getrennt von der des Product Owners, die beiden Rollen arbeiten aber eng zusammen bzw. unterstützen sich gegenseitig bei ihren Aufgaben.
Gut zu wissen: Da Doppelrollen in Scrum generell ein hohes Komplikations- und Konfliktpotential aufweisen, sollte der Scrum Master auch niemals als Team Member mitarbeiten. Weitere Informationen zu diesem Thema finden Sie hier.
Für die Rolle des Scrum Masters kommen nur Personen in Frage, die über eine ausgezeichnete Expertise in Scrum verfügen, da sie ein breites Spektrum an Tätigkeiten beinhaltet.
Die Hauptaufgaben und Verantwortlichkeiten des Scrum Masters sind:
Coach und Mediator für das Scrum-Team (Facilitator)
Berater in der Organisationsentwicklung
Verantwortlicher für den Prozess und seine Implementierung (Prozessautorität)
Moderation von Scrum Meetings
Beseitigung von Hindernissen (z.B. Beschaffung von Hardware oder Klärung von Kommunikationswegen)
Schutz vor störenden Einflüssen (während des Sprints)
Gewährleistung des Informationsflusses zwischen Product Owner und Team (Transparenz)
Entwicklungsteam
Das Entwicklungsteam ist für die Umsetzung des Projektes verantwortlich und besteht in der Regel aus fünf bis neun Entwicklern und Fachkräften, deren Aufgabe die Lieferung der vom Product Owner definierten Funktionalitäten in der festgelegten Reihenfolge ist.
Das Entwicklungsteam organisiert sich selbst, um den besten Weg für die Zielerreichung zu ermitteln und muss dazu in der Lage sein, die Sprintziele auch ohne Abängigkeiten von anderen Teilnehmern zu erreichen.
Die Zusammenstellung erfolgt cross-funktional, das bedeutet, das Generalisten mit Spezialisten (z.B. Programmierern, Architekten, Datenbankadministratoren etc.)
durchmischt werden. Dadurch können die Teammitglieder Ihre unterschiedlichen Fähig- und Fertigkeiten in das Projekt einbringen und sich bei Bedarf auf bestimmte Aufgabenbereiche spezialisieren.
Die Hauptaufgaben und Verantwortlichkeiten des Entwicklungsteams sind:
Einhaltung der vereinbarten Qualitätsstandards
Teilnahme am Daily Standup Meeting (Statusbericht)
Tägliche Aktualisierung der Restaufwände im Sprint Backlog
Aktiver Berater des Product Owner
Wählt die passenden Werkezeuge und Tools für die zu erledigenden Arbeiten aus
Überwacht den Fortschritt der Arbeit und leitet selbständig Verbesserungsmaßnahmen ein
Artefakte
Die Artefakte dienen in Scrum zur Steuerung, zur Bewahrung des Überblickes und der Erreichung einer maximalen Transparenz beim Austausch von Schlüsselinformationen innerhalb des Projektes.
Product Backlog
Das Product Backlog ist eine geordnete Liste aller Anforderungswünsche, die in Zusammenarbeit mit den internen und externen Stakeholdern erstellt wird, und das zu entstehende Produkt reflektiert. Es liegt gänzlich in der Verantwortung des Product Owners und entwickelt sich zusammen mit dem Produkt oder Projekt kontinuierlich weiter, das bedeutet, dass es niemals wirklich vollständig ist.
Das Product Backlog setzt sich aus einzelnen Backlog Items (z.B. User Stories, Epics, Spezifikationen oder Bugs) zusammen, die die Anforderungen aus Kundensicht und in einer für diesen verständlichen Sprache beschreiben. Die Punkte werden nach wirtschaftlichem Nutzen, Risiko, Aufwand und Notwendigkeit priorisiert, wobei die am höchsten gewichteten ganz oben auf der Liste stehen.
Tipp: Ein Product Backlog kann in seiner einfachsten Form eine simple Excel-Liste sein, mittlerweile gibt es aber eine Vielzahl von praktischen Tools, deren Funktionalitäten speziell auf das Projektmanagement mit Scrum abgestimmt sind.
Sprint Backlog
Beim Sprint Backlog handelt es sich um eine Liste, die während des Sprint Plannings erstellt wird und in der Verantwortung des Entwicklungsteams liegt. Sie enthält alle Backlog Items, die für den aktuellen Sprint ausgewählt wurden, sowie die dazu gehörenden Tasks und kann während des laufenden Sprints jederzeit erweitert oder ergänzt werden.
Das Sprint Backlog gibt fortlaufend den Stand der vom Entwicklungsteam geplanten Arbeiten wider, die zur Erreichung des Sprintziels noch geleistet werden können. Es stellt somit eine Art Realtime-Reporting-Tool für das Projekt und die Team-Mitglieder dar.
Inkrement
Das Inkrement (deutsch: „vergrößern“ oder „Zuwachs“) ist ein Teilergebnis des Projektes, das am Ende eines Sprints in einem nutzbaren (auslieferbaren) Zustand sein muss und der Definition of Done entspricht. Es enthält die Summe aller Product Backlog Einträge, die im Sprint umgesetzt wurden.
Gut zu wissen: Als Definition of Done werden in Scrum die verbindlichen Abnahmenkriterien für ein Backlog Item oder Inkrement bezeichnet. Diese werden häufig in einer Checkliste festgehalten und sind für alle Teams, die gemeinsam an einer Aufgabe arbeiten, gleich.
Aktivitäten
Last but not least werfen wir noch einen Blick auf die fünf Aktivitäten in Scrum. Diese laufen jeweils in einem festgelegten Zeitrahmen, den sogenannten „Timeboxes“ ab.
Sprint
Wie bereits erwähnt, basiert Scrum auf einem iterativ-inkrementellen Vorgehensmodell, das sich durch regelmäßige und wiederholbare Arbeitschritte auszeichnet, die wiederum aufeinander aufbauen. Diese zeitlich beschränkten Interationen oder Zyklen werden als Sprints bezeichnet und können von wenigen Tagen bis zu einem Kalender-Monat reichen. Sie haben immer ein festes Start- und Enddatum und folgen nahtlos aufeinander.
Ziel eines Sprints sind die Entwicklung, Erstellung und das Testen eines funktionsfähigen Zwischenproduktes (Inkrement).
Gut zu wissen: In der agilen Softwareentwicklung wurden Sprints anfänglich auf maximal 30 Tage terminiert, inzwischen geht die Tendenz aber mehr zu kürzen Zeitspannen von ein oder zwei Wochen.
Sprint Planning
Beim Sprint-Planning kommen die Mitglieder des Scrum Teams (Product Owner, Scrum Master, Entwicklungsteam) zusammen, um die Aufgaben für den kommenden Sprint zu besprechen und zu planen. Bei einem vierwöchigen Sprint beträgt die Timebox für die Planung maximal acht Stunden und setzt sich aus zwei gleich langen Teilen zusammen:
Teil 1: Der Product Owner stellt dem Team die Backlog-Punkte für den kommenden Sprint vor und erläutert die fachlichen Anforderungen. Im Anschluss wird gemeinsam ein Sprint-Ziel erarbeitet und ein Forecast hinsichtlich Aufwand und Machbarkeit erstellt.
Teil 2: Das Team legt konkret fest, wie die Anforderungen umgesetzt werden sollen und welche Schritte dafür erforderlich sind. Dazu werden die vorher ausgewählten Backlog-Punkte in Aufgaben (Tasks) unterteilt und verfeinert. Dadurch entsteht ein Sprint-Backlog, das die Backlog-Punkte mit einem Überführungsplan für die Produkt-Funktionalitäten verbindet.
Daily Scrum
Das Daily Scrum ist ein täglich stattfindendes Status-Meeting zwischen den Mitgliedern des Scrum-Teams mit einer Dauer von höchstens 15 Minuten. Es findet immer zur selben Zeit am selben Ort statt und dient zur Abstimmung und Synchronisation der Arbeiten innerhalb des aktuellen Sprints und zur Überprüfung der Ziel-Erreichbarkeit.
Die Mitglieder des Entwicklungsteams beantworten im Daily Scrum die folgenden drei Fragen:
Was habe ich seit dem letzten Daily Scrum fertig gestellt, um das gemeinsame Sprint Ziel zu erreichen?
Was werde ich bis zu nächsten Daily Scrum erreichen?
Welche Hindernisse gibt es bzw. was hindert mich an der Fertigstellung?
Sprint Review
Das Sprint Review findet immer am Ende eines Sprints statt und dient zur Präsentation und Abnahme der Sprint-Ergebnisse. Die neuen Funktionalitäten des Produktes werden detailliert anhand der Abnahmekriterien erläutert und demonstriert.
Neben dem Scrum Team kommen hier auch zukünftige Anwender, Investoren, Vertreter des Managements und andere Stakeholder zusammen, um sich über den Projektverlauf zu informieren, Feedback einzuholen oder Änderungswünsche einzubringen. Ideen für weitere Funktionalitäten werden von allen Beteiligten gemeinsam besprochen.
Sprint Retrospektive
Nach dem Sprint Review und vor dem nächsten Sprint Planning steht die Retrospektive. Dabei überprüft das Scrum Team seine bisherige Arbeitsweise und bekommt Gelegenheit, diese zu untersuchen und gegebenenfalls zu adaptieren. Der Fokus liegt dabei auf der kontinuerlichen Prozessverbesserung und der Steigerung von Effizienz und Effektivität in den zukünftigen Sprints.
Die in der Sprint Retrospektive erarbeiteten Maßnahmen werden geplant und dokumentarisch festgehalten. Bei einem vierwöchigen Sprint sollte sie maximal 3 Stunden beanspruchen.
Fazit
Scrum ist ein agiles Verfahren zur Entwicklung komplexer Systeme, das dafür ausgelegt ist, sich schnell an Veränderungen anzupassen. Dadurch können neue Ansätze und Ideen sehr zeitnah umgesetzt werden, in der täglichen Praxis erfordert das aber eine gewisse Konsequenz. Als Kombination von Planbarkeit und agilen Ansätzen ist Scrum aber durchaus eine gute Alternative zu den etablierten Projektmanagement-Methoden, die mit ihrer Flexibilität auch mehr dem modernen Zeitgeist entspricht.