Mehr Verantwortung - klare Ziele

Der Scrum Guide 2020

Am 18. November wurde – zum 25. Geburtstag von Scrum – der Scrum-Guide aktualisiert und liegt nun in der Version 2020 vor. Wir haben hier die wichtigsten Änderungen und Neuerungen zusammengefasst.  

Purposefully incomplete

Dass der Scrum Guide lediglich ein Framework – also ein Rahmen – für die optimale Gestaltung von Software- oder Produktentwicklung ist, war schon immer klar. Mit der neuen Version wird dieser Aspekt aber sehr deutlich hervorgehoben. Es obliegt jeder Organisation selbst, wie sie diesen Rahmen an ihre Organisation anpasst. Deshalb ist der neue Scrum Guide auch viel weniger methodenorientiert (beispielsweise gibt es nicht mehr dir klassischen drei Fragen für das Daily genauso wie das Schätzen als Methode zur Größenbestimmung von Backlog-Items entfällt), sondern stärker an Prinzipien und Sinn ausgerichtet.

Mehr Verantwortung für das ganze Team

Im neuen Scrum Guide erfährt das Scrum-Team eine deutliche Aufwertung. Einerseits geschieht das durch die Schaffung der Rolle des Developer - es gibt kein Development Team mehr, sondern nur noch die Rollen Product-Owner, Scrum-Master und Developer. Alle sind sie im gleichen Maß verantwortlich für die Erreichung ihrer Ziele, sitzen in einem Boot - es gibt keine Konkurrenz oder Hierarchie unter den Rollen und kein Sub-Team mehr. Zum anderen spricht der Scrum Guide nicht mehr von Rollen, sondern Accountabilities: Scrum Master, Product Owner und Developer sind Verantwortlichkeiten innerhalb des Teams, was das Team als Ganzes stärkt und dessen Einheit hervorhebt. Zudem spricht der neue Scrum Guide nicht mehr von einem selbstorganisierten Developer-Team, sondern von einem selbst-gemanagten Scrum-Team. 

Klare Ziele

Bisher gab es für jeden Sprint – neben den Backlog-Items (Tasks, User-Stories), die umgesetzt werden sollen – ein Sprint-Goal. Dieses Ziel für den aktuellen Sprint soll dem Team dabei helfen, sich auf das Wesentliche zu fokussieren und bei Entscheidungen zu priorisieren. Dasselbe gibt es jetzt auch das Product-Backlog: Das Product-Goal. Es hilft dabei auf zweierlei Weise:

• Als Planungsgrundlage für das Scrum-Team: Jeder Sprint sollte das Produkt näher zum Product Goal bringen.
• Es hilft dem Scrum Team, den Fortschritt seiner Arbeit am Product Backlog sichtbar und messbar zu machen. 

Um dem Sprint-Goal Gewicht zu verleihen, ist es zudem in den Kontext des Planning eingeordnet und erweitert die Ziele dieses Termins um die Frage „Warum ist der Sprint wertvoll für den Kunden/Stakeholder“. Die Frage ist so wichtig, weil man dadurch einen guten Überblick bekommt, ob zum einen alle dasselbe Verständnis vom Sprint haben und zum Anderen wir als Dienstleiter dem Kunden gut genug erklärt haben, warum wir tun was wir tun und auch die Wertschöpfung des Kunden und die daraus abgeleiteten Anforderungen gut zueinander passen.

Commitments

Scrum definiert drei wesentliche Artefakte: Das Product Backlog, das Sprint Backlog und das Increment (also das Ergebnis eines Sprints). Mit dem neuen Scrum Guide erhält jedes der Artefakte ein Commitment: Das Product Goal, das Sprint-Goal und die Definition of Done. Diese Commitments werden oft als bloße Versprechen, etwas zu liefern falsch verstanden. Die Commitments dienen dazu, den Sinn des Artfekats klar zu machen und die Qualität des Ergebnisses zu maximieren. Das wird auch dadurch verstärkt, dass der neue Scrum Guide nicht mehr an einem Increment als Sprintergebnis festhält, sondern dass jedes Mal, wenn ein Backlog-Item die Definition of Done erfüllt, ein Increment entsteht.

Neues Verständnis der Verantwortlichkeiten von Scrum Master, Product Owner und Developer

Alle drei Verantwortlichkeiten haben sich gegenüber der Vorgängerversion deutlich geändert: 

Product Owner

Der Product Owner ist nicht mehr länger “nur” der verlängerte Arm der Kunden/Stakeholder und dessen Wünschen, sondern tatsächlicher „Owner“ des Backlog. Er berücksichtigt nach wie vor die Bedürfnisse des Kunden, darf dessen Erwartungen und Ideen aber challengen und bestimmt letztendlich, was ins Backlog aufgenommen wird. Der Scrum Guide spricht jetzt davon, dass es Aufgabe der Stakeholder ist zu versuchen, den Product Owner von Änderungen im Backlog zu überzeugen.

Scrum Master

Den Begriff des Servant Leader gibt es nicht mehr. Stattdessen wird der Scrum Master als „true leaders who serve the Scrum Team and the larger organization“ gesehen. Damit wird er in der Organisation aufgewertet und die Rolle hervorgehoben, denn vielfach wird der Scrum Master als besserer Assistent gesehen und seine Stärken, die oft im Gebrauch von Soft-Skills und einem guten Prozessverständnis liegen missachtet.

Developer

Genauso, wie der Product Owner gegenüber seinen Kunden gestärkt wird, werden die Developer gegenüber dem Product Owner gestärkt: z.B. wird im neuen Scrum Guide auf das explizite Schätzen verzichtet: Es wird nur noch davon gesprochen, dass die Developer die „size“ eines Backlog-Items bestimmen (also auch z.B. von Tasks) – das heißt auch, indem sie die Items z.B. schneiden oder generell die Größenordnung bestimmen.

Insgesamt soll das für ein ausgewogenes Team sorgen, das auf Augenhöhe agiert und einen starken Platz in der Organisation einnimmt und so für den Kunden den maximalen Mehrwert liefert – denn das ist immer noch der Hauptzweck von Scrum: In der kürzesten Zeit den größten Wert für den Kunden zu schaffen.