Scrum Guide
Der Scrum Guide ist der Leitfaden zur Methode Scrum, er wurde – wie auch Scrum selbst – von Ken Schwaber und Jeff Sutherland entwickelt und wird kontinuierlich verbessert. Scrum besteht aus nur wenigen Regeln, die sich aus fünf Aktivitäten, drei Artefakten und drei Rollen zusammensetzen. Die Kurzfassung ist im Agile Atlas zusammengefasst, der Scrum Guide ist die ausführlichere Variante des Leitfadens.
Allgemeine Informationen zum Thema
Durch Techniken für die Umsetzung der Aktivitäten, der Artefakte und der Rollen wird das Scrum-Framework konkretisiert und dann umgesetzt. Dabei gibt es auf der einen Seite klar definierte Wirkungsmechanismen und zentrale Elemente, auf der anderen Seite steht den Teilnehmern aber ein großes Maß an Freiheit zur Verfügung, um die individuelle Ausgestaltung zu ermöglichen.
An dieser Stelle wird es jedoch häufig problematisch, weil viele Unternehmen zwar die essentiellen Bestandteile des Scrum Guide kennen, aber oft davon abweichen. Dies betrifft meist den Ablauf von Sprints, die Länge der Sprints, die Treffen (Meetings), die Größe der Teams und das Reguirements-Engineering. Nicht selten kommt es zu falschen Einschätzungen bei Aspekten wie Aufwandsschätzung und der Qualitätssicherung[1].
Die Scrum-Theorie nach dem Scrum Guide
Die Scrum-Theorie basiert auf der empirischen Prozesssteuerung, abgekürzt: Empire. Gedankliche Grundlage ist die Annahme, dass Wissen durch Erfahrungen gewonnen und vermehrt wird, wobei die jeweiligen Entscheidungen auf der Grundlage des bereits Bekannten getroffen werden. Im Scrum Guide von 2013 heißt es, dass Scrum einen iterativen und inkrementellen Ansatz wählt, um die Sicherheit von Prognosen bzw. Terminen und Ergebnissen zu schaffen und die entstehenden Risiken auf ein Minimum zu reduzieren. Jede Implementierung von Empire basiert auf den drei Säulen Transparenz, Überprüfung (Inspection) und Anpassung (Adaption).
Die Transparenz ist besonders für die Beteiligten wichtig, die den Verantwortungsbereich innehaben. Notwendige Voraussetzung für die Transparenz ist ein gemeinsamer Standard, der zuvor festgelegt wird und an den sich alle halten und orientieren. Dieser betrifft beispielsweise die Prozesssprache und ein gemeinsames Verständnis von Begrifflichkeiten wie etwa „Done“.
Unter dem Punkt Überprüfung (Inspection) wird die Kontrolle der Erreichung von Sprint-Zielen verstanden, die dazu dient, Abweichungen, die nicht gewünscht sind, zu erkennen. Das Überprüfen sollte keine Überhand annehmen, um die eigentliche Arbeit nicht zu stören, es sollte zudem von Prüfern durchgeführt werden, die gewissenhaft und fachlich befähigt sind.
Die Anpassung ist die Konsequenz aus den Ergebnissen der Überprüfung. Alle Aspekte des Prozesses, die von gesetzten Grenzwerten in einer nicht akzeptablen Form abweichen, müssen behoben und neu an die Prozesse angepasst werden.
Im Scrum Guide werden vier formale Ereignisse vorgeschrieben, die im Guide-Abschnitt „Ereignisse“ genauer beschrieben werden. Diese sind:
1. Sprint Planning
2. Daily Scrum
3. Sprint Review
4. Sprint Retrospektive
Das Scrum Team gemäß des Scrum Guides
Das Scrum Team setzt sich zusammen aus dem Product Owner, dem Entwicklungsteam und dem Scrum Master. Im Scrum Guide ist klar formuliert, dass Scrum Teams interdisziplinär und selbstorganisierend sind, also selbst darüber entscheiden, wie sie die Arbeit erledigen. Der Guide setzt voraus, dass interdisziplinäre Teams alle Kompetenzen mitbringen, die sie dazu befähigen, ihre Arbeit fachlich einwandfrei zu verrichten. Personen außerhalb des Entwicklungsteams sind dazu nicht nötig.
Laut Scrum Guide wurde das Modell der Teamarbeit entwickelt, um Produktivität, Flexibilität und Kreativität zu steigern. Wenn die inkrementelle Auslieferung von (vorläufig) fertigen Produkten vollzogen wird, wird dies mit dem oben erwähnten „Done“ dokumentiert. So wird sichergestellt, dass es ein jeweils funktionierendes Produkt gibt, selbst wenn die Prozesse noch nicht beendet worden sind[2].
Update des Scrum Guides 2017: Klärung von Missverständnissen
Obwohl Scrum bereits seit 1995 angewendet wird, kam der Scrum Guide erst im Jahr 2010 heraus. 2017 brachten Schwaber und Sutherland ein Update heraus, weil sie mit einer Reihe von Missverständnissen aufräumen wollten. So stellten sie klar, dass Scrum sich nicht auf den IT-Einsatz reduzieren lässt und schreiben an einer Stelle explizit (das war bis dahin noch nicht der Fall gewesen), dass Scrum sich nicht auf den Einsatz der Software-Branche beschränkt.
Offenbar wollten Schwaber und Sutherland mit dem Update darüber hinaus den Aspekt der Freiheit bei der Arbeit in den Vordergrund stellen. So veränderten sie die ursprüngliche Formulierung zur Scrum Review von „ein vierstündiges Meeting für einen 1-Monat-Sprint“ in „zumeist ein vierstündiges Meeting für einen 1-Monat-Sprint.“
Da es auch bei der Rolle des Scrum Masters seit Beginn von Scrum immer wieder Unklarheiten gab, formulieren Schwaber und Sutherland eine genauere Beschreibung der Aufgabenstellung für den Scrum Master: „Die Aufgabe des Scrum Masters ist es, Scrum so zu fördern und zu unterstützen, wie es im Scrum Guide niedergeschrieben ist. Scrum Master machen das, indem sie allen dabei helfen, die Scrum Theorien, Praktiken, Regeln und Werte zu verstehen.“[3].
Bedeutung für das Development
Der Leitfaden Scrum Guide fasst die Bedeutung, Aufgabenverteilung und Umsetzung des Scrum-Ansatzes gut zusammen und ist als Lektüre, wenn man mit Scrum arbeiten will, faktisch unverzichtbar. Da es sich bei Scrum um ein komplexes System handelt, das viel Frei- und Spielraum lässt, ist die Zuhilfenahme des Scrum Guides also unbedingt zu empfehlen.
Einzelnachweise
- ↑ Scrum Definition de.wikipedia.org. Abgerufen am 08.12.2017
- ↑ Scrum Guide scrumguides.org. Abgerufen am 08.12.2017
- ↑ Update Scrum Guide: 5 Missverständnisse, die aufgeklärt werden scrum.de. Abgerufen am 08.12.2017