
Steckbrief SCRUM
Steckbrief SCRUM
Der Begriff Scrum lässt sich auf die japanischen Wirtschaftswissenschaftler Ikujiro Nonaka und Hirotaka Takeuchi zurückführen. In ihrem im Jahr 1986 erschienenen Artikel „The New Product Development Game“ beschreiben sie den sogenannten „Rugby-Approach“. Die erfolgreichen Produktentwicklungsteams werden hier mit dem aus dem Rugby stammenden Gedränge, bei dem viele Spieler eng zusammenstehen, verglichen.
Als der Rugby-Approach dann ca. 10 Jahre von Jeff Sutherland und Ken Schwaber zu dem heute bekannten Framework weiterentwickelt wurde, nannten sie ihn, unter direktem Verweis auf diesen Artikel, Scrum:
“We call the approach the SCRUM methodology (see Takeuchi and Nonaka, 1986), after the SCRUM in rugby -- a tight formation of forwards who bind together in specific positions when a scrumdown is called.”
Inzwischen werden mehr als 90 Prozent aller agilen Projekte mit Scrum gemanagt, und mehr als 12 Millionen Menschen weltweit nutzen Scrum in den verschiedensten Branchen.
Scrum ist ein Rahmenwerk (Framework), das sich aus drei Komponenten zusammensetzt:
- Prinzipen (aus dem agilen Manifest)
- Werte (Values) – (*auch dazu haben wir einen Blogbeitrag)
- Scrum-Regeln (festgelegte Rollen, Artefakte und Events)
Das agile Manifest
Die wohl bekannteste Aufstellung agiler Prinzipien ist das agile Manifest. Es dient als Fundament der Scrum-Methode. Mit seinen vier Leitsätzen und 12 Prinzipien gibt es Teams eine Orientierung für Entscheidungen im Alltag. Da Scrum in der Softwareentwicklung entstanden ist, bezieht sich auch das agile Manifest auf diesen Kontext.
1. Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
2. Funktionierende Software ist wichtiger als eine umfassende Dokumentation.
3. Zusammenarbeit mit dem Auftraggeber ist wichtiger als Vertragsverhandlung.
4. Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans.
Indem Teams die Leitsätze des Manifests befolgen, konzentrieren sie sich konsequent auf den Kunden-Mehrwert.
12 agile Prinzipien
Auch die Prinzipien des agilen Manifest sind ganz klar auf den Kundennutzen ausgerichtet. In 12 Punkten werden die wichtigsten Aspekte der Zusammenarbeit eines Scrum-Teams definiert:
- Mit dem Nutzer zusammenarbeiten - Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
- Änderungen begrüßen - 'Heiße' Anforderungsänderungen selbst spät in der Entwicklung willkommen.
- Cross-funktionale Teams - Im Team sind alle Kompetenzen vereint, die zur Lösung der Aufgabe nötig sind und um das Ziel zu erreichen.
- So schnell wie möglich liefern - Höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.
- Starte mit den Motivierten - Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.
- Gleichmäßiges Tempo - Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
- Funktionierende Produkte sind das Maß - Funktionierende Software ist das wichtigste Fortschrittsmaß.
- Simplicity - Einfachheit, die Kunst, die Menge nicht getaner Arbeit zu maximieren, ist essenziell.
- Face 2 Face Kommunikation - Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteam zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.
- Exzellenz und gutes Design - Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
- Selbstorganisation - Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
- Inspektion und Adaption - In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.
Einen Blogbeitrag mit einer detaillierteren Beschreibung der Prinzipien finden Sie hier. ((LINK))
Die Scrum Rollen
SCRUM Master
Der Scrum Master ist der Coach des Teams. Er moderiert die Sitzungen, schult das Team in der Scrum Arbeitsweise und achtet darauf, dass sich das Team an die Scrum Spielregeln hält. Er schützt das Team während des Sprints, so dass das Team sich auf die vereinbarten Ziele konzentrieren kann. Der Scrum Master hilft dem Team, sich selbst zu verbessern, schneller zu werden und eine höhere Qualität zu liefern. Er kümmert sich darum Hindernisse (Impediments) aus dem Weg zu räumen.
Product Owner
Der Product Owner vertritt die Interessen des Kunden und anderer Stakeholder. Er sorgt dafür, dass sich das Team mit den richtigen Themen beschäftigt. Zu diesem Zweck führt der Product Owner eine Liste (Product Backlog) mit Items, die dem Produkt noch hinzugefügt werden müssen. Die wichtigste Aufgabe des Product Owners ist die Festlegung von Prioritäten, so dass die im Sprint festgelegten Tätigkeiten einen maximalen Wert für den Kunden erbringen. Der Product Owner übernimmt auch die Abstimmung der Prioritäten mit den verschiedenen Stakeholdern.
Development Team
Das Development Team ist multidisziplinär, crossfunktional und arbeitet selbstorganisiert. Das heißt, dass das Team selbständig in der Lage ist, alle Aufgaben vom Entwurf, der Umsetzung, dem Testen bis hin zur Auslieferung zu übernehmen. Das Team besteht aus 5 bis 9 Mitgliedern und ist sowohl für die Planung als auch die Durchführung der Tätigkeiten während des Sprints verantwortlich. Das Besondere an Scrum ist die eigene Verantwortung des Teams für den Arbeitsprozess. Da jeder Sprint mit einer Evaluation sowohl des Produktes wie auch der Zusammenarbeit endet, wird kontinuierlich an einer Verbesserung gearbeitet.
Die Scrum Meetings
Daily
Jeden Tag hält das Team ein kurzes Meeting von 15 Minuten, das „Daily Scrum“ oder „Daily Standup“ genannt wird. Ziel dieses Meetings ist ein Statusabgleich, Transparenz und ggf Abhängigkeiten rechtzeitig zu erkennen. Um das Meeting kurz und effektiv zu halten, bleiben alle stehen und jeder beantwortet die folgenden 3 Fragen:
Was habe ich seit dem letzten Daily erreicht?
Was werde ich bis zum nächsten Daily tun?
Gibt es etwas, was mich behindert?
Sprint Planning Meeting
Jeder Sprint beginnt mit einem Sprint Planning Meeting. In diesem Meeting bespricht der Product Owner die Tätigkeiten, die er vom Team gern erledigt haben möchte. Anschließend wählt das Team die Items/Aufgaben aus dem Backlog aus, die in einem Sprint bearbeitet werden können. Diese Items werden vom Team in Aufgaben aufgeteilt, die wiederum mit einer Schätzung versehen werden. Das Ergebnis ist ein Sprintplan, der innerhalb des nächste Sprint-Zyklus umgesetzt wird.
Sprint Review
Im Sprint Review am Ende eines jeden Sprints wird das Ergebnis des Sprints vorgestellt. Das Team zeigt mit einer Demo bzw. einem Zwischenprodukt, dass das Produkt wirklich funktioniert und der Definition of Done entspricht. Ziel dieses Meetings ist die möglichst greifbare Darstellung der erzielten Fortschritte. Dies ist für den Product Owner ein wichtiger Moment, um Feedback von anderen Stakeholdern zu erhalten.
Retrospective
Der Sprint wird mit der Retrospective (Retro) beendet. In diesem Meeting reflektiert das Team die Zusammenarbeit und den gemeinsamen Arbeitsprozess im vergangenen Sprint. Zum Beispiel mit den Fragen: Was lief gut, was lief nicht gut, was sollte beibehalten werden und was sollte verbessert werden. Das Team verständigt sich auf eine bis maximal drei Aufgaben, die gemeinsam festgelegt werden und als Aufgaben in den nächsten Sprint mitgenommen werden. Damit verbessert sich die Zusammenarbeit kontinuierlich und die zwischenmenschlichen und kommunikativen Themen haben einen festen Platz im Arbeitsprozess.
Weitere Scrum Begriffe
Definition of Done (DoD)
Die Definition of Done beschreibt, welche Anforderungen das Ergebnis eines Sprints erfüllen muss. Die Definition of Done wird vom Team selbst erstellt und beschreibt Dinge wie Testing, Modultests, Dokumentation usw.
Scrum Board – Kanban Board
Das Scrum Board oder auch Kanban Board ist eine Tafel, an der alle Sprint Backlog Items hängen. Die Aufgaben für den jeweiligen Sprint sind an der Tafel auf 3 Spalten verteilt:
To Do, In Progress und Done.
Die wichtigsten Aufgaben hängen oben an der Tafel, der Sprint Backlog ist damit nach Priorität sortiert. Mit dieser Tafel hat das Team einen Überblick über den aktuellen Status. Das Kanban Board ist für das Team der zentrale Ort beim Daily, um die verbleibenden Tätigkeiten und die Maßnahmen abzustimmen.
Sprint
Die Scrum-Methode ist iterativ. Jede Iteration wird „Sprint“ genannt. Das hat aber nichts mit schnellem Tempo zu tun, denn ein agiles Prinzip ist ein gleichmäßiges Tempo, das auf unbegrenzte Zeit gehalten werden kann, sondern beschreibt eine Iterationsschleife. Ein Sprint dauert 2 bis maximal 4 Wochen. Innerhalb dieser Zeit bearbeitet das Team eine im Vorfeld ausgewählte Menge an Aufgaben, die vollständig abgearbeitet werden. Ergebnis jedes Sprints ist ein Stück funktionierende Software. Dadurch ist das Produkt schnell einsetzbar und das Team erhält schnell Feedback zum Produkt und zum Prozess.
User Stories
User Stories sind Items, die im Product Backlog stehen. Diese beinhalten Anforderungen, zum Beispiel von Kunden, die noch realisiert werden müssen. Eine typische Formulierung ist: Als Nutzer will ich <ZIEL / WUNSCH>, damit <NUTZEN> ...
Der große Unterschied zu klassischen Requirements (Anforderungen) besteht darin, dass die User Stories beschreiben, warum etwas getan werden muss. Der Grund oder der Anlass ist für das Team wichtig, um eine passende Lösung zu entwickeln.