Was ist
SCRUM?
Was ist Scrum?
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 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.
Scrum Werte
Diese Werte sind wichtig, da sie letztendlich das gegenseitige Vertrauen im Scrum-Team fördern. Vertrauen ist entscheidend für den Erfolg eines Teams. Ohne vertrauensvolle Basis wird das Team keine Transparenz schaffen können, womit auch die Inspektion und Adaption fehlgeleitet wird.
Bestandteile von Scrum
Rollen
Ein Scrum Team umfasst verschiedene Verantwortlichkeiten („Accountabilities“). Die Erfahrung zeigt, dass diese Verantwortlichkeiten sinnvollerweise auf drei Rollen aufgeteilt werden:
- Scrum Master
- Product Owner
- Developer
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:
Mehr zur Rolle des Scrum Masters
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.
Mehr zur Rolle des Product Owners
Entwickler ("Developer")
Die Entwickler*innen („Developer“) sind 3-9 Personen, die zusammen einen Inkrement erstellen. Dabei sind alle Disziplinen vertreten, die benötigt werden, um aus einem Backlogitem ein Produktinkrement zu schaffen. In Scrum bleiben Teams über mehrere Sprints stabil, um den verschiedenen Teambildungsphasen Rechnung zu tragen.
Aufgabe der Developer 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 der Developer, die eigenen Hindernisse innerhalb des Teams selbst zu lösen.
Mehr zur Rolle der Developer
Artefakte
Product Backlog
Das Product Backlog ist eine geordnete 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. Somit wird für alle interessierten Personen transparent, wohin sich ein Produkt entwickeln soll.
Ein Product Backlog ist ein lebendiges Artefakt, d.h. die enthaltenen Items werden konstant verfeinert, repriorisiert, entfernt oder neue Items werden ins Backlog aufgenommen.
Das Product Backlog enthält als zugehöriges Commitment das „Product Goal“ (Produktziel). Dieses gibt der Produktentwicklung eine Richtung. Das Product Goal kann je nach Kontext eher kurzfristig (bspw. eine bestimmte Funktionalität) oder eher langfristig (bspw. in Form einer Produktvision) formuliert werden.
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.
Das Sprint Backlog enthält als zugehöriges Commitment das „Sprint Goal“. Dieses fasst ganz kurz und prägnant das unumstössliche Ziel des Sprints zusammen: „Weshalb machen wir diesen Sprint?“.
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).
Dementsprechend umfasst das Inkrement als zugehöriges Commitment die „Definition of Done“ als gemeinesamen Qualitätsstandard.
Events
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 Planning
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 RETROSPEcTIVE
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
- User Stories
- Visualisierung von Arbeit
- XP Praktiken
- viele weitere mehr
Diese zusätzlichen Praktiken sind immer abhängig vom Kontext, in dem sich das Scrum Team bewegt. Deshalb werden sie auch nicht im Scrum Guide formuliert. Der Scrum Guide definiert die „Spielregeln“ von Scrum. Es ist den Personen die Scrum anwenden überlassen, die hilfreichsten Praktiken und Spieltaktiken zu finden und anzuwenden.