Erfolgreich komplexe Projekte mit Scrum umsetzen.

In unserem Artikel über die Scrum Methode erklären wir den Begriff und die Herkunft und beschreiben, welche Rollen, Events und Artefakte das Scrum Framework besitzt.

Was ist die Scrum Methode?

Die Scrum Geschichte

WAS IST DIE SCRUM METHODE?

Die Geschichte der Scrum Methode beginnt 1986. In diesem Jahr führten zwei japanische Wirtschaftsexperten den Begriff im Zusammenhang mit der Produktentwicklung ein. Hirotaka Takeuchi und Ikujiro Nonaka veröffentlichten in der Harvard Business Review den Artikel New New Product Development Game (das doppelte "Neu" ist tatsächlich Teil des Titels). Die Autoren beschreiben darin einen neuen Ansatz für die kommerzielle Produktentwicklung, der die Geschwindigkeit und Flexibilität erhöht. Inspiriert wurden sie durch Fallstudien von Herstellerfirmen aus der Automobil-, Kopierer- und Druckerindustrie.

Das erste Scrum-Projekt wurde 1993 von Jeff Sutherland ins Leben gerufen. In Zusammenarbeit mit Ken Schwaber definierte Sutherland 1995 die Scrum Methode schließlich als formalen Prozess. Seitdem ist Scrum immer weiter verfeinert und verbessert worden. Die aktuelle Stand der Scrum Methode ist im offiziellen Scrum Guide beschrieben. Im Jahr 2001 trafen sich Sutherland und Schwaber zusammen mit mehreren Pionieren des agilen Denkens in einem Skigebiet in Utah, um Gemeinsamkeiten in agilen Methoden zu bewerten. Das Agile Manifest entstand aus dem Konsens dieser Gruppe heraus und ist bis heute die Grundlage agiler Arbeit und agiler Frameworks.

Was ist Scrum?

WAS IST DIE SCRUM METHODE?

Scrum ist ein von Jeff Sutherland und Ken Schwaber entwickeltes agiles Framework, das es Teams in einem komplexen Umfeld ermöglicht, gleichzeitig kreativ und produktiv Produkte mit dem höchstmöglichen Wert zu entwickeln. Es hilft Teams dabei, aus Erfahrungen zu lernen, die Zusammenarbeit selbst zu organisieren und sich kontinuierlich zu verbessern. Während Scrum ursprünglich vor allem im Rahmen der Softwareentwicklung eingesetzt wurde, wird es mittlerweile in den unterschiedlichsten Bereichen, wie z.B. Forschung & Entwicklung, Marketing oder Vertrieb verwendet.

Der Name "Scrum" geht ursprünglich auf einen englischen Slang-Begriff zurück und bedeutet "Menschenauflauf" oder "Gedränge". Gleichzeitig steht der Begriff "Scrum" auch für einen bestimmten Spielzug im Rugby-Sport. Die beiden Autoren des oben bereits angesprochenen Artikels "New New Product Development Game" Hirotaka Takeuchi und Ikujiro Nonaka sind Fans der Sportart Rugby und nannten die im Artikel vorgestellten Vorgehensweisen den "Rugby-Approach". Für den "Rugby-Approach" müssen laut Takeuchi und Nonaka 6 Bedingungen erfüllt sein: "Built-in instability", "Self-organizing project teams", "Overlapping development phases", "Multilearning", "Subtle control" sowie "Organizational transfer of learning". Als Jeff Sutherland und Ken Schwaber Scrum schließlich als formalen Prozess definierten, bezogen sie sich bei dem Namen "Scrum" auf den Artikel von Takeuchi und Nonaka.

Was macht Scrum aus?

WAS IST DIE SCRUM METHODE?

Scrum soll dabei helfen, Komplexität zu beherrschen. Daher beruht Scrum auf Emergent Practice. Emergent Practice wiederum basiert auf den 3 Säulen Transparenz, Kontrolle und Anpassung. Das Scrum Framework kennt verschiedenen Rollen, Events und Artefakte. Die Rollen, Events und Artefakte existieren, um Emergent Practice zu ermöglichen. Scrum kennt nur wenige Regeln und ist sehr leichtgewichtig. Dies führt dazu, dass Scrum zwar einfach zu verstehen, aber schwierig zu beherrschen ist. Es geht bei Scrum nicht darum, Regeln und Prozesse stumpf zu befolgen, sondern darum, bei allem, was man tut, agil zu denken und zu handeln. Damit Scrum funktionieren kann, ist es daher zwingend notwendig, dass ein Scrum Team den Sinn hinter Scrum verstanden hat. Dabei können die 4 Werte des agilen Manifests sowie die 5 Scrum Werte helfen.

Die 4 Werte des agilen Manifests lauten:

  1. Individuals and interactions over processes and tools.
  2. Working software over comprehensive documentation.
  3. Customer collaboration over contract negotiation.
  4. Responding to change over following a plan.

Die 5 Scrum Werte sind:

  • Fokus
  • Commitment
  • Mut
  • Offenheit
  • Respekt

Iterativ und inkrementell

WAS IST DIE SCRUM METHODE?

Da langfristige Planungen und Vorhersagen in einem komplexen Umfeld unmöglich sind, verwendet Scrum einen iterativen und inkrementellen Ansatz:

Iterativ bedeutet, dass ein Produkt schrittweise entwickelt, getestet und ausgeliefert wird, um so früh wie möglich Kundenfeedback zu erhalten. Es steht im Gegensatz zum klassischen Wasserfallmodell, in dem die einzelnen Projektphasen, wie z.B. Konzept, Design, Entwicklung und Testing, lediglich einmal nacheinander durchlaufen werden. Beim iterativen Vorgehen werden diese Phasen dagegen während jeder Iteration immer und immer wieder durchlaufen.

Inkrementell bedeutet, dass das entwickelte Produkt nicht einmal, typischerweise am Ende des Wasserfallprozesses, sondern laufend, nämlich am Ende jeder Iteration, ausgeliefert wird. Dadurch kann viel früher Feedback der Kunden gewonnen werden, was wiederum in die weitere Entwicklung des Produkts einfließen kann.

Durch iterative und inkrementelle Entwicklung kann Scrum das Risiko von Fehlschlägen minimieren und die gleichzeitig die Kundenzufriedenheit maximieren.

Scrum Rollen

WAS IST DIE SCRUM METHODE?

Scrum Master

Jedes Scrum Team benötigt einen Scrum Master. Seine Aufgabe ist es, dafür zu sorgen, dass der Scrum Prozess eingehalten und tatsächlich gelebt wird. Er hilft Personen innerhalb und außerhalb des Scrum Teams dabei, die Theorie und Praktiken sowie die Regeln und Werte von Scrum zu verstehen und anzuwenden. Als Servant Leader unterstützt der Scrum Master das Development Team dabei, den Scrum Prozess zu verstehen und zu befolgen, kollaborativ und professionell zusammenzuarbeiten und sich kontinuierlich zu verbessern. Er hilft außerdem dem Product Owner dabei, das Product Backlog zu pflegen und sicherzustellen, dass das Development Team zu jeder Zeit den höchstmöglichen Wert für den Kunden schafft. Außerdem schafft er ein Gleichgewicht zwischen den Interessen des Product Owners, wie z.B. möglichst schnell möglichst viele neue Features zu entwickeln, und den Interessen des Development Teams, wie z.B. benötigtes Know-how aufzubauen. Der Scrum Master ist eine essenzielle Rolle und für den Erfolg der Scrum Methode unerlässlich.


Product Owner

Die wichtigste Aufgabe des Product Owners besteht darin, den Wert der Arbeit des Development Teams zu maximieren. Sein Werkzeug dafür ist das Product Backlog. Das Product Backlog enthält alle Anforderungen an das Produkt, die der Product Owner definiert hat. Um die Anforderungen zu definieren und zu sortieren, tauscht er sich regelmäßig mit Stakeholdern und Kunden aus. Er wägt alle Vorschläge und Wünsche ab und entscheidet, ob und wie diese in das Product Backlog einfließen. Der Product Owner ist die zentrale Anlaufstelle für alle Anforderungen an das Produkt.

Er ist die einzige Person, die entscheidet, an was das Development Team als nächstes arbeitet. Er stellt sicher, dass das Development Team den Sinn und Zweck der Anforderungen versteht und beantwortet alle Fragen, die das Development Team hat. Er hat aber keinen Einfluß darauf, wie das Development Team seine Anforderungen umsetzt. Dies unterscheidet ihn z.B. vom klassischen Projektmanager.


Development Team

Das Development Team ist ein cross-funktionales Team, das aus 3-9 Personen besteht und über alle Kompetenzen verfügt, um die Anforderungen, die der Product Owner im Product Backlog definiert hat, von Anfang bis Ende (End-2-End) umzusetzen. Bei weniger als 3 Personen ist der Aufwand für den Scrum Prozess im Verhältnis zu dem Wert, den das Team schaffen kann, zu hoch. Bei mehr als 9 Personen wird wiederum der Aufwand für die Organisation der Arbeit und die Kommunikation im Team zu groß. Außerdem entsteht die Gefahr der Bildung von Sub-Teams. Bei Scrum ist allerdings das Development Team immer als Ganzes für die Entwicklung, Qualität und Auslieferung der Produktinkremente verantwortlich. Es gibt nicht nur keine Sub-Teams, sondern auch keine Titel für die einzelnen Mitglieder des Development Teams. Das Development Team ist außerdem ein selbstorganisiertes Team. Dies bedeutet, dass das Development Team selbst dafür verantwortlich ist, die Regeln für die Zusammenarbeit im Team zu definieren. Der Scrum Master unterstützt das Team dabei und achtet darauf, dass der Scrum Prozess eingehalten wird. Das Development Team arbeitet an Anforderungen, die der Product Owner im Product Backlog definiert hat. Das Development Team entscheidet aber selbst, wie es diese umsetzt.

Jedes Scrum Team besteht aus einem Scrum Master, einem Product Owner und dem Development Team.

Scrum Events

WAS IST DIE SCRUM METHODE?

Sprint

Ein Sprint ist der Rahmen für eine Iteration, in der ein funktionierendes und potentiell auslieferbares Product Increment entwickelt wird. Ein Sprint hat eine Dauer von ein bis vier Wochen. Bei einer Dauer von weniger als einer Woche ist der Aufwand für den Scrum Prozess im Verhältnis zu dem Wert, den das Team schaffen kann, zu hoch. Bei einer Dauer von mehr als vier Wochen besteht die Gefahr, dass keine klares Ziel mehr vorhanden ist, auf das das Development Team hin arbeitet. Die Abstände zwischen den Sprint Review Events werden größer und das Development Team erhält zu selten Feedback zu den von ihm entwickelten Product Increments. Die Länge der Sprints sollte bei einem Scrum Team möglichst konstant bleiben, da ein Development Team über die Zeit lernt, sich die Arbeit für einen Sprint bestmöglich zu organisieren. Jede Änderung an der Länge der Sprints wird ein Scrum Team daher etwas zurückwerfen.


Der neue Sprint beginnt unmittelbar nach Beendigung des vorherigen Sprints. Es gibt also keine Lücke zwischen den Sprints. Ein Sprint enthält alle weiteren Scrum Events, wie z.B. das Sprint Planning das Sprint Review, die Sprint Retrospektive und das Daily Scrum. Die eigentliche Entwicklung sowie das Backlog Refinement finden ebenfalls innerhalb des Sprints statt. Für jeden Sprint wird ein Sprint Goal definiert, das dem Development Team Orientierung innerhalb des Sprints geben soll. Während eines Sprints werden keine Änderungen vorgenommen, die das Sprint Goal gefährden. Falls neue Erkenntnisse vorliegen, kann allerdings der Umfang des Sprints zwischen dem Product Owner und dem Development Team neu verhandelt werden.


Sprint Planning

Jeder neue Sprint beginnt mit dem Sprint Planning. Das Sprint Planning besteht aus mehreren Phasen. Zunächst stellt der Product Owner das aktuelle Product Backlog vor und das Development Team wählt eine Reihe von Anforderungen für das Sprint Backlog aus. Anschließend erstellt das Development Team einen Plan für die Umsetzung der ausgewählten Anforderungen. Dafür werden aus den Einträgen konkrete Aufgaben abgeleitet. Es kann durchaus vorkommen, dass das Development Team dabei feststellt, dass die initiale Einschätzung nicht ganz korrekt war und es mehr oder weniger Einträge umsetzen kann als zunächst vermutet. Wenn das Development Team den Plan für die Umsetzung erstellt hat, wird es diesen dem Product Owner vorstellen. Das Development Team committed sich, die von ihm ausgewählten Anforderungen im nächsten Sprint umzusetzen. Im letzten Schritt definieren Product Owner und Development Team gemeinsam ein Sprint Goal für den Sprint. Bei einer Sprint Dauer von 4 Wochen sollte das Sprint Planning nicht länger als 8 Stunden dauern. Bei kürzeren Sprints wird in der Regel auch für das Sprint Planning weniger Zeit benötigt.


Sprint Review

Jeder Sprint endet mit dem Sprint Review. Nach dem Sprint Review findet nur noch die Sprint Retrospektive statt. Danach beginnt der nächste Sprint. Im Sprint Review demonstriert das Development Team dem Product Owner die umgesetzten Anforderungen. Neben dem Product Owner können auch Stakeholder oder Kundenvertreter am Sprint Review teilnehmen. Das Ziel des Sprint Reviews ist es, direktes Kundenfeedback zum Produkt zu erhalten, Probleme, mögliche Änderungen oder neue Funktionen zu diskutieren und über das weitere Vorgehen zu entscheiden. Es soll dem Development Team dabei helfen, besser zu verstehen, was der Kunde von dem Produkt erwartet. Bei einer Sprint Dauer von 4 Wochen sollte das Sprint Review nicht länger als 4 Stunden dauern. Bei kürzeren Sprints wird in der Regel auch für das Sprint Review weniger Zeit benötigt.

Sprint Retrospektive

Die Sprint Retrospektive ist das letzte Event eines jeden Sprints. Sie dient dazu, die Zusammenarbeit im gesamten Team zu verbessern und einen kontinuierlichen Verbesserungsprozess zu etablieren. Es ist wichtig, dass die Sprint Retrospektive in einer offenen und vertrauensvollen Atmosphäre stattfindet, damit keine Probleme oder Verbesserungen zurückgehalten werden. Die Sprint Retrospektive ist das wichtigste Werkzeug, das ein Scrum Team besitzt, um seine Zusammenarbeit zu verbessern. Für die Durchführung der Sprint Retrospektive gibt es eine Vielzahl an Formaten, den verwendet werden können. Die Auswahl des Formats sowie die Moderation des Events werden vom Scrum Master übernommen. Am Ende der Sprint Retrospektive sollten klar definierte und vom gesamten Team verabschiedete Verbesserungsmaßnahmen vorliegen. Diese werden, neben den Anforderungen aus dem Produkt Backlog, beim nächsten Sprint Planning ebenfalls in das Sprint Backlog übernommen. Damit wird sichergestellt, dass an den besprochenen Verbesserungen auch tatsächlich zeitnah und konkret gearbeitet wird. An der Sprint Retrospektive sollte immer das gesamte Scrum Team teilnehmen. Bei einer Sprint Dauer von 4 Wochen sollte die Sprint Retrospektive nicht länger als 3 Stunden dauern. Bei kürzeren Sprints wird in der Regel auch für die Sprint Retrospektive weniger Zeit benötigt.


Daily Scrum

Das Daily Scrum soll dem Development Team dabei helfen, die Zusammenarbeit während des Sprints laufend anzupassen und neu zu organisieren. Es soll dem Team dabei helfen, die vorhandenen Ressourcen bestmöglich einzusetzen. Es ist kein Status-Meeting, in dem der aktuelle Stand berichtet wird. Es ist auch nicht dafür da, um Probleme oder mögliche Lösungen zu diskutieren. Stattdessen sollte jedes Mitglied des Development Teams die folgenden 3 Fragen beantworten:

  • Was habe ich seit dem letzten Daily Scrum für die Erreichung des Sprint Goals getan?
  • Was werde ich bis zum nächsten Daily Scrum für die Erreichung des Sprint Goals tun?
  • Gibt es Hindernisse, die mich von der Erreichung des Sprint Goals abhalten?

Anschließend können die Teammitglieder die gewonnenen Erkenntnisse dazu nutzen, die Zusammenarbeit anzupassen. Probleme oder Fragestellungen, die während des Daily Scrum aufkommen, können im Anschluss an das Meeting von den betroffenen Personen diskutiert werden. Um den Aufwand zu reduzieren, sollte das Daily Scrum jeden Tag zur gleichen Zeit am gleichen Ort stattfinden. Es bietet sich an, das Daily Scrum morgens durchzuführen, damit es bei der Planung und Organisation des anstehenden Tages helfen kann. Das Daily Scrum hat immer eine feste Timebox von 15 Minuten.


Backlog Refinement

Das Backlog Refinement ist kein offizielles Scrum Event, sondern dient der Verfeinerung des Product Backlogs sowie der Vorbereitung auf das nächste Sprint Planning. Das Schätzen der Einträge des Product Backlogs findet üblicherweise ebenfalls im Backlog Refinement statt. Wenn ein Sprint Planning sehr lange dauert und viele Frage zu den einzelnen Anforderungen aufkommen, ist dies oft ein Anzeichen dafür, dass in den letzten Sprints nicht genügend Zeit für das Backlog Refinement aufgewendet wurde. Da es kein offizielles Scrum Event ist, besitzt es auch keinen festen Zeitpunkt und keinen festen Umfang. Ein Scrum Team kann aber davon ausgehen, dass es bis zu 10% seiner Zeit für das Backlog Refinement benötigen wird.

Die Scrum Methode besitzt 5 Events. Diese sind der eigentliche Sprint, das Sprint Planning, das Sprint Review, die Sprint Retrospektive und das Daily Scrum.

Scrum Artefakte

WAS IST DIE SCRUM METHODE?

Product Backlog

Das Product Backlog ist eine geordnete Liste und enthält alle aktuell bekannten Anforderungen an das Produkt. Es ist dynamisch und niemals vollständig oder fertig. Stattdessen wird es laufend vom Product Owner überarbeitet und weiterentwickelt. Die Product Backlog Einträge, die oben stehen, haben aus aktueller Sicht den höchsten Wert für den Kunden und werden daher vom Development Team als nächstes entwickelt. Aus diesem Grund sind Product Backlog Einträge, die weiter oben stehen, in der Regel bereits klarer und detaillierter beschrieben als Backlog Einträge, die weiter unten stehen. Das Product Backlog sollte immer genügend Einträge enthalten, um das Development Team für die nächsten 2-3 Iterationen auszulasten. Enthält das Product Backlog weniger Einträge, kann das Product Backlog nicht mehr sinnvoll sortiert werden und es besteht die Gefahr, dass an Anforderungen gearbeitet wird, die nicht den höchsten Wert für den Kunden bieten. Im Scrum Framework arbeitet nur ein Scrum Team an einem Product Backlog. Bei größeren Projekten kann es allerdings notwendig sein, dass die Arbeit auf mehrere Scrum Teams aufgeteilt wird. In diesem Fall können auch mehrere Scrum Teams an einem Product Backlog arbeiten. Es handelt sich dann aber nicht mehr um die klassische Scrum Methode und es muss ein entsprechendes Skalierungsframework verwendet werden.


Sprint Backlog

Das Sprint Backlog enthält alle Anforderungen, die das Development Team beim Sprint Planning aus dem Product Backlog für den aktuellen Sprint ausgewählt hat. Wieviele Einträge aus dem Product Backlog sich das Development Team für einen Sprint vornimmt, entscheidet einzig und alleine das Development Team.

Die einzige Regel ist, dass das Development Team die Einträge von oben nach unten aus dem Product Backlog auswählen muss. Damit ist sichergestellt, dass das Development Team immer an den Anforderungen arbeitet, die den höchsten Wert für den Kunden liefern. Während der Product Owner für das Product Backlog verantwortlich ist, liegt die Verantwortung für das Sprint Backlog beim Development Team. Beim Sprint Planning, aber auch während eines Sprints, wird sich das Sprint Backlog dynamisch weiterentwickeln. Das Development Team wird die Einträge im Sprint Backlog immer weiter verfeinern, um damit seine Arbeit bestmöglich zu organisieren.


Product Increment

Als Product Increment bezeichnet man die Summe aller Anforderungen, die sowohl während des laufenden Sprints, als auch während vorheriger Sprints entwickelt wurden. Am Ende eines jeden Sprints sollte ein funktionierendes Product Increment vorhanden sein, das potenziell ausgeliefert werden kann. Falls eine Definition of Done (DoD) vorhanden ist, muss es dieser entsprechen. Mit jedem Product Increment kommt ein Scrum Team der Umsetzung der Produktvision einen Schritt näher.


Definition of Done (DoD)

Die Definition of Done (DoD) ist kein offizielles Scrum Artefakt, sondern eine Checkliste, die definiert, welche Kriterien eine vom Development Team umgesetzte Anforderung für die Abnahme durch den Product Owner erfüllen muss. Der Inhalt der DoD hängt von einer Reihe von Variablen ab, wie z.B. der Art des zu entwickelnden Produkts, der verwendeten Technologien oder den aktuellen Herausforderungen. Verantwortlich für die Erstellung der DoD ist der Product Owner. Verantwortlich für die Einhaltung der DoD ist das Development Team.

Die Scrum Methode kennt 3 Artefakte. Diese sind das Product Backlog, das Sprint Backlog und das Product Increment.

Haken

Scrum besitzt nur wenige Regeln, ist leicht verständlich und schnell einführbar.

Haken

Scrum ermöglicht das schnelle Reagieren auf Veränderungen.

Top Vorteile der Scrum Methode

WAS IST DIE SCRUM METHODE?

Die Scrum Methode bietet eine ganze Reihe an Vorteilen. Wir haben Ihnen die Wichtigsten zusammengestellt.

Haken

Scrum verbessert die Kommunikation und reduziert die Dauer und Anzahl von Meetings.

Haken

Scrum schafft Transparenz und fördert einen kontinuierlicher Verbesserungsprozess.

Haken

Scrum fördert mehr Eigenverantwortung und Selbstorganisation.

Haken

Scrum reduziert den Aufwand für Steuerung, Kontrolle und Reporting.

Haken

Scrum reduziert das Risiko für Fehlschläge und erhöht die Kundenzufriedenheit.

UNSERE SERVICES

Ebenfalls für Sie interessant?

Wie können wir die Vorteile von agilem Arbeiten mit Scrum praktisch erleben? Wie erreichen wir ein gemeinsames Verständnis für agiles Arbeiten im Team?

Unsere Agile Coaches helfen dabei, agile Teams aufzubauen oder bereits bestehende agile Teams zu High-Performance-Teams weiterzuentwickeln.

Können wir auch Ihnen helfen?

ERSTBERATUNG ANFORDERN

Dann zögern Sie nicht und fordern Sie noch heute unsere kostenlose und unverbindliche Erstberatung an.

Copyright © 2020 München. Alle Rechte vorbehalten.