19. Nov 2020
Was der neue Scrum Guide für XITASO bedeutet

Am 18. November 2020 wurde die neue Version des Scrum Guides veröffentlicht, die im Vergleich zu vorherigen Anpassungen substanzielle Veränderungen enthält. Was sich geändert hat und welche Auswirkungen dies auf die tägliche Arbeit bei XITASO hat, darüber berichtet unser Agile Coach Baptiste Grand.

Der neue Scrum Guide 2020 beinhaltet neben der Glättung und Modernisierung einiger Konzepte und Abschnitte auch die Abschaffung von Begriffen oder die Abschwächung starrer Vorgaben. Die Zielsetzung der Änderungen ist für mich klar: Weniger starre Regelungen erweitern den Spielraum für ein Scrum-Team, mit seinen Prozessen zu experimentieren, bietet mehr Autonomie und Freiheiten für „inspect and adapt“. Es geht vielmehr darum, dass das Scrum-Team ein gemeinsames Ziel erreicht. Der neue Scrum Guide vereinfacht viel Komplexität, die ursprünglich aus der Software-Umgebung stammt. Scrum 2020 wird so noch kompatibler für Teams, die nicht aus der Software-Entwicklung kommen, wie etwa Marketing-, Sales- oder Hardware-Teams.

In diesem Beitrag werden die wichtigsten Änderungen aufgegriffen und diskutiert.

Das Dev-Team ist formell abgeschafft

Die Abschaffung des Dev-Teams erscheint auf den ersten Blick eine fundamentale Veränderung zu sein. Andererseits sollte diese Änderung die geringsten Auswirkungen haben. Trotzdem hat es mich einige Zeit gekostet, diesen Einschnitt zu verstehen: Warum wird ausgerechnet das Entwicklungsteam, das Herz und der Motor von Scrum, abgeschafft? Weshalb wurde diese Entscheidung getroffen?

Im bisherigen Scrum findet man einige Antworten. Ich habe zahlreiche Materialien, mein gesammeltes Wissen und meine Erfahrungen auf den Prüfstand gestellt, aber am Ende hat mir ein Kollege, den ich dabei unterstützt habe, ein Professional Scrum Master zu werden, einen entscheidenden Impuls gegeben:

Denn alles, was das Dev-Team betrifft oder was man über das Dev-Team aussagen kann, lässt sich genauso gut über das Scrum-Team als Ganzes sagen: Selbstorganisation kennzeichnet beide. Cross-Funktionalität ebenfalls. Ein Inkrement, das die Definition of Done erfüllt, ebenso. Wenn man sich das folgende Zitat ansieht, kann man getrost den Begriff „Dev-Team“ durch „Scrum-Team“ ersetzen, ohne dass sich in der täglichen Arbeit etwas ändern wird.

„The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of ‚Done‘ product at the end of each Sprint. [..] Only members of the Development Team create the Increment.“

Wenn man also den Begriff „Dev-Team“ durch „Scrum-Team“ ersetzen kann, warum bräuchte man dann ein spezielles Sub-Team nur für die Entwicklung? Vereinfacht ausgedrückt braucht es lediglich ein Scrum-Team, das sich prototypisch aus Entwicklern, einem Product Owner und einem Scrum Master zusammensetzt.

Wenn aus diesem Grund einfach nur der Begriff „Dev-Team“ verschwindet, wäre das zu verschmerzen. Aber welche Auswirkungen hat das konkret? Ändert sich beispielsweise etwas am Sprint Backlog?

Was bedeutet das für das Sprint Backlog?

Vereinfacht ausgedrückt war bis zur Aktualisierung des Scrum Guides das Dev-Team der Owner des Sprint Backlogs, welches formal auch nur vom Dev-Team geändert werden konnte. Auf dieselbe Art und Weise, wie das Product Backlog in den Verantwortungsbereich des Product Owners fällt.

Diese Aufteilung sollte ursprünglich den Zweck erfüllen, Störungen vorzubeugen. Denn die Planungen sollten jeweils in den besten Händen liegen, damit das Scrum-Team am Ende des Sprints ein „Done“-Inkrement entwickeln konnte.

Nur was passiert nun mit dem Sprint Backlog? Wer pflegt das Backlog, wenn das Dev-Team als Owner abgeschafft ist? Und wenn die Ownership in den Verantwortungsbereich des Scrum-Teams als Ganzes fällt, wie geht man mit der möglichen Gefahr um, dass Product Owner oder Scrum Master in das Sprint Backlog eingreifen, um ihre eigenen Interessen zu verfolgen?

An dieser Stelle hilft es, sich daran zu erinnern, dass Scrum Individuen und deren Interaktionen stärker gewichtet als Prozesse und Tools.

„Individuals and interactions over processes and tools!“

Letztendlich war, ist und bleibt Kommunikation eines der entscheidenden Kriterien eines erfolgreichen Scrum-Teams, um Störungen vorzubeugen.

Das Sprint-Ziel wird ein Scrum-Artefakt

Diese Änderung ist meiner Meinung nach eine sehr gute Weiterentwicklung. Die Fähigkeit eines Scrum-Teams, sich selbst zu organisieren, seine Sprint-Ziele zu planen und zu erreichen, ist entscheidend. Ein Sprint-Ziel erzeugt Fokussierung und unterstützt die Entscheidungen, was während eines Sprints zu tun – oder nicht zu tun – ist.

Das Scrum-Team sollte sich deshalb jeden Tag fragen: Können wir das Sprint-Ziel erreichen? Wenn nein, in welcher Art und Weise müssen wir den Plan anpassen? Das Scrum-Team sollte keine Angst haben, geplante Backlog Items aus seinem geplanten Sprint zu entfernen, wenn es dem Sprint-Ziel dient. Aus diesem Grund wurden die Themen rund um das Scrum Planning im neuen Scrum Guide angepasst, das Sprint-Ziel zu einem Scrum-Artefakt aufgewertet und die Frage aufgenommen: Warum ist dieser Sprint wertvoll?

Mit der Aufwertung des Sprint-Ziels zu einem Artefakt wird stärker deutlich, wie wichtig es ist, etwas Werthaltiges zu liefern. Scrum-Teams werden dadurch gezwungen, ihre eigenen Ziele zu präzisieren. Somit wird auch dem Product Owner geholfen, in die Zukunft zu planen oder darüber nachzudenken, was das nächste Sprint-Ziel sein könnte. Oder sich vorzustellen, wie das Sprint-Ziel des nächsten Jahres aussehen könnte.

Das Produkt-Ziel ist ein neues Scrum-Artefakt

Die nächste Errungenschaft des Scrum Guides 2020 ist etwas völlig Neues, nämlich ein Fokus auf das Produkt-Ziel. Auf der einen Seite wird die Einführung anspruchsvoller Produkt-Ziele helfen, eine Produkt-Vision zu schaffen und wirkungsvolle Sprint-Ziele zu entwickeln. Auf der anderen Seite besteht in meinen Augen die Gefahr, dass viele Menschen diese Produkt-Ziele falsch anwenden werden, um etwa unpassende Techniken aus dem Projektmanagement in das Scrum-Framework hineinzupressen.

Die Idee, die hinter der Einführung von Produkt-Zielen steckt, ist jedenfalls gut. Es geht darum, eine übergeordnete Hierarchieebene in der Produkt-Definition zu schaffen, Features oder Meilensteine, die das Scrum-Team in den kommenden Monaten, Jahren oder Dekaden erreichen will. Produkt-Ziele sollen dabei helfen, Sprint-Ziele zu definieren, die zu eindeutigen Produkt Backlog Items führen. Mit der Hilfe von Produkt-Zielen kann man planen, eine Roadmap kreieren und eine Produkt-Vision transparent machen. Damit fokussiert man sich auf das „WHY“.

Jeden Tag versucht ein Scrum-Team, sich auf eine (Produkt-)Vision zu verständigen – und nicht darauf, die X Top-Items aus dem Produkt Backlog zu wählen, wobei X mit der Velocity des Teams zusammenpasst.

Stattdessen soll erreicht werden, dass das Scrum-Team die Items sorgfältig dahingehend auswählt, dass das aktuelle Produkt-Ziel erreicht wird. Ganz konkret nutzen Teams hierfür beispielsweise „Epics“ in Tools wie JIRA. Dort wurden „Epics“ jedoch viel zu oft dazu genutzt, verschiedene Produkt Backlog Items zu kategorisieren und nicht als große Features aufgefasst, die entwickelt werden sollen.

Die Aufnahme von Produkt-Zielen in den Scrum Guide 2020 soll also helfen, das Produkt Backlog aufzuräumen und Epics in klare und transparente Produkt-Ziele umzuwandeln, die das Scrum-Team erreichen will.

Scrum wird skalierbar

Scrum wurde ursprünglich dafür designet, von einem Scrum-Team umgesetzt zu werden. Einem Scrum-Team mit einem Produkt, einem Product Owner, einem Scrum Master, einem Dev-Team und einem Inkrement.

Aber mit zunehmender Komplexität von Projekten und Aufgaben ist das Bedürfnis entstanden, Scrum zu skalieren, komplexere Fragestellungen zu behandeln, denen ein Team allein nicht gewachsen ist. Heutzutage gibt es eine Vielzahl an Frameworks, die genau an dieser Stelle ansetzen und Erfolg zwar versprechen, in der Praxis aber mehr oder weniger gut funktionieren. Im Gegensatz zu diesen Frameworks ist Scrum diesem gewachsenen Bedarf nicht gerecht geworden – bis zu Scrum 2020.

Wenn Scrum-Teams zu groß werden, sollten sie in Betracht ziehen, sich in enger gefassten Scrum-Teams neu zu organisieren, von denen sich jedes einzelne Team auf dasselbe Produkt konzentriert. Dafür sollten sie dasselbe Produkt-Ziel, dasselbe Produkt Backlog und denselben Product Owner haben.

Die Veränderungen des Scrum Guides 2020 schaffen hier Klarheit. Es ist nun auch rein formell in Ordnung, wenn mehrere Scrum-Teams am selben Produkt arbeiten, solange sie dasselbe Produkt-Ziel verfolgen, dasselbe Product Backlog bearbeiten und denselben Product Owner haben. Wie dies die verschiedenen Scrum Scaled Frameworks beeinflusst, bleibt abzuwarten, ist aber auf jeden Fall spannend. Und Scrum ist jetzt endlich skalierbar, ohne dass man auf andere Frameworks zurückgreifen muss.

Autor & Ansprechpartner

Ihr habt Fragen, Ideen oder Feedback zu diesem Thema? Kontaktiert uns gerne!

Baptiste Grand
baptiste.grand@xitaso.com