Wenn Sie ein Buch zum Thema Scrum aufschlagen, finden Sie dort eine Formulierung wie: »Der Product Owner ist für das Projekt verantwortlich. Er trifft alle Entscheidungen.« Er entscheidet in der Theorie sowohl über den Umfang als auch den Auslieferungstermin der Software. Ich habe noch nicht ein einziges Unternehmen erleben dürfen, in dem der PO wirklich so weit reichende Befugnisse gehabt hätte, wenn es sich bei dem Projekt nicht gerade um ein internes Subsystem gehandelt hat. Die Frage lautet also, wie weit sollten die Befugnisse des Product Owners gehen, und wie weit reichen sie in der realen Welt?
Keine Geschäftsleitung und kein Programmmanagement der Welt gibt die Kontrolle über ein Softwareprojekt vollständig aus der Hand. Meistens bewegt sich der Product Owner in einem vorgegebenen Rahmen, in dem oft ein Auslieferungstermin und ein grober Leistungsumfang fest definiert sind. Das ist in meinen Augen vollkommen in Ordnung. Die Scrum-Aussage, dass der Product Owner alle Entscheidungen eigenverantwortlich treffen kann, ist einfach praxisfern und wird (fast) nirgendwo gelebt. Ausnahmen finden wir, wenn der Geschäftsführer selbst den Product Owner spielt (es führt zu weit, hier darzulegen, warum das nur bedingt eine gute Idee ist), oder wenn es sich um ein System mit eher geringerer Bedeutung handelt.
Das Problem beginnt erst, wenn man sich nicht darauf verständigt, wie weit die Entscheidungsbefugnisse des Product Owners gehen, und beide Seiten hier von unterschiedlichen Dingen ausgehen. Das kann ein paar sehr unangenehme Gespräche – manchmal auch Schlimmeres – zur Folge haben. Zunächst einmal ist es wichtig, dass man sich als PO vom Gedanken verabschiedet, alles allein entscheiden zu dürfen, was natürlich nichts daran ändert, dass man fürchterlich auf den Deckel bekommt, wenn die Sache schief geht, denn die Sache mit der Verantwortlichkeit für den Projekterfolg wird bei Misserfolg nur zu gern wörtlich aus dem Regelbuch übernommen. Gewöhnen Sie sich als Product Owner auch an diesen Gedanken.
Bitte verstehen Sie mich nicht falsch. Ich möchte auch nicht zu schwarz malen. Wenn Scrum in einem Unternehmen gut funktioniert, dann wissen alle Beteiligten, dass man die wichtigen Entscheidungen gemeinsam trifft. Und man weiß auch, dass nicht sofort der Product Owner an den Pranger gestellt wird, wenn es schief geht, sondern nur dann, wenn der Grund für das Scheitern auch in seinem Aufgabenbereich lag. Dafür ist es notwendig, dass sich alle darauf verständigen, wann die Zuständigkeiten des Product Owners beginnen, und wann sie enden. Dies sollten Sie in jedem Fall zu Projektbeginn ansprechen und auch klar definieren und fixieren. Wenn dies nur schwammig formuliert wird oder alle meinen, dass man schon irgendwie klar käme, weil das sowieso irgendwie logisch sei (die wichtigen Dinge gingen eben über die Geschäftsleitung/Programmmanagement, die Details wären Sache des POs), ist die Wahrscheinlichkeit sehr hoch, dass man irgendwann feststellt, dass es eben doch nicht so klar ist.
Dieses Thema kann entweder vom Product Owner selbst oder auch vom Scrum Master angesprochen werden. Ich rate jedoch jedem PO, das selbst auf den Tisch zu bringen. Man steht für seine eigenen Interessen ein. Wenn man in einer solchen Sache einen anderen für sich sprechen lässt, signalisiert das Schwäche und Abhängigkeit. Das sollte zwar kein Thema sein, und man sollte diese Dinge auch nicht unbedingt so interpretieren, aber in den allermeisten Unternehmen muss man in einer Führungsposition (und als solche wird der Product Owner interpretiert) Stärke zeigen.
Dieses Thema ist Teil der Projektorganisation, wie sie zu Beginn des Projekts definiert wird. Product Owner, Scrum Master und Team verständigen sich auf die Sprintlänge, die Definition of Done und all die anderen entwicklungsspezifischen Dinge, während sich Product Owner, Scrum Master und alle anderen auf alles andere einigen. Der Scrum Master sollte dabei vorangehen, Vorschläge machen und überzeugen. Er kann jedoch nicht allein entscheiden. So ist es beispielsweise sinnvoll, dass sich alle Beteiligten (Stakeholder, Geschäftsleitung, PO etc.) regelmäßig treffen und austauschen. Der Scrum Master schägt das vor und argumentiert mit den Vorteilen dieser Runde. Wenn alle anderen das jedoch verweigern (aus welchem Grund auch immer), dann kann er das nicht vorschreiben, sondern muss sich fügen. Ein Unternehmen, in dem Agile Gedanken ernst genommen werden, wird in den meisten Fällen jedoch den Empfehlungen des Scrum Masters folgen oder diese zumindest aufnehmen und nach einem Kompromiss suchen.
Es bedeutet nicht, dass ein Unternehmen Agilität nicht verstanden hat, wenn es nicht allen Vorschlägen des Scrum Masters folgt, so lange es sich damit auseinandersetzt und sich bemüht, die Absicht des Scrum Masters zu verstehen. Folgt darauf der Versuch, unter Einbeziehung des Scrum Masters, einen Kompromiss zu finden, dann ist alles in Ordnung, sofern es sich um echtes Bemühen und nicht nur um ein Alibimeeting handelt.
Dieser gesamte Prozess der Definition der Projektorganisation ist enorm wichtig und wird leider sehr oft zu schnell abgehandelt. Wenn Sie hier Fehler machen oder unachtsam sind, leidet das Projekt enorm. Wenn Sie Fragen haben, helfe ich Ihnen gern.
Zurück zu den Befugnissen des Product Owners: Wenn man sich darauf verständigt, sich regelmäßig zu treffen und auszutauschen, dann ist Vieles gewonnen. In diesen Meetings wird der Product Owner die Priorisierung der Epics und Anforderungen ansprechen und seinen Vorschlag vorstellen. Er kann auch erklären, wie er zu dieser Reihenfolge kommt, und warum er meint, dass ein Vorgehen nach diesem Plan sinnvoll ist. Es geht hierbei nicht um die Details und einzelne Anforderungen, sondern um die großen Themen (eben die Epics – ich rate Ihnen dringend dazu, diese für die Sortierung Ihres Backlogs zu nutzen). Die Runde wird in aller Regel den Vorschlägen des Product Owners folgen, vielleicht auch eine kleine Änderung besprechen. Wichtig ist, dass diese vorbereitende Planungsarbeit des Product Owners ernst genommen und zur Grundlage der gemeinsam getroffenen Entscheidung über Umfang und Releasetermin der Software wird.
Der Rahmen, in dem sich der Product Owner später frei bewegen kann, wird also unter Mitwirkung des POs abgesteckt. Dieser sollte das Projekt soweit vorbereiten, dass er seinen Plan über Umfang und Termine aufgrund von Fakten und Recherchen erstellen kann. In der Regel hat ein anderer die Idee für das Projekt. Ein anderer macht sich erste Gedanken über den Leistungsumfang. Mit diesen ganz groben Vorgaben erarbeitet der Product Owner einen Releaseplan, der dann zumindest von der Geschäftsleitung abgesegnet wird (oder dem Programmmanagement oder wem auch immer).
Nimmt das Unternehmen Scrum und die Rolle des Product Owners ernst, dann wird seine Planungsarbeit weitestgehend übernommen und zur Grundlage des weiteren Vorgehens. Der Releaseplan wird unter Leitung des Product Owners gemeinsam finalisiert. Nach seiner Meinung fragt man, auf seinen Rat hört man. Wenn Sie das in Ihrem Unternehmen so vorfinden, dann ist alles in Ordnung. Wenn der Releaseplan und damit auch der Umfang der Software weitestgehend vorgegeben ist, dann wird der Product Owner zum reinen Verwalter des Entwicklungsteams. Das hat wenig mit einem Agilen Vorgehen zu tun.
Innerhalb dieses gemeinsam definierten Rahmen sollte sich der Product Owner jedoch frei bewegen können. Es ist seine Aufgabe die Details zu definieren (selbstverständlich im Austausch mit den jeweiligen Stakeholdern). Es ist seine Aufgabe, die Sprints zu planen und vorzubereiten. Er ist Ansprechpartner für die Entwickler. Bei ihm laufen die Fäden zusammen. Damit hat er auch den Releaseplan im Blick und kann rechtzeitig eingreifen, wenn Änderungen nötig werden. Dies ist der Moment, in dem er sich wieder mit Anderen abstimmen muss. Der Releaseplan stellt auch den Weg zum Return of Investment dar, er ist in wirtschaftliche Abhängigkeiten eingebunden. Wenn ein Produkt erst später oder mit geringerem Leistungsumfang veröffentlicht werden kann, dann betrifft dies das gesamte Unternehmen. Diese Entscheidung sollte der Product Owner nicht allein treffen. Der Grund dafür ist einfach: er kann nicht alles wissen. Andere wissen vielleicht besser, was Mitbewerber gerade planen. Andere wissen vielleicht besser, ob es sich das Unternehmen leisten kann, vielleicht einen Monat länger mit der Veröffentlichung zu warten. Am Gespräch mit Investoren ist oftmals nur die Geschäftsführung beteiligt.
Es kann viele Gründe geben, wichtig ist nur, dass der Releaseplan nicht allein Sache des Product Owners ist, auch wenn seine Arbeit die Grundlage dafür ist. Innerhalb des Releaseplans sollte er sich jedoch frei bewegen können. Noch weiter von außen Einfluss zu nehmen, schränkt Product Owner und Entwicklungsteam in ihrer Arbeit so weit ein, dass nicht mehr von einem Agilen Vorgehen gesprochen werden kann. Es läuft darauf hinaus, dass der Austausch das Vorgehen bestimmt. Product Owner und Stakeholder verständigen sich auf den großen Plan, PO und Team verständigen sich auf die Details. Die Rolle des Product Owners ist also mehr die einer Schnittstelle als die eines großen Entscheiders, auch wenn er an allen Entscheidungen beteiligt ist.
