Scrum 3.0 im Einsatz

Als ich 2015 als Produkt Moderator (oder moderierender Product Owner) bei meinem vorherigen Arbeitgeber angefangen habe, ahnte ich nur, was für spannende Herausforderungen und neue Erfahrungen im Kontext der agilen Softwareentwicklung auf mich zukommen.

Im Dezember 2015 konnte ich Boris Gloger in Berlin bei einem inspirierenden Vortrag begeistert zuhören, in dem es um die logische Weiterentwicklung von Scrum 1.0 bis hin zu Scrum 3.0 ging.

Wie schreibt Boris Gloger dazu so schön passend in seinem Unternehmens-Blog:

»Wir dürfen heute nicht mehr die ollen Kamellen erzählen, denn die haben sich über die Jahre als nicht funktional erwiesen.«

Was hat sich aus meiner Sicht bezüglich Scrum verändert?

Das Schätzen von User Stories hat eine geringere Bedeutung als früher; es dient hauptsächlich der Kommunikation im Team, weniger der Messung der Velocity (relative Entwicklungsgeschwindigkeit)
Die Velocity dient zur Messung des Entwicklungstempos, nicht der Produktivität
Im Umsetzungsteam sind alle Fähigkeiten vorhanden, um das Produkt ganzheitlich zu entwickeln
User Stories werden nicht mehr nur vom Product Owner geschrieben, das gesamte Team arbeitet an den Stories
Dailys bestehen nicht mehr aus den drei Standardfragen, sondern stellen das Tagesziel in den Vordergrund, erzeugen einen Fokus und dienen zur Koordination der Zusammenarbeit - auch zwischen den Gewerken
Der Scrum Master befähigt die Teammitglieder, richtig zu kommunizieren, einen Umgang mit Störungen zu erlernen; das Team muss nicht mehr beschützt werden
Der Scrum Master arbeitet als Servant Leader, als Handlungsempfehler und Orientierungshilfe
Eine Sprint hat immer einen klaren Fokus, ich nannte es derzeit (denglisch) Number One Goal (+ kleine Nebenziele)
Es wird kontinuierlich deployed, Releases sind, sofern die Rahmenbedingungen es zulassen, nicht mehr zeitgemäß
Der Product Owner ist zuständig für das Business aus Unternehmensperspektive (ROI), das WHY, die Vision, Strategie
Nicht nur der Product Owner, alle Teammitglieder sind dicht am (End)kunden und arbeiten im hohen Maße kundenzentriert
Mob programming: Alle Teammitglieder arbeiten zusammen und unterstützen sich gegenseitig
T-Shape Profile: Durch die enge Zusammenarbeit und das größere Verständnis für die anderen Gewerke können Teammitglieder auch Aufgaben übernehmen, die nicht zum ihrer ursprünglichen Arbeit gehören: Jeder kann testen, der Frontend Entwickler unterstützt im Backend, Marketing programmiert mit Unterstützung Testszenarien...
Teammitglieder übernehmen unterschiedlichste Verantwortung: Leiten von Kick-Off Meetings, Einstellungsgespräche, Umsetzung diverser Maßnahmen, Feedback...
Das gesamte Team entwickelt ein Business Sense, ein Verständnis für das Ergebnis des Produkts bzw der unternehmerischen Leistung
Teams müssen nicht mehr zwingend zusammen in einem Büro sitzen
Das Product Backlog ist so kurz wie nur möglich

Was mir an Scrum vorher missfallen hat?

Der Product Owner ist grundsätzlich das Bottleneck, schlimmer noch, der Single Point of Failure
Produkt- und Priorisierungsentscheidungen werden allein vom Product Owner getroffen
Das Team verspürt wenig Verantwortung gegenüber dem Ergebnis, der Product Owner ist verantwortlich, er trifft schließlich die Entscheidungen
Das mehrfach erlebte fehlende fachliche Domainwissen des Product Owner lässt ihn/sie ins Projektmanagement abrutschen
Das Team ist kaum in den Entstehungsprozess für User Stories eingebunden was nicht selten zu Verschiebungen und Ping-Pong-Kommunikation führt
Die Velocity sorgt als »Interne Referenz« zur Produktivitätsmessung oft dafür, dass Teams sich mehr mit sich als mit dem Kunden beschäftigen
Innovatives und hypothesenbasiertes Arbeiten kann ich im agilen Kontext wenig beobachten: Es geht fast ausschließlich um Prozessoptimierung und um die Verlagerung der Verantwortung in genau diesen Prozess
Der Scrum Master soll immer das Team beschützen; das Team vor dem Product Owner, das Scrum Team vor dem Marketing usw.
Dem Daily wird von Teams wenig Wert zugemessen; die drei Daily Fragen werden (zu Recht) als sinnlos angesehen

Eine Scrum 3.0 Erfahrung

Ich konnte an diesem besagten Tag zufrieden feststellen, dass wir in unserer Organisation bereits viele sehr gute Schritte getan hatten. Und ich war echt stolz auf das Team.

Irgendwann Mitte 2016 kam ich zurück aus dem Urlaub und es gab seitens der Geschäftsführung eine strategische Änderung. Es gab in der Zeit keinen Monat, in dem nicht unvorhergesehene Änderungen an der Tagesordnung waren. Das Umsetzungsteam (Team), bestehend aus Backend- wie Frontend-Entwicklern, Marketing, BI-Analyse, Vertretern des Kundensupports, Product Owner/Moderator), war bereits resilient genug, um mit solchen kleinen schwarzen Schwänen umzugehen. In dem Fall musste im Ergebnis ein Projekt bzw. Epic vorgezogen werden, für das es keine Vorarbeiten, Vorbereitungen gab.

Also haben wir ein Experiment durchgeführt: Wir sind mit dem Problem "Der Benutzer kann nicht mit einer Volltextsuche suchen" in den Sprint gegangen. Ziel des Sprint war, das Problem auf Basis der Eingangshypothese mit einer ersten Iteration gelöst zu bekommen, dies als Grundlage für Feedback vom Kunden und Analysen zu benutzen um die Hypothese zu bestätigen oder zu verwerfen und die weiteren Schritte auf der Basis priorisieren zu können. Genau dafür ist Scrum schließlich der richtige Rahmen: Sich iterativ der perfekten Lösung zu nähern, weil man sie vorher nicht kennt.

Fehlende Vorbereitung hieß in diesem Fall: Es gab keine ausgearbeiteten User Stories, technische Evaluation, Prototypen geschweige Wireframes oder Mockups. Wir hatten allerdings wie bei jedem für das Quartalsziel vorausgewählte Projekt einen klar ausdefinierten Projekt Scope: Problemstellung aus Sicht des Kunden, Metriken, Out of Scope Definitionen, Cost of Delay, Grober Aufwand für das erste Release.

Der Sprint begann mit der Konzepterstellung im Team, gefolgt von groben User Stories, die den Rahmen definierten. Sie waren grob, da sie nicht bis ins Detail ausgearbeitet waren. Funktionalitäten wurden nach MoSCoW priorisiert. Alle waren daran beteiligt, auch der Kundensupport und das Marketing Team. Für das UX Konzept wurden zunächst zwei Prototypen auf dem Papier zur Diskussion gestellt, danach ein Prototyp weiterentwickelt. Dieser wurde dem Kundensupport zeitnah zum Testen vorgelegt. Iterativ wurde im Zusammenspiel der Prototyp verbessert. Marketing analysierte inzwischen Themen, die als Eingabe dem Team halfen, die richtigen Entscheidungen zu treffen. Wohlgemerkt ... nicht der Product Owner sondern das Team traf die Entscheidungen. Sobald die ersten Entscheidungen auf dem Tisch lagen, startete die eigentliche Produktentwicklung ... immer im Zusammenspiel aller, immer nach Pareto Prinzip. Qualität war gemäß DoD (Definition of Done) zwingend, wurde nicht hinterfragt.

Welches Ergebnis hatte dieser Sprint?

Anstrengend war es, jedoch hat dieses Experiment herausragend funktioniert!

Trotz anfangs einsetzendem Panik-Modus bei ein bis zwei Teammitgliedern haben wir gemeinsam das Sprintziel erreicht. Alle wollten ein funktionierendes Ergebnis und standen dafür ein. Live! Wir hatten am Ende des Sprints eine funktionierende, getestete, hochwertige Lösung. Nicht alle Funktionalitäten konnten umgesetzt werden. Jedoch weit mehr als die unbedingt erforderlichen.

Die Motivation war unglaublich, das Zusammenspiel geprägt von Hilfsbereitschaft, Offenheit und Flexibilität. Und es gab keine Überstunden. Das Team war am Ende durch, aber glücklich.

Ein weiteres Umdenken, was Agilität für uns bedeutet, fand statt. Die Kohärenz des Teams nahm in der Zeit gewaltig zu. Man kam sich näher, wurde sozialer, hatte mehr Verständnis. Auch über diesen Sprint hinaus.

Was haben wir daraus gelernt?

Modernes Scrum ist definitiv nicht mehr Scrum von 2001. Es ist nicht nur die Antwort auf Prozessoptimierung oder eine inkrementelle Herangehensweise zur Abarbeitung von Aufgaben, es steht vielmehr für eine auf Innovation und starkem Kundenfokus basierende Produktentwicklung, die ganzheitlich gedacht wird, die die Diversität eines Teams mit einschließt und somit das unglaubliche Potenzial des Teams entfalten kann. Und die Kundenprobleme wirklich lösen und nicht nur Hygiene- bzw. Basisfunktionalitäten oder Funktionalitäten à la Konkurrenz umsetzen kann.

Wir konnten beweisen, dass Entscheidungen spätmöglichst getroffen werden können und sollten. Eine gute Vorbereitung setzt nicht voraus, dass alles schon fest steht. Vielmehr sollte die Vorbereitung aus einem klaren Ziel, klaren Verantwortlichkeiten, einer gesunden Wertekultur, Erfahrungen, Entscheidungskompetenz und einem gewissen Reifegrad bestehen. Dann lässt sich fast jedes Problem zur Laufzeit lösen.

Wir haben es aus unterschiedlichen Gründen nicht geschafft, diese Arbeitsweise fest zu etablieren. Doch haben wir viel erreicht: Augenhöhe, Vertrauen, Wertschätzung im gesamten Team haben spürbar zugenommen, die Kommunikation wurde dauerhaft besser und intensiver. Wir haben einen weiteren agilen Reifegrad erlangt.

Warum ist Scrum 3.0 für jedes Agile Unternehmen relevant?

Agilität hat schon in vielen Unternehmen Einzug gehalten. Sie verbessern mit Scrum mitunter erfolgreich bestehende Technologien und Geschäftsmodelle. Jedoch haben auch diese Unternehmen nur selten Ambitionen für disruptive Innovationen, die in unserer heutigen schnelllebigen Zeit immer wichtiger werden. Es fehlt an Anreiz und Weitblick, die Wirtschaftslage ist derzeit oft großartig.

Um diesem sogenannten »Innovators Dilemma« zu entkommen, bietet Scrum 3.0 aus meiner Sicht einen ersten herausragenden Rahmen für das entsprechende Setup und Agile Mindset auf Teamebene. Wohlgemerkt, einen ersten.

Wir haben u.a. mit dem Experiment nachweisen können, dass Teams dafür bereit und Mitarbeiter bei entsprechenden Rahmenbedingungen fähig sind, Agil nach Scrum 3.0 zu arbeiten.