Das Product Owner Team ist ein Konstrukt, das in vielen großen Agile Transformationen verwendet wird, um die Herausforderungen des Scrum Product Owners skaliert zu bewältigen. Die spezifische Zusammensetzung des Produktteams hängt jedoch stark von den individuellen Bedürfnissen des Unternehmens ab. Daher scheint es keinen großen Konsens darüber zu geben, wie dieses Team umgesetzt werden soll. Zusammenfassend gesagt, die diesem Team zugeordneten Personen teilen die Rolle des Scrum Product Owners.

Die Community of Practice für Product Owner, kann vom Ablauf ähnlich wie die Community of Practice für Scrum Master abgehalten werden. Die Inhalte weichen jedoch voneinander ab. Große Lösungsteams werden daher oft als Programme bezeichnet. Solche Teams sind oft in Teams von Teams organisiert. Jedes der Subteams arbeitet demzufolge auf seiner Seite an der Gesamtlösung. Um dies effektiv zu tun, muss es eine Koordination zwischen den Subteams geben. Der Product Owner in jedem Subteam ist ein Mitglied des Product Owner Teams für das Programm.

Das Product Owner Team wird von einem Chief Product Owner geleitet. Der Chief Product Owner kann Product Owner eines Entwicklerteams sein. Dies ist bei kleinen Programmen üblich, obwohl sich die Verantwortung für die Leitung des Product Owner Teams bei größeren Programmen als Vollzeitarbeit erweisen wird. In Unternehmen mit einer starken Produktmanagementkultur kann der Chief Product Owner ein Senior Product Manager sein. Die Community of Practice für Product Owner ist also ein Zusammanschluss der Product Owner für agiles Programmmanagement.

Projekte vs. Programme

Projekte sind temporäre, einmalige Vorhaben. Sie sind in der Regel an Kosten-, Ressourcen-, Budget- und Zeitvorgaben gebunden. Projekte haben klare Endtermine und kurzfristige Ziele, die konkreten Ergebnissen oder Ergebnissen Platz machen. Programme bestehen aus mehreren zugrundeliegenden, miteinander verbundenen Projekten. Diese Projekte ergänzen und bauen sich gegenseitig auf, um ein größeres, langfristiges Geschäftsziel zu erreichen. Ein erfolgreiches Programm fördert strategische Vorteile und organisatorisches Wachstum und nicht nur ein einzelnes, greifbares Ergebnis.

Agil + Programm Management = Agiles Programm Management

Ganz einfach, oder? Nicht ganz.

Agiles Programm Management bedeutet für verschiedene Menschen unterschiedliche Dinge. Es könnte das Management mehrerer agiler Projekte bedeuten. Es könnte auch etwas so Herausforderndes bedeuten wie die Implementierung des Scaled Agile Frameworks; aber es könnte so einfach sein wie die Implementierung von täglichen Stand-ups für Product Owner. Agile ist eine Denkweise – eine Denkweise über Softwareentwicklung. Diese Denkweise wird schrittweise auf andere IT- und Nicht-IT-Geschäftsbereiche wie das Projektmanagement übertragen. Diese Denkweise berücksichtigt Veränderungen im Geschäftsumfeld, fördert die Neugewichtung, das Hinzufügen oder Kürzen von Anforderungen, die Anpassung von Zeitplänen usw. Es ist einfach und allgemein verstanden als das Management mehrerer zusammenhängender Projekte. Im Rahmen von Vertragsverhandlungen bedeutet Programmmanagement die Leitung des Projektmanagementbüros, einschließlich Finanzen, Risiko, Sicherheit, Verträge, Akquisition, etc. Im privaten Sektor bedeutet Programmmanagement oft die Verwaltung mehrerer verwandter Projekte mit sich überschneidenden Zielen, Anforderungen und Ergebnissen.

Bei agilem Programm Management geht es um die folgenden drei Prinzipien:

• Das Geschäft kennenlernen
• Verständnis für die spezifischen Herausforderungen des Teams entwickeln
• Entwicklung eines spezifischen Ansatzes, um den Bedürfnissen der Stakeholder gerecht zu werden.

Ziemlich vage, oder? Viele Projektmanagementbüros konzentrieren sich ausschließlich auf Check-the-Box Listen (wie Statusberichte und Projektpläne), die aber weder Probleme lösen noch Ergebnisse erzielen. Agile erfordert einen ergebnisorientierten Ansatz für den Betrieb eines Projektmanagementbüros. Infolgedessen lösen Programm Manager Probleme, indem sie sich auf Werte konzentrieren, mit Menschen interagieren und sich an Veränderungen anpassen. Die Wertschöpfung erfordert eine tiefe Wertschätzung des Geschäftsproblems und die Konzentration auf die Lösung dieses Problems. Agile Projektmanagementbüros sind strukturiert und werden mit einem Ziel betrieben: Werte für Teams, Stakeholder und Organisationen zu finden und zu liefern – wie machen Sie das also?

Die Zusammenarbeit ist ein Schlüsselelement für ein erfolgreiches agiles Programmmanagement.

Kommunikation. Gespräche helfen, Probleme zu verstehen, Erwartungen und Prioritäten zu setzen und die Zusammenarbeit zu fördern. Doch trotz dieser Vorbereitung ändern sich die Gegebenheiten und Umstände eines Projekts..

Die Prioritäten ändern sich ständig

Dies muss man akzeptieren. Agile Projektmanagementbüros antizipieren Veränderungen und können sich anpassen, weil sie iterative Ansätze anwenden, was zu mehr Flexibilität im Umgang mit Veränderungen führt. Diese Art von Projektmanagementbüros können sich schnell ändern, mit weniger Geschwindigkeitsschwankungen als beim traditionellen Programmmanagement.

Agile Programmverwaltung ist schwierig.

Agile Prinzipien können in einem traditionellen Projektmanagementbüro angewendet werden. Teammitglieder sollten nach dem Wert in jeder Aktivität suchen und in ständigem Kontakt zum Kunden stehen. Stakeholder, Interessengruppen, Kollegen und andere interessierte Parteien helfen dem Team, sich anzupassen, indem Sie Veränderungen planen und annehmen.

Wie man ein agiles Programm erstellt

Wenn ein Programm vom traditionellen Projektmanagement zum Agilen übergeht, müssen das Team und die Stakeholder zwei wichtige Konzepte berücksichtigen:

• Der Fokus des Product Owners liegt auf der Optimierung des Wertes der Ergebnisse des Entwicklungsteams. Das Entwicklungsteam ist darauf angewiesen, dass der Product Owner zuerst die wichtigsten Arbeiten priorisiert.
• Das Entwicklungsteam kann nur dann Arbeit annehmen, wenn es über Kapazitäten verfügt. Der Product Owner drängt die Arbeit nicht auf das Team und verpflichtet sie nicht zu willkürlichen Terminen. Das Entwicklungsteam zieht die Arbeit aus dem Backlog des Programms, da es neue Arbeiten annehmen kann.

Roadmaps

Eine Roadmap beschreibt, wie sich ein Produkt oder eine Lösung im Laufe der Zeit entwickelt. Roadmaps bestehen aus Initiativen, die große Funktionsbereiche umfassen, und beinhalten Zeitpläne, die mitteilen, wann ein Feature verfügbar sein wird. Während sich das Programm entwickelt, wird akzeptiert, dass sich die Roadmap ändern wird – manchmal subtil, manchmal breit. Ziel ist es daher, die Roadmap auf die aktuellen Marktbedingungen und langfristigen Ziele auszurichten.

Anforderungen

Jede Initiative in der Roadmap wird in eine Reihe von Anforderungen unterteilt. Agile Anforderungen sind leichte Beschreibungen der erforderlichen Funktionalität und nicht die 100-seitigen Dokumente, die mit traditionellen Projekten verbunden sind. Sie entwickeln sich im Laufe der Zeit weiter und nutzen das gemeinsame Verständnis des Teams für den Kunden und das gewünschte Produkt. Agile Anforderungen bleiben schlank, während jeder im Team durch kontinuierliche Gespräche und Zusammenarbeit ein gemeinsames Verständnis entwickelt. Erst wenn die Umsetzung beginnt, werden sie mit allen Details ausgearbeitet.

Backlog

Das Backlog setzt die Prioritäten für das agile Programm. Das Team erfasst alle Items im Backlog: neue Features, Bugs, Erweiterungen, technische oder architektonische Aufgaben, etc. Der Product Owner priorisiert die Arbeiten im Backlog. Das Entwicklungsteam nutzt dann das priorisierte Backlog als einzige Quelle für die Wahrheit darüber, was zu tun ist.

Agile Liefermechanismen

Agile kann mit verschiedenen Frameworks (wie Scrum und Kanban) zur Auslieferung von Software implementiert werden. Scrum Teams verwenden Sprints, um die Entwicklung zu steuern. Frameworks verwenden oft Epics und Versionen, um die Entwicklung für einen synchronisierten Release- Rhythmus bis zur Produktion zu strukturieren.

Agile Kennzahlen

Agile Teams leben von Metriken. Diagramme wie Burndown und Regelkarten helfen dem Team bei der Vorhersage der Lieferrhythmen. Diese Kennzahlen und Artefakte sorgen dafür, dass sich alle auf die großen Ziele konzentrieren und stärken das Vertrauen in die Fähigkeit des Teams, zukünftige Arbeit zu leisten.

Agile läuft auf Vertrauensbasis

Ein agiles Programm kann nicht ohne ein hohes Maß an Vertrauen unter den Teammitgliedern funktionieren. Es erfordert Offenheit, um schwierige Gespräche darüber zu führen, was für das Programm und das Produkt richtig ist. Da Gespräche in regelmäßigen Abständen stattfinden, werden Ideen und Anliegen regelmäßig geäußert. Das bedeutet, dass die Teammitglieder auch Vertrauen in die Fähigkeit und Bereitschaft des anderen haben müssen, die in diesen Gesprächen getroffenen Entscheidungen umzusetzen.

Das Product Owner Team

Das Product Owner Team trifft sich so oft wie nötig. Dies kann auch in der Form und Häufigkeit eines Dailys passieren. Die wichtige Sache ist, dass sie sich selbst organisieren, um festzustellen, was für sie am besten funktioniert. Das Product Owner Team kann Business-Analysten (ein Beispiel für eine spezielle Rolle im DAD) umfassen, die die Product Owner bei der Zusammenarbeit mit Stakeholdern unterstützen, um ihre Anforderungen zu verstehen. Dies ist besonders wichtig, wenn das Team eine hohe Komplexität angeht oder wenn die Interessengruppen geografisch verteilt sind. Dieses Team ist daher für die Aktivitäten des Anforderungsmanagements innerhalb des Programms verantwortlich. Dazu gehören:

Identifizierung des anfänglichen Umfangs des Programms

Das Product Owner Team wird gerade genug erste Anforderungsmodelle durchführen, möglichst unter aktiver Beteiligung der Interessengruppen, um den anfänglichen Umfang des Programms zu ermitteln. Dieser Bereich wird sich mit hoher Wahrscheinlichkeit im Laufe der Zeit weiterentwickeln, aber vorerst ist es das Ziel, den Bereich ausreichend zu erforschen, um das Programm in die richtige Richtung zu lenken. Weitere Informationen finden Sie im Prozessziel Explore Initial Scope.

Ermittlung der laufenden Anforderungen

Eine der Hauptaufgaben eines jeden Product Owners besteht darin, die Anforderungen der Interessengruppen zu ermitteln und zu untersuchen. Im Falle eines Programms muss das gesamte Product Owner Team seine Bemühungen zur Erhebung von Anforderungen koordinieren.

Zuordnung von Anforderungen zu Subteams

Wenn neue Anforderungen identifiziert werden, arbeitet das Product Owner Team, um das geeignete Subteam für die Ausführung der Arbeit zu identifizieren und die Arbeit dann diesem Team zuzuweisen.

Verwaltung von Anforderungsabhängigkeiten

Es gibt immer Abhängigkeiten zwischen den Anforderungen, und diese Abhängigkeiten sollten von den entsprechenden Product Ownern verwaltet werden. Wenn beispielsweise eine Anforderung, die der Untergruppe A zugeordnet ist, von einer anderen Anforderung abhängt, dann sollte diese idealerweise entweder vor oder gleichzeitig implementiert werden.

Entwicklung einer Produkt-Roadmap.

Das Product Owner Team ist verantwortlich für die Entwicklung einer Produkt-Roadmap für das Programm, die eine hochrangige Geschäftsausrichtung für das Produkt festlegt. Diese Roadmap sollte die allgemeine Geschäfts-Roadmap des Unternehmens widerspiegeln, falls vorhanden.

Stakeholder-Management

Beim Stakeholder-Management geht es darum, die Motivationen und Verhaltensweisen von Personen zu identifizieren und dann zu verstehen, was sie in einem Projekt erreichen wollen oder beeinflussen können. Hieraus könenn relevante Strategien entwickelt werden. Das Stakeholder-Management ist eine der wichtigsten „Soft Skills“ ist, die ein Product Owner haben kann.

Alles über die Aufgaben eines Prduct Owner erfahrt ihr im Artikel Scrum Basics: Product Owner [link]