Scrum Guide 2020 – Die wichtigsten Änderungen

Keine Kommentare

Der aktuelle Scrum Guide 2020 ist der Kern von Scrum. Was hier nicht drin steht, ist kein Scrum. In regelmäßigen Abständen wird der Scrum Guide von Ken und Jeff höchstpersönlich an neue Erkenntnisse angepasst und aktualisiert. Dieser Post geht auf die einzelnen Änderungen ein. Er hilft dir und deinem Team zu verstehen, was diese Änderungen für euch in der täglichen Arbeit bedeuten. 

YouTube

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren

Video laden

Weniger ist Mehr

Leitmotiv für den neuen Scrum Guide ist eine Vereinfachung in der Sprache und der Länge. Scrum als Framework muss durch euch ganz individuell ausgestaltet werden – jetzt mehr denn je. Hilfestellungen und Vorschläge wurden aus dem Scrum Guide entfernt und können an geeigneter Stelle woanders veröffentlicht, besprochen und aktualisiert werden.  

Genauso wurden alle Referenzen zur IT entfernt. Schließlich ermöglicht Scrum ganz allgemein ein empirisches Vorgehen zur komplexen Problemlösung. Ob sich diese komplexen Probleme nun durch Software oder etwas ganz anderes lösen lassen, ist unerheblich. 

Weniger ist Mehr im Scrum Guide 2020Ein Beispiel für etwas Entfallenes sind die drei berühmt-berüchtigten Fragen des Daily Scrums. Diese haben in der Vergangenheit oft dazu geführt, das Daily Scrum zu einem Status-Report-Meeting verkommen zu lassen. Alternativ kann sich das Scrum Team auch einfach am Sprint Backlog orientieren.

Des Weiteren identifiziert ein Scrum Team in einer Retrospektive nach wie vor die wirkungsvollsten Verbesserungen. Ob diese Verbesserungen aber zwingend dem nächsten Sprint Backlog hinzugefügt werden oder nicht, bleibt offen. 

Ein Team

Product Owner, Scrum Master und Development Team Rollen im Scrum TeamBisher gab es in Scrum drei Rollen: Product Owner, Scrum Master und Development Team. Zusammen bildeten sie das Scrum Team. So entstand ein Scrum Team eher als Sekundärprodukt. Als ein Konglomerat aus Individuen, welche mehr oder weniger zufällig zusammen arbeiten mussten.

Jetzt dreht der Scrum Guide 2020 den Spieß um! An erster Stelle steht das Scrum Team als fundamentale Einheit aus festen Mitgliedern. Dieses Team, das Scrum Team, ist der konstante Kern und gemeinsam verantwortlich für die Erstellung eines wertvollen und einsatzbereiten Increments. 

Kein Team-im-Team mehr! Kein Developer gegen Product Owner und der Scrum Master muss deren Konflikte lösen. Kein “ich bin Scrum Master für diese 17 Teams – und mache das nur nebenbei”. Kein “ich bin zwar Product Owner, habe aber keine Zeit! Wenn ihr Glück habt, dann kann ich bei der Sprint Planung dabei sein. Ansonsten bin ich leider zu beschäftigt”. 

Ein festes Scrum Team mit den Verantwortungen des Developers, Scrum Masters und dem Product Owner nach dem Scrum Guide 2020Das Scrum Team ist das Fundament. Diese Leute arbeiten zusammen und sind gemeinsam verantwortlich! Um die Arbeit zu strukturieren gibt es drei Verantwortungen im Scrum Team (keine Rollen):

  1. die des Product Owners,
  2. die des Scrum Masters
  3. die des Developers.

Das Scrum Team zeichnet sich gemeinsam für alle produktbezogenen Aktivitäten verantwortlich: vom Stakeholder-Management, über Produktexperimente, Forschung, Entwicklung, Betrieb, Wartung … alles was dazu gehört. Das ganze Paket. Dazu muss es alle notwendigen Fähigkeiten im Team haben, um mit jedem Sprint ein wertvolles Increment herstellen zu können.

Tschüß Selbst-Organisation

Eine vermeintlich große Änderung ist, dass das Scrum Team nicht mehr selbst organisierend (engl.: self-organizing), sondern selbstverwaltend (engl.: self-managing) ist. Die Änderung ist gar nicht so groß, wie man zuerst vermuten könnte. Es werden im wesentlichen die Vokabeln an das Gemeinte angepasst.

Im alten Scrum Guide wird von den selbst-organisierenden Teams gefordert, dass sie selbst entscheiden wie sie die eigene Arbeit gestalten. In Hackmans „Leading Teams“ sind selbst-organisierende Teams (dort: self-designing) auch für die Team-Konstellation im Unternehmen verantwortlich. Sie entscheiden selbst, wer Teil des Teams ist und wer nicht. Somit besteht hier ein Mismatch zwischen der gebrauchten Vokabel im Scrum Guide (Selbst-Organisation) und dem Gemeinten (die eigene Arbeit verwalten).

Ziel des Scrum Guide 2020 war eine Vereinfachung. Im Einklang damit wird von einem Scrum Team „nur“ vorausgesetzt, dass es selbst-verwaltend ist. 

Habt ihr euch mal folgendes überlegt? Es liegt ein stärkerer Fokus auf dem Scrum Team. Die Verantwortungen sind team-intern. Und ein selbstverwaltenden Scrum Team kann selbst entscheiden, wer was macht. Das heißt doch, dass ein Scrum Team eigentlich frei darin ist, auch die Verantwortungen des Scrum Master, des Product Owners und des Developers intern zu regeln. Cool, oder?

Sprint Planning

Das Sprint Planning besteht aus den Teilen “Planning 1” und “Planning 2”? Nicht ganz. Das war früher einmal so. Selbst im Scrum Guide 2017 ist nur noch von zwei Themen bzw. Topics die Rede. Das erste Thema ist das “Was”: der Inhalt des nächsten Sprints. Das zweite Thema das “Wie”: die Planung oder Konzeption der technischen Realisierung des Increments. Diese beiden Themen können zeitlich aufeinanderfolgend stattfinden, müssen sie aber nicht. 

Im Scrum Guide 2020 werden diese zwei Themen noch um ein Drittes ergänzt: das “Warum”. Das neue dritte Thema “Warum” ergänzt also die beiden bisherigen Themen “Was” und “Wie”. Es beantwortet die Frage: “Warum ist dieser Sprint überhaupt wertvoll?” oder “Wie können wir den Wert unseres Produktes am besten steigern?” 

Das Sprintziel wird vom Scrum Team gemeinsam erstellt. Dadurch enthält der Sprint eine verpflichtende Ausrichtung. Ausgangspunkt für das Sprintziel ist ein Vorschlag des Product Owners. Während der Sprintplanung kann der Vorschlag vom gesamten Scrum Team zur Formulierung des Sprintziels genutzt werden.  

Das Produktziel

Ein vollständig neues Konzept ist das Produktziel. Wie soll das gehen mit mehreren Scrum Teams, oder sogar mehreren Produkten? Dazu sollte man sich zuerst in Erinnerung rufen, dass der Scrum Guide für ein Scrum Team mit einem Produkt gedacht ist. Somit sind Anpassungen bei mehreren Produkten oder mehreren Scrum Teams immer notwendig. 

Damit das Product Backlog nicht zu einem Sammelsurium an inkohärenten Tasks, Features und Bugfixes verkommt, steht das Produktziel quasi als Überschrift über dem Product Backlog. Unter dem Strich setzt es den Product Owner auch ein wenig unter Zugzwang, das Product Backlog wertoptimierend zu strukturieren.

Wenn die Produktvision der Leuchtturm am Horizont ist, dann ist das Produktziel eine Etappe auf der Reise dorthin. Jeder Sprint sollte das Produkt näher an das Produktziel bringen. Idealerweise kann dieses “Annähern” direkt durch Metriken validiert werden. Ein neues Produktziel kann und sollte das alte erst ersetzen, wenn dieses (gut genug) erreicht wurde, oder aus anderen Gründen verworfen werden kann. 

Die drei Selbstverpflichtungen

Neben den prominent von Scrum geforderten Rollen, Artefakten und Events, waren im Scrum Guide auch andere Dinge beschrieben. Diese standen aber eher lose neben den Rollen, Artefakten und Event. Dies war zum Beispiel das Sprintziel oder die Definition of Done.

Mit der Formulierung des Produktziels ist es jetzt möglich, den drei Artefakten drei sogenannte Selbstverpflichtungen (oder auf Englisch commitments) zuzuordnen. Diese Selbstverpflichtungen schützen vor schwammigen und beliebigen Artefakten. Sie fördern Fokus und Transparenz und machen Fortschritt sichtbar und messbar.

Zum Product Backlog gehört das Produktziel, zum Sprint Backlog das Sprintziel, und zum Increment die Definition of Done.  

An dieser Stelle lohnt eine Übersicht, wer die Selbstverpflichtungen erstellt und wer sich daran gebunden fühlen sollte. 

  1. Das Produktziel wird vom Product Owner entwickelt und kommuniziert. Es ist das langfristige Ziel des gesamten Scrum Teams. 
  2. Zur Erstellung des Sprint Ziels arbeitet das gesamte Scrum Team zusammen. Es ist die selbstverpflichtende Zielvorgabe der Developer für den Sprint. Gute Sprintziele leiten und bündeln den Fokus des gesamten Scrum Teams. Gleichzeitig sind sie flexibel genug, um den Sprint Forecast nicht exakt in Stein zu meißeln. 
  3. Die Definition of Done des Increments ist eine Eigenkreation des Scrum Teams. Vorgaben der Organisation sollten berücksichtigt werden. Die Developer verpflichten sich, die Definition of Done für das Increment einzuhalten.

Fazit

Das waren auch schon die größten Änderungen und Aktualisierungen des Scrum Guides 2020. Wie denkt ihr darüber: Sind dies lediglich kleine Details und Wortklaubereien, oder stellt es Scrum für euch in ein ganz neues Licht?

Praktische Tipps zum Kick-Start für dein Team mit dem Scrum Guide 2020

Damit ihr direkt mit dem neuen Scrum Guide in eurem Team starten könnt, sind im folgenden „Cheat-Sheet“ die Änderungen aufgelistet. Dazu gesellen sich praktische Hinweise für das Produktziel, das Sprintziel und die Definition of Done.

Jetzt herunterladen, ausdrucken und loslegen: Praktische Tipps zum Scrum Guide 2020

Außerdem würde ich mich sehr freuen, euch oder eure Kolleginnen und Kollegen bei einer meiner nächsten Scrum Trainings begrüßen zu dürfen. Diese finden übrigens aktuell komplett virtuell und remote statt.

Scrum Guides

Andreas Ebbert-Karroum

Agile Principal Consultant bei der codecentric AG.

Andreas Ebbert-Karroum hat mit seinen über 20 Jahren Erfahrung in der Softwareentwicklung (wenn man die ersten Anfänge auf dem Commodore C16 und den ersten eigenen PCs vernachlässigt) und 15 Jahren Erfahrung in agilen Projekten den Wert „Agilität“ 2008 mit zur codecentric gebracht. Scrum-Teams hat er in allen Rollen (Entwickler, Scrum Master, Product Owner) verstärkt, als Agiler Coach begleitet oder agile Methoden und Werte in ganzen IT-Abteilungen und Unternehmen eingeführt.

Seit 2010 ist Andreas Ebbert-Karroum Trainer bei scrum.org und hält mit den Zertifikaten für PSD, PSM I / II / III und PSPO I / II die Schulungen:

Über 1.000 Abonnenten sind up to date!

Die neuesten Tipps, Tricks, Tools und Technologien. Jede Woche direkt in deine Inbox.

Kostenfrei anmelden und immer auf dem neuesten Stand bleiben!
(Keine Sorge, du kannst dich jederzeit abmelden.)

* Hiermit willige ich in die Erhebung und Verarbeitung der vorstehenden Daten für das Empfangen des monatlichen Newsletters der codecentric AG per E-Mail ein. Ihre Einwilligung können Sie per E-Mail an datenschutz@codecentric.de, in der Informations-E-Mail selbst per Link oder an die im Impressum genannten Kontaktdaten jederzeit widerrufen. Von der Datenschutzerklärung der codecentric AG habe ich Kenntnis genommen und bestätige dies mit Absendung des Formulars.

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.