Am 18. November 2020 wurde der neue Scrum Guide 2020 offiziell vorgestellt. Mit der neuen Version des Scrum Guides feiert die Scrum Community das 25-jährige Bestehen von Scrum. Jeff Sutherland und Ken Schwaber haben mit Unterstützung der Scrum Community Aktualisierungen vorgenommen, um den Scrum Guide knackiger, schlanker und transparenter zu machen. In diesem Artikel lesen Sie, was sich Wesentliches geändert hat und was die Gründe dahinter sind. Lesen Sie weiter, damit Sie auf dem neusten Stand sind.
Basierend auf 25 Jahren Erfahrung
Im Jahr 2000, gleich nach dem eigentlichen agilen Manifest, umfasste gemäss Ken Schwaber die erste Version des Scrum-Guides 160 Seiten und hatte sieben Phasen. Die erste offiziell veröffentlichte Version im Jahr 2010 von ScrumAlliance® umfasste 13 Seiten. Der Scrum Guide entwickelte sich immer weiter mit dem Ziel, nicht nur in Software-Entwicklungsprojekten anwendbar zu sein, sondern in allen Gebieten, wo etwas Neues entsteht.
Die letzte Version des Scrum Guides erschien 2017. Die neueste Version wurde am 18. November 2020 vorgestellt, ist noch schlanker, hat noch weniger Ausdrücke und ist noch weniger vorschreibend.
Gemäss den Autoren ist der aktualisierte Scrum Guide schlanker, aber sein Kern bleibt empirisch. Die Grundpfeiler Transparenz, Inspektion und Anpassung (Transparency, Inspection and Adaptation) sind nach wie vor die Eckpfeiler guten Scrums. Der aktualisierte Scrum Guide basiert auf 25 Jahren Scrum, das von der Scrum Community praktiziert wird.
Scrum hasn’t changed at all—we’re just getting the description better”
Jeff Sutherland
Die folgende Beschreibung ist die Zusammenfassung, die auf der Website von scruminc.com gelesen werden kann. Hier finden Sie die wichtigsten Änderungen im Vergleich zur Version 2017 des Scrum-Guides.
Das sind die wesentlichen Änderungen
Noch weniger vorschreibend
Im Laufe der Jahre wurde der Scrum-Guide immer einschränkender. Die Version 2020 zielt darauf ab, Scrum wieder zu einem minimal ausreichenden Rahmenwerk zu machen. Dies wurde erreicht, indem die Daily Scrum-Fragen entfernt wurden, die Sprache um PBI-Attribute und Retro-Items im Sprint Backlog aufgeweicht wurde, der Abschnitt zur Sprint-Absage (sprint cancelation) gekürzt wurde und vieles mehr.
In dieser Form bildet der Scrum Guide ein solides, Fundament ohne stark einzuschränken und kann so situativ und abhängig von der Erfahrung des Teams, mit Best Pratices und eigenen Erfahrungen ergänzt werden.
Ein Team, fokussiert auf ein Produkt
Ziel war es, das Konzept eines separaten Teams innerhalb eines Teams zu beseitigen, das zu einem “uns und denen” Verhalten zwischen dem Product Owner und dem Development Team geführt hat. Der Begriff “Development-Team” wurde abgeschafft. Es gibt jetzt nur noch ein Scrum-Team, das sich auf dasselbe Ziel konzentriert und drei verschiedene Arten von Verantwortlichkeiten hat: Product Owner, Scrum Master und Entwickler (jeder, der am Sprintinkrement arbeitet). Dies stärkt den Teamgedanken, die Zusammenarbeit und den Fokus auf das zu entwickelnde Produkt.
Einführung des Produktziels
Der Scrum-Guide 2020 führt das Konzept eines Produktziels ein, um das Scrum-Team auf ein größeres, wertvolles Ziel auszurichten. Jeder Sprint soll das Produkt näher an das übergeordnete Produktziel bringen.
Der Product Owner ist dafür verantwortlich, sicherzustellen, dass das Product Backlog ein Ziel hat, welches das Team versteht, sich dafür begeistert und sich dafür einsetzt – und das ganze Team sich gemeinsam darauf zubewegt.
Ein Heim für das Sprint-Ziel, Definition of Done und Produkt-Ziel
Frühere Scrum-Guides beschrieben das Sprint-Ziel und die Definition of Done, ohne ihnen wirklich eine Identität zu geben. Sie waren nicht ganz Artefakte, sondern hingen irgendwie an Artefakten. Durch Hinzufügen von “Produktziel” bietet die Version 2020 mehr Klarheit. Jedes der drei Artefakte enthält nun Verpflichtung (Committment) gegenüber diesen.
Beim Product Backlog handelt es sich um das Produk-Ziel, beim Sprint Backlog um das Sprint-Ziel und beim Inkrement um die Definition of Done. Sie existieren, um Transparenz und Fokus auf den Fortschritt jedes Artefakts zu bringen.
Selbstmanagt über Selbstorganisierend
Frühere Scrum-Guides bezeichneten Entwicklungsteams (Teammitglieder, die am Sprintinkrement arbeiten) als selbstorganisierend, indem sie selber auswählen, wer welche Arbeit macht und wie diese gemacht werden sollen. Mit einem stärkeren Fokus auf das Scrum-Team betont die Version 2020 ein sich selbst-mangendes Scrum-Team, das selber bestimmt, was gemacht wird, wer es macht wie es gemacht werden soll. Die Absicht mit “self-manging” ist ein noch höherer Grad an Selbstbestimmung
Drei Sprintplanungsthemen
Zusätzlich zu den Sprint Planning Themen “Was” und “Wie” legt der Scrum-Guide 2020 den Schwerpunkt auf ein drittes Thema, dem “Warum”. Dieses sich auf das Sprint-Ziel.
Gemäss Jeff haben großartige Scrum Teams immer alle drei Fragen beantwortet. Nur das “Warum” war nicht im Guide aufgeführt. Jetzt geht es also um das Warum, das Was und das Wie. Diese Begriffe hört man immer wieder in Agil. Beginnen Sie mit dem Warum – das ist der beste Anfang! Es hilft, alle auf die gleiche Seite zu bringen und alle zu motivieren, wenn das Scrum-Team weiß, warum es tut, was es tut.
Great Scrum teams have always answered all three questions. The Why? What? and How? It’s just that Why wasn’t listed in the guide.”
Allgemeine Vereinfachung der Sprache für ein breiteres Publikum
Der Scrum-Guide 2020 legt den Schwerpunkt darauf, redundante und komplexe Aussagen zu eliminieren und alle verbleibenden Rückschlüsse auf die IT-Arbeit (z.B. Test, System, Design, Anforderung, etc.) zu beseitigen. Durch die Verallgemeinerung von Begriffen und Vereinfachung der Sprache soll Scrum Guide noch universeller anwendbar, z.B. in der Industrie, dem Gesundheitswesen oder anderen Wirtschaftszweigen. Der Scrum-Guide umfasst jetzt weniger als 13 Seiten.
Ist der Scrum Guide tatsächlich besser geworden?
Ich war schon immer für einfache, gut verständlich und allgemein anwendbare Projektmanagementmethoden, die den Anwendern einige wenige, aber einzuhaltende Regeln gibt und Grundwerte definiert, aber auch viel Freiheit gibt, wie dann die Arbeit nach Best-Practices umgesetzt wird. Diese Strategie hat auch der Scrum Guide.
Nach meiner Meinung ist das Scrum-Guide-Überarbeitungs-Team dieses mal zu weit gegangen und hat den Guide so “neutralisiert” und vereinfacht, damit Scrum wirklich in allen Bereichen der Geschäftswelt verwendet werden kann. Er ist nun so oberflächlich, dass man ihn in dieser Art nicht gebrauchen kann und, z.B. für Softwareprojekte einen separaten, spezifischeren Guide braucht.
Hier ein Beispiel: Im ganzen Guide finden den Begriff Anforderungen nicht mehr. Es wird nur noch von Backlog-Items gesprochen. Was sind nur aber Backlog-Items? Wer sich nicht auskennt, hat nun keine Ahnung. Der Begriff Anforderung war vermutlich schon zu IT-lastig.
Alt: “The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product.”
Neu: The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.”
Geht man hier davon aus, dass ein Produkt schon besteht? Das ist unverständlich.
Sie haben aber den Scrum Guide nicht nur vereinfacht, sondern auch “verkompliziert”, denn es wird neu zwischen “Responsible” und “Accountable” unterschieden. Was auf gut Deutsch “Umsetzungsverantwortlich” und “Rechenschaftspflichtig” bedeutet. War das wirklich notwendig? Aus meiner Sicht nicht!
Selbstmanagt über Selbstorganisierend? Da haben mich die Argumente von Jeff Sutherland in der Präsentation des neuen Guides überhaupt nicht überzeugt. Das ist aus meiner Sicht nur Wortklauberei und hilft dem Scrum Guide und seinen Anwendern nicht weiter. Vielleicht wird hier in der englischen Sprache bei den Begriffen mehr differenziert. Was meinen Sie dazu?
Die Einführung des Produktziels, dass sich einem höheren Ziel ausrichtet war überfällig. Jeff Sutherland und Ken Schwaber vermeiden zwar den Begriff Product Vision, aber aus meiner Sicht ist damit das “höhere Ziel” gemeint. Die Product Vision ist in agilen Projekten verbreitet, fordert aber den Product Owner und wird deshalb vielleicht noch zu wenig angewendet.
Die Abschaffung des Begriffes “Development Team” ist sinnvoll. Es gibt nur ein Team – das Scrum-Team – und dies fördert die Zusammenarbeit und reisst Grenzen nieder.
Der neue Scrum-Guide 2020 kann hier heruntergeladen werden.
Hier gibt es noch mehr Wissen
Dies war eine Übersicht über den neuen Scrum Guide 2020 mit seinen wesentlichen Änderungen. Was meinen Sie zu der neuen Version? Stimmen Sie mit meinen Aussagen überein oder haben Sie eine andere Ansicht oder Ergänzungen? Teilen Sie Ihre Erfahrung den Lesern unten im Kommentarfeld mit, damit wir alle eine weitere Sicht kennenlernen. Danke!
Möchten Sie mehr erfahren, wie Sie Ihre Projekte mit agilem Projektmanagement und Scrum noch erfolgreicher machen ? Mein Buch „Scrum – Agiles Projektmanagement und Scrum erfolgreich anwenden“ bringt Sie einen wichtigen Schritt weiter!
Kennen Sie jemanden, den dieser Artikel auch interessieren könnte? Dann leiten Sie ihn einfach weiter oder teilen ihn. Danke!
