Jetzt Andreas Scrum-Trainings auf scrum.org buchen
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.
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.
Ein 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
Bisher 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”.
Das 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):
- die des Product Owners,
- die des Scrum Masters
- 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.
- Das Produktziel wird vom Product Owner entwickelt und kommuniziert. Es ist das langfristige Ziel des gesamten Scrum Teams.
- 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.
- 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
Jetzt Andreas Scrum-Trainings auf scrum.org buchen
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.
- PSM | Professional Scrum Master
- PSPO | Professional Scrum Product Owner
- PSD | Professional Scrum Developer
Scrum Guides
War dieser Beitrag hilfreich?
Weitere Beiträge
von Andreas Ebbert-Karroum
27.6.2018 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Andreas Ebbert-Karroum
Agile Principal Consultant
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.