The 2020 Scrum Guide: Update-Notes von agile-masters.de

Am 18.11.2020 gab es pünktlich zum 25jährigen Jubiläum von Scrum ein Update für den Scrum Guide.

von Mario und Mandy Kraus, am
Agile Masters Scrum Guide 2020_11

Agile Masters Scrum Guide Update

 

 

Am 18.11.2020, gab es pünktlich zum 25jährigen Jubiläum von Scrum ein Update für den Scrum Guide. Wir haben uns das „2020 Scrum Guide Event“ per Zoom angesehen. Naja, zunächst haben wir es nur versucht. Trotz vorheriger Registrierung war das Zoom Event bereits zum Start um 16:00 Uhr unserer Zeit so voll, dass sich keine weiteren Teilnehmer mehr einwählen konnten. Damit verpassten wir die erste Stunde und damit alle Hinweise auf die Neuerungen. Was wir in der letzten Stunde – als die essentiellen Infos gemeinsam mit vielen Wissenshungrigen bereits raus waren – sahen, war eine Art Podiumsdiskussion unter anderem mit JJ Sutherland, dem Sohn von Jeff Sutherland.

In der Wartezeit machten wir uns online auf die Suche nach der aktuellen Version des Scrum Guide. Die Seite, auf der es den offiziell gibt – https://www.scrumguides.org – war zu dieser Zeit sehr gut besucht und das begehrte Dokument erst nach vielen Versuchen erhältlich. Wir haben es dann tatsächlich geschafft, die 2020er Version von „The Scrum Guide“ herunterzuladen. Es gibt die aktuelle Fassung schon in Hebräisch und Japanisch. Da es aber noch keine deutsche Version gibt, haben wir das offizielle englische Dokument auf Änderungen zur 2017er Version überprüft. Ganz so einfach war das nicht, da sich die beiden Versionen in ihrem Aufbau leicht und im Umfang deutlich unterscheiden. Die ersten Details haben wir allerdings schnell entdeckt, die sich um das Product Goal und die Rollen in Scrum drehen.

Das Product Goal als langfristiges Ziel ist nun eine Art Bestandteil des Product Backlog. Unser erster Eindruck war, dass das Produkt Ziel nun als Item, Epic oder sonst irgendwie im Product Backlog stehen soll. Wir verstehen es nun eher als eine Art Überschrift. Der 2020 Scrum Guide definiert das Product Goal als Commitment, welches die Basis für die Arbeit am Product Backlog bildet. Das Product Backlog verbessert Transparenz und Fokus in Bezug auf das Ziel (also das Product Goal), welches wir mit unserer Arbeit erreichen möchten. Die Arbeit von vielen Scrum Teams erhält damit den Anstoß, noch wertorientierter und nicht von Features und Items dominiert zu werden. Abgeleitet wird dieses Product Goal aus der Vision.

Für das Sprint Backlog heißt das Pendant zum Product Goal „Sprint Goal“. Das Sprint Ziel ist uns bereits bekannt. Allerdings teilen wir die Erfahrung anderer Coaches, das sich Teams gelegentlich schwer tun mit der Formulierung eines Sprint Ziels. Im aktuellen Scrum Guide ist das Sprint Ziel nun explizit ein Thema im Planning und ganz klar im Rahmen des Plannings zu formulieren. Neben dem „“Was“ und dem „Wie“ stellt sich das Team nun zu Beginn des Plannings die Frage nach dem „Wofür“. Damit wird das Planning zu einem deutlich mehr zielorientierten Event und die Ressourcenplanung steht weniger im Vordergrund als bisher. Jeder Sprint soll das Product dem Product Goal ein Stück näherbringen.

„Rollen“ gibt es im aktuellen Scrum Guide nicht mehr. Innerhalb eines Scrum Teams haben wir nun drei „Verantwortungsbereiche“ – so unsere vorläufige Übersetzung von „specific accountabilities“. Und damit gibt es auch kein „Development Team“ mehr. Jeder im Team, der nicht Scrum Master oder Product Owner ist, heißt nun „Developer“. So wird einerseits die Betrachtung des Dev-Teams als Teilmenge des Scrum Teams abgeschafft, was wir sehr begrüßen. Andererseits wird im gleichen Zug der Produktbegriff geschärft:

„A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.”

Wir lösen uns damit noch mehr von dem Begriff „Software“, wie er im Agile Manifesto verwendet wurde. Wir haben schon länger das Wort „Produkte“ anstelle von „Software“ bei der Vermittlung der Werte verwendet und fühlen uns durch diese Produkt Definition darin bestätigt. Damit wird aus unserer Sicht auch die Verantwortlichkeit der Developer deutlich weiter gefasst. Wahrscheinlich sehen nur wir in Deutschland diesen Begriff in unseren Scrum Teams so eng, weil „Developer“ für uns meist gleichbedeutend sind mit Menschen, die beruflich Softwareentwickler sind. Tatsächlich sind alle, die am Erfolg eines Produkts arbeiten, in Scrum nun „Developer“. Das können UX-Designer, Business Analysten oder alle anderen Menschen im Team sein, die etwas zur Entwicklung dieses Produkts beitragen.

Während wir noch den bisherigen und neuen Scrum Guide parallel gelesen und nach Neuerungen gesucht hatten, googelten wir, ob schon jemand die Änderungen übersichtlich aufbereitet hat. Und da lief uns ein kurzfristiges Angebot von Björn Jensen über den Weg. Das D-A-CH Chapter der Scrum Alliance hat noch am selben Abend ein Scrum Guide Update Seminar angeboten. Björn Jensen ist der Mensch, bei dem wir unsere ersten Scrum Trainings für die Zertifizierungen zum Product Owner bzw. Scrum Master hatten. Wir konnten uns keinen besseren Coach als ihn vorstellen, um die Neuerungen zu besprechen. Über die Website seiner Firma https://www.jensen-und-komplizen.de erfolgte die kostenlose Anmeldung und die Bestätigung kam wenige Minuten später. Sodann saßen wir mit ganz vielen anderen Scrum Praktizierenden neugierig ab 19:00 Uhr vor den Bildschirmen und lauschten den Ausführungen von fünf Scrum Ikonen aus dem deutschsprachigen Raum.

Feinheiten, die uns bei der ersten Durchsicht des 2020 Scrum Guide noch nicht aufgefallen waren, wurden erörtert. Wir erhielten genau die Informationen, nach denen wir gesucht hatten. Bis 21:00 Uhr verbrachten wir eine sehr kurzweilige Zeit in dem Webinar. Fragen und Antworten schärften die Sicht der Teilnehmer auf DoD, DoR, Schätzungen und viele Themen aus der täglichen Praxis.

Der neue Scrum Guide beschreibt ein „self-managing“ Team. Um den Unterschied zum bisher als „self-organizing“ bezeichneten Team zu verstehen, war die während des Webinars gezeigte Authority Matrix von J. Richard Hackman sehr hilfreich. Ein self-managing Team hat demnach die Fähigkeit zum Monitoring und Managen der Arbeitsprozesse und des Fortschritts. Interessant war die anschließende Diskussion darüber, wie sich Teams in Richtung self-designing oder gar self-governing entwickeln können und was es mit den Teams und ihren Produkten macht, wenn die Organisation dabei nicht Schritt hält.

So wie das Product Goal ab jetzt das Commitment zum Product Backlog ist und das Sprint Goal zum Sprint Backlog, wird die Definition of Done nun als Commitment zum Increment definiert. Damit gehört ab jetzt zu jedem der drei Artefakte ein Commitment. Die Definition of Ready ist wie bisher nicht im Scrum Guide enthalten. Die Diskussion mit den Mitgliedern des D-A-CH Chapter der Scrum Alliance schärfte erneut das Verständnis aller Teilnehmer dafür, wieviel wichtiger die Kommunikation im Team ist. Mehrere Teilnehmer konstatierten, dass die DoR ein Qualitätshilfsmittel ist, mit dem eine organisatorische Unzulänglichkeit – nämlich mangelhafte Kommunikation – versucht werden soll auszugleichen.

Das Increment (bzw. die Inkremente) ist nach unserer Meinung nun besser definiert. Den bisherigen Scrum Guide verstanden wir so, dass ein Team auf ein einziges Increment am Ende des Sprints hinarbeitet. Nun wird klar definiert, dass in einem Sprint multiple Increments geschaffen werden können. Jedes Sprint Backlog Item wird mit der Erfüllung der Definition of Done automatisch zum Increment. Die Summe der Inkremente wird im Review präsentiert. Vorherige Auslieferungen sind ausdrücklich erwünscht, was förderlich für einen Continuous Deployment- bzw. Continuous Delivery-Ansatz ist.

Wir haben die zwei Stunden mit Björn und Komplizen sehr genossen. Am Rande wurde noch über no estimates, Kanban und weitere Themen diskutiert. Wir denken, dass wir die Neuerungen im 2020er Scrum Guide langsam beginnen zu verstehen. In unsere ersten Daily Scrums nach dem Update ließen wir bereits Infos und Erkenntnisse einfließen. Die nächsten Events werden sicher auch spannend. Wir werden uns Zeit dafür nehmen, unsere Teams mit dem neuen Scrum Guide vertraut zu machen. Wie bisher auch, ist er allerdings nicht dogmatisch für uns. Wir mögen die „Guide“-lines und begrüßen es ausdrücklich, dass der neue Scrum Guide sprachlich insgesamt weniger Vorschriftscharakter hat und sich weiter vom Thema Software gelöst hat.

Kurz nach der Veröffentlichung haben wir sicher noch nicht alle Neuerungen entdeckt und verstanden. Wir freuen uns auf die deutsche Übersetzung, die beim D-A-CH Chapter der Scrum Alliance bereits in Arbeit ist und sicher bald online steht. Für Feedback schreibt uns gerne Post an mail@agile-masters.de – wir freuen uns schon auf ein Update für die Update-Notes zum Scrum Guide Update. ?