Der Scrum Guide 2013 – was gibt es Neues?

Der neue Scrum Guide 2013 ist seit einer Woche herunterladbar, momentan noch ausschließlich auf Englisch. Es lohnt sich, genauer hinzusehen, was Ken Schwaber und Jeff Sutherland geändert haben.

(Alle Hervorhebungen in Zitaten von mir).

Praxisnäher oder schon ScrumBut?

Viele kleine, unscheinbare Einfügungen (best, usually, …) und Änderungen im Text sorgen für neue Ausnahmen und Relativierungen. Was früher noch zumindest als fragwürdig galt, taucht nun als dezentes Zugeständnis auf:

  • Die Sprintlänge darf jetzt offiziell variieren, sollte es aber am besten nicht („Sprints best have consistent durations throughout a development effort.“).
  • Das Sprintziel darf jetzt im Sprint nicht mehr gefährdet werden, bisher war bereits die Beeinträchtigung verboten („endangered“ ersetzt das alte „affected“). Über die Grenze dazwischen darf spekuliert und viel diskutiert werden. Bei der Arbeit.
  • Die Zusammensetzung des Entwicklungsteams muss über einen Sprint nicht mehr konstant bleiben. Niemand muss sich also mehr verstecken mit Modellen wie einer Teilzeit-Mitgliedschaft (z.B.: Frank ist nur jeden Mittwoch da) oder auch der Austauschbarkeit von Human Resources (z.B.: es muss immer „ein Entwickler“ im Team sein, egal ob das Michael oder Frank ist).
  • Bisher galt: wurde die Sprintlänge gekürzt, mussten auch die Ereignisse SprintplanungSprint-Review und Sprintretrospektive proportional gekürzt werden. Jetzt werden sie in diesem Fall nur als „usually shorter“ bezeichnet. 2015 dann vermutlich als „sometimes shorter“.
  • Tasks haben nicht mehr einen Tag als strikte Obergrenze für ihre Bearbeitungsdauer. Hier halten Ken und Jeff gar nicht erst bei „usually“ inne, sondern zerlegen die Einträge des Product Backlogs often to units of one day or less“.

Höflich zusammengefasst: es wird ab sofort gebilligt, die Arbeit gemäß Scrum dem Arbeiten in vor-agiler Zeit deutlich anzugleichen. Man könnte es auch weniger höflich eine Lizenz zum Bullshit nennen: Ken und Jeff haben hier in der Diskussion zu ScrumButs deutlich Stellung bezogen – für meine Begriffe im sumpfigen Gelände.

Sprintplanung ab sofort ganz neu? Nein.

Die Sprintplanung hat keine zwei gleich langen Teile mehr. Statt dessen werden die beiden Teile zu Themen umdeklariert, ihre Überschriften bleiben aber gleich:

  1. What can be done this Sprint? und
  2. How will the chosen work get done?

Praktisch bedeutet das nur, dass beide Themen unterschiedlich lange diskutiert werden können. Thema 1 muss trotzdem vor Thema 2 abgehandelt werden. Implizit scheint es jetzt auch eine Anwesenheitspflicht für den Product Owner bei Thema 2 zu geben, zumindest wurde die Formel „The Product Owner may be present“ ersatzlos gestrichen.

Heisse Kartoffel Sprintziel: essen will sie jeder

Wozu ein Sprintziel? Als Sinn wird „Kohärenz“ in Bezug auf irgend etwas genannt,  was das Entwicklungsteam zur Zusammenarbeit bringt, statt zur isolierten Arbeit von Einzelnen. Leider spielt laut Scrum Guide keine Rolle, ob das Sprintziel fachlich, technisch oder mit Blick auf das Firmensommerfest kohärent ist:  „The Sprint Goal can be any other coherence“, Hauptsache Teamwork.

Die Fragen während des Daily Scrum werden ab sofort als Erinnerung an das Sprintziel und den teamorientierten persönlichen Beitrag dazu ausgerichtet. Beispielsweise heißt es nicht mehr

  • „What has been accomplished since the last meeting?“ (2011), sondern
  • „What did I do yesterday that helped the Development Team meet the Sprint Goal?“ (2013).

Das finde ich gut, wenn auch etwas angestrengt erzieherisch. Die Verantwortung für das Formulieren des Sprintziels wird allerdings wie eine heiße Kartoffel so schnell im Kreis herumgereicht, dass einem schwindlig wird:

  • „The Product Owner discusses the objective that the Sprint should achieve…“
    Sagte man früher einfach „mitteilen“, „verkünden“ oder „anordnen“, so nutzt man heute „discuss“ (oder das unsägliche „communicate“) – als hätten die Zuhörer etwas mitzureden.
  • After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal.“
    „Ein“  Sprintziel wird nachträglich, passend zur Vorhersage des Entwicklerteams ausgearbeitet? Sicher?
  • Having set the Sprint Goal and selected the Product Backlog items for the Sprint, the Development Team decides how…“
    Moment: die Entwickler haben das festgesetzt? Wirklich? Oder ist das einfach nur schlampig formuliert?

Zusammengefasst: der Product Owner teilt allen die objective des Sprints mit, das Scrum Team arbeitet ein Sprint Goal aus, und gesetzt hat es am Ende angeblich das Development Team.

So sehr mir insgesamt die neue starke Betonung des Sprintziels gefällt: ich fürchte, als Guide wird hier eher der agile gesunde Menschenverstand nützlich sein als ein Papier mit solch halbgaren Formulierungen. Eine verpasste Chance!

Raider heißt jetzt Twix

…sonst ändert sich nix:

  • Einträge im Product Backlog, die fertig zur Übernahme in einen Sprint sind, wurden die letzten beiden Jahre „ready“ oder „actionable“ genannt. Ab sofort heißt das „Ready“. Mit großem R. Eine kleiner Schritt für die Orthographie, ein großer Sprung vorwärts für die Scrum-Community.
  • Die Definition of „Done“ ist noch nicht done und pendelt absatzweise hektisch zwischen „Done“ und „done“.
  • Die laufende Pflege und Überarbeitung des Product Backlogs wurde die letzten beiden Jahre in der Community meist „grooming“ genannt. Ab sofort heißt das „refinement“.

Feiges Geschwurbel

Manches Buzzword soll offensichtlich unangenehmen Klartext überdecken. Schönstes Beispiel: „Artifact transparency“

Ein als besondere Neuerung angepriesener Abschnitt: Transparenz bei Artefakten sei gut. Und selbstredend ist der Scrum Master verpflichtet, jedem auch bei der Herstellung von noch mehr Transparenz zu helfen. Mehr konnte ich dem Text zunächst nicht entnehmen. Ich habe es redlich und wiederholt versucht.

Einige Gläser (Frappé) später fiel mir dann ein, dass Scrum-Werte wie Offenheit und Mut nicht mehr Teil des Scrum Guides sind (s.u.). Mir dämmerte bei der Lektüre, dass mit „Transparenz“ hier letztlich Wahrheit gemeint ist. Das industrielle Scrum von 2013 hat anscheinend die Kraft verloren, diesen Begriff „Wahrheit“ offen und mutig zu benutzen, um nach mehr davon zu verlangen. Was für eine Ironie.

Rollen: Harder, better, faster, stronger

Es gibt angeblich mehr zu tun, in einigen Rollen:

Der PO…

…konnte sich bisher damit begnügen, die Wertschöpfung des Entwicklerteams sicherzustellen. Aber das altbackene und prozessverdächtige „ensuring“ musste jetzt dem wesentlich dynamischeren „optimizing“ weichen. Wer braucht da noch Kanban!

Für den Scrum Master…

…reicht „Understanding long-term product planning in an empirical environment“ ab sofort nicht mehr, das Wörtchen „long-term“ wurde einfach gestrichen. Eine heimtückische Änderung, finde ich, denn sie ersetzt schlagartig das, was nie existierte, durch das, was jemand anderes als der Scrum Master längst hätte tun müssen.

Auch wichtig: die neue Aufgabe „Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value“. Ich freue mich auf viele heitere Szenen, wenn der in anderthalb Tagen zum CSM geschulte Scrum Master vorschriftsmäßig sicherstellt, dass der ebenfalls in anderthalb Tagen zum CSPO geschulte Product Owner seine Kernaufgabe auch wirklich beherrscht.

Und eine besonders sportliche neue Idee zur Hirnakrobatik in der Sprintretrospektive: „The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum process.“ Je öfter und länger ich über diese Formel und ihre praktischen Konsequenzen für den Scrum Master nachdenke, desto [Schimpfwörter gelöscht, bitte bleiben Sie sachlich! – die Red.].

Weg damit!

Ist Produktentwicklung zu komplex für Scrum?

Zwei Jahre lang galt: „Scrum is a framework structured to support complex product development.“ Diese Struktur möchten Ken und Jeff jetzt offenbar lieber durch (ihr?) zusätzliches Consulting schaffen und streichen den Passus ersatzlos. Erhalten geblieben ist an anderer Stelle nur das nebulöse „Scrum is a process framework that has been used to manage complex product development.“

Vision? Endlich Geschichte.

Aufatmen beim Scrum Master: „Clearly communicating vision“ steht nicht mehr auf seiner To-Do-Liste. Diese Unterstützungsleistung für den PO entfällt ersatzlos, vielleicht, weil eine Vision, die klar vermittelt werden soll, ja zuerst einmal existieren müsste. Das ist im industrialisierten Scrum immer unwahrscheinlicher geworden, also weg damit – das Wort „vision“ taucht jetzt im Scrum Guide nirgendwo mehr auf.

Was nur konsequent ist und dem Schicksal der „values“ folgt. Die Scrum-Werte (Respekt, Mut, Offenheit, Fokus und Commitment – wie es in den Sagen und Mythen vergangener Zeiten lautet, falls ich mich recht entsinne) wurden ja bereits getilgt: hieß es im Scrum Guide 2009 noch, der Scrum Master habe dafür zu sorgen, dass sich das Team an „Scrum values, practices, and rules“ halte, lautet die Formel seit 2011 „Scrum theory, practices, and rules“.

Da scheint mir bizarr, wie Ken Schwaber kürzlich kritisierte, andere hätten wohl das agile Prinzip „Individuals and Interactions over Processes and Tools“ aus den Augen verloren. Er empfiehlt: „Keep the values, keep the principles, think for yourself.“ Eat your own dog food, Ken.

Du musst es nicht tun, sondern nur verstehen!

Und nochmals Aufatmen beim Scrum Master: das naive „Teaching the Development Team to create clear and concise Product Backlog items“ (2011) gehört nicht mehr zu seinen Aufgaben, es weicht endlich einem professionellen „Helping the Scrum Team understand the need for clear and concise Product Backlog items“ (2013).

Ich finde, das spart Arbeit. Denn man darf getrost voraussetzen, dass dieser Bedarf jedem längst schmerzlich bewusst ist. Somit fällt für den Scrum Master auch hier keine wirkliche Mehrarbeit an. Trotzdem – es wäre sicher mehr drin gewesen. Für die kommende Version des Scrum Guides schlage ich etwas vor wie: Nurturing the Scrum Team’s appreciation of the need for transparent Product Backlog items.

In der Gosse gelandet: vom festen Event zur formellen Gelegenheit

Welcher Satz stammt aus dem Scrum Guide 2011 und welcher aus dem Scrum Guide 2013?

„Although improvements may be implemented at any time, the Sprint Retrospective provides…

  • „… a dedicated event focused on inspection and adaptation.“
  • „… a formal opportunity to focus on inspection and adaptation.“

Muss ich auflösen? Allenfalls für Menschen, die Geburtstagspartys als formelle Gelegenheiten betrachten, um sich ihren Freunden zu widmen. Oder auch nicht.

Easter eggs – Lachen mit Scrum

Ken und Jeff haben durchaus Sinn für Humor, wie ein paar Fundstücke zeigen:

  • 2011 hielten sie Scrum noch für „Extremely difficult to master“, jetzt haben sie das „extremely“ entsorgt.
  • Der Product Owner muss nur noch optional lügen, also im Sprint Review nicht mehr unbedingt „completion dates based on progress to date“ extrapolieren – in Klammern folgt jetzt ein neckisches „(if needed)“.
  • Abweichlern, die Scrum nicht als Framework bezeichnen wollen, werden die Instrumente gezeigt: die zugehörige Überschrift „Scrum Overview“ wird zu „Definition of Scrum“ umgetitelt. Nehmt das, Ihr Ketzer! Auch sonst werden die Zügel der Orthodoxie straffer angezogen – 2011 schienen noch „Specific strategies for using the Scrum framework“ denkbar, jetzt sind es nur noch „Specific tactics.

Mein subjektives Fazit

Der neue Scrum Guide 2013 ist ein konsequenter Schritt in Richtung industriell betriebenes Scrum. Werte waren bereits 2011 ausgemerzt, die Produktvision wird es jetzt. Aus dem Sammelsurium von vermeintlichen Kleinständerungen stechen bei genauerem Hinsehen viele ScrumButs ins Auge, die den Segen der Scrum-Erfinder bekommen. Um nur ein zwei zu nennen: Tasks, die länger als einen Tag dauern; oder Teammitglieder, die bei laufendem Sprint aus dem Team abgezogen oder in das Team entsandt werden können.

Die Verbesserungen sind demgegenüber marginal, wenn auch einige überfällige darunter sind, etwa das Einfordern eines Sprintziels.

Wer im Vergleich dazu lesen möchte, was gut gelebtes Scrum wirklich sein kann, dem empfehle ich als Erholung nach dem Scrum Guide das neue Buch von Tobias Mayer zu lesen, seine Essaysammlung The People’s Scrum.

Bildnachweis:
The 10 Commandments © John Taylor | CC BY 2.0