TalkAbout

Zum 25: Das steckt im neuen Scrum Guide

Von Korbinian Erdmann @KF_Erdmann auf Twitter
19. November 2020

Vor 25 Jahren erblickte „Scrum“ das Licht der Welt, als seine Erfinder Jeff Sutherland und Ken Schwaber es 1995 als Konferenzpaper einer breiteren Öffentlichkeit vorstellten.[1] Dieses Jahr, am 18. November 2020, stellten die beiden die neueste, mittlerweile siebte Version des Scrum Guides vor, die die Version vom November 2017 ersetzt. Der Scrum Guide 2020[2] definiert den gegenwärtigen Soll-Zustand des Frameworks. Eine neue Scrum Guide Version hat weitreichende Implikationen, orientieren sich doch Scrum-Implementierungen weltweit an diesem Dokument. Darüber hinaus dient es natürlich auch als Grundlage für alle Scrum-Zertifizierungen – Grund genug also, sich die Neuerungen in der 2020-Version einmal anzuschauen.[3]

Im Folgenden werde ich die meiner Meinung nach wichtigsten Änderungen im Vergleich zur vorhergehenden Version umreißen. Dabei habe ich nicht den Anspruch alle Änderungen vollständig abzubilden, sondern schaue mir die großen Tendenzen an: Welche grundlegenden Änderungen finden wir im neuen Guide? Mit welchen begrifflichen Änderungen gehen sie einher? Und was ist die Absicht dahinter?

Nicht nur für die Software-Entwicklung

Beim Blick in den neuen Guide fällt eines sofort auf: Der neue Scrum Guide ist deutlich kürzer, präziser und einfacher verständlich als die 2017-Version. Entfallen sind auch die allermeisten Fachbegriffe aus dem IT-Kontext, wie etwa Cloud, testing, architecture oder operations. Das Ziel ist hier eindeutig: Das Framework noch flexibler und adaptiver für Nicht-IT-Kontexte zu machen. Dieser Trend, Scrum auch jenseits der IT einzusetzen, besteht schon seit mehreren Jahren, somit spiegelt der neue Guide die Realität, wenn er sich in den Bezeichnungen weniger IT-spezifisch gibt.[4]

Darüberhinaus beschreibt sich Scrum nun ausdrücklich als absichtlich unvollständig („purposefully incomplete“). Hier wird noch deutlicher gemacht, dass Scrum eben ‚nur‘ ein Rahmenwerk darstellt, dessen praktische Ausgestaltung letztlich denen überlassen bleibt, die damit arbeiten. Entsprechend entfallen auch konkrete Methodenvorschläge, wie etwa die klassischen drei Fragen für das Daily: „Was habe ich gestern gemacht, was auf das Sprintziel einzahlt? Was werde ich heute tun? Was für Impediments stehen mir im Weg?“ Diese tauchen im neuen Guide nicht mehr auf – wie lange es dauern wird, bis Teams sich von der Formel lösen können, bleibt abzuwarten.  

Produktgedanke gestärkt

Die wichtigsten inhaltlichen Änderungen im 2020 Scrum Guide: eine Stärkung des Produktgedankens und mehr Fokus auf die Einheit des Scrum Teams.

Auf den ersten Blick fällt auf, dass es jetzt als neuen Begriff das „Product Goal“ gibt. Dieser ersetzt das früher verwendete „Vision“ und ist auch prominenter platziert. „Vision“ wurde als zu vage empfunden, während „Product Goal“ konkreter danach fragt, was mit dem Produkt genau erreicht werden soll. Dieser Fokus wird noch verstärkt durch den ebenfalls neuen Zusatz, dass es für ein Scrum Team immer nur ein Product Goal geben kann – bevor man ein neues in Angriff nimmt, muss man erst das alte erreichen oder bewusst fallenlassen. Das Scrum Team fokussiert sich ganz auf das entstehende Product und verpflichtet sich auf das zugehörige Product Goal.

Das „Product Goal“ gesellt sich zum schon bekannten „Sprint Goal“, das die Sinnhaftigkeit des Sprints hervorheben soll. Beide Ziele, „Product Goal“ und „Sprint Goal“, sollen Teams dabei helfen, sich auf das eigentlich Wichtige ihrer Arbeit zu fokussieren. Das „Product Goal“ dient somit der Organisation und Priorisierung des Backlogs, das „Sprint Goal“ bietet bekanntermaßen den Fokus für das Sprint Backlog, die „Definition of Done“ bietet eine ähnliche Orientierung hinsichtlich der Qualität der entstehenden Inkremente. Zusammen werden „Product Goal“, „Sprint Goal“ und „Definition of Done“ jetzt als “Commitments” für ihr jeweiliges Artefakt bezeichnet. Eine Änderung sei an dieser Stelle hervorgehoben: Im Sprint können nun mehrere Inkremente entstehen, nämlich jedes Mal, wenn ein Product Backlog Item die Definition of Done erfüllt.

"Team" neu vermessen

Neben einer Stärkung des Produktfokus schärft der neue Scrum Guide den Begriff des Teams. Um den Teamgedanken zu stärken, verschwindet im aktuellen Scrum Guide der Begriff des Development Teams, stattdessen wird nun von „Developers“ gesprochen. Der Teambegriff findet also nur noch auf das Scrum Team Anwendung und wird damit deutlich präziser. Hiermit soll zum Ausdruck kommen, dass Developers, Product Owner und Scrum Master in einem Boot sitzen und Product Owner und Development Team keine Gegenspieler sein sollen. Innerhalb des Scrum Teams soll es weiterhin keine Subteams geben. Da das Development Team strenggenommen ein Subteam des Scrum Teams war, wird hier nun Klarheit geschaffen und Grenzen abgebaut.

Eine weitere große Änderung: Der 2020er Scrum Guide spricht nicht mehr von Rollen, sondern von Verantwortlichkeiten. Developers, Product Owner und Scrum Master sind also jetzt Verantwortlichkeiten innerhalb des Scrum Teams, was die Wichtigkeit des Teams als Einheit unterstreichen soll. Die Aufwertung des Teams gegenüber einer etwaigen Organisation zeigt sich auch darin, dass das Team nicht mehr nur self-organizing sein soll, sondern jetzt von self-managing die Rede ist.

Aufwertung von Scrum Master und PO

Eine deutliche begriffliche Aufwertung erfahren die Scrum Master – diese werden nicht mehr als Servant Leader bezeichnet, sondern als „true leaders who serve the Scrum Team and the larger organization“. Mit dieser Änderung reagieren Sutherland und Schwaber darauf, dass die Scrum Master Verantwortlichkeit in ihrer Wahrnehmung in vielen Organisationen auf Sekretärstätigkeiten und Protokollantendienste verengt wird. Das ist insofern eine interessante Entwicklung, als der Scrum Master schon bei seiner Ersterwähnung 1998 explizit als „Team Leader Role“ bezeichnet wurde.[5] Dieser Leadership-Aspekt trat in den letzten Jahren immer mehr in den Hintergrund und wird nun wieder explizit gestärkt, insofern könnte man hier ansatzweise eine Rolle rückwärts erkennen.[6]

Deutlich gestärkt wird außerdem die Position des Product Owners seinen Stakeholdern gegenüber: Aus der 2017er Version des Guides konnte noch herausgelesen werden, dass der Product Owner die Wünsche eines Komitees von Stakeholdern nur repräsentieren und ordnen kann, auch wenn das damals schon nicht der Idealvorstellung entsprach.[7] In der 2020er Version ist diese Möglichkeit verschwunden, der Product Owner repräsentiert hier nur noch die Bedürfnisse der Stakeholder, die ihn noch dazu überzeugen müssen, um ihre Vorstellungen in das Product Backlog zu bekommen.[8] Der Product Owner wird innerhalb seiner Organisation dadurch mächtiger, dafür werden die Developers dem Product Owner gegenüber nun gestärkt. Das sieht man unter anderem daran, dass die Begriffe "Schätzung" oder "schätzen" im aktuellen Scrum Guide nicht mehr enthalten sind – im 2017er Guide fand sich „estimate“ in verschiedenen Formen noch sieben Mal. Stattdessen findet sich nun der Begriff „size“ in Bezug auf Backlog Items, wobei betont wird, dass die Festlegung dieser Größe bei den Developern liegt. Hier erfahren die Developer also eine Aufwertung: Sie schätzen nicht einfach die Größe vorgegebener Backlog Items sondern bestimmen aktiv deren Größe, etwa, indem sie sie kleiner schneiden.

Mehr Verantwortung in einem gestärkten Team

Die Absicht des Scrum Guides von 2020 ist klar: das gesamte Scrum Team soll sich für das Produkt verantwortlich fühlen und das Team soll eine hierarchiefreie Einheit sein, das sich als Ganzes auf strategische Ziele (Product Goal, Sprint Goal) und Qualitätsmaßstäbe (Definiton of Done) verpflichtet – eine deutliche Antwort auf Scrum-Implementierungen, wo der Product Owner am Anfang des Sprints bei den Entwicklern eine Liste von Product Backlog Items bestellt und am Ende des Sprints auf den Tisch haut, wenn er sie nicht vollumfänglich geliefert bekommt.

Soweit die meiner Meinung nach auffälligsten Änderungen des neuen Scrum Guides, die ich an dieser Stelle bewusst nicht in ihrer Sinnhaftigkeit bewerten möchte. Ich gestatte mir aber die Befürchtung, dass es besonders in sehr klassisch-hierarchisch organisierten Konzernen einige Reibungspunkte geben dürfte, besonders was die Stärkung von Scrum Master und Product Owner betrifft, aber auch das Self-Management der Developers. Das ist aber nicht neu, denn Reibungspunkte von Ist und Soll gibt es schon, seit es Scrum gibt. Wie sehr sich die neuen Definitionen und Terminologien in freier Wildbahn durchsetzen, wird die Zukunft zeigen. Dem Erfolg von Scrum werden aber auch terminologisch unterschiedliche Implementierungen keinen Abbruch tun, schließlich hat Jeff Sutherland bei der Vorstellung des neuen Guides selbst gesagt: „Scrum hasn’t changed at all. We’re just finding ways of describing it better.“[9]

 

[1] Nämlich auf der OOPSLA-Konferenz in Austin, Texas. Das entsprechende Paper findet sich hier: http://www.jeffsutherland.org/oopsla/schwapub.pdf

[2] https://www.scrumguides.org/scrum-guide.html

[3] Vgl. auch die Revisionshistorie auf https://www.scrumguides.org/revisions.html.

[4] Ein Beispiel dafür, dass der Guide präziser als sein Vorgänger ist, findet man gleich zu Beginn: Hat der 2017-Guide dem Leser auf der ersten Seite noch drei leicht verschiedene Definitionen von Scrum angeboten, so liefert der aktuelle Guide nur noch eine: „Scrum is a lightweight framework that helps people, teams, and organisations generate value through adaptive solutions for complex problems.“

[5] Vgl. Beedle, Devos, Sharon, Schwaber, Sutherland, Scrum: An extension language for hyperproductive software development. http://jeffsutherland.org/scrum/scrum_plop.pdf.

[6] Noch 2012 ist die Führungsfunktion des Scrum Masters sehr explizit, vgl. Schwaber, Sutherland, Software in 30 days, 2012, S. 57. „The Scrum Master manages the project the Scrum way.“

[7] „The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.“

[8] „The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.“

[9] Ein Video davon gibt es hier: https://scruminc.cmail20.com/t/j-l-atldyyd-ijjudkjtht-j/

Neuen Kommentar schreiben

Public Comment form

  • Zulässige HTML-Tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd><p><h1><h2><h3>

Plain text

  • Keine HTML-Tags erlaubt.
  • Internet- und E-Mail-Adressen werden automatisch umgewandelt.
  • HTML - Zeilenumbrüche und Absätze werden automatisch erzeugt.

ME Landing Page Question