Hinweis: Dieser Blogbeitrag verwendet zur Vereinfachung der Lesbarkeit das generische Maskulinum. Damit sind selbstverständlich alle Geschlechter (m/w/d) angesprochen.
Eine Frage zum Einstieg:
Was tut man, wenn folgende Situation besteht: Es gibt ein "Scrum Team", wird dem Product Owner untersagt, am Sprint Planning teilzunehmen, sondern dieser stattdessen im Vorfeld angewiesen wird, seine Anforderungen für den Sprint vorab zu kommunizieren, um den Developern die Gelegenheit zu geben, sich auch auf andere Produkte konzentrieren zu können?
Der erste Impuls mag lauten: Jegliches Engagement ist zwecklos, Weglaufen die einzige Option. Denn die Implementierung von Scrum ist definitiv gescheitert!
Doch dieser Weg wird nicht dazu führen, die Benefits, die in der Anwendung von Scrum liegen, effektiv zu nutzen und damit den größtmöglichen Nutzen zu erzielen. Denn immerhin muss man der Organisation ja zugute halten, dass sie sich offensichtlich auf Scrum einlassen möchte, ansonsten gäbe es gar keinen Product Owner.
Wie also kann man versuchen, Schritte zu gehen, die einem Product Owner helfen, in einem solchen Umfeld zu bestehen?
Hier drei Tipps, die ich Product Ownern in einer solchen Situation empfehle, um die Situation zu verändern:
1. Scrum Master konsultieren
Ein Scrum Master ist laut Scrum Guide
"... accountable for establishing Scrum as defined in the Scrum Guide".
Da offensichtlich das Fernhalten eines Product Owners vom Sprint Planning völlig entgegen der Darstellung im Scrum Guide ist, sollte ein Scrum Master auf diese Fehlentwicklung hinweisen und mit der Organisation erörtern, warum dieser Umstand besteht. Unabhängig daovn, ob die Entscheidung bewusst oder unbewusst getroffen wurde, behindert sie doch die Zusammenarbeit innerhalb des Scrum Teams. Ein Scrum Master kann durch gezielte Fragestellungen im Coaching darauf hinwirken, das Bewusstsein für eine effektive Implementierung von Scrum in der Organisation zu schärfen und Impediments, die dieser Entwicklung im Wege stehen, aktiv entgegenzuwirken.
Kleiner "fun fact" am Rande: In dem genannten Beispiel-Szenario gibt es sogar keinen Scrum Master. Hier besteht also noch viel größerer Handlungsbedarf. Denn die bestehende Implementierung von Scrum, die offenkundig dem Ansinnen von Scrum laut Scrum Guide widerspricht, kann noch nicht einmal durch einen Scrum Master kritisch geprüft und herausgefordert werden. Es gibt also ein überborderndes Impediment, was es zu lösen gilt, um anschließend einzelne Entwicklungsschritte gehen zu können.
2. Impact aufzeigen
Etwas, was zu 1.) helfen kann, ist es, den Impact aufzuzeigen, der sich aus der Situation ergibt. Denn nichts ist frustrierender für einen Product Owner, wenn er seiner Aufgabe nicht gerecht werden kann.
Das bewusste Ausschließen aus einem Sprint Planning gehört de facto dazu. Denn es geht in einem Sprint Planning nicht nur darum, als Product Owner über die Product Backlog Items zu "referieren" und diese dem übrigen Scrum Team vorzustellen, sondern auch darum, gemeinsam ein Ziel für den Sprint zu definieren. Um dieses effektiv tun zu können, benötigt man jedoch aucch eine Information darüber, wie viele Elemente aus dem Product Backlog von den Developern bearbeitet werden können. Gibt es diese Rückkopplung zwischen Product Owner und Developern nicht, wissen beide nicht, worauf sich im Sprint fokussiert werden soll.
Letztlich kann dies dazu führen, dass die Developer während des Sprints nicht wissen, wie sie sich organisieren sollen, was im Endeffekt in einem Nichtvorhandensein eines Inkrements besteht, da parallel an vielen Dingen gearbeitet wurde ohne klaren Fokus auf das Wesentliche. Und wo kein Inkrement geschaffen wurde, dort entsteht auch kein Wert für das Produkt.
Dieser Pfad zeigt beispielhaft auf, welche Konsequenzen sich aus einer bestimmten, vermeintlich kleinen Abweichung vom im Scrum Guide beschriebenen Setup ergeben können.
3. Multi-Tasking ist Mist!
Wenn - wie in obigem Beispiel dargestellt - Developer an mehreren Produkten gleichzeitig arbeiten sollen und entsprechend von unterschiedlicher Seite mit Product Backlog Items konfrontiert werden, dann entstehen schnell Irritationen. Es ist nicht klar, welches Produkt und welche Tätigkeit wirklich wichtig ist, denn die Entscheidung darüber wird ausgesessen und ignoriert. Oder noch schlimmer: Es wird gleich der Eindruck vermittelt, es sei gut, an allen Themen gleichzeitig zu arbeiten.
Doch Gerald Weinberg hat in seinem Buch Quality Software Management: Systems Thinking aus dem Jahr 1991 bereits herausgestellt, dass Multitasking nicht zielführend ist. 
So sinkt laut seiner Aussage die Produktivität um 20% ab, sofern eine weitere Aufgabe zur Bearbeitung hinzukommt. Mit jeder weiteren Tätigkeit, die aufgenommen werden muss, folgt eine weitere Produktivitätseinbuße um weitere 20%. Daher lautet das Credo: Versucht, euch auf ein Projekt (in diesem Falle ein Produkt) zu konzentrieren und schafft die Voraussetzungen dafür, dass sich Scrum Teams als solches, aber Developers im Besonderen auf ein Thema fokussieren können und damit einen wichtigen Scrum Value leben können.
Fazit
Wie es im Scrum Guide definiert ist:
"Scrum is simple. [...] The Scrum framework is purposefully incomplete, [...] is built upon by the collective intelligence of the people using it. [...] the rules of Scrum guide their relationships and interactions."
Natürlich schreibt das Scrum Framework nicht alle Details. Vielmehr noch: Viele Details wurden mit der vergangenen Revision des Scrum Guide gestrichen (z.B. die drei Leitfragen im Daily Scrum). Dies geschieht, um mehr Flexibilität zu ermöglichen und Individuen, Teams und Organisationen die Freiheit zu geben, selbst über eine effektive Implementierung von Scrum nachzudenken.
Aber: Es gilt immer auch, die Auswirkungen des eigenen Handelns zu bedenken und zu hinterfragen. Wenn ich mich als Organisation dazu entscheide, meinen Product Owner vom Sprint Planning auszuschließen, dann führt das zu einer negativen Veränderung in der Art und Weise, wie dieser mit den übrigen Mitgliedern des Scrum Teams interagiert und die letztlich den Erfolg von Scrum konterkariert.
Haltet also die Augen offen und helft eurem Umfeld, einen bewussteren Umgang mit Scrum zu pflegen. Nähere Details können wir gern auch in meinen Professional Scrum Master oder Professional Scrum Product Owner-Trainings besprechen.