Was unterscheidet „Scrum by the Book“ von Scrum in der Realität?
Als ich anfing in der Produktentwicklung zu arbeiten, erst als Product-Owner und später als Scrum Master, wollte ich alles über die Entwicklung von Produkten lernen. Ich wollte jedes Detail verstehen. Deshalb versuchte ich, jedes Buch aus den Bereichen Softwareentwicklung, Produktmanagement und Scrum zu lesen.
Je länger ich in diesem Bereich tätig war, desto schockierter war ich, wie sehr sich die Bücher von der Realität in meinem Unternehmen unterschieden. In den Büchern war von Teams die Rede, die regelmäßig Software lieferten und eigenständig lernten, was sich Kunden wünschen und was nicht. Viele Teams, in denen ich in den ersten Jahren gearbeitet habe, entwickelten einfach nur Funktionen, die ihnen aufgetragen wurden. Und vielleicht bekam diese Funktionen nie ein Kunde in die Hände.
Dies frustrierte mich. Manchmal machte es mich sogar wütend und ich dachte mir:
„Was läuft hier falsch?“
Langsam resignierte ich. Damals hätte ich mir gewünscht, dass mir jemand gleich zu Anfang meiner Karriere die Wahrheit über Scrum gesagt hätte.
Deshalb hier drei Wahrheiten:
Wahrheit #1: Anforderungen kommen aus dem Fachbereich
Kunden sind keine Experten.
Sie verstehen nicht, wie Probleme gelöst werden können. Sie verstehen auch nicht, was technisch möglich ist und was nicht. Und ganz gewiss können sie nicht das Potenzial einer Lösung bewerten. Deshalb unterstreichen viele Bücher aus dem agilen Produktmanagement den Wert der Entdeckung. Sie vermitteln, dass Anforderungen aus dem Fachbereich eher ignoriert werden sollten. Stattdessen sollten agile Produktmanager Kundeninterviews oder Ähnliches nutzen, um die Schmerzen und Ziele der Nutzer zu entdecken. Und zu diesen entdeckten Problemen dann passende Lösungen entwickeln.
Nach meiner Erfahrung sind die Anforderungen des Fachbereichs jedoch sehr wertvoll. In der Realität nutzen Teams sie als Hinweise darauf, wo es ein unbefriedigtes Bedürfnis der Kunden gibt. Sie können eine Abkürzung darstellen, in welche Richtung sich UX-Forschung und Entdeckungsarbeit des Teams orientieren sollten.
Deshalb sehe ich Erfolg im Produktmanagement eher so:
Er besteht darin, zu wissen, wann Anforderungen blind umgesetzt werden können und wann mehr über die Probleme der Nutzer herausgefunden werden sollte.
Wahrheit #2: Aufteilung der Product-Owner-Verantwortung
Es kann nur einen geben.
Die Rede ist natürlich vom Product-Owner. Ich kenne kein Buch mit Scrum im Titel, das dies nicht propagiert. Die Analogien hierzu liegen auf der Hand. Wie viele Fahrer hat ein Auto? Wie viele Präsidenten hat ein Land? Wie viele Kapitäne hat ein Schiff? So sehr mir die Analogien und die beschriebenen Vorteile von Verantwortung und Entscheidungsgeschwindigkeit einleuchten, so wenig spiegelt dies die Realität in vielen Unternehmen wider. Aus meiner Erfahrung haben 8 von 10 Produkten, an denen mehr als ein Team arbeitet, auch mehrere Product-Owner.
Warum ist die Realität so anders?
Ich denke, Bücher übersehen gerne Folgendes: Es geht nicht nur um Verantwortung für das Produkt, Agilität oder Unternehmenserfolg. Sondern auch um Status, Hierarchie und Karriere. Product-Owner für ein großes Produkt zu sein ist eben keine binäre Entscheidung: Entweder du bist Product-Owner oder nicht. Sondern es ist ein Karriereweg. Mehr Verantwortung geht Hand in Hand mit steigendem Senioritätslevel im Unternehmen. Und deshalb wird es immer auch Junior-Produktmanager geben, die am Anfang ihrer Karriere stehen, aber am gleichen Produkt arbeiten wie ein senioriger Produktmanager. Natürlich könnten Unternehmen nun dem seniorigsten Produktmanager die Product-Owner-Verantwortung übertragen und den jüngeren Kollegen nur als Produktmanager betiteln.
Allerdings ist das einfach nicht die Realität in vielen Unternehmen.
Wahrheit #3: Interdisziplinäre Teamarbeit
Scrum Teams müssen interdisziplinär sein.
Getrennte Abteilungen und Teams führen zu komplizierten Übergaben, vielen Dokumenten und stiller Post. Deshalb sprechen sich die meisten Bücher über Scrum für Feature-Teams aus. Eine Gruppe von Experten aus unterschiedlichen Bereichen des Unternehmens, die gemeinsam alle Fähigkeiten abdecken, die es zur Entwicklung, Auslieferung und zum Betrieb des Produkts benötigt. In Büchern liest sich das gut. Wie immer liegen auch hier die Vorteile auf der Hand. Weniger Abhängigkeiten. Schnellere Entscheidungen. Was viele Unternehmen nur im Fall einer Krise als Task-Force kennen, einfach zur Normalität machen.
Die Realität sieht wieder anders aus. Interdisziplinäre Teams stellen weiterhin eher die Ausnahme als die Regel dar. Ein Grund mag sein, dass viele Unternehmen als Projekt-Organisationen aufgebaut sind und nicht als Produkt-Organisationen. Ein anderer mag sein, dass Karrierewege mehr auf Spezialisierung ausgerichtet sind und damit die Zusammenarbeit in Teams nicht fördern. Und häufig scheitert es einfach daran, dass es nicht genug Mitarbeiter mit dieser Fähigkeit gibt, damit jedes Team abgedeckt werden kann. Ich denke hier etwa an UX oder Data-Science.
Deshalb tun wir gut daran, interdisziplinäre Teams nicht als Endstation in der Teamentwicklung zu sehen, sondern als temporäre Lösung. Was häufig auch sinnvoll ist, da Produkte auch einen Lebenszyklus durchlaufen und somit nicht immer die gleichen Fähigkeiten zur Entwicklung nötig sind.
Oder in anderen Worten:
Der Schlüssel zu interdisziplinären Teams ist keine feste Teamstruktur, sondern interdisziplinäre Zusammenarbeit.
Betrachten wir diese drei Wahrheiten, dann können wir daraus die Frage schließen: Wenn die Realität, wie Scrum in Unternehmen praktiziert wird, nicht zu der Meinung in einschlägigen Fachbüchern passt, …
Warum braucht es dann eigentlich noch einen Scrum Master?
Diese Frage habe ich mir in meinen ersten Jahren als Scrum Master auch gestellt.
Immer dann, wenn ich aufs Neue realisierte, wie es wirklich in einem Unternehmen um Scrum steht. Irgendwann habe ich den Artikel „Scrum Fails?“ von Ken Schwaber gelesen:
„Scrum ist wie Schach. Entweder man spielt es nach den Regeln, oder man tut es nicht. Scrum und Schach haben weder Erfolg noch Misserfolg. Sie werden entweder gespielt oder nicht. Diejenigen, die beide Spiele spielen und ständig üben, können sehr gut darin werden. Im Falle von Schach können sie Großmeister werden. Im Falle von Scrum können sie herausragende Entwicklungsorganisationen werden, die von ihren Kunden geschätzt, von ihren Benutzern geliebt und von ihren Konkurrenten gefürchtet werden.“
Ich denke, was uns Ken hier sagen will:
Wenn sich ein Unternehmen entscheidet, Scrum zu nutzen, dann ist es die Aufgabe eines Scrum Masters, dafür zu sorgen, dass Scrum nach den Regeln gespielt wird. Das bedeutet, dass ich mich als Scrum Master nicht mit der vorherrschenden Realität im Unternehmen zufriedengeben darf.
Was mich zu einer – leider unangenehmen – weiteren Wahrheit bringt:
Bonus-Wahrheit: Als Scrum Master spielen wir nach den Regeln von Scrum
Soll heißen:
Auch wenn niemand im Unternehmen den Wert der Regeln von Scrum sieht, sollten wir weiterhin alles daransetzen, das zu ändern. Das bedeutet letztendlich, Verantwortung zu übernehmen. Als Scrum Master übernehmen wir die Verantwortung für die Umsetzung von Scrum. Und niemand hat behauptet, dass die Arbeit eines Scrum Masters einfach ist. Aus meiner Erfahrung müssen wir hierfür in Führung gehen – und zu führen kann häufig sehr einsam sein.
Deshalb empfehle ich dir:
Suche dir eine Community von Gleichgesinnten
Suche nach anderen Scrum Mastern, die sich auch nicht mit der vorherrschenden Realität im Unternehmen zufriedengeben. Scrum Master, die unaufhörlich nach Wegen suchen, Scrum so zu etablieren und umzusetzen, dass ihr Unternehmen eine herausragende Entwicklungsorganisation wird.
Eine Möglichkeit, diese Community zu finden, stellt unser „Professional Scrum Master – Advanced“-Training dar.
Dort lernst du mit Gleichgesinnten,
- wie du die Definition-of-Done nutzt, um Risiken in der Softwareentwicklung frühzeitig zu finden,
- Strategien, die Product-Ownern in jeder erdenklichen Lage helfen werden,
- ein Vorgehen, wie du mit jedem Stakeholder strukturiert Gespräche über Veränderung durchführst,
- mit welchen Metriken du den Erfolg deines Teams quantifizieren kannst
- und noch viel mehr.
Neugierig, wie das Training abläuft? Dann wirf doch einen Blick hierauf:
Über 271 Scrum Master sind meiner Empfehlung bereits gefolgt – vielleicht lernen wir uns ja auch bald persönlich im Training kennen? Marc und ich freuen uns schon.
Bis dahin: Scrum on.