Der beste Scrum Guide, den es je gab Scrum Guide 2020 – die Aktualisierungen unter der Lupe

Scrum Guide 2020 – die Aktualisierungen unter der Lupe

Pünktlich zum 25. Geburtstag von Scrum und drei Jahre nach der jüngsten Aktualisierung des Scrum Guide haben die Erfinder dieses wohl verbreitetsten agilen Rahmenwerks, Jeff Sutherland und Ken Schwaber, am 18. November eine Aktualisierung veröffentlicht.

Der beste Scrum Guide, den es je gab Scrum Guide 2020 – die Aktualisierungen unter der Lupe

Scrum Guide 2020 – die Aktualisierungen unter der Lupe

Pünktlich zum 25. Geburtstag von Scrum und drei Jahre nach der jüngsten Aktualisierung des Scrum Guide haben die Erfinder dieses wohl verbreitetsten agilen Rahmenwerks, Jeff Sutherland und Ken Schwaber, am 18. November eine Aktualisierung veröffentlicht.

Ich fasse hier die sieben großen Änderungen (siehe dazu auch die offizielle Versionshistorie) im Vergleich zur Version von 2017 in drei Abschnitten zusammen, und bewerte deren Bedeutung für die Praxis. Eines vorweg: Für mich – als jemand der Scrum außerhalb der IT einsetzt und über die Jahre unzählige Scrum Teams begleitet hat – ist der Versionssprung auf den Scrum Guide 2020 der wichtigste Sprung in der Geschichte des Scrum Guide.

1. Scrum für alle

Für den neuen Scrum Guide haben die Autoren einige konkrete Anweisungen und Definitionen entfernt und den Guide dadurch deutlich verschlankt (12 statt 17 Seiten Inhalt). Verschwunden sind zudem sämtliche Begriffe mit Bezug zur IT oder zur ProduktentwicklungProduktentwicklungDie Entwicklung eines neuen Produktes zählt zu den klassischen Projektaufgaben. Die Produktentwicklung findet zwischen Forschung und Marktforschung statt. Forschung liefert neue Möglichkeiten, Marktforschung neue Kundenanforderungen. Aufgabe der Produktentwicklung ist es, produktions- und marktreife Produkte so zu definieren, dass das Unternehmen mit ihnen maximalen Ertrag erwirtschaften kann.. Der Konsistenz und Einfachheit halber gibt es zwar noch ein "Product" und "Developer", der Scrum Guide stellt aber klar, dass damit komplexe Probleme und Menschen mit entsprechender Expertise gemeint sind.

Dadurch tragen Sutherland und Schwaber dem inzwischen sehr breiten Einsatzspektrum von Scrum Rechnung (Marketing, QualitätsmanagementQualitätsmanagementQualitätsmanagement ist der Oberbegriff für alle Tätigkeiten, Führungsaufgaben und Methoden, die zur Planung, Sicherung, Verbesserung und Prüfung der Qualität eines Produktes oder einer Dienstleistung gehören. Der PMBOK(R) Guide 2004 zählt zum Project Quality Management die drei Prozesse Quality Planning, Perform Quality Assurance und Perform Quality Control., Schulen usw.) und beenden die früher immer wieder anzutreffende Diskussion über mögliche Einsatzbereiche.

2. Ein Team, ein Ziel

Product OwnerProduct OwnerProduct Owner ist eine der drei Verantwortlichkeiten (bis 2020 Rollen) bei Scrum . Der Product Owner ist verantwortlich für das Product Backlog ., Scrum MasterScrum MasterScrum Master ist eine der drei Verantwortlichkeiten (bis 2020 Rollen) im agilen Rahmenwerk  ↑Scrum . Der Scrum Master ist dafür verantwortlich, dass die Beteiligten Scrum richtig verstehen und umsetzen. Für den Qualifikationsnachweis als Scrum Master gibt es zwei aufeinander aufbauende Zertifikate, den Professional Scrum Master level 1 (PSM I) und den Professional Scrum Master level 2 (PSM II), die von Scrum.org in einem Online-Test erworben werden können. und Entwicklungsteam. Statt letzterem gibt es nun Entwickler (Developer), sodass das Scrum Team das einzige Team in Scrum ist. Auch der Begriff der Scrum-Rollen ist Geschichte, er wurde ersetzt durch Verantwortlichkeiten. Das Scrum Team als Ganzes ist dafür verantwortlich, dass das "Product Goal" erfüllt wird, indem es das Product BacklogProduct BacklogProduct Backlog ist bei Scrum die Liste aller Anforderungen für ein zu erstellendes Produkt. Sprint für Sprint abarbeitet.

Diese Gesamtverantwortung war zwar zuvor schon in Scrum verankert, jedoch mildern deren Betonung sowie die Abschaffung des Entwicklerteams als Team im Team den kulturell oft vorhandenen Bruch zwischen denjenigen, die das "Was" bestimmen und jenen, die das "Wie" umsetzen. Die neue, klare Definition verhindert Diskussionen über die Zuständigkeit – auch der Product Owner und der Scrum Master sind nun explizit mitverantwortlich für die Ergebnisse.

Der Scrum Guide macht hier auch noch einmal klar, dass es für ein Team zu einem ZeitpunktZeitpunktIn der Netzplantechnik wird mit " Zeitpunkt " ein Punkt auf einer frei gewählten Zeitachse bezeichnet, solange diese noch nicht auf die Echtzeit abgebildet ist. nur ein Product Goal geben kann (es können jedoch mehrere Teams gemeinsam an einem Goal arbeiten). Dass ein Mensch oder eine OrganisationseinheitOrganisationseinheitEine Organisationseinheit ist ein Element der Aufbauorganisation, das in der Regel im Organigramm ausgewiesen wird. Beispiele für Organisationseinheiten sind Unternehmensbereiche, Abteilungen, Niederlassungen oder Tochterunternehmen. Organisationseinheiten können selbst Organisationen sein. an EffektivitätEffektivitätEffektivität beschreibt die Ausrichtung des Projektportfolios auf die geschäftlichen Interessen der Trägerorganisation . Eine mögliche Messgröße für Effektivität ist das Verhältnis von tatsächlich erreichtem zu angestrebtem Nutzen durch Projektarbeit. verliert, sobald er/sie mehrere Ziele gleichzeitig verfolgt, sollte eigentlich selbstverständlich sein. Die in der Praxis häufig erlebte Überlastung und Defokussierung zeigt jedoch, wie wichtig eine solche klare Aussage ist.

Auch an einer zunächst unscheinbaren Stelle spiegelt sich die hervorgehobene Gesamtverantwortung wider: Im alten Scrum Guide stand, dass das Entwicklungsteam das "Wie" (und das "Wer") selbstorganisiert umsetzt. Da es jetzt nur noch ein Team gibt, muss auch das "Was" (vertreten durch den Product Owner) mit in die Definition der Arbeitsweise aufgenommen werden: Der Scrum Guide spricht jetzt davon, dass das gesamte Scrum Team "selbstgemanagt" ist, das trifft die schon lange in Scrum angelegt Grundintention deutlich präziser als die alte Definition eines selbstorganisierten Entwicklungsteams.

3. Frag immer erst warum

Bisher bestand das Sprint PlanningSprint PlanningIm Sprint Planning plant das Scrum Team zu Beginn eines Sprints das Sprint-Ziel sowie das angestrebte Produktinkrement und legt das Sprint Backlog fest. Darauf aufbauend erstellt das Entwicklungsteam den Ablaufplan für den Sprint. aus den beiden Aspekten "Was" und "Wie": Das Entwicklungsteam zog sich Items aus dem Product Backlog (PBIs) in das Sprint Backlog ("Was") und leitete aus diesen seinen Plan für den Sprint ab, oft in Form von Aufgaben ("Wie") zu den jeweiligen dem Product Backlog Items. Im neuen Scrum Guide wird nun dem Sprint Backlog (dieses enthält ja den Plan für den Sprint) ein dritter Aspekt hinzugefügt: das "Warum" (Buchtipp hierzu).

Das bisher auch schon vorhandene Sprint Goal erhält dadurch einen größeren Stellenwert. Das ist gut, denn die Erfahrung zeigt, dass es mitunter schwierig ist, ein sinnvolles Sprint Goal zu bestimmen. Oft liegt das daran, dass die Sortierung und der Zuschnitt der Backlog Items optimiert werden sollte. Manche Teams scheuen diesen AufwandAufwandAufwand (Projektmanagement) ist die Menge aller monetär quantifizierbaren Eingangsgrößen in ein Projekt, in ein Programm, in ein Projektportfolio oder in einen Teil eines Projekts. und verzichten lieber darauf, ein Sprint Goal zu definieren. Dieser Ausweg ist nun (zurecht) nicht mehr möglich.

Die Erhöhung von Fokus und Commitment durch die Vereinbarung von Zielen beschränkt sich jedoch nicht nur auf die beiden Backlogs, sondern zieht sich durch bis zum dritten Artefakt, dem Increment. Jedem Artefakt ist nun ein sogenanntes Commitment zugeordnet, welches das entsprechende Artefakt präzisieren soll: Für das Product Backlog ist es das Product Goal, für das Sprint Backlog das Sprint Goal und für das Increment die Definition of DoneDefinition of Done" Definition of Done " bezeichnet in  Scrum  die verbindlich vereinbarten  Abnahmekriterien  für die Umsetzung eines Backlog-Items oder eines  Inkrements .  . Dadurch gibt es für diese drei bisher "frei schwebenden" Vereinbarungen jeweils einen definierten Platz.

Mein Fazit

Im Scrum Guide 2020 werden Verantwortung und Fokus noch klarer herausgestellt und stehen damit noch deutlicher im KonfliktKonfliktAufgrund der Neuheit und Einmaligkeit von Projekten treten während der Projektabwicklung mit großer Wahrscheinlichkeit Konflikte auf. In erster Linie sind bei Projekten organisatorische oder Inter-Rollen-Konflikte zu erwarten. Dies bedeutet, dass Organisationseinheiten oder Funktionsträger nicht miteinander vereinbare Maßnahmen durchsetzen wollen. Ein organisatorischer Konflikt liegt z.B. vor, wenn zur Projektbeschleunigung die vorgeschriebenen Qualitätsprüfungen nicht im vollen Umfang durchgeführt werden. Ein Inter-Rollen-Konflikt kann z.B. im gleichzeitigen Anspruch zweier Projektleiter auf eine Engpassressource bestehen. zu den mancherorts etablierten ineffektiven Vorgehensweisen – eine Chance, um besser zu werden. Im die neue Version wurde auch explizit aufgenommen, dass Scrum nur als Gesamtkonzept seine volle Wirkung entfalten kann. Wer Elemente weglässt, muss mit den dadurch verursachten Nachteilen leben. Durch das Entfernen der Bezüge zur Softwareentwicklung fällt ein gerne genutztes Argument gegen den Einsatz von Scrum weg. Scrum steht damit jedem offen, der mit hoher Effektivität komplexe Probleme lösen möchte.

Seit einem Vierteljahrhundert setzen Millionen von Anwendern Scrum ein und durch deren Feedback wird Scrum ständig weiterentwickelt. Aktuell scheint kein besserer Ansatz für die teambasierte Lösung von komplexen Problemen verfügbar zu sein, doch auch der Scrum Guide 2020 bildet nur den aktuellen Erfahrungsstand ab, der Guide wird sich weiterhin entwickeln und noch weiter verbessern. Bleiben wir gespannt.

Jetzt Feedback geben und mitdiskutieren!

Wir würden uns über Ihre Bewertung und/oder einen Kommentar freuen ‒ nur so können wir Ihnen in Zukunft noch bessere Inhalte liefern.

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung.
1 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 10
Kommentare 1

Das könnte Sie auch interessieren

Drei Jahre nach der jüngsten Aktualisierung haben Ken Schwaber und Jeff Sutherland eine neue Version ihres Scrum Guide veröffentlicht. Die wichtigste Ergänzung: Values!

Unlocked Content
Vorschaubild

Immer mehr Firmen setzen auf agiles Projektmanagement. Dementsprechend wächst die Nachfrage nach qualifizierten Mitarbeitern, die idealerweise auch über die entsprechende Zertifizierung verfügen.

Alle Kommentare (1)

Georg
Angermeier
Dr.

Hallo Joachim,
vielen Dank für diese kompakte und so treffende Zusammenfassung der Änderungen im neuen Scrum Guide!
Mir gefällt vor allem die nun deutlich pragmatischere und entspanntere Darstellung. So wurde mein "Lieblingsstolpersatz": "Sprint cancellations are often traumatic to the Scrum TeamScrum TeamDas Scrum Team besteht aus Scrum Master , Product Owner und den Entwicklern  (vormals Entwicklungsteam). Im Managementsystem Scrum ist die Projektorganisation durch das Scrum Team definiert., and are very uncommon." ersatzlos gestrichen und klar formuliert, dass der Product Owner eben einen Sprint abbrechen kann, wenn das Sprint Goal obsolet geworden ist.
Mein neuer persönlicher Lieblingssatz des Scrum Guides ist aber: "Scrum is simple." Das kann man meines Erachtens nach nicht oft genug betonen. 12 Seiten kann jeder lesen, beherzigen und umsetzen. Vor allem aber: Ganz einfach machen!