Am 18. November 2020 wurde eine neue Version des Scrum Guides veröffentlicht. Welche Änderungen sich daraus im Vergleich zu der vorherigen Version aus dem Jahr 2017 werden innerhalb dieses Artikels aufgezeigt.
Die neue Version des Scrum Guides (PDF-Version) wurde von 19 auf 14 Seiten gekürzt, dies liegt vor allem daran, dass aus dem Scrum Guide redundante Aussagen entfernt, sowie komplexdargestellte Inhalte vereinfacht ausgedrückt wurden. Darüber hinaus gibt es bezüglich der Scrum Zeremonien keine klaren Vorgaben bzw. Handlungsschritte mehr. Die Autoren heben hervor, dies ein bewusster Schritt ist und Scrum auf der gesammelten Intelligenz der Menschen aufbaut, die Scrum nutzen wollen. Dies ist eine implizierte Aufforderung an die Nutzer von Scrum das Framework zu hinterfragen und auch gemäß der drei Säulen: Transparenz, Inspektion und Adaption pragmatisch anzupassen. Abgerundet wird dieser Simplifizierungsansatz durch die sprachliche Auflockerung innerhalb der Definition der Scrumtheorie. Die Autoren verweisen auf „Beobachtungen“, statt konkreten „Wissen“. (Empiricism asserts that knowledge comes from experience and making decisions based on what is observed)
Im Allgemeinen wurde in der neuen Version betont, dass Scrum kein Prozess-Framework mehr ist, sondern ein leichtgewichtiges Framework, das bei der Lösung von komplexen Problemen unterstützen soll. Auch dies änderte sich, da in der vorherigen Version von komplexen Produkten gesprochen wurde. Ein weiteres Aufbrechen des Scrum Rahmens erfolgte dadurch, dass die Einsatzgebiete von Scrum gestrichen wurden. Die Version von 2017 widmete dem Einsatzgebiet von Scrum noch ein vollständiges Unterkapitel „Uses of Scrum“, welches in der neuen Version von 2020 nicht mehr aufzufinden ist. Dort versuchten die Autoren die Vielfältigkeit von Scrum aufzuzeigen, die aber gleichzeitig dem Framework nicht gerecht wurden, da die per Definition die Definition der Einsatzgebiete wiederrum eine Einschränkung dieser ist.
Eine weitere Änderung ist, dass die Autoren nicht mehr von einer Produktvision sprechen, sondern vereinfacht von einem Produktziel. Dies wird vor allem bei den Artefakten relevant, die am Schluss des Artikel beleuchtet werden.
Ein ebenfalls neuartiger Gedanke ist die Aufnahme des LEAN Konzepts im Rahmen des Scrum Frameworks, welcher sich meiner Meinung auch sehr gut mit dem Konzept von Scrum ergänzt. Im Rahmen von LEAN wird sog. WASTE identifiziert und abschließend abgestellt, damit man sich auf das wesentliche fokussieren kann. Dies ist deckungsgleich mit dem zehnten Punkt des agilen Manifestos der besagt: „Simplicity–the art of maximizing the amount of work not done–is essential.“, was in diesem Kontext ebenfalls eine Fokussierung auf das Wesentliche adressiert.
Nachdem wir nun die grundsätzlichen Änderungen der Scrum Guide Versionen von 2017 und 2020 verglichen haben, möchte ich detaillierter auf die Änderungen bzgl. der Säulen von Scrum, die Rollen, Zeremonien und Artefakte eingehen.
Säulen von Scrum
Die drei Säulen von Scrum bleiben unverändert Inspektion, Transparenz und Adaption. Die Änderung diesbezüglich ist, dass die Inspektion sich nicht mehr konkret auf das Sprintziel, sondern allgemeiner auf das gegenseitig vereinbarte Ziel bezieht. Eine weitere sinnvolle Anpassung des Guides ist auch die Bezugsherstellung zwischen den einzelnen drei Säulen. Der Scrum Guide liefert hierzu die folgenden drei hervorgehobenen Aussagen:
- Inspection enables adaptation. Inspection without adaptation is considered pointless. Scrum events are designed to provoke change.
- Transparency enables inspection. Inspection without transparency is misleading and wasteful.
- Adaptation becomes more difficult when the people involved are not empowered or self-managing. A Scrum Team is expected to adapt the moment it learns anything new through inspection.
Scrum Team
Das Kapitel des Scrum Teams und der darin beinhalteten Rollen hat in der neuen Version erhebliche Überarbeitungen erhalten. Diese fangen bei der Teamzusammensetzung an.
Der neue Scrum Guide spricht nun von dem Product Owner, Scrum Master und Entwicklern. Es gibt kein Development Team mehr per Definition. Dies war eine beabsichtigte Änderung um ein besseres Teamgefühl und einen besseren Teamrahmen zu setzen. Oftmals erweckte der Aufbau des Scrum Teams als Product Owner, Scrum Master und Entwicklungsteams eine Sonderstellung der zwei erstgenannten Rollen. Im Sinne von Scrum liegt der Fokus auf der Erreichung des Produktziels und dieses ist nur in einer engen und effizienten Zusammenarbeit aller Rollen zu erreichen. Eine Sonderstellung oder weitere Abgrenzung waren in diesem Sinne daher eher kontraproduktiv. Die Autoren betonen ebenfalls, dass es keine Hierarchien und sog. Sub-Teams gibt. Dies ist möglicherweise ebenfalls der Grund wieso die Rolle der Entwickler im neuen Scrum Guide an erster Stelle vor dem Produkt Owner und Scrum Master definiert wurde.
Eine ebenfalls wichtige Anpassung des Scrum Guides ist das Verständnis und die verstärkte Bemächtigung des Scrum Teams bezüglich der Arbeitsweise. Dieses soll nicht nur selbstorganisierend arbeiten, dies bedeutet selbstständig festlegen wer und wie gearbeitet, sondern selbstleitend, was bedeutet, dass auch eigenständig festgelegt wird, woran gearbeitet werden soll.
Wo die neue Version die ein oder andere Kürzung bezüglich Vorschläge eingearbeitet hat, ergänzte sie auch einen Vorschlag bezüglich eines skalierten Ansatzes, der sehr pragmatisch ist. Sollte das Scrum Team zu groß werden, so sollte es aufgeteilt werden, allerdings mit demselben Produkt im Fokus. Dadurch ergibt sich laut der neuen Version auch Vorschlag, dass dieses Teams dasselbe Produktziel, Produkt Backlog, als auch Product Owner haben.
Eine weitere Änderung ist, dass es keine klaren Vorgaben der Teamgröße mehr gibt. Der Guide spricht sich lediglich dafür aus, dass das Team so klein wie nötig und so groß wie sinnvoll sein sollte um das Produktziel zu erreichen. Dies liegt daran, dass sehr große Teams einen erhöhten organisatorischen Aufwand bezüglich Abstimmungen und Kommunikation mit sich nachziehen.
Rollen in Scrum
Die wohl tiefergreifendste Änderung bezieht sich auf die Definition der Rollen. Der Scrum Guide spricht sich nicht mehr für eine „Responsbility“ (verantwortlich) für die zu erledigenden Aufgaben aus, sondern macht die Rollen nun „Accountable“ (verantwortlich / rechenschaftspflichtig). Welche Änderungen in der jeweiligen Rolle sich ergeben haben, zeige ich nun auf:
Entwickler
Neben der namentlichen Änderung vom Entwicklungsteam hin zu Entwicklern gab es noch weitere Änderungen. Diese Änderungen beziehen sich auf die Verstärkung des Pflichtbewusstseins jeden einzelnen. Dies spiegelt sich darin, dass die Entwickler für die folgenden Aufgaben „accountable“ sind, um während eines jeden Sprints einen nützlichen Teil zum Inkrement liefern zu können.
- Erstellen eines Plans für den Sprint, das Sprint Backlog;
- Einbringen von Qualität durch Einhaltung einer Definition des Erledigten;
- Jeden Tag ihren Plan an das Sprint-Ziel anpassen; und
- Sich gegenseitig als Fachleute zur Rechenschaft ziehen.
Product Owner
Wie eingangs bereits erklärt wurde das Produktziel in den Vordergrund gestellt. Das Produktziel löst die altbekannte Produktvision ab. Die die Entwicklung und explizite Kommunikation des Produktziels bleibt weiterhin in der Verantwortung des Product Owners.
Darüber hinaus wurde die Stellung des Product Owners im Rahmen der Organisation gegenüber den Stakeholdern verstärkt. Sollten Stakeholder den Wunsch äußern, neue produktbezogene Änderungen ins Backlog mitaufnehmen zu lassen, so genügt es nicht mehr diese Punkte zu adressieren, was impliziert das diese Punkte definitiv aufgenommen werden und sich lediglich die Frage nach dem „wann“ der Umsetzung stellte, sondern, dass der Product Owner überzeugt werden soll, die Punkte mit ins Produkt Backlog aufzunehmen.
Ein weiterer Punkt der aufzeigt, dass der Scrum Guide keine klaren Vorgaben mehr macht, spiegelt sich in der Möglichkeit der Product Owner Aufgabendelegation wieder. So schreibt der Scrum Guide nicht mehr vor, dass Aufgaben nur noch an den Scrum Master oder Entwickler delegiert werden können. Wichtig dabei ist jedoch, dass der Product Owner nicht nur „responsible, sondern jetzt auch accountable“ für diese Aufgaben ist.
Scrum Master
Die Rolle des Scrum Masters wurde in Bezug auf die Organisationsverantwortlichkeit ausgedehnt. Der neue Scrum Guide betont immer öfter, dass der Scrum Master nicht nur dem Team, sondern immer der gesamten Organisation dient, indem er das theoretische, als auch praktische Wissen von Scrum innerhalb des Teams und der Organisation multipliziert. Die Scrum Master Tätigkeiten wurden auf Basis der bisherigen Leading und Coaching Fähigkeiten um die des Trainers und Beraters ergänzt. In dieser Funktion wurde auch eine neue Tätigkeit mitaufgenommen, nämlich die Reduzierung konkreter Barrieren zwischen Stakeholdern und Scrum Teams.
Ein Fakt der mich persönlich wundert ist die Streichung der folgenden Tätigkeit:
“Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.”
Meines Erachtens macht es sehr viel Sinn weiterhin mit anderen Scrum Mastern zusammenzuarbeiten und sich auszutauschen um das Gesamtziel der agilen Transformation der Organisation voranzutreiben. Wieso dieser Punkt in der neuen Version gestrichen wurde oder meine Interpretation möglicherweise falsch ist, ist noch offen.
Darüber hinaus wurde die Rolle des Moderators als Scrum Master herausgefordert, indem der Scrum Guide ihn nicht mehr explizit für die Produktivität, als auch Zielerreichung der Scrum Zeremonien in den Vordergrund stellt, sondern immer das gesamte Team.
Scrum Zeremonien
Basierend darauf, möchte ich nun auf die Veränderungen innerhalb der Scrum Zeremonien eingehen.
Wie bereits im allgemeinen Teil betont, ist der Scrum Guide hier offener gestalten und gibt keine klaren Anweisungen mehr für die einzelnen Zeremonien.
Sprint
Die Beschreibung des Sprints ist inhaltlich weitestgehend unverändert. Die Autoren betonten nochmal, dass der Sprint eine Entwicklung hin zur Erreichung des Produktziels im Fokus haben muss. Ausserdem stellten sie sicher, dass das Backlog Refinement teil des aktiven Sprints ist, auch wenn es nicht als eigenständige Zeremonie klassifiziert wurde. Dies ist meiner Meinung nach einer sehr guten Ergänzung, da sich oft die Frage stellte, wann das Backlog Refinement stattfinden soll.
Ebenfalls wurde das Unterkapitel „Cancelling a Sprint“ gestrichen und lediglich mit der folgenden Aussage abgedeckt: „A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint”. Es gibt keine klaren Handlungsanweisungen mehr wie in der Version von 2017.
Daily
Der die überarbeite Version gibt keine Vorgaben mehr bezüglich der Art und Weise der Durchführung. Das Daily soll weiterhin time-boxed in 15 Minuten abgeschlossen sein und die Erreichung des Sprintziels unterstützen und eine Transparenz bezüglich des nächsten Arbeitstags liefert. In der Version von 2017 wurde der Vorschlag erarbeitet die folgenden drei Fragen zu beantworten:
- What did I do yesterday that helped the Development Team meet the Sprint Goal?
- What will I do today to help the Development Team meet the Sprint Goal?
- Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
Dieser Vorschlag wurde restlos gestrichen. Auch die Rolles des Product Owners und Scrum Masters wurden in Bezug auf das Daily geschärft. Sollte der Product Owner oder Scrum Master an einem Item aus dem Sprintbacklog arbeiten, so nehmen sie als Developer an dieser Zeremonie teil.
Sprint Planning
Die zweiteilige Sprintplanung: Die Planung des „Was“ und die Planung des „Wie“ aus dem Scrum Guide von 2017 wurde nun um eine dritte Dimension ergänzt. Diese Dimension zielt auf die generelle Werthaltigkeit des Sprints ab und wird den anderen beiden Dimensionen vorangestellt.
Zusammenfassend beinhaltet dies gesamte Sprintplanung die folgenden drei Dimensionen:
- Topic One: Why is this Sprint valuable?
- Topic Two: What can be Done this Sprint?
- Topic Three: How will the chosen work get done?
Sprint Review
Während das Unterkapitel des Sprint Reviews in der Version von 2017 noch ausführliche Vorschläge bezüglich des Vorgehens bzw. der Durchführung der Zeremonie mitgegeben wurde, reduzierte man in der Version von 2020 sich auf die Betonung des Sinns des Sprintreviews. Das Sprintreview soll die getane Arbeit inspizieren und die zukünftige Arbeit evaluieren. Diese Zeremonie sollte sich nicht auf eine reine Präsentation beschränken, sondern vielmehr als Arbeitssession verstanden werden.
Scrum Artefakte
Nachdem die Rollen und die Zeremonien beleuchtet wurden, werde ich abschließend auf die Scrumartefakte eingehen.
Neuartig ist, ist dass die Artefakte nun in Bezug zueinander oder in Bezug auf die Ziele gestellt wurden.
Jedes Artefakt enthält eine Verpflichtung, sicherzustellen, dass es Informationen liefert, die die Transparenz und den Fokus erhöhen, an denen der Fortschritt gemessen werden kann:
- Für das Product Backlog ist es das Produktziel.
- Für das Sprint Backlog ist es das Sprintziel.
- Für das Inkrement ist es die Definition of Done.
Diese Verpflichtungen bestehen, um den Empirismus und die Scrum-Werte für das Scrum-Team und seine Stakeholder zu stärken
Sollten Sie noch weitere Fragen oder Anmerkungen bezüglich der neuen Version des Scrum Guides haben, so können Sie uns gerne kontaktieren!