Der neue Scrum-Guide – besser für den Mittelstand

Ursprünglich für die agile Softwareentwicklung entwickelt, setzt sich Scrum mit seinen schlanken Strukturen in immer mehr Bereichen und Branchen durch. Pünktlich zum 25. Geburtstag des Frameworks wurde eine neue Version des Scrum-Guide veröffentlicht. Wir haben uns die Veränderungen genauer angeschaut und fassen zusammen. Viele der Änderungen gehen auf die Anwendung von Scrum in der Praxis zurück und es wird viel Text-Balast abgeworfen. Von diesen Änderungen können besonders auch mittelständische Unternehmen profitieren.

Weniger Scrum-Bürokratie, mehr Scrum-Guide

Seit der letzten großen Überarbeitung von 2017 wurde der Scrum-Guide mehrfach geupdated. Was bisher eher wie eine Ansammlung verschiedener To-Do-Listen und Detailanleitungen wirkte, ist jetzt ein schlüssigeres Gesamtkonzept. Insgesamt ist der Scrum-Guide nun auch allgemeingültiger formuliert. So wurde die Produktorientierung aufgegeben, dafür “Complex Work” als Hauptanwendung eingeführt. Scrum lässt sich damit ohne große Übersetzungsarbeit in deutlich mehr Bereichen einsetzen.

Vor allem durch die Anpassung an die bisherige praktische Nutzung gewinnt die Verständlichkeit des Textes. Dazu fallen viele formale Vorgaben weg. Sie waren zwar in der Form eigentlich auch nicht gedacht, aber konnten von Bürokraten so gelesen werden. Beispielsweise ist das Product Backlog jetzt dauerhaft in Arbeit und ist damit weniger an den einzelnen Events aufgehängt. Hierdurch entsteht ein kontinuierlicher Work-Flow statt forcierte Unterbrechungen durch formale Pflichten.

Verantwortung und Effektivität als Mindset

Der neue Scrum-Guide setzt noch konsequenter auf Empirie als zentralen Mindsetaspekt. Hieraus werden die Grundsätze der Transparenz, Prüfung und Anpassung abgeleitet. Diese finden sich in allen Tätigkeiten wieder und bauen aufeinander auf. So wurde zum Beispiel Transparenz explizit auch auf Stakeholder erweitert, weil Prüfungen auch durch sie mit vorgenommen werden können. Damit kommt die Zusammenarbeit mit dem Kunden viel stärker zum Tragen, statt die Arbeit für ein perfektes Produkt zu glorifizieren.

Hieraus entstehen grundsätzliche Anforderungen an das Mindset der Mitglieder des Scrum-Teams. Flexibilität und Selbstdenken werden noch stärker als bisher betont. Damit fallen gleichzeitig weitere bürokratische Elemente weg. Neu eingeführt wird Lean Thinking, was nicht mit Engstirnigkeit zu verwechseln ist. Es geht um die effektive und effiziente Nutzung von Ressourcen, auch der eigenen Denkleistung. Lösungen sollen nutzbar und werthaltig sein, nicht einfach nur neu.

In der Organisation müssen Freiheiten für das Team gewährleistet werden, sonst ist Scrum hinfällig. Das ist oft eine Schwierigkeit für den Mittelstand und häufig der Grund, warum agile Ansätze scheitern. Dafür wird vom Scrum-Team aber weitaus mehr Selbstmanagement und Verantwortlichkeit gefordert! Es wird u.a. die Verantwortung für den Release eines Inkrements vom Product-Owner losgelöst, womit der Output schneller produktiv gehen kann. Die Lösungsfindung wandert dadurch mehr in die Eigenverantwortung des Teams. Hierin wird das Geben und Nehmen zwischen Scrum-Team und Gesamtorganisation deutlich.

Klare Zielorientierung statt technische Spielerei

Eine oder besser DIE zentrale Änderung betrifft die Einführung von Commitments für alle Artefakte. Mit Product Goal, Sprint Goal und Definition of Done kommt mehr Transparenz in die Entwicklung.  Während Sprint Goal und Definition of Done schon immer im Scrum-Guide vorhanden waren, ist das Product Goal hinzugekommen. Damit wird der Fokus noch stärker als bisher auf Ergebnisse und Wertschöpfung gelegt. Auch die Ebene wird verschoben – vom einzelnen Inkrement hin zum Gesamtergebnis. Ins gleiche Horn bläst die Änderung, dass es in Scrum nun um Lösungen statt Produktentwicklung geht. Ergebnisse überflügeln jetzt die Prozessperspektive.

Wenn man sich die einzelnen Scrum Ereignisse anschaut, fallen vor allem zwei Änderungen auf:

• Sprint Planning: Es soll sichergestellt werden, dass das Product Goal und die Backlog-Items verstanden sind. Hierauf baut dann das Sprint Goal auf und ist nicht mehr unabhängig für jedes Inkrement. Das sichert eine konsistentere Zielerreichung. Diese ist auch immer an und mit den Stakeholdern zu denken.
• Sprint Review: Das Review soll nicht als Schleuse für Releases gesehen werden – die dauerhafte Nutzengenerierung steht im Vordergrund. Deshalb sind nun auch mehrere Inkremente pro Sprint möglich, um schneller zum Ziel zu kommen.

Stärkere Integration im Unternehmen

Die Anforderungen an Unternehmen, die Scrum nutzen wollen, steigen. Das ist natürlich auf den ersten Blick eine noch größere Hürde für die Einführung. Der neue Scrum-Guide hebt die Voraussetzungen für das ganze Scrum-Team, indem gesagt wird, dass “They are structured and empowered by the organization to manage their own work”. Hier wird mit Empowerment eine gewisse Ressourcenausstattung und auch das Selbstmanagement garantiert. Dazu ist das Unternehmen angehalten, flexible Strukturen für die Scrum-Teams zu schaffen.

Den Anforderungen entgegen steht dafür ein aufpolierter Scrum Master. Er nimmt seine Rolle als Individuum deutlich anpackender wahr und bringt sich mehr in das Gesamtunternehmen ein. Neu sind die aus der Praxis bereits häufig bekannten Inhouse-Trainings und Beratungen für alle anderen Unternehmenseinheiten. Es fällt die Kollaboration mit anderen Scrum Mastern im Unternehmen aus der Aufgabenbeschreibung raus, weil die Rolle selbst auf stärkeren Beinen steht. Gleichzeitig reduziert die stärkere Identität die bürokratischen Vorgaben im Scrum-Guide.

Je länger die Scrum-Teams zusammenarbeiten, desto besser können sie sich entwickeln. Die bereitgestellten Ressourcen sind dafür die Basis. Die Teams lernen im Verlauf von Projekten und ihrer Routinetätigkeit ständig dazu und können so die in sie gesetzten Erwartungen und Ziele immer weiter anheben. Das baut Vertrauen auf und ermöglicht höhere Schlagzahlen. Und wenn Vertrauen nicht genug ist, reduzieren schnellere Zyklen mögliche Risiken durch engmaschigere Kontrollpunkte.

Das gesamte Team ist für die Inkremente veranwortlich. Damit besteht weniger Trennung in den Perspektiven von Product Owner und Entwicklern, die jeweils unterschiedliche Agenden verfolgen konnten. Jetzt sitzen sie zusammen in der Verantwortung und werden über das Product-Goal an das Unternehmen rückgebunden. Durch die neue Möglichkeit, mehrere Inkremente pro Sprint zu erarbeiten, nähert sich Scrum dem klassischen Projektmanagement an – nicht vom Mindset, sondern durch eine höhere Kompatibilität. Inkremente können quasi als Meilensteine gedacht werden und damit besser zwischen Sprints und Projektplänen synchronisiert werden.

Rollen mit mehr Hands-on Mentalität

Die Scrum Rollen werden zu Verantwortlichkeiten. Auch wenn es sich erstmal widersprüchlich anhört, bekommen Scrum Master und Product Owner dadurch eine eigenständigere Identität. Sie sind jetzt nicht mehr nur unterstützende bzw. extern orientierte Aufgabenbündel. Hierzu trägt bei, dass mehr aktive Schnittstellen zum Kunden und Stakeholdern vorgesehen sind. Das ist insbesondere für Kooperationen zwischen Startups und Mittelstand relevant, weil sich die unterschiedlichen Fach- und Lebenswelten so besser aufeinander abstimmen lassen. Gleichzeitig werden sie stärker mit den Entwicklern verbunden, bspw. in Doppelrolle als Entwickler, wenn sie aktiv bei der Bearbeitung des Sprint Backlogs sind. Die formale Hürde des Entwickler-Teams fällt weg, es gibt jetzt nur noch ein Team:

• Product Owner: Mit dem Product Goal hat er einen klaren Fixpunkt erhalten und muss diesen explizit und verständlich kommunizieren. Damit entsteht zwangsläufig eine größere Interaktion und Nähe zu den Entwicklern. Gleichzeitig ist er präsenter in den Events und somit stärker in die Wertschöpfung integriert. Er trägt die Verantwortung für Transparenz, Sichtbarkeit und Verständlichkeit des Product Backlogs, auch für die Stakeholder und sorgt so für eine bessere Ausrichtung der Scrum-Teams im Unternehmen. Andersrum sollen die vielfältigen Stakeholder durch ihn repräsentiert werden. Damit muss seine Arbeit und Perspektive unternehmerischer gestaltet sein als bisher.
• Scrum Master: Vom Unterstützer wird er zum True Leader. Damit rückt er als Person mehr in den Fokus und ist weniger in Hintergrundaktivitäten gefangen. Er soll stärker am Erreichen der Definition of Done mitwirken. Hierfür wird ihm auch mehr Durchsetzungskraft für Events eingeräumt, bspw. kommt er beim “Facilitating stakeholder collaboration as requested or needed” raus aus dem Klein-Klein des Produkts und integriert Scrum aktiv tiefer im Unternehmen.
• Entwickler: Die Entwickler machen die Arbeit. Damit ändert sich für sie erstmal wenig. Sie bekommen aber mehr praktische Verantwortung, z.B. für das Sprint Backlog, die tägliche Ausrichtung am Sprint-Goal oder als Profis für hohe eigene Standards.

Der Scrum-Guide für alle

Dadurch, dass der Scrum-Guide nun weniger konkret beschreibt, wie die Elemente von Scrum umgesetzt werden sollen, ist er nicht nur kürzer, sondern auch einfacher zu lesen. Dazu verzichtet er auf viele Begriffe aus dem IT-Kontext. Diese Fokussierung auf das Wesentliche macht ihn für ein breiteres Publikum interessant. Zwar ändert sich in einem gut funktionierenden Scrum-Team nur wenig, die Theorie ist aber deutlich praktischer geworden.

1. Lösungsorientierung statt Produktorientierung. Scrum hilft nun ganz bewusst in mehr Bereichen und Branchen.
2. Mit der klareren Zielorientierung folgt der Scrum-Guide der gelebten Praxis. Das macht die Planung von Projekten in klassisch operierenden Unternehmen einfacher.
3. Das Team ist näher am Kunden und Stakeholder. Das erleichtert auch die weitere Verbreitung in Unternehmen.
4. Product Owner und Scrum Master bekommen mehr Persönlichkeit. Sie interagieren mehr mit den Entwicklern und damit stärker in die Wertschöpfung eingebunden.
5. Die Rollen sind weniger exotisch. Sie können dank der verständlicheren Grundlagen besser von bestehendem Personal übernommen werden.

Für unsere Arbeit wird Scrum damit noch bedeutender. Wir haben mehr Anknüpfungspunkte an klassische Arbeitsformen im Mittelstand und dabei weniger bürokratische Elemente zu beachten. Scrum kann so leichter in verschiedene Bereiche oder Abteilungen eingeführt werden und damit Prozesse, Kommunikation und die Zusammenarbeit des Teams deutlich verbessern.