Scrum

„Scrum ist einfach, jedoch schwierig zu meistern“ – Ken Schwaber 

Scrum ist ein einfaches Framework zur Lösung komplexer Probleme. Komplexe Probleme sind per Definition nicht mit einem (ausgefeilten) Plan lösbar. Gerade bei Produkt- und Software-Entwicklungen handelt es sich um komplexe Problemstellungen. 
Das Framework umfasst drei Rollen, drei Artefakte und fünf Events, insgesamt also elf Bestandteile und ist somit ein sehr schlankesFramework. Scrum baut auf dem Agile Manifesto und den entsprechenden Prinzipien auf.

Das Framework lässt sich wie folgt veranschaulichen:

Scrum Framework

Scrum wird im Scrum Guide beschrieben, dieser Guide ist das „Regelwerk“ von Scrum. Die Elemente werden weiter unten ausführlicher beschrieben. Scrum baut auf „Empirischer Prozesskontrolle“ auf.
 
 
 

Empirische Prozesskontrolle

Empirische Prozesskontrolle beruht auf Transparenz – Inspektion – Adaption
  • Es wird Transparenz über den aktuellen Zustand  geschaffen
  • Davon ausgehend wird eine Situation untersucht (Inspektion)
  • Aufgrund der Ergebnisse dieser Inspektion wird das weitere Vorgehen angepasst (Adaption)
Scrum weist also einen geschlossenen Lernzyklus auf. Dieser macht das Framework sehr mächtig, da konsequent und in sinnvollen Zyklen Transparenz über eine aktuelle Situation geschaffen und das weitere Vorgehen darauf aufbauend angepasst wird. Somit kann rasch auf veränderte Gegebenheiten reagiert werden.
 
Die feste Kadenz ist sehr wichtig: Die Kadenz reduziert die Komplexität in der sich das Team bewegt und fördert die Transparenz, da immer das gleich grosse Zeitfenster betrachtet wird.
 

Scrum-Werte

Neben der Basis der empirischen Prozesskontrolle baut Scrum auf fünf Werten auf:
Scrum Values
 
Diese Werte sind wichtig, da sie letztendlich das gegenseitige Vertrauen im Scrum-Team fördern. Vertrauen ist entscheidend für den Erfolg eines Teams.
 

Bestandteile von Scrum

Rollen

Scrum Master

Die Aufgabe des Scrum Masters ist es, das Befolgen der Scrum-Regeln zu fördern. Dabei arbeitet der Scrum Master eng mit dem Team und der Organisation zusammen. Insbesondere ist er/sie auch für das Entfernen von Hindernissen (Impediments) des Teams in der Organisation zuständig.

Diese Rolle ist sehr vielfältig und wird in den meisten Unternehmen unterschätzt. Das „Agile Coaching Institute“ zeigt verschiedene Haltungen auf, die ein Scrum Master einnehmen kann:

 

Product Owner

Die Rolle des Product Owners wird, wie jene des Scrum Masters, von einer Person besetzt. Seine/ihre Aufgabe ist es, mit den Stakeholdern und Team zusammenzuarbeiten, um das Product Backlog aktuell und auf die Produktvision ausgerichtet zu halten.

Die Priorisierung der Arbeit im Product Backlog ist einzig die Aufgabe des Product Owners. Ziel der Priorisierung ist, durch den Einsatz des Teams möglichst viel Wert zu schaffen.

Entwicklungsteam

Das Entwicklungsteams (oder kurz: Teams) setzt sich aus 3-9 Personen zusammen. Dabei sind alle Disziplinen im Team vertreten, die benötigt werden, um aus einem Backlogitem ein Produktinkrement zu schaffen. In Scrum werden Teams etabliert, die über mehrere Sprints stabil bleiben.

Aufgabe des Teams ist es, innerhalb eines Sprints entlang der Prioritäten des Product Owners ein Produktinkrement zu schaffen. Dabei müssen die erledigten Arbeiten der „Definition of Done“ genügen, damit von einer einheitlichen Qualität der erledigten Arbeiten ausgegangen werden kann.

Wichtig ist, dass ein Produktinkrement eine Release fähige Qualität aufweist (d.h. zum Beispiel auch getestet und in das Gesamtsystem integriert wurde). Dies ist notwendig, damit die für die empirische Prozesskontrolle notwendige Transparenz entstehen kann.

Selbstorganisation ist ein wichtiges Prinzip von Scrum. Deshalb ist es auch die Aufgabe des Entwicklungsteams, die eigenen Hindernisse innerhalb des Teams selbst zu lösen.

Artefakte

Product Backlog

Das Product Backlog ist eine priorisierte Liste an Arbeit für die Entwicklung eines Produktes. Es ist die „Single Source“ für Arbeit des Teams. Darin liegt der grosse Wert des Product Backlogs: Alle Arbeit des Teams ist an einem Ort festgehalten und transparent.

Ein Product Backlog ist ein lebendiges Artefakt, d.h. die enthaltenen Items werden konstant verfeinert, repriorisiert, entfernt oder neue Items werden ins Backlog aufgenommen.

Sprint Backlog

Während des Sprint-Planning entscheidet das Team, in Rücksprache mit dem Product Owner, welche Items aus dem Product Backlog im nächsten Sprint bearbeitet werden. Diese Items werden im Sprint Backlog dargestellt und kontinuierlich abgearbeitet. Wie die Lösungsfindung erfolgt liegt im Ermessen des selbst-organisierten Teams.

Produktinkrement

Ziel eines Sprints ist die Erschaffung eines Produktinkrements. Dieses sollte eine „releasefähige“ Qualität aufweisen, d.h. spätestens nach dem Sprint Review auf Entscheid des Product Owners hin für den Markt freigegeben werden können.

Dieser Grad an Qualität ist notwendig, um spätere, unvorhersehbare Nacharbeiten zu vermeiden. So ist der Zustand des Produktes jederzeit transparent, was notwendig ist für den Erfolg der empirischen Prozesskontrolle (und somit des Teams).

Zeremonien

Sprint

Ein Sprint ist die Kadenz, in der das Scrum-Team plant und arbeitet. Dabei ist ein Sprint höchstens vier Wochen lang, wobei eine kürzere Dauer bevorzugt wird. Unmittelbar nach Ende eines Sprints folgt der Beginn des folgenden Sprints.

Sprint-Planung

Die Sprint-Planung dient dazu, einen Forecast über die Arbeiten des kommenden Sprints zu machen. Dabei arbeitet das Team eng mit dem Product Owner, um die höchst priorisierten Items zu identifizieren und danach deren Lösung zu planen. Eine Sprint-Planung dauert maximal 8 Stunden bei einem 4-wöchigen Sprint (bei kürzeren Sprints entsprechend kürzer).

Während der Sprint-Planung wird das Sprint-Ziel festgelegt. Dieses gibt dem Team während dem Sprint Flexibilität in der Lösungsfindung, und gleichzeitig Sicherheit in Form von Leitplanken vor.

Sprint-Review

Am Sprint-Review wird das während dem Sprint erstellte Produktinkrement vom Team, Product Owner und Stakeholdern untersucht bzw. inspiziert. Insofern spielt der Sprint-Review eine wichtige Rolle in der empirischen Prozesskontrolle. Das Ergebnis der Inspektion wird im Backlog und/oder der nächsten Sprint-Planung berücksichtigt. Die Timebox für den Sprint-Review ist 4h für einen 4-Wochen-Sprint (entsprechend kürzer bei kürzeren Sprints).

Sprint-Retrospektive

An der Sprint-Retrospektive wird die Zusammenarbeit des Teams untersucht und notwendige Anpassungen identifiziert. Dabei arbeitet das Team eng mit Product Owner und Scrum Master zusammen. Beispielsweise identifiziert das Team Anpassungsbedarf bei der „Definition of Done“, um die Produktqualität weiter zu steigern.

Die Timebox der Sprint-Retrospektive ist 3h für einen 4-wöchigen Sprint (entsprechend kürzer bei kürzeren Sprints).

Daily Scrum

Der Daily Scrum dient der Förderung der Transparenz während eines Sprints. Es handelt sich um ein tägliches Treffen des Teams mit einer Timebox von 15 Minuten. Diese Zeit nutzt das Team um sich über den Stand der Arbeiten im Hinblick auf das Erreichen des Sprint-Ziels zu informieren und allfällige Hindernisse zu identifizieren.
 

Unterstützende Elemente

Zusätzlich zu diesen im Scrum-Guide beschriebenen Elementen können folgende Elemente und Praktiken bei der Verwendung von Scrum hilfreich sein:
  • User Stories
  • Visualisierung von Arbeit
  • XP Praktiken
  • Test Driven Development

Unsere Scrum-Trainings

Es gibt derzeit keine bevorstehenden Veranstaltungen.