Ich arbeite bei ACOLAD als ECM-Team-Coach und verbringe die meiste Zeit damit, führende Produktteams bei der Implementierung von COTS-Anwendungen (Common-of-Shelf-Software) in Unternehmensumgebungen zu leiten. Dies beinhaltet die Einführung agiler Softwareentwicklungsmethoden sowie die Zusammenführung von Geschäftsanwendern und Entwicklern in einem T-förmigen, multifunktionalen Team.
Wenn man sich gut funktionierende Scrum-Teams anschaut, ist eines klar: Wenn der Product Owner (PO) der Schlüssel zu einem erfolgreichen Produkt darstellt, steht das Team bildhaft für dessen verschlossene Schatztruhe.
Der PO spielt eine der drei Rollen (Scrum Master, Leiter des Entwicklerteams und Product Owner) des Scrum-Frameworks für agiles Projektmanagement. Er ist die einzige Person, die für die Verwaltung des Product Backlogs verantwortlich ist. Auf den Punkt gebracht: die Liste aller Elemente, die innerhalb des Projekts erledigt werden müssen. Diese können entweder technisch oder benutzerzentriert sein, z. B. in Form von User Storys (US). Den Product Backlog klar auszudrücken sowie die Bedürfnisse von Stakeholdern in brauchbare Anweisungen zur Erstellung und Bereitstellung von Lösungen für diese Herausforderungen umzusetzen – darin liegt der Schlüssel zum erfolgreichen Start eines agilen Softwareentwicklungsprojekts.
In vielen Fällen sind die Business-Stakeholder auf Kundenseite nicht in der Lage, sich dem Tempo des agilen Teams anzupassen und übermitteln Informationen und Anforderungen nicht auf die richtige Art. So kann das Entwicklungsteam schlecht nachvollziehen, welche Aufgaben zu erledigen sind. Um beide zusammenzuführen, muss der PO sicherstellen, dass das Product Backlog sichtbar, transparent und für alle klar und deutlich ist. Dieser soll zeigen, woran das Team als Nächstes arbeiten wird, um ein Ziel zu erreichen bzw. eine Frist einzuhalten.
Wie kann ein Agile Product Owner sein Team dazu bringen, Ihm zu vertrauen und außerdem einen größeren Nutzen für den Kunden im Rahmen eines Softwareentwicklungsprojekts zu erschaffen? Durch meiner Erfahrung, habe ich nachfolgend die vier wichtigsten Bereiche aufgelistet, in denen ein Product Owner gute Leistungen erbringen muss, um die Effektivität von Scrum-Teams aufrechtzuerhalten:
Sie leiten die Produktentwicklung und erschaffen den größtmöglichen Nutzen für den Kunden. Die Agilität schreibt einem sich selbst organisierenden Team das Tempo vor und der Product Owner ist neben dem Agile Lead oder Scrum Master der zweite Servant Leader im Team. Sorgen Sie stets dafür, einen zusätzlichen Geschäftswert zu erschaffen – besonders dann, wenn das Entwicklerteam als oberste Priorität stattdessen erst die technischen Schulden bereinigen möchte. Behalten Sie Ihre Ressourcen im Griff und nutzen diese geschickt zur Erschaffung eines besseren Produkts. Denken Sie allerdings immer daran, dass der Code / die Infra immer einem lebenden Organismus gleicht.
Lernen Sie Ihr Produkt/Ihre Aufgabe in- und auswendig kennen.
Legen Sie Ihren Fokus eher auf das Team als auf die Business-Stakeholder. Diese sind zweifellos wichtig, stellen Sie aber sicher, dass Sie das Entwicklerteam stets im Griff behalten.
Übernehmen Sie die Verantwortung für das Projekt und die Vorführungen. Verlassen Sie sich nicht auf das Entwicklerteam, wenn es darum geht zu zeigen, was als Team erreicht wurde. Beteiligen Sie sich an allen Prozessen, von der Bereitstellung bis zur Produktion sowie bei Wartungsarbeiten, und sammeln Sie das notwendige Feedback, um sich kontinuierlich voranzubringen.
Das Team kann erst mit der Arbeit beginnen wenn die Aufgabenverteilung klar ist. Ebenso sollte das Backlog-Management ordnungsgemäß durchgeführt werden. Der PO muss es sich als Aufgabe machen, das Entwicklerteam zu motivieren, den Backlog zu verbessern, eine Verbindung mit der Zielgruppe (Benutzer) herzustellen und den Fortschritt in einem Incident Tracker zu protokollieren.
Untersuchen und anpassen – das sind zwei Begriffe, die öfter im Rahmen von Agilität fallen. Der PO ist verantwortlich für den Nutzen, der durch das gesamte Team erschaffen wird. Aber dieser geht eben auch Hand in Hand mit der Qualität. Es gibt absolut keinen Nutzen, wenn die Benutzer diesen nicht annehmen wollen und das Produkt den Standards nicht entspricht.
Der PO sollte alle Aspekte der „Definition of Done“ überprüfen. Entsprechen diese der Realität? Stellen Sie sicher, dass die Prioritäten des Projekts von den Softwareentwicklungsteams gut verstanden werden. In vielen Fällen liefert das Softwareentwicklungsteam nur das, was sie für wirklich wichtig halten. Kommunikation ist an dieser Stelle sicherlich vorhanden, generell neigen allerdings Menschen dazu, an dem zu arbeiten, was ihnen gefällt und nicht daran, was wirklich getan werden muss. Der PO sollte genaustens verfolgen, was letztendlich geliefert wird.
Der Agile Product Owner ist der zweite Servant Leader im Scrum Team mit Fokus auf dem Begriff "Leader". Unabhängig davon, ob Sie eine agile Methode verwenden oder nicht – fest steht, dass die Rolle des Product Owners für den Erfolg eines Softwareentwicklungsprojekts entscheidend ist. In eher unerfahrenen Teams, in denen sich das Projektmanagement zu agileren Praktiken und einer agileren Denkweise entwickelt, kann der PO im Rahmen der Umsetzung der Aufgabe zur Bereitstellung einer qualitativ hochwertigen Lösung noch weitaus mehr bewegen.