Kategorien: Agilität, Methoden|

Wer sich auf den agilen Weg begeben möchte, wird eher früher als später auf die Scrum Methode stoßen. Diese ist einer der populärsten Ansätze aus der agilen Welt. Ursprünglich für die Softwareentwicklung konzipiert, findet die Scrum Methode mittlerweile weit über diese Grenzen hinaus Anwendung. Denn sie kann dabei helfen, den Herausforderungen vieler Projekte zu begegnen: Volatilität, Ungewissheit, Komplexität und Ambiguität (VUKA).

Definition von Scrum

Scrum wurde bereits 1995 von Ken Schwaber und Jeff Sutherland erstmalig vorgestellt, die in ihrem Scrum Guide folgende Definition formuliert haben:

„[Scrum ist] 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 höchstmöglichem Wert auszuliefern.

Scrum ist:

  • Leichtgewichtig
  • Einfach zu verstehen
  • Schwierig zu meistern“

Bei der Scrum Methode handelt es sich nicht um eine holistische Projektmanagement-Methode, sondern um ein Framework, das in Form von Rollen, Ereignissen und Artefakten leitende Pfeiler für das agile Teammanagement in komplexen Projekten setzt.


Die Scrum Methode baut auf den agilen Werten auf und wird empirisch, also aus Erfahrungen lernend, iterativ und inkrementell umgesetzt. Ein Gesamtprodukt besteht aus mehreren Teilprodukten (Inkrementen). Diese werden, in sich wiederholenden Etappen, sogenannten Iterationen, erstellt, überprüft und gegebenenfalls angepasst.

Die agilen Werte der Scrum Methode

Als agiles Framework setzt Scrum die Einhaltung der agilen Werte voraus. Damit ein Scrum-Team erfolgreich arbeiten kann, sollte es selbst und idealerweise alle Stakeholder die folgenden Werte leben:

  • Offenheit: Das Scrum-Team und alle Stakeholder gehen offen mit ihrem Arbeitsfortschritt und mit Hindernissen und Problemen um.

  • Commitment: Jedes Mitglied des Scrum-Teams verpflichtet sich zu dem Ziel des Teams. Das Team ist immer gemeinsam verantwortlich.

  • Fokus: Das Team fokussiert sich auf die Erreichung des gemeinsamen Ziels, auf die Maximierung des Produktwerts und damit des Kund*innennutzen

  • Respekt: Die Mitglieder des Scrum-Teams respektieren sich gegenseitig und bewegen sich auf Augenhöhe.

  • Mut: Das Scrum-Team hat den Mut, seinen Weg zu gehen, alles im Sinne des Kund*innennutzen zu tun und auch schwierige Aufgaben zu bearbeiten.

Die Scrum Rollen

Ein Scrum Team besteht aus einem Product Owner, dem Entwicklungsteam und dem Scrum Master. Das Team arbeitet immer selbstorganisiert und ist dazu auch befähigt. Durch die cross-funktionale Zusammensetzung des Teams sind alle Kompetenzen, um eigenständig und eigenverantwortlich arbeiten zu können, vorhanden. Befähigung bedeutet aber auch, dass das Team dazu autorisiert ist, Entscheidungen selbst zu treffen und diese zu verantworten.

Der Product Owner (PO) ist, wie der Name schon andeutet, für das Produkt und dessen Wertmaximierung verantwortlich. Er ist der Business-versierte im Team. Der PO verfolgt den größtmöglichen Business Value für das eigene Unternehmen sowie für die Kund*innen und versucht diese miteinander zu vereinen. Der PO hat das „Was?“ von der Grobplanung des Projekts bis hin zu jeder Anforderung im Blick und vermittelt und überwacht diese Ziele und die Produktvision. Dafür bildet er die Schnittstelle zum Kund*innen und muss durch enge Zusammenarbeit mit ihm ein tiefes Verständnis der Kund*innenbedürfnisse und Anforderungen entwickeln. Diese übersetzt er in Product Backlog Items und priorisiert sie mit dem Ziel des maximalen Business Value. Zu den wichtigsten Aufgaben eines Product Owners zählen also:

  • Erfassung der Kund*innen bedürfnisse
  • Formulierung der Anforderungen (Product Backlog Einträge)
  • Detaillierung und Priorisierung der Product Backlog Einträge
  • Sicherstellung und Überprüfung der Umsetzung von Anforderungen

Das Entwicklungsteam besteht aus drei bis neun Mitgliedern, die jede Fachexpertise abdecken, die für die Umsetzung des Projekts benötigt wird. Es ist für die Umsetzung der Items aus dem Product Backlog sowie die eigentliche Lieferung des Produktes verantwortlich. Die Items haben sie zu Beginn des Sprints gemeinsam beschlossen Der PO hat dabei zwar durch die Priorisierung der Backlog Items und der gemeinsamen Auswahl des Sprintziels Einfluss darauf, was das Entwicklungsteam bearbeitet, jedoch nicht, wie es diese Aufgaben bewältigt. Das Entwicklungsteam organisiert sich und ihre Arbeitsweise selbst. Ein ideales Scrum Entwicklungsteam versteht sich als Einheit und verpflichtet sich als gesamtes Team zu ihrer Aufgabe. Dabei gibt es keine Titel oder Hierarchien unter den Entwicklern und jedes Teammitglied ist gleichermaßen für alles verantwortlich. Der Aufgabenbereich des Entwicklungsteams lässt sich wie folgt zusammenfassen:

  • Umsetzung der Product Backlog Einträge
  • Lieferung eines Produktes, das allen Kund*innen- und Qualitätsanforderungen entspricht
  • Selbstorganisation der Zusammenarbeit

Der Scrum Master coacht als dienender Anführer („Servant Leader“) das Entwicklungsteam und den Product Owner. Ziel ist es einen reibungslosen Ablauf des Projekts zu ermöglichen. Dazu beseitigt er Hindernisse und stellt sicher, dass die Scrum Theorie und Regeln eingehalten werden. Außerdem schirmt er das Team vor störenden Einflüssen von außen ab. Z.B. indem er für ein besseres Verständnis von Scrum in der Organisation und bei anderen beteiligten Stakeholdern sorgt. Als Servant Leader hat er dabei keine Weisungsbefugnis, sondern macht auf Missstände aufmerksam und schlägt Anregungen und Lösungswege vor. Ein guter Scrum Master sieht sich für folgende Aufgaben verantwortlich:

  • Unterstützung des Entwicklungsteams und Product Owners bei der Umsetzung des Projekts
  • Beseitigung von Hindernissen aller Art
  • Sicherstellung der Umsetzung der Scrum Methode
  • Vermittlung der Scrum Methode an Stakeholder und Entwicklung in der gesamten Organisation

Die Scrum Ereignisse

Das Scrum Framework definiert einige Scrum Ereignisse, die regelmäßig, zielgerichtet und zeitlich begrenzt terminiert stattfinden. Weitere Besprechungen oder Meetings neben den klassischen Scrum Ereignissen sollten möglichst vermieden werden. Der Sprint ist der Kern des Prozesses und umfasst alle weiteren Scrum Ereignisse: Sprint Planning, Daily Scrum, Sprint Review und Retrospektive.

Der Sprint

Als Sprint bezeichnet man eine zeitliche begrenzte Iteration. Ziel ist es, innerhalb eines Sprints die definierten Items abzuarbeiten bzw. zu entwickeln. Ein Sprint dauert eine bis maximal vier Wochen. Die Dauer des Sprints wird je nach Projekt individuell bestimmt. So soll in einem komplexen und volatilen Projekt das Risiko minimiert werden. Die Länge eines Sprints sollte über die gesamte Projektlaufzeit vom Projektteam konsistent gehalten werden. Da ein Sprint auch die vor- und nachbereitenden Tätigkeiten der eigentlichen Entwicklungsarbeit beinhaltet, folgt auf einen Sprint nahtlos der nächste. Während eines Sprints werden keine Änderungen am Sprintziel vorgenommen und keine Qualitätsschmälerungen vorgenommen. Wird deutlich, dass das Sprintziel hinfällig geworden ist, kann ein Sprint abgebrochen werden. Hat das Projektteam die Umsetzung eines oder mehrerer Items, innerhalb des Sprints zeitlich nicht geschafft, schiebt es  diese(s) zurück in das Backlog. Der Sprint wird in diesem Fall nicht verlängert.

Sprint Planning

Jeder Sprint beginnt mit einem Sprint Planning. Dabei schätzt das Entwicklungsteam auf Grundlage des priorisierten Product Backlogs (dem Item- oder Aufgabenspeicher), wie viele Items im aktuellen Sprint umgesetzt werden können. Im Anschluss wählen sie die Items mit der höchsten Priorität, die sinnvoll zu einem Produktinkrement zusammengesetzt werden können. Daraus definiert das Scrum Team das Ziel für den aktuellen Sprint. Im Anschluss erstellt das Entwicklungsteam das Sprint Backlog und legt fest, welche Aufgaben je Backlog Item zu erledigen sind. Für einen vierwöchigen Sprint beträgt die maximale Dauer des Plannings acht Stunden.

Daily Scrum

Das Daily Scrum findet täglich zu einer festen Uhrzeit statt. Es dient vor allem dem Entwicklungsteam, Transparenz und eine gute Kommunikation zu schaffen und die Aufgaben untereinander zu koordinieren. Jedes Mitglied des Entwicklungsteams beantwortet knapp die folgenden drei Fragen:

  1. Was hast du seit dem letzten Daily Scrum geschafft?
  2. Was willst du bis zum nächsten Daily Scrum tun?
  3. Welche Hindernisse standen/ stehen dir im Weg?

Rückfragen und Diskussionen sollen im Daily Scrum vermieden werden und im Nachgang stattfinden. Die maximale Dauer beträgt 15 Minuten.

Sprint Review

Zum Abschluss des Sprints findet ein Review statt. Dabei handelt es sich um ein informelles Meeting des Scrum Teams, der Kund*innen und weiterer interessierter Stakeholder. Das bedeutet, dass je nach Projekt, zu unterschiedlichen Review Terminen auch unterschiedliche Personen teilnehmen können. Im Review präsentiert und überprüft man das Ergebnis des Sprints, also das Produktinkrement. Das Treffen ermöglicht einen offenen Austausch zwischen allen Beteiligten und stärkt die Zusammenarbeit mit den Kund*innen. Änderungen und neue Anforderungen werden in das Product Backlog aufgenommen. Für einen einmonatigen Sprint reicht ein vierstündiges Review.

Sprint Retrospektive

Als letztes Ereignis eines Sprints wird die Retrospektive abgehalten. Dieses Meeting ist ausschließlich für das Scrum Team angesetzt, um die Zusammenarbeit des Sprints zu reflektieren. Dabei soll kritisch betrachtet und offen angesprochen werden, ob und was in Bezug auf die beteiligten Personen, Beziehungen, Prozesse und Werkzeuge im nächsten Sprint verbessert werden kann und welche Maßnahmen dafür getroffen werden müssen. Je Sprintwoche beträgt die Dauer 45 Minuten. Mehr Informationen zur Retrospektive haben wir in unserem Artikel Methoden Retrospektive festgehalten.

Scrum Artefakte

Neben den Rollen und den Ereignissen stellen die Artefakte die dritte wesentliche Säule der Scrum Methode dar. Die Artefakte lassen sich als Bausteine verstehen, die für die Scrum Methode verwendet werden. Sie stellen den Wertentstehungsprozess dar und dienen in Scrum als transparente Dokumentation.

Product Backlog

Das Product Backlog ist eine geordnete Liste aller Anforderungen, die an das Gesamtprodukt gestellt werden. Die Verantwortung liegt in den Händen des Product Owners. Es ist ein dynamisches Artefakt, da man im Laufe des Projekts ständig neue Funktionalitäten, Verbesserungen, o.ä. aufnimmt oder streicht. Das Product Backlog ist somit nie vollständig und entwickelt sich über die Projektlaufzeit. Die Items werden, je höher ihre Priorität wird, verfeinert, sodass sie für das Entwicklungsteam klar verständlich für den nächsten Sprint bereitstehen. Items werden in Form von User Stories („Als möchte ich <Funktionalität>, um zu erreichen“) formuliert. Das Entwicklungsteam schätzt den Umsetzungsaufwand einer User Story anhand von Story Points.

Das Sprint Backlog

Das Sprint Backlog besteht aus Items aus dem Product Backlog.

Alle Items die im aktuellen Sprint bearbeitet werden, werden im Sprint Backlog dokumentiert. Das Sprint Backlog unterteilt sich in drei Spalten: Im Backlog/Doing/Done.

Dadurch ist zu jeder Zeit sichtbar, wer an welchem Item arbeitet und wie der aktuelle Stand ist.

Man darf einen Task erst auf Done setzen, wenn dieser der „Definition of Done“ entspricht. Dabei handelt es sich um eine Art Checkliste, die nichtfunktionale Anforderungen, z.B. auch Qualitätsanforderungen, die für das gesamte Produkt gelten, festhält. Das Sprint Backlog ist ein Werkzeug des Entwicklungsteam und steht daher in dessen Verantwortung.

Produktinkrement

Das Produktinkrement, ist das Ergebnis aller User Stories aus einem Sprint. Daher setzt es sich wie ein Puzzle zusammen und ergibt nur im Gesamten ein Bild. Des Weiteren stellt auch einen Teil der Produktvision dar. Ein Inkrement sollte immer potenziell auslieferbar sein. Das heißt, es sollte ein in sich geschlossenes funktionierendes Teilprodukt sein, das testbar ist und zu dem man im Review Feedback geben kann. Es wird aber nicht zwangsläufig auch tatsächlich nach dem Sprint direkt ausgeliefert oder an die Kund*innen übergeben, weil es vielleicht allein im Sinne der Gesamtlösung noch keine sinnvoll einsetzbare Funktionalität darstellt.

Fazit – Scrum Methode verstehen ist der erste Schritt auf einem gewinnbringenden Weg

Die Scrum-Väter haben ihr Framework nicht umsonst als leicht verständlich, doch schwer zu meistern definiert. Zwar ist der Scrum Guide schnell gelesen und seine Essenz schnell verstanden, wer ihn dann im Unternehmen anwenden möchte, wird aber schnell viele Fragen haben, auf die das Scrum Framework keine Antwort gibt. Es lohnt sich trotzdem, sich auf die Scrum Reise zu begeben. Auch in sehr komplexen Projekten, in denen zu Beginn noch gar nicht ganz klar ist, wie das Endprodukt aussehen soll und die von sich ständig ändernden Rahmenbedingungen und Anforderungen geplagt sind, kann Scrum Großes bewirken. Nicht umsonst wird die Scrum Methode seit mittlerweile 25 Jahren erfolgreich eingesetzt.

Bei Scrum muss sich jeder individuell dazu entscheiden die Methode in seinem Projekt und seiner Organisation zu implementieren. Danach heißt es dann Step by Step und Trial & Error – in kleinen Schritten lernen, ausprobieren, Erkenntnisse machen. Aber das Schöne dabei ist: während man Scrum lernt, verhält man sich so schon ganz im Sinne von Scrum – empirisch, iterativ, inkrementell und vor allem mutig.

Inhaltsverzeichnis zeigen
Array

Inhaltsverzeichnis zeigen