Bei jeder Diskussion über die Einführung von Scrum kommt man an die Frage, wer die nicht-fachlichen Themen und Aufgaben bearbeitet. In eigentlich jedem Projekt gibt es ja über die reine Softwareentwicklung hinaus weitere Aufgaben. Diese können z.B. technischer Natur sein, wie das Bereitstellen von Serverkapazität, oder auch organisatorischer Art, wie die Information des Betriebsrates. Darüber hinaus sind meist in regelmäßigen Abständen Steuerungsgremien zu informieren und irgendjemand muss auch Routinearbeiten, wie das Erstellen von Berichten erledigen. Im klassischen Vorgehen werden diese Aufgaben meist auf der Rolle des Projektleiters gebündelt, doch was tun bei agilen Methoden?
In einer idealen Welt würden die Aufgaben zwischen den Rollen Product Owner und Team aufgeteilt. Der Product Owner übernimmt dabei z.B. alles, was nicht direkt mit der Entwicklung zu tun hat und das Team fühlt sich für alles verantwortlich, was für die Fertigstellung des Systems notwendig ist, also z.B. auch Serverbeschaffung und Rollout. In der Praxis habe ich das so aber leider noch nicht beobachten können. Häufig sind die fachlich guten Product Owner nicht unbedingt gute Manager und haben neben dem Projekt auch noch fachliche Arbeit zu leisten. Teams wiederum fühlen sich ebenso häufig nur für die reine Softwareentwicklung verantwortlich und ignorieren alles außerhalb von Entwicklungs- und Integrationsumgebung.
Die naheliegende, aber denkbar schlechteste Lösung ist, einfach weiterhin einen Projektmanager zu haben, der alle Aufgaben übernimmt, die sonst nicht erledigt werden würden. “Denkbar schlechteste Lösung”, da hierdurch ein Konflikt zwischen den Rollen Product Owner und Projektmanager vorprogrammiert ist. Selbst wenn sie beide zusammen arbeiten wollen, stellen sie aus Sicht der Projektumgebung jeweils allein verantwortliche Entscheidungsträger dar. Mal abgesehen davon, dass dieses Konstrukt zu nicht endenden Diskussionen über Scrum und dessen richtige Umsetzung führen kann.
Eleganter und in der Praxis mit weit weniger Problemen behaftet ist es, statt einem einzelnen Product Owner ein Team von Product Ownern (in der Regel zwei) zu etablieren. Dies hat den Vorteil, dass es aus Sicht des Teams und des Projektumfeldes nur eine Rolle gibt. Dass hierbei die Beteiligten unterschiedliche Facetten der Rollen ausfüllen, führt nach meiner Erfahrung nicht zu Problemen. Diskussionen über die richtige Umsetzung von Scrum sind ebenfalls seltener, da ja nur eine Rolle “Product Owner” vorhanden ist, die alle Aufgaben und Pflichten übernimmt. Ein weiterer Vorteil ist, dass dieses Konstrukt eine gute Skalierbarkeit und Flexibilität mit sich bringt: Solange nicht eine Person alle Aufgaben übernehmen kann, arbeiten zwei oder mehrere Product Owner zusammen. Ist dies nicht mehr der Fall, kann auch einer alleine alle Aufgaben übernehmen, ohne das Prozesse angepasst werden müssten. Auch eine Stellvertreterregelung und eine redundante Verteilung von Wissen ergeben sich damit quasi von selbst.
Natürlich kann auch dieses Konstrukt nicht funktionieren, wenn die beiden Product Owner nicht zusammen arbeiten wollen. Doch in diesem Fall stünde jedes Projekt vor einem schwerwiegenden Problem, ganz egal wie die Rollen benannt sind.
