Scrum-Methode Scrum Guide Scrum Vorgehensmodell
Stellen Sie sich vor: Es werden Projekte geplant und Zeitangaben dafür anvisiert, die leider nicht eingehalten werden können. Das führt zu Frustration auf beiden Seiten. Ein Ansatz ist: Wenn herkömmliche Methoden nicht funktionieren - warum es dann nicht mit etwas anderem versuchen? Die Scrum-Methode ist so ein Vorgehensmodell. Ursprünglich stammt die Scrum-Methode wie auch die Kanban-Methode aus der Softwareentwicklung. Wie sie funktioniert, lesen Sie hier...

Scrum-Methode: Mit Teamspirit zum Ziel

Scrum Definition Scrum Vorgehensmodell Scrum Bedeutung AbkürzungDer englische Begriff Scrum ist keine Abkürzung, sondern stammt aus dem Rugby und bedeutet übersetzt soviel wie "dichtes Gedränge". Das entsteht, wenn sich im Rugby die Spieler um den Ball versammeln.

Die Scrum-Methode kommt ursprünglich aus der Softwareentwicklung, wird aber mittlerweile als eine Methode im agilen Projektmanagement verwendet.

Die Rolle des Rugbys ist nicht unwichtig. Dahinter steckt der Gedanke, dass Produktentwicklung mit Einzelkämpfern den heutigen Anforderungen von Schnelligkeit und Flexibilität nicht gewachsen ist. Wenn hingegen ein Team versucht, Wege als Einheit zurückzulegen und dabei den Ball hin- und herspielt, könnte das zum Erfolg führen.

Obwohl die Anfänge der Scrum-Methode sich bis in die achtziger Jahre zu den beiden Wirtschaftstheoretikern Ikujirō Nonaka und Hirotaka Takeuchi zurückverfolgen lassen, waren es Ken Schwaber und Jeff Sutherland, die 1995 auf der OOPSLA, einer jährlich abgehaltenen Forschungskonferenz, erstmals eine Definition von Scrum lieferten. Demnach ist Scrum:

Ein Rahmenwerk, innerhalb dessen Menschen komplexe adaptive Aufgabenstellungen angehen können, und durch das sie in die Lage versetzt werden, produktiv und kreativ Produkte mit dem höchstmöglichen Wert auszuliefern.
Scrum ist:

  • Leichtgewichtig
  • Einfach zu verstehen
  • Schwierig zu meistern

Scrum-Methode: Selbstorganisation statt Regeln

In der Scrum-Methode existieren nur wenige Regeln; die Hauptsache ist, dass das Team sich selbst organisieren kann und sich interdisziplinär zusammensetzt, damit möglichst viele Kompetenzen abgedeckt werden. Darüber hinaus gestaltet sich Scrum folgendermaßen: Es gibt Aktivitäten, die sich auf drei Rollen und drei Artefakte aufteilen.

Scrum funktioniert empirisch, inkrementell und iterativ, das heißt, die Anwendung erfolgt aufgrund von Erfahrungen, in kleinen Schritten und sich wiederholenden Etappen. Die Projektlaufzeit des Scrum Prozesses wird in sogenannte Sprints eingeteilt, die zwischen zwei und maximal vier Wochen dauern können.

Ein Sprint besteht aus:

  • Sprint Planning,
  • Daily Scrums,
  • Sprint Review und
  • Sprint Retrospektive.

Am Ende eines jeden Sprints wird ein funktionsfähiges Produkt (Done) dem Auftraggeber vorgelegt. Seine Rückmeldungen dazu bilden die Grundlage weiterer Überarbeitungen.

Die drei Rollen für direkt am Prozess Beteiligte sind:

  • Product Owner

    Er steht stellvertretend für die Anwender des Produkts oder die Stakeholder des Projekts. Im Falle einer Software wären das beispielsweise die Nutzer, die sich einen reibungslosen Ablauf wünschen. Im Falle eines Produktes sind es die Produktmanager, die ihre Kunden repräsentieren.

  • Team

    Das Team organisiert sich selbst, es braucht schon aufgrund seiner geringen Größe (zwei bis neun Teammitglieder) keinen klassischen Projektleiter. Daher erhält es keinerlei Vorschriften, wie es vorzugehen hat. Aufgrund seines interdisziplinären Aufbaus finden sich dort Software-Architekten ebenso wie beispielsweise Programmierer, Qualitätssicherer und Tester.

  • Scrum Master

    Er übernimmt die Funktion eines Moderators. Das bedeutet, dass er dafür sorgt, dass im Team die Theorie, die Praktiken und die Regeln der Scrum-Methode eingehalten werden. Außerdem ist er Ansprechpartner für Außenstehende, indem er klärt, welche Interaktionen mit dem Team förderlich sind und welche nicht.

Die Scrum-Methode beinhaltet vier Ereignisse, die unterschiedliche Formen von Meetings darstellen und eine zeitliche Beschränkung (Time Box) haben:

  • Sprint Planning

    Im Sprint Planning plant das Team den nächsten Sprint. Dabei werden die Anforderungen in konkrete Aufgaben (Tasks) zerlegt. Diese sollten innerhalb eines Tages bearbeitet werden können. Großer Wert wird hier auf effiziente Kommunikation gelegt; die wird "Face-to-Face" und keinesfalls lediglich durch Übergabe von Dokumenten praktiziert. Das Ergebnis des Sprint Planning ist der Sprint Backlog.

  • Daily Scrum

    Zu Beginn eines jeden Arbeitstages trifft sich das Team zu einem maximal viertelstündigen Meeting, dem Daily Scrum. Es wird bevorzugt im Stehen abgehalten, da dies die Konzentration auf wichtige Punkte fördern soll. Einmal am Tag wird so der Austausch mit allen Teammitgliedern gewährleistet. Jedes Teammitglied erläutert kurz seinen Stand der Dinge:

    • Was wurde seit dem letzten Meeting erledigt?
    • Was wird bis zum nächsten Meeting geplant?
    • Welche Hindernisse/Probleme behindern das Vorankommen?

    Probleme, die sich nicht innerhalb einer Viertelstunde lösen lassen, werden an den Scrum Master übergeben. Daily Scrum ist ein wesentliches Mittel zur Reflexion und Selbstorganisation des Teams.

  • Sprint Review

    Am Ende eines jeden Sprints steht eine Sprint Review. Hier präsentiert das Entwicklungsteam das Produkt-Inkrement (im Sinne von "Done"). Dabei wird das Produkt überprüft und der Product Backlog gegebenenfalls angepasst. Der Product Owner ebenso wie die Stakeholdern können Input geben, allerdings obliegt die letzte Entscheidung darüber, ob Anforderungen verändert werden, dem Product Owner.

  • Sprint Retrospective

    Bei der Retrospektive geht es um eine Überprüfung der Arbeit des Projektteams, um sie kontinuierlich zu verbessern. Zentrale Fragen sind hier beispielsweise:

    • Was hat die Zusammenarbeit behindert?
    • Was war besonders förderlich für die Zusammenarbeit?
    • Welche neuen Ansätze sollten stärker berücksichtigt werden?

Bei den Scrum Artefakten handelt es sich um drei Dokumente, die im Wesentlichen der Transparenz dienen:

  • Product Backlog

    Das Product Backlog ist eine To-Do-Liste mit Anforderungen (Requirements). Es wird ständig weiter enwickelt und vom Product Owner geführt. Da das Product Backlog dynamisch ist, ist es niemals vollständig - der Product Owner passt es ständig an das Produkt an.

  • Sprint Backlog

    Aus den Anforderungen des Product Backlogs wird eine Auswahl an Anforderungen getroffen, die das Team innerhalb eines Sprints bearbeitet wird. Die einzelnen Aufgaben im Sprint Backlog werden Tickets genannt. Jedes Teammitglied übernimmt die Verantwortung für ein eigenes Ticket. Das Sprint Backlog gibt eine Prognose darüber inwieweit das nächste Inkrement funktionstüchtig sein wird beziehungsweise, welche Arbeit noch notwendig ist, um ein funktionsfähiges Done liefern zu können. Hier wird zur besseren Visualisierung oft mit dem Kanban-Board gearbeitet.

  • Product Increment

    Am Ende jedes Sprints steht ein funktionsfähiges Zwischenprodukt – das Produktinkrement. Es muss auch dann einsatzfähig sein, wenn der Product Owner es noch nicht ausliefern will.

Der große Vorteil der Scrum-Methode ist, dass sie mit wenig Hilfsmitteln und geringem Aufwand zu betreiben ist. Ungeeignet hingegen ist sie für Branchen, in denen es auf eine umfangreiche Dokumentation ankommt oder bei denen Leben in Gefahr wäre - so beispielsweise bei militärischer oder pharmazeutischer Software-Entwicklung.

[Bildnachweis: Karashaev by Shutterstock.com]