Der Scrum Guide von Ken Schwaber und Jeff Sutherland ist das offizielle Scrum Regelwerk. Pünktlich zum 25-jährigen Jubiläum wurde dieser aktualisiert. Hier erfährst du, welche wichtigen Änderungen es gibt!
Die Ende November 2020 veröffentlichte Version des Scrum Guides ist eines der größten Updates der Geschichte und die erste Aktualisierung seit 2017. Und auch wenn die neue Version keine radikalen Änderungen mit sich bringt, enthält sie doch enorm wichtige Veränderungen und Klarstellungen!
Hier die – aus meiner Sicht – wichtigsten Änderungen:
Einfacher geschrieben & Ballast abgeworfen
Was gleich zu Beginn auffällt ist, dass der neue Scrum Guide statt 19 nur noch 14 Seiten umfasst. Er ist also deutlich kürzer und letztlich auch einfacher zu lesen.
Möglich ist das dadurch, dass sich der Scrum Guide wieder mehr auf sein Hauptanliegen konzentriert: er sollte nämlich nie eine detaillierte Anleitung zur Umsetzung, sondern vielmehr Rahmenwerk sein, in dem die Kernelemente/-regeln beschrieben werden.
Mit dieser Fokussierung konnten dann auch einige Passagen, in denen es um einzelne Umsetzungsdetails geht, gestrichen werden. Beispiele hierfür sind u.a. die 3 Fragen im Daily Scrum, Details zum Ablauf und Inhalt des Sprint Reviews oder auch Details zum Product Backlog.
Einerseits macht diese Reduktion auf die grundlegenden Regeln es sicher einfacher Scrum auf die jeweiligen Bedürfnisse (bei der Umsetzung in verschiedenen Branchen) anzupassen. So sind u.a. auch die IT-spezifischen Begriffe – wie Anforderungen oder Testen – entfernt worden. Andererseits waren diese nun entfernten Umsetzungsdetails gerade für Einsteiger sicher hilfreich.
Wenn dir diese Details also geholfen haben, dann lies sie gerne auch weiterhin in der 2017er-Version nach (hier auf DE und hier auf EN).
Developer:innen (statt Development Team)
Eine der größten Schwachstellen in Scrum war – meines Erachtens – die bisherige Schwammigkeit bei einer zentralen Rolle von Scrum: dem Development Team.
Mir war nämlich nie ganz klar, warum ein Team eine Rolle sein soll und dann auch noch innerhalb eines anderen Teams – nämlich dem Scrum Team – als Subgruppe verankert ist. Ich glaube auch, dass dies in der Praxis zu einigen Problemen (u.a. bei der gemeinsamen Verantwortlichkeit) geführt hat.
Im neuen Scrum Guide wurde dieses Problem nun zum Glück gelöst! Aus der Rolle „Development Team“ wurde nun die Rolle „Developer:innen“. Somit gibt es nur noch ein Team – nämlich das Scrum Team, das aus einem Product Owner, einem Scrum Master und mehreren Developper:innen besteht.
Developer:innen als Stellvertreter:innen!
Leider wurde auch im 2020er Scrum Guide am Begriff Developer:innen festgehalten, was bei der Anwendung von Scrum außerhalb der Softwareentwicklung immer wider zu Fragezeichen führt.Positiv zu nennen ist aber, dass Sutherland und Schwaber im Vorwort darauf hinweisen, dass hiermit niemand ausgeschlossen werden soll: “Wir verwenden das Wort “Developer:innen” in Scrum nicht, um jemanden auszuschließen, sondern um zu vereinfachen. Wer auch immer vom Einsatz von Scrum profitiert, soll sich angesprochen fühlen”. Also explizit auch Entwickler:innen, Forscher:innen, Analyst:innen, Wissenschaftler:innen und andere Spezialist:innen.
Das Product Goal
Der neue Scrum Guide behebt auch eine weitere Schwachstelle: das bisher fehlende Product Goal.
Denn nicht nur in agilen Projekten gilt: Damit die Arbeit eines Teams auf ein großes und meist weit in der Zukunft liegendes Ziel optimal fokussiert werden kann, bedarf es eines klar und transparent formulierten Ziels. Und gerade für die einzelnen Sprints ist ein übergeordnetes Ziel, an dem sich diese messen lassen, von großer Wichtigkeit.
In der neuen Version des Scrum Guides wurde dieses Product Goal nun explizit mit aufgenommen und beschreibt “einen zukünftigen Zustand des Produkts, welches dem Scrum Team als Planungsziel dienen kann”.
Mehr Transparenz durch Commitments
Die Aufnahme des Product Goals ermöglicht auch eine Verbesserung in der Struktur des Scrum Guides.
Denn bisher waren zwar die – für eine erfolgreiche Arbeit so wichtigen – Elemente „Sprint Goal“ und „Definition of Done“ bereits aufgeführt. Eine gute strukturelle Verankerung wurde aber erst mit der Einführung des Product Goals erreicht.
Jedem Artefakt ist nun nämlich ein Commitment zugeordnet:
- dem Product Backlog das Product Goal
- dem Sprint Backlog das Sprint Goal und
- dem Increment die Definition of Done.
Und auch wenn dies nach einer eher kleinen Änderung aussieht, ist die strukturelle Klarheit nicht zu unterschätzen. Denn mit jedem Commitment sollen Transparenz und Fokus verbessert werden, um dadurch den Fortschritt besser messbar zu machen.
Selbstmanagement statt Selbstorganisation (und klarere Gesamtverantwortlichkeit)
Im bisherigen Scrum Guide wurde das Development Team als selbstorganisierend beschrieben, d.h. das Team entscheidet selbst, wie es die Arbeit erledigt und wie es sich organisiert.
Mit dem neuen, stärkeren Fokus auf das Scrum Team, tritt nun das Selbstmanagement stärker in den Vordergrund, d.h. das Scrum Team entscheidet nicht nur wie die Arbeit erledigt wird, sondern auch was und wann es bearbeitet werden soll. Das Scrum Team gestaltet also weitgehend unabhängig von äußeren Einflüssen seine Arbeit.
Zudem wird nun auch explizit die Umsetzungsverantwortlichkeit für ALLE produktbezogenen Aktivitäten angesprochen, also die “Zusammenarbeit mit den Stakeholder:innen, Verifikation, Wartung, Betrieb, Experimente, Forschung und Entwicklung und alles, was sonst noch erforderlich sein könnte”.
Gerade dieser letzte Teil räumt mit einem leider oft anzutreffenden Missverständnis auf:
Der starke Fokus auf die Softwareentwicklung des Development-Teams führte oft zu einer “Auslagerung” von “sonstigen” Tätigkeiten (wie z.B. Vertragsgestaltung, o.ä.) in die anderen Abteilungen des Unternehmens. Und genau an diesen Schnittstellen traten dann “Intransparenzen” und Probleme auf, welche oft zu Mehrarbeit, geringerer Qualität und geringerer Geschwindigkeit führten.Dies kann so nun nicht mehr aufrecht erhalten werden. Diese “sonstigen Tätigkeiten” müssten nun wieder in das Scrum Team zurückgeholt werden, was letztlich weniger Schnittstellen und damit ein besseres Ergebnis in kürzerer Zeit zur Folge haben wird.
Fazit: Scrum bleibt Scrum, wird aber “besser”
Wie du siehst, sind im neuen Scrum Guide einige wichtige Änderungen, Klarstellungen und Verbesserungen enthalten.
Die Refokussierung auf Scrum als “leichtgewichtiges Rahmenwerk, welches Menschen, Teams und Organisationen hilft, Wert durch adaptive Lösungen für komplexe Probleme zu generieren” ist meines Erachtens ein guter Schritt, um Scrum auf die jeweiligen Bedürfnisse bei der Umsetzung in verschiedenen Branchen anzupassen. Auch wenn noch nicht alle IT-spezifischen Begriffe aus dem Guide entfernt wurden.
Aber trotz dieser ganzen Änderungen gilt: Scrum bleibt Scrum. Und ganz in diesem Sinne stellt der neue Guide einfach ein neues Increment aus einer weiteren Iteration dar 🙂