Scrum: Agiles Projektmanagement – modern & flexibel

Wenn Teams heute ein Projekt anfangen, starten sie nicht einfach unbedacht mit der Arbeit. Denn insbesondere größere Aufträge benötigen ein funktionierendes Projekt- oder Produktmanagement. Agiles Vorgehen ist heutzutage in vielen Unternehmen gang und gäbe. Der Fokus liegt dabei auf flexiblen Arbeitsweisen, inkrementellen Entwicklungen und transparenten Vorgängen. Im Dunstkreis des agilen Projektmanagements begegnet einem immer häufiger auch der Begriff „Scrum“. Ursprünglich für die Software-Entwicklung gedacht, ist das Modell inzwischen auch in vielen anderen Bereichen beliebt. Was genau sich hinter dem Buzzword verbirgt, erklären wir Ihnen in diesem Artikel.

Die Geschichte von Scrum geht bis in die 1980er-Jahre zurück – in seiner heutigen Form ist es aber erst seit 1995 in Umlauf. In dem genannten Jahr haben Ken Schwaber und Jeff Sutherland, die beide ursprünglich getrennt voneinander einander ähnelnde Modelle in ihren Unternehmen eingesetzt hatten, ein gemeinsames Paper herausgebracht. Dabei ging es ihnen darum, Arbeit produktiver zu gestalten und gleichzeitig möglichst wenige Regularien einzuführen, die die Produktivität einschränken könnten.

Um das zu ermöglichen, legt Scrum ein Rahmenwerk (Framework) fest, das man auf verschiedene Situationen anwenden kann. Das geschieht mit dem Zweck, sowohl die Arbeitsweise als auch das Produkt fortwährend zu verbessern. Teil des Frameworks sind daher festgelegte Rollen, Ereignisse, Artefakte und Regeln. Innerhalb dieser Begrenzungen sollen Scrum-Teams möglichst effizient Ergebnisse erreichen, die dem Kunden das bestmögliche Produkt bescheren. Kunden beziehungsweise Auftraggeber und Nutzer nehmen daher bei Scrum eine wichtige Position ein: An ihren Anforderungen orientiert sich die Entwicklung.

Hinsichtlich der Arbeit mit Scrum spielen zwei Schlüsselbegriffe immer wieder eine Rolle:

• Iterativ: Bei Scrum wird ein Produkt laufend weiterentwickelt. Die Arbeit beschreibt somit einen Zirkel, der von der Planung über Entwicklung und Testing zur Evaluation kommt und von da aus wieder in die Planungsphase übergeht. Somit befasst sich Scrum nicht nur mit der initialen Herstellung, sondern auch mit künftigen Weiterentwicklungen.
• Inkrementell: Scrum basiert auf der Vorstellung, dass ein Produkt schrittweise erstellt wird. Diese Schritte stellen Zwischenziele dar. Damit wendet man sich von einer Arbeitsweise ab, die auf ein einziges großes Ziel am Ende der Entwicklung abzielt. Um sich größere Flexibilität zu erhalten, unterteilt man große Projekte in mehrere kleinere.

Kombiniert man beides, bedeutet ein iterativ-inkrementelles Vorgehen also, dass es sich bei der Entwicklung um einen schrittweisen und andauernden Prozess handelt. Damit wird zum einen der Prozess an sich sehr viel transparenter, da häufiger Überprüfungen der Arbeit vorgesehen sind (resultierend aus der kleinschrittigeren Vorgehensweise), und zum anderen verbessert man auch die Qualität des Produkts, da dessen Funktionalität fortwährend geprüft wird.

Scrum entstammt ursprünglich der agilen Software-Entwicklung. Dort setzt man auf Agile Scrum, um kontinuierlich die Arbeit an Programmen zu verbessern. Aber auch bei anderen Produkten – zum Beispiel bei der Herstellung von Hardware – ist Scrum ein wirksames Modell. Doch am Ende eines Scrum-Projektes muss nicht zwingend ein Produkt im eigentlichen Sinne stehen: Jedes ergebnisorientierte Projekt kann von Scrum profitieren. So wird das Modell zum Beispiel auch bei der Organisation von Marketingteams oder Verwaltungsorganen sowie beim Entwickeln von Dienstleistungen eingesetzt.

Ausgangspunkt von Scrum sind aber immer kleine Teams – wobei „klein“ ein relativer Begriff ist: Für große Arbeitsgruppen eignet sich das flexible Modell allerdings weniger. Häufig ist es aber möglich, eine große Gruppe in mehrere kleinere Teams zu unterteilen. Scrum eignet sich nämlich auch bestens dafür, Teams untereinander zu vernetzen. Teamwork hat in diesem Modell nämlich einen hohen Stellenwert: Innerhalb eines Scrum-Teams sollen sich die einzelnen Mitglieder mit ihren unterschiedlichen Fähigkeiten gegenseitig ergänzen.

Scrum versteht sich weniger als feste Methode oder konkrete Arbeitstechnik, sondern ist vielmehr nur ein Rahmenwerk, das den Teams feste Bezugspunkte für ihre Arbeit bietet. In diesem Framework gibt es bestimmte Rollen, Ereignisse und Artefakte.

Innerhalb eines Scrum-Teams gibt es drei feste Rollen: das Team, den Product Owner und den Scrum Master. Beim Team handelt es sich um die eigentlichen Entwickler des Produktes. Die Gruppe ist so aufgestellt, dass sie sich selbst organisieren kann. Sie legt dabei auch selbst fest, wie sie zu einem vereinbarten Ziel gelangt. Bei Scrum gibt es innerhalb des Teams zudem keine Hierarchien mehr. Zwar ist es selbstverständlich, dass jeder Mitarbeiter seinen eigenen Aufgabenbereich hat, beim abschließenden Review müssen aber alle gemeinsam Rechenschaft über das Produkt ablegen.

Die Größe des Teams ist nicht konkret festgelegt: Man sollte so aufgestellt sein, dass man schnell und flexibel agieren kann, aber auch leistungsfähig bleibt. Also nicht zu groß und nicht zu klein. Schwaber und Sutherland schlagen zwischen 3 und 9 Mitglieder pro Team vor.

Bei Scrum ist der Product Owner für die Qualität des Produkts und der Arbeit zuständig. Somit nimmt diese Person eine Kontrollfunktion ein. Product Owner organisieren den Product Backlog, eine Liste, die die Anforderungen an das Projekt festlegt (mehr zum Product Backlog erfahren Sie unter dem Punkt Scrum-Artefakte.) Zu seinen Aufgaben gehört auch, die Ziele in eine sinnvolle Reihenfolge zu bringen und diese verständlich zu dokumentieren. Der Product Owner ist eine autoritäre Rolle: Zwar legen die Teams selbst fest, wie sie die im Backlog formulierten Ziele erreichen, aber die Festlegung der Ziele liegt im Ermessen des Product Owners. Und dies darf auch von niemandem angezweifelt werden: Um maximale Produktivität zu gewährleisten, muss das Team den Entscheidungen des Product Owners vertrauen. Dennoch kann man nicht von einer Führungsperson sprechen: Product Owner und das Team haben unterschiedliche Aufgabenfelder und sind in diesen maßgeblich. So wie das Team nicht den Backlog in Frage zu stellen hat, mischt sich der Product Owner auch nicht in den Entwicklungsprozess ein.

Der Scrum Master fungiert im Vergleich zu den anderen beiden Rollen als Art Mediator. Scrum Master sind dafür verantwortlich, Scrum in den Arbeitsablauf zu integrieren und durchzusetzen. Das bedeutet auch, dass diese Rolle für die Organisation der Scrum-Ereignisse zuständig ist: Sie legt somit Meetings fest und moderiert diese auch. Darüber hinaus steht der Scrum Master sowohl dem Team als auch dem Product Owner helfend zur Seite. Dabei greift er aber nie in den eigentlichen Entwicklungsprozess ein. Seine Funktion besteht lediglich darin, den an der Produktion beteiligten Mitarbeitern die Arbeitsabläufe zu vereinfachen und somit Produktivität und Kreativität zu steigern.

Als Ansprechpartner sorgt der Scrum Master dafür, dass alle Beteiligten die Abläufe richtig verstehen: Er gibt Tipps zum Erstellen von Backlogs oder zur Organisation des Teams und versucht allgemein, Hindernisse aus dem Weg zu räumen. Der Scrum Master hat also unter anderem die Funktion eines Coachs. Für diese Rolle ist es entscheidend, Scrum genauestens zu kennen. Deshalb kann man sich auch als Scrum Master zertifizieren lassen. Inzwischen gibt es mehrere Zertifizierungsstellen, die auch entsprechende Trainings anbieten. Sowohl die Scrum Alliance als auch Scrum.org wurden von Ken Schwaber gegründet und bieten die Zertifikate Certified Scrum Master bzw. Professional Scrum Master an.

Organisiert man Arbeitsabläufe nach dem Prinzip von Scrum, gibt es bestimmte Ereignisse, die regelmäßig eintreffen. Da es sich bei Scrum um einen iterativen Prozess handelt, vollzieht sich die Arbeit in wiederholenden Zyklen: Jedes Ereignis findet bei jeder Wiederholung erneut statt. Die Häufigkeit der Scrum-Ereignisse bewirkt, dass außerplanmäßige Meetings selten bis gar nicht stattfinden. Alle Ereignisse haben zudem einen festen Zeitrahmen.

Den Zyklus selbst nennt man Sprint. Dieser beschreibt den Zeitraum einer Entwicklungsphase. Am Ende eines Sprints wird vom Entwicklerteam ein fertiges Produktinkrement ausgeliefert. Das heißt, die Entwicklung muss zu einem Produkt geführt haben, das potenziell ausgeliefert werden kann. Somit hat jeder Sprint eine konkrete Mission, die man am Ende als „fertig“ kennzeichnet. Der Zeitrahmen für einen Sprint wird im Vorfeld festgelegt, sollte aber nicht mehr als 30 Tage betragen. Bei der Festlegung der Zeitspanne sollte man folgende Faktoren berücksichtigen: Ein Sprint darf weder verlängert noch verkürzt werden, und auch die kommenden Sprints des Projekts sollten die gleiche Dauer haben.

Sprints werden bewusst kurz gehalten, damit man bei der Formulierung der Ziele nicht zu kompliziert denkt. Die kurze Dauer sorgt auch dafür, dass mindestens einmal im Monat eine Überprüfung der Entwicklung stattfindet. Nur in wenigen Ausnahmefällen darf ein Product Owner (und auch nur dieser) einen Sprint abbrechen. Möglich ist der Abbruch zum Beispiel, wenn das Ziel nicht mehr erreicht werden muss, weil das Unternehmen inzwischen eine andere Zielsetzung hat. Grundsätzlich sollten Sprints aber nicht abgebrochen werden, weil dies die Produktivität stark mindert.

Ein Sprint beginnt mit dem Sprint Planning: An diesem Ereignis sind alle Rollen des Scrum-Teams beteiligt. Während eines maximal acht Stunden andauernden Meetings besprechen die Beteiligten das anstehende Produktinkrement: Was soll im Inkrement enthalten sein und wie möchte man das Ergebnis erreichen? Ausgangspunkt für die Planung ist der Product Backlog. Das Entwicklerteam und der Product Owner verständigen sich gemeinsam darauf, welche Ziele im kommenden Monat erreicht werden können. Daraufhin bespricht das Entwicklerteam, wie die Aufgaben bewältigen werden soll. Am Ende des Meetings sollten die Entwickler ihren Plan mit dem Product Owner und dem Scrum Master besprechen können.

Innerhalb des Sprints findet jeden Tag ein Daily Scrum statt – immer zum gleichen Zeitpunkt und am gleichen Ort, denn das spart Organisationsaufwand. Bei dem 15-minütigen Meeting bespricht das Entwicklerteam, welche Aufgaben an diesem Tag anstehen und was man am vergangenen Tag erreicht hat. Auch die Entwickler beurteilen den allgemeinen Fortschritt des Projekts: Wie weit ist man bei der Abarbeitung der Backlog-Einträge vorangekommen? Der tägliche Abgleich stellt sicher, dass alle Beteiligten die Ziele im Blick behalten, wodurch letztlich auch die Produktivität gesteigert wird.

Der Scrum Master sorgt zwar dafür, dass ein Daily Scrum stattfindet, den Ablauf des Meetings machen aber die Entwickler untereinander aus. Sie legen fest, welche Themen besprochen werden. Solange es inhaltlich um die Erreichung des Sprint-Ziels geht und die 15 Minuten nicht überschritten werden, mischt sich der Scrum Master nicht ein. Er achtet auch darauf, dass andere Personen, die dem Daily Scrum beiwohnen, die Entwickler nicht bei ihrer Arbeit stören.

Wenn ein Sprint zu Ende ist, folgt ein Sprint-Review: Dabei wird das Produktinkrement überprüft. Gemeinsam mit Personen, die nicht Teil des Scrum-Teams sind, aber dennoch ein wichtiges Interesse an dem Produkt haben, wie zum Beispiel Unternehmenseigentümer oder Kunden (bei Scrum gesammelt als Stakeholder bezeichnet), werden die Ergebnisse ausgewertet. Dabei spricht man auch über den Arbeitsprozess als solchen, geht auf Probleme bei der Entwicklung ein und tauscht sich über Herausforderungen aus. Dies hat auch Einfluss auf die weitere Planung, denn der Product Owner nutzt die Gelegenheit, auf den Fortschritt des Backlogs einzugehen. Die Erkenntnisse des Sprints beeinflussen die Prognose für die kommenden Leistungen.

Einfluss auf den Backlog hat auch die jeweilige Marktsituation: Insbesondere bei langfristigen Projekten können sich im Laufe der Zeit Prioritäten verschieben und Budgets ändern. Auch solche Themen werden im Sprint-Review beachtet und verändern die zukünftige Vorgehensweise. Bei einem einmonatigen Sprint sollte man für das Review nicht mehr als vier Stunden einplanen.

Auf das Sprint-Review folgt ein weiter Rückblick: die Sprint-Retrospektive. Innerhalb eines maximal dreistündigen Meetings setzt sich das gesamte Scrum-Team (also inklusive Product Owner und Scrum Master, aber ohne Stakeholder) für eine Feedback-Runde zusammen. Während beim Review vor allem das Produkt und das Voranschreiten des Projekts im Zentrum stehen, geht es bei der Retrospektive überwiegend um die Teamarbeit. Ziel dieses zweiten Rückblicks ist es, die Arbeit untereinander zu verbessern und interne Probleme aus dem Weg zu schaffen. Sobald ein Sprint beendet ist, beginnt der nächste erneut mit dem Sprint Planning.

Gegenstände, die bei Scrum eine wichtige Rolle spielen, werden Artefakte genannt. Dazu gehören beispielsweise auf der einen Seite Product Backlog und Sprint Backlog und auf der anderen Seite das abgeschlossene Inkrement.

Bei Scrum ist Transparenz ein wichtiger Faktor. Alle beteiligten Personen sollen jederzeit alle Informationen möglichst leicht erhalten können. Deshalb achtet man bei der Gestaltung der Scrum-Artefakte darauf, dass diese einfach und verständlich formuliert sind. Beim Product Backlog ist dafür der Product Owner zuständig: Bei dem Backlog handelt es sich um eine sortierte Liste aller für das Produkt entscheidenden Elemente. Zu diesen gehören sowohl die Funktionalitäten des Produkts als auch Fehlerbehebungen oder Verbesserungen.

Die Arbeit am Product Backlog findet andauernd statt: Die Liste wird dynamisch geführt – neue Erkenntnisse fließen jederzeit ein und sorgen dafür, dass Einträge stärker ausdifferenziert werden, neue Aufgaben hinzukommen und die Sortierung angepasst wird. Am Anfang steht dem Product Owner bei der Erstellung meist der Scrum Master zur Seite. Denn die Master wissen aufgrund ihrer Erfahrung, wie das Dokument formuliert sein muss, um den Ansprüchen der Transparenz und Effektivität zu genügen. Einträge sollten sich generell an den Anforderungen des Kunden orientieren. Neben einer Beschreibung des geforderten Features enthält das Dokument auch einen Vermerk zum Arbeitsaufwand sowie einen Eintrag zur Prioritätsstufe.

Neben dem Product Backlog gibt es noch den Sprint Backlog, wobei sich letzterer aus dem ersten generiert. In den Sprint Backlog kommen alle Einträge des Product Backlogs, die beim Sprint Planning für den kommen Sprint ausgewählt wurden. Damit stellt dieser Backlog alle Schritte bis zum Ziel des jeweiligen Sprints dar. Während des täglichen Daily Scrums wird anhand des Sprint Backlogs der Fortschritt beurteilt. Auch diese Liste kann während des Sprints aktualisiert werden, damit sie den Ansprüchen und Herausforderungen des Teams entspricht. Deshalb liegt es auch in der Verantwortung der Entwickler, Änderungen im Sprint Backlog vorzunehmen. Weder Product Owner noch Scrum Master dürfen die Liste verändern.

Am Ende eines Sprints präsentiert das Entwicklerteam das Inkrement – also das Ergebnis der Entwicklungsphase. In einem Inkrement sollen alle Einträge des Sprint Backlogs sowie alle Inkremente vorheriger Sprints enthalten sein. Ein Inkrement muss zumindest potenziell immer direkt auslieferbar sein. Es sollte einsatzbereit sein, selbst wenn gar nicht geplant ist, das Produktinkrement auch tatsächlich auszuliefern. Im Sprint Review stellt das Team das Inkrement vor und Product Owner und Stakeholder können das Ergebnis begutachten.

Scrum bietet einige Vorteile – sowohl im Vergleich zu anderen agilen Verfahren als auch zu traditionelleren Projektmanagement-Methoden. Diese liegen vor allem in der kleinschrittigen Vorgehensweise und den wenigen Regeln, die das Scrum-Team einschränken:

• Kommunikation: Gutes Projektmanagement kann nur funktionieren, wenn alle Teammitglieder auf dem gleichen Stand sind. Scrum liegt viel Wert darauf, dass Mitarbeiter viel miteinander kommunizieren. Deshalb sind die Scrum-Ereignisse relativ hoch getaktet. Das tägliche Meeting zum Tagesbeginn sorgt dafür, dass kein Entwickler an den anderen vorbeiarbeitet und in der abschließenden Retrospektive werden auch Probleme innerhalb des Teams angesprochen.
• Flexibilität: Bei Scrum setzt man relativ kurze Sprints an. Da maximal ein Monat zwischen zwei Planungsmeetings liegt, kann man das Projekt auch kurzfristig ändern und an neue Anforderungen anpassen.
• Transparenz: Die stetige Kommunikation aller Teammitglieder sowie die Gestaltung der Scrum-Artefakte sorgen für eine hohe Transparenz. Backlogs sind so formuliert, dass jeder Beteiligte sich darin leicht zurechtfindet und die benötigten Informationen zum Projekt findet.
• Qualitätskontrolle: Durch das iterative Prinzip von Scrum ist eine stetige Kontrolle des Produkts gegeben. Fehlerbehebungen gehören genauso zum Product Backlog wie Weiterentwicklungen. Beim Sprint Review präsentiert das Entwicklerteam zudem ein fertiges Inkrement. Product Owner und Stakeholder haben dabei Gelegenheit, sich von der Qualität zu überzeugen. So kann deutlich schneller auf Fehler in der Entwicklung reagiert werden, als wenn man erst ganz am Ende eines Projekts eine fehlerhafte Funktion feststellt.
• Kreativität: Scrum geht von der Selbstorganisation des Teams aus. Statt von oben herab die Arbeitsweise vorzugeben, gehen die Entwickler mit eigenen Ideen ans Werk. Da das Framework von Scrum zudem vergleichsweise offen ist und wenige Regeln hat, können einzelne Teammitglieder freier Ideen einbringen.
• Effektivität: Im Vergleich zu klassischem Projektmanagement herrscht bei Scrum eine sehr viel geringere Dokumentationspflicht. Im Fokus soll das funktionierende Produkt stehen und nicht eine lückenlose Dokumentation, die Zeit und Ressourcen kosten. Stattdessen kann sich das Team während des Sprints voll auf die Entwicklungsarbeit konzentrieren und diese so ausführen, wie es das für sinnvoll hält.

Trotz der überzeugenden Vorteile eignet sich Scrum nicht für jeden Betrieb gleichermaßen. Aufgrund folgender Nachteile ist Scrum für einige Unternehmen nicht die ideale Lösung:

• Mangelnder Überblick: Was für das eine Team ein großer Vorteil sein kann, ist für das andere eher ein Nachteil: Die sehr kurzschrittige Planung kann dafür sorgen, dass man das große Ganze bei umfassenderen Projekten aus den Augen verliert.
• Aufwendige Kommunikation: Scrum-Ereignisse sind fest eingetaktet. Doch für manche Teams und Projekte kann ein solch hohes Maß an Kommunikation unnötig sein. Die täglich stattfindenden Daily Scrums hindern in solchen Fällen eher die Produktivität. Man verwendet zu viel Zeit auf Organisation und Kommunikation statt auf die eigentliche Arbeit am Produkt.
• Verunsicherung hinsichtlich Planung und Zuständigkeit: Scrum sieht vor, dass Teams sich selbst organisieren. Das kann durchaus vorteilhaft sein, doch in einigen Bereichen und Branchen kann solch flache Hierarchie auch zur Verunsicherung bei der Planung und Unklarheiten hinsichtlich der Zuständigkeit führen.
• Nicht integrierbar: In manche Unternehmensstruktur lässt sich Scrum nur durch starke Anpassungen integrieren. In solchen Fällen stellt sich die Frage, ob man nicht mehr Effektivität verliert, als man durch Scrum hinzugewinnt.

Ob sich Scrum auch für Ihr Unternehmen eignet, müssen Sie also letztlich selbst beurteilen und abwägen, ob die flachen Hierarchien und die regelmäßige Kommunikation in Scrum-Teams auch in Ihrem Betrieb zu einer Produktivitätssteigerung und einer höheren Arbeits- und Produktqualität führen.