Scrum – Methode für agiles Projektmanagement

Eine der bekanntesten Methoden im agilen Projektmanagement ist Scrum. Korrekterweise muss man ergänzen, dass im Scrum Guide von Scrum als “Rahmenwerk” (Framework) zur Entwicklung, Auslieferung und Erhaltung komplexer Produkte gesprochen wird. Ursprünglich aus der Softwareentwicklung stammend, hat dieses Vorgehensmodell weite Verbreitung in verschiedenen Branchen erfahren. Es bricht mit Gewohnheiten von klassischem Projektmanagement und setzt auf Eigenverantwortung. Darüber hinaus wird eine enge Abstimmung innerhalb des Teams großgeschrieben. Scrum ist damit ein Inbegriff von agiler Arbeit.

Grundannahmen von Scrum

Die Ursprünge von Scrum liegen in den 1990ern. In dieser Zeit wurden in der Autoindustrie neue Vorgehensweisen beim Projektmanagement ausprobiert. Ab Mitte der 90er begannen Jeff Sutherland und Ken Schwaber, ihre Ansätze formal zu beschreiben.

Die wichtigste Erkenntnis dabei ist, dass der Entwicklungsprozess nicht vorherzusagen ist. Viele klassische Modelle des Projektmanagements haben einen Planungsansatz. Dabei wird davon ausgegangen, dass alle Anforderungen vor Produktionsbeginn bekannt sind. In realen Projekten entstehen jedoch oftmals während des Prozesses neue Anforderungen, die nicht im Plan auftauchen. In der plangetriebenen Projektentwicklung bedeutet diese Abwandlung eine enorme Umstellung, die einen großen Overhead erzeugt.

Scrum versucht, die mangelnde Flexibilität abzufedern. Es macht sich bewusst, dass nicht alle Anforderungen zu Beginn eines Projekts feststehen. Deshalb ist der Scrum-Prozess dynamisch und hierarchiefrei organisiert. So kann ein Team auf sich verändernde Anforderungen schnell reagieren.

Herkunft des Namens

Der Name scrum stammt aus dem Englischen und bedeutet Gedränge. Seinen Ursprung hat der Begriff im Rugby. Damit wird eine Standardsituation bezeichnet, bei der die Teams um den Ball kämpfen. Die Vordenker des Prozessmodells sahen darin eine gute Analogie zum dynamischen Entwicklungsprozess, der ihnen vorschwebte.

Charakteristika von Scrum

Scrum gehört zu den iterativen, inkrementellen Prozessmodellen. Inkrementell bedeutet, dass während des Prozesses neue Anforderungen hinzukommen können. Iterativ ist das Modell deshalb, weil es bestimmte Schritte im Laufe des Projekts wiederholt. Im Scrum werden diese Zyklen “Sprint” genannt.

Der Ansatz ermöglicht es somit, bessere Ergebnisse zu erzielen als ein plangetriebener Managementansatz. Dabei spielen verschiedene Aspekte eine Rolle:

• Dynamik: Durch wiederkehrende Arbeitsschritte kann das Team auf veränderliche Anforderungen reagieren. Gleichzeitig ist die Aufgabe in kleinere, überschaubare Teilschritte gegliedert.
• Transparenz: Alle Teammitglieder sind über Fortschritt und veränderte Aufgaben informiert. Auch Schwierigkeiten werden offen kommuniziert.
• Überprüfung: Die Anforderungen können dynamisch angepasst werden. Dabei spielen die verschiedenen Zyklen im Prozessmodell eine Rolle, an deren Ende eine Evaluation und Neubewertung des Projekts stehen.

Die verschiedenen Aspekte von Scrum

Scrum ist als Projektmanagement-Ansatz sehr umfassend. Um Scrum als Methode zu beschreiben, müssen verschiedene Aspekte betrachtet werden. Dazu gehören zunächst verschiedene Rollen, die ein agiles Team bzw. Projekt benötigt. Der Scrum-Prozess besteht zudem aus verschiedenen Ereignissen, die zu unterschiedlichen Zeitpunkten eintreten. Des Weiteren gehören verschiedene Schriftstücke – in der Literatur als “Artefakte” bezeichnet – zum Prozess. Dort werden die Anforderungen festgehalten und für die Bearbeitung der Aufgabe strukturiert.

Rollen in Scrum

Man unterscheidet im Scrum-Prozess zwischen internen und externen Rollen im Prozess. Die internen Rollen sind diejenigen, die sich um das Projekt kümmern und in Scrum-Zyklen arbeiten. Die externen Rollen (Stakeholder) liefern Anregungen und Anforderungen für das Projekt.

Interne Rollen

Für Teams, die innerhalb des Scrum-Prozesses arbeiten, gibt es drei verschiedene Rollen: Product Owner, Teammitglied und Scrum Master. Das Team arbeitet mit flachen Hierarchien, die jedoch verschiedentlich abweichend interpretiert werden.

Product Owner

Der Product Owner ist im weiteren Sinne mit einem Projektmanager vergleichbar. Als Einzelperson ist der Product Owner dafür zuständig, die Eigenschaften des zu entwickelnden Produkts festzulegen. Dazu gehört, den Nutzen des Produkts zu maximieren. Wie genau der Nutzen festgelegt ist, obliegt dem Product Owner allein.

Er steht im Austausch mit den Stakeholdern und legt fest, welche Anforderungen am Ende eines Zyklus erfüllt wurden.

Im Modell ist der Product Owner damit hierarchisch über den Teammitgliedern angesiedelt, da er über den Erfolg oder Misserfolg eines Sprints entscheiden kann. In der Praxis wird diese Hierarchie oft aufgeweicht.

Teammitglied

Da Scrum aus dem Software Development stammt, wurde diese Rolle im ursprünglichen Modell als Entwickler bezeichnet. Für die Übertragbarkeit auf andere Branchen eignet sich der weniger spezifische Begriff “Teammitglied” jedoch besser.

Teammitglieder sind gleichberechtigt. Das Team organisiert die Zuteilung der Aufgaben mithilfe verschiedener Methoden. In einem Scrum-Team sind idealerweise alle Abteilungen vertreten, die für den Erfolg des Projekts notwendig sind. Zudem sollten das Team seine Arbeitsschritte eigenständig entscheiden können.

Scrum Master

Der Scrum Master ist für den reibungslosen Ablauf des Prozesses verantwortlich. Insbesondere wenn das Unternehmen noch wenig Erfahrung mit agilem Projektmanagement hat, hat der Scrum Master große Verantwortung. Er muss den Prozess anleiten und seinen Ablauf ermöglichen. Er tritt im Team als Moderator auf und hat keine Weisungsbefugnis.

Stakeholder

Stakeholder sind externe Stellen, die jedoch ein Interesse am Erfolg des Projekts haben. Erster Ansprechpartner für die Stakeholder ist der Product Owner, der aus den Anforderungen und Wünschen der Stakeholder das Backlog für das Produkt zusammen stellt. Stakeholder können sowohl real existierende Personen als auch Personas sein.

Einige Stakeholder sind:

• Management: Hilft dabei, den Prozess erfolgreich zu gestalten. Dazu gehört die Bereitstellung von Räumlichkeiten und Geldmitteln.
• Kunden: Haben Interesse am erfolgreichen Abschluss des Projekts. Ihnen steht das Produkt am Ende zur Verfügung. Die Wunschvorstellung des Kunden sollte maßgeblich für die Erstellung der Projektanforderungen sein.
• Anwender: Diejenigen, die das Produkt schlussendlich nutzen. Nicht immer sind Anwender direkt am Scrum-Prozess beteiligt. Daher ist es essentiell, die Anforderungen dieser Gruppe zu berücksichtigen.

Ereignisse in Scrum

Der Prozess wird iterativ gestaltet. Dabei legt das Team einen Zyklus fest, in welchem bestimmte Zielstellungen erreicht werden sollen. Je nach Gesamtdauer des Projekts wiederholen sich innerhalb dieses Zyklus bestimmte Ereignisse. Das Ziel dieses Ansatzes ist es, durch kurze Dauer der Zyklen einen dynamischen Prozess zu erzeugen, bei dem das Team auf veränderte Anforderungen oder neue Herausforderungen reagieren kann. Die wiederkehrenden Zyklen bezeichnet man als Sprint.

Ein Sprint kann je nach Anforderung des Projekts unterschiedlich lang sein. Üblicherweise dauert ein Sprint zwischen einer und vier Wochen. Sprints sollten während des gesamten Projekts die gleiche Länge haben, um dem Projekt einen Rhythmus zu verleihen.

Im Laufe eines Sprints werden bestimmte Ereignisse abgehalten:

• Sprint Planning
• Daily Scrum
• Sprint Review
• Retrospektive

Sprint Planning

In dieser Phase, die am Anfang eines Sprints steht, werden die Ziele für den aktuellen Zeitraum festgelegt. Dazu sondiert das Team das Product Backlog. Aus diesen Anforderungen erstellt es das den Sprint Backlog, eine Liste von Aufgaben, die während des aktuellen Zyklus erledigt werden können. Darüber hinaus legen Teammitglieder fest, wie die Ziele erreicht werden. Dazu stehen verschiedene Methoden, etwa das Planning Poker, zur Verfügung.

Ein Sprint Planning sollte max. zwei Stunden pro Woche, die der Zyklus dauert, in Anspruch nehmen. Wenn ein Sprint zwei Wochen dauert, entfallen also vier Stunden auf das Sprint Planning.

Daily Scrum

Die Teammitglieder tauschen sich zu Beginn eines Arbeitstags beim Daily Scrum über den Fortschritt des Projekts aus. Ziel ist es dabei, dass alle Teammitglieder im Bilde sind, was den Stand des Sprints betrifft. Üblich ist es, dass Teammitglieder skizzieren, welche Ziele für den Tag haben und welche Hindernisse sie auf dem Weg identifizieren.

Beim Daily Scrum werden keine Entscheidungen getroffen, die den Ablauf des Sprints beeinflussen.

Sprint Review

Im Sprint Review stehen die Erfolge des Sprints auf dem Prüfstand. Wichtig ist dabei, dass Stakeholder einbezogen werden. Die am Ende eines Sprints stehenden Änderungen am Produkt können nämlich beispielsweise alle Anforderungen erfüllen, aber trotzdem für Stakeholder nicht nutzbar sein.

Der Dialog mit den Stakeholdern führt dazu, dass Anforderungen im Backlog angepasst oder präzisiert werden. Aufgrund dieses Feedbacks entscheidet der Product Owner, ob die Änderungen am Produkt akzeptiert werden oder eine weitere Anpassung nach neuen Anforderungen erforderlich ist. Das Review sollte eine Stunde pro Sprint-Woche nicht überschreiten.

Sprint Retrospektive

Die Retrospektive schließt einen Sprint-Zyklus ab. Dabei evaluiert das Team den Prozess im abgelaufenen Sprint. Ziel ist es, die Effizienz zu steigern. Wurden bspw. viele der gesteckten Ziele nicht erreicht, sind für den nächsten Sprint weniger ambitionierte Ziele angemessen.

Bei der Retrospektive ist eine offene Gesprächsatmosphäre wichtig. Alle Beteiligten sollten ihre Meinung frei äußern können, insbesondere dann, wenn Kritik geübt wird.

Die Ergebnisse der Retrospektive können im Sprint Backlog dokumentiert werden. Pro Sprintwoche sollten max. 45 Minuten auf die Retrospektive entfallen.

Scrum-Artefakte

Bestimmte Dinge, die für den Prozess von Bedeutung sind, werden Scrum Artefakte genannt. Dabei handelt es sich teils um Dokumente, teils um Objekte des tatsächlichen Entwicklungsprozesses.

Product Backlog

Das zentrale Dokument für den Entwicklungsprozess ist das Product Backlog. Hier werden die zentralen Anforderungen an das fertige Produkt dokumentiert. Dabei ist das Backlog nicht statisch, sondern wird dynamisch weiterentwickelt. Der Product Owner hat die Herrschaft über das Product Backlog, nimmt Änderungen vor und priorisiert die Einträge.

Wie genau die Anforderungen formuliert sind und priorisiert werden, ist nicht festgelegt. Eine Reihe von Techniken steht zur Verfügung, um das Product Backlog zu verwalten.

Sprint Backlog

Im Rahmen des Sprint Plannings bestimmt das Team aus den Einträgen im Product Backlog die Ziele für den aktuellen Sprint. Diese werden im Sprint Backlog hinterlegt. Im Laufe des Sprints, z. B. beim Daily Scrum, werden die aktuellen Entwicklungen im Sprint Backlog dokumentiert. Als Visualisierung des Fortschritts stehen verschiedene Methoden zur Verfügung. Weit verbreitet ist es, das Sprint Backlog als Kanban-Tafel zu dokumentieren.

Inkrement

Damit ist die Erweiterung des Produkts gemeint, welche im aktuellen Sprint entwickelt wird. Je nach Branche kann es sich beim Inkrement um ein physisches Objekt handeln, aber auch um ein immaterielles Objekt wie etwa ein Software-Update.

Das Inkrement stellt das Ergebnis eines erfolgreichen Sprints dar und sollte für seinen Zweck einsetzbar sein. Trifft dies nicht zu, bietet die Sprint-Retrospektive die Möglichkeit, den Prozess zu optimieren.

Scrum ist ein ganzheitlicher Prozess

Scrum ist mehr als nur ein Schlagwort: Es handelt sich um eine Art, Projekte umzusetzen, die tief im Selbstverständnis verwurzelt sein muss. Eine hierarchisch organisierte Firma, die nur aus Trendgründen auf Scrum baut, wird wahrscheinlich Probleme haben.

Der Grund liegt darin, dass die Zusammenarbeit in großen Teilen ohne Hierarchien angelegt ist. Firmen, die auf eine hierarchische Organisation bauen, werden Rollenkonflikte beim Scrum-Prozess erleben.

Daher ist die Umsetzung von Scrum als Projektmanagement-Methode nur möglich, wenn Agilität bereits Teil der Unternehmensphilosophie ist. Scrum ist keine Methode, die einem Team übergestülpt werden kann, sondern muss ganzheitlich umgesetzt und im Unternehmen gelebt werden.

 

Bildnachweise

Titelbild: #270246232 | © Rassco – stock.adobe.com
Rugby-Scrum: #128757326 | © Jack – stock.adobe.com
Scrum Master: #365005545 | © metelevan – stock.adobe.com
Scrum-Team: #433873633 | © SpicyTruffel – stock.adobe.com
Scrum-Board: #303430811 | © Berk – stock.adobe.com