Der Product Owner, die unterschätzte Rolle im SCRUM

Beschäftigt man ich mit SCRUM und anderen agilen Techniken, wird schnell klar dass es sich hierbei meist um Entwicklergetriebene Vorgehensmodelle handelt. Sehr gut zu erkennen ist dies darin, dass zumeist in epischer Breite beschrieben wird, wie genau die Steuerung der Arbeitsflüsse im Team geschehen soll – wobei das Team in der Regel dann auch das „Entwicklungsteam“ meint – unabhängig davon ob es sich dabei um die Entwicklung von Software oder was auch immer handelt.

Ohne Frage ist es eine gute Sache, dass sich solche Entwicklungsteams um ihre Vorgehensweise Gedanken machen, denn leider trifft man gerade hier doch zu oft nicht sehr ausgegorenen Strukturen an. Insofern halte ich den Hype der hier in den vergangen Jahren entstanden ist als durchaus sinnvoll, notwendig. Doch die meisten Publikationen zu SCRUM im Speziellen und Agilität im Allgemeinen befassen sich sehr stark mit eben genau dieser Innensicht: sie beschäftigen sich hauptsächlich damit, wie Anforderungen möglichst agil in ein Endprodukt gegossen werden.

Doch woher kommen denn eigentlich diese Anforderungen, und was geschieht am Ende damit?  Und diese Frage führt meines Erachtens zu einem wesentlichen Erfolgsfaktor in der Implementierung agiler Vorgehensmodelle – neben den Modellen an sich. Den der Product Owner spielt in diesen Szenarien eine ganz wesentliche Rolle: er identifiziert die Anforderungen an das zu entwickelnde Produkt, er sorgt dafür dass diese ausreichend detailliert beschrieben sind, er nimmt die Ergebnisse der Entwicklung ab und übergibt sie an die ursprünglichen Anforderer.

Damit steht und fällt der Erfolg agiler Vorgehensweisen mit den Kompetenzen des Product Owners ebenso wie mit dem Können der Entwickler! Denn hat dieser zu geringen oder gar einen falschen Bezug zu denjenigen die die Anforderungen haben, fehlt ihm Fachlichkeit, Empathie, Urteilsvermögen um zu identifizieren, was die wirklich wichtigen Merkmale sind dies es gilt umzusetzen, so wird er Anforderungen falsch oder möglicherweise gar nicht, oder nicht richtig priorisiert in den Entwicklungszyklus einsteuern. Nicht zuletzt muss er am Ende die Ergebnisse der Entwicklung gegen die ursprünglichen Anforderungen spiegeln können, um bewerten zu können ob der Zeitpunkt gekommen ist mögliche Iterationen zu verlassen und fertige Produkte auszuliefern.

Hier erkennt man in einem ach so ganz anderen, gehypten Vorgehen dann doch wieder die klassischen Element der Business Analyse und des Requirements Engineerings. Nicht zuletzt auch  Elemente des Projektmanagements – der Product Owner muss ein Meister des Stakeholdermanagements sein um zu erkennen, wen er abholen muss und wem er ggf. weniger Beachtung schenken braucht.

Scrum ist meines Erachtens ein Wirkkreis, ebenso wie klassisches Projektmanagement – die Qualität des Outputs kann maximal so gut sein wie die Qualität des Inputs. Für den inneren Teil dieses Wirkkreises und dessen Effizienz ist – ohne Frage der Scrum Master und sein Team sowie die Umsetzung der hier eingesetzten Vorgehensweise entscheidend. Doch für den äußeren Teil dieses Wirkkreises ist der Product Owner die entscheidende Ressource: die Ergebnisse am Ende aller Iterationen werden maximal nur so gut sein, wie der Product Owner die entscheidenden Stakeholder identifizieren und deren Anforderungen analysieren und – für den SCRUM gut portioniert – dokumentieren und priorisieren konnte. Doch auch das ist hier nur „die halbe Miete“ – die SCRUM Ergebnisse müssen getestet und gegen die Anforderungen gespiegelt werden, nicht zuletzt sind die Ergebnisse an die Anforderer als fertiges Produkt „zurück zu geben“ – auch ist es wieder entscheidend, wie, wann, an wen und in welcher Form dies geschieht.

Es wird Zeit, SCRUM (und agiles Vorgehen im Allgemeinen) ganzheitlich zu betrachten – es geht nicht nur um den Master und sein Team, es geht auch und vor allem um Stakeholder und Anforderer. Und auch hier gilt die klassische Binsenweisheit des Projekt Managements (leider zu oft vergessen): nur der Auftraggeber entscheidet über den Erfolg eines Projekts. Oder anders: auch agile Vorgehensweisen stehen und fallen (auch!) mit den Aspekten des Stakeholder- und Anforderungs-Managements.