In den letzten Jahren wurde viel darüber diskutiert, wie Scrum weiterentwickelt werden kann. Manchmal konnte man etwas wie „Scrum 2.0“ oder ähnliches sehen. In der Vergangenheit haben die Urväter von Scrum, Ken Schwaber und Jeff Sutherland, aber immer betont, dass Scrum an sich nicht geändert werden muss. Am 20.7. haben Ken und Jeff nun ein Update des Scrum-Primers veröffentlicht. Wie die beiden schreiben, handelt es sich dabei um Präzisierungen einzelner Elemente und Techniken und das Entfernen von nicht zum Scrum-„Kern“ gehörigen Dingen. Die wichtigsten Änderungen sind in einem Begleitschreiben aufgezählt.
Die erste Änderung betrifft den Begriff „Development-Team“. Bisher wurde immer vom Scrum-Team gesprochen, Ken und Jeff sagen jetzt, dass das Team, das die Arbeit erledigt, das „Entwicklungsteam“ ist. Egal, welche Art Arbeit von den jeweiligen Teammitgliedern übernommen wird – sie werden Enwickler genannt. Uhh… ich höre schon die Aufschreie derer, die als UI-Designer, Qualitätssicherer oder Konzepter in den Teams mitarbeiten ;).
Eine zweite – wie ich finde: einschneidende – Änderung betrifft das „Commitment“ für einen Sprint. Bisher haben wir immer gelebt, dass ein Team am Ende der Sprintplanung dem Product Owner verspricht, bestimmte Teile (das, was im Sprint Backlog steht) am Ende des Sprints zu liefern. Diese verbindliche Zusage gibt es jetzt nicht mehr. Das Entwicklungsteam erstellt eine Prognose ( „Forecast“) darüber, was es glaubt, innerhalb des Sprints an Arbeit erledigen zu können. Diese Prognose wird während des Sprints, wenn mehr Informationen vorliegen, immer wieder angepasst. Das ist vordergründig gesehen eine einschneidende Veränderung. Wenn man sich aber ansieht, wie es in den meisten Teams mit dem „Commitment“ funktioniert (oder eben nicht), wird man feststellen, dass sich hier der Plan der Realität anpasst – ein schönes Beispiel für Inspect-and-Adapt ;). Da viele Entwicklungsteams schlichtweg damit überfordert sind, dieses Versprechen zu leisten, kann man auch gleich diese teilweise ins Krampfhafte ausufernden Debatten („…könnt ihr versprechen, das zu liefern?“) von vornherein streichen. Allerdings muss natürlich der Wille vorhanden sein, das prognostizierte Ziel auch zu erreichen.
Nächste Änderung: Ein Burndown-Chart ist nun nicht mehr zwangsläufig gefordert (und wurde von uns auch nie als ultimativ zwingend angesehen). Es reicht, wenn die Restaufwände für einen Sprint tagesaktuell erfasst und veröffentlicht werden und dafür gesorgt wird, dass permanent an der Erledigung aller Arbeiten innerhalb des Sprints gearbeitet wird. Wir kennen Teams, die ohne Burndown-Chart ausgekommen sind, weil z.B. das Taskboard allein schon genug Aussagekraft über den Grad der Zielerreichung hat.
Eine Releaseplanung ist sinnvoll, aber kein erforderlicher Bestandteil von Scrum. Inhaltlich sicher richtig, aber das sollte niemanden davon abhalten, sich dem Thema Releaseplanung nachdrücklich zu widmen. Aus unserer Erfahung sind gerade eine Releaseplanung und eine „strategische“ Steuerung der Entwicklung sowohl wichtig als auch schwierig.
Das Product Backlog soll nun sortiert und nicht mehr priorisiert sein. Hier kommt das zum Tragen, was wir immer schon als Reihenfolge statt Priorität benannt haben – es darf im Product Backlog keine zwei Einträge mit der gleichen Wichtig-/Wertigkeit geben. Das finde ich persönlich sehr wichtig, das Wort „Priorität“ ist verbrannt, da es dazu führt, dass immer nur in den Kategorien „sehr wichtig“, „wichtig“ und „weniger wichtig“ (oder so ähnlich) gedacht wird, und dies bei einem Product Backlog nicht zu der notwendigen Klarheit in der Reihenfolge führt.
Der Konzept der Sprint-Backlog-Items entfällt. Das Sprint Backlog besteht aus den Product-Backlog-Items plus einem Plan, wie man sie entwickeln und ausliefern möchte. Ein interessanter, aber eigentlich selbstverständlicher Satz steht hier quasi als Randbemerkung mit drin: „A selforganizing Development Team always has a plan.“
In Summe sind das, wie Ken und Jeff schreiben, keine grundsätzlichen Änderungen, sondern kleinere evolutionäre Anpassungen an die Erfahrungen aus diversen Jahren Scrum in den unterschiedlichsten Umfeldern. Die dazugewonnene Präzision in der Beschreibung hilft, Missverständnisse von vornherein zu vermeiden – und das ist sehr gut. Und, was ich persönlich gut finde, es wird jedes Jahr dieses Update geben.
Also, kein Scrum 2.0, was viele gefordert haben, sondern eben ein Scrum 2011, das sich den Gegebenheiten der Gegenwart angepasst hat und dann weiter tun wird.
Allerdings – eine Revolution ist es dann doch: bisher hatte sich Ken immer strikt geweigert, auch nur kleine Änderungen an Scrum vorzunehmen.
Den aktuellen Scrum-Primer kann man von der Seite scrum.org herunterladen: http://www.scrum.org/storage/scrumguides/Scrum_Guide%202011.pdf , die Original-Beschreibung der Updates findet sich unter http://www.scrum.org/storage/Scrum%20Update%202011.pdf
