TopMenue

Product-Owner

Scrum ist der Rahmen, Scrumcess der Prozess

Verantwortungsbereiche des Product-Owner  ^

In jedem Projekt muss es eine Hand geben, in der alle Fäden zusammenlaufen und die über alle Teile und Belange des Projektes den Gesamtüberblick hat. Bei Scrum fällt dies der Rolle des Product-Owners zu.

Der Product-Owner ist das Herz des Projektes, der starke Mann (oder die starke Frau) in Scrum, er ist der Held der Geschichte, er nimmt die zentrale Position in Scrum ein, er treibt das Projekt im Sinne des Stakeholder voran. Er trägt die Gesamtverantwortung für das Projektbudget und den wirtschaftlichen Erfolg des Projekts. Zu guter Letzt liegt es in seiner Verantwortung, dass in dem Projekt eine Software entsteht, die den Stakeholder eine möglichst hohe Wertschöpfung (ROI), ermöglicht.

Er ist, wie der Name der Rolle bereits ausdrückt, während der Erstellung der „Eigentümer“ des Produktes, er definiert und plant im Sinne der Stakeholder und in enger Abstimmung mit ihnen das fachliche Design, er trifft in ihrem Namen alle wesentlichen Entscheidungen, er gibt alle Eigenschaften des Produktes und damit die Richtung der Entwicklung vor.

Auf der einen Seite ist es also so, dass er „das Ganze“ hat und sein Hals (insbesondere, wenn etwas schief geht) in der Schlinge steckt. Auf der anderen Seite jedoch ist er niemandem gegenüber weisungsbefugt, d.h., er kann auf nicht einfach wie-auch-immer-gearteten Druck auf wen-auch-immer ausüben, um den Erfolg des Projektes so oder so zu „erzwingen“ und, vor allem, da er „den Strick um den Hals“ („single chockable neck“) hat, kann er am Ende, sollte irgendetwas schief gehen, die Schuld gegenüber den Stakeholdern auch nicht auf jemand anderen abwälzen.

Dass ist ein grundlegendes Prinzip von Scrum und nirgendwo sonst wird klarer, dass Scrum auf vollständiger Transparenz und auf den höchstmöglichen Einsatz aller Beteiligten setzt.

Wenn sich im Projekt aber gar nichts mehr bewegt, weil andere ihren Aufgaben nicht (mehr) nachkommen und niemand sie dazu bewegen kann, ihrer Verantwortlichkeiten nachzukommen, bleibt ihm am Ende nichts mehr, als diesen Zustand zu dokumentieren und das Projekt zu verlassen.

Ist „Product-Owner“ eine Position oder ein Titel?  ^

Weder, noch. Product-Owner ist, wie Scrum-Master auch, eine Aufgabe, die es ohne „wenn und Aber“ auszufüllen gilt.

Aufgaben des Product-Owner  ^

Erarbeitung der Produktvision  ^

Gleich zu Beginn eines Projektes erarbeitet der Product-Owner gemeinsam mit den Stakeholdern eine Produktvision in Form eines klaren, plakativen Bildes des zu entwickelndem Produktes. Diese Produktvision wird der Product-Owner dem Projektteam im Kick-off-Meeting (das in Scrum nicht näher spezifiziert wird) vorgestellt. Sie ist das Leitbild, an dem sich alle Beteiligten orientieren können und müssen.

Permanenter Ansprechpartner für Stakeholder und Entwicklungsteam  ^

Der Product-Owner ist der wichtigste Ansprechpartner sowohl für die Stakeholder auf der einen, als auch für das Entwicklungsteam auf der anderen Seite. Er steht zwischen diesen beiden Gruppen, er trennt und verbindet sie zugleich, er ist Filter und Übersetzer, Organisator, Koordinator, Verantwortlicher in jeder Hinsicht, sowie Planer und Entscheider.

Stakeholder und Entwicklungsteam sollten einander durchaus kennenlernen, aber sie sollten auf gar keinen Fall direkt und ohne Einbindung des Product-Owner irgendwelche Nebenabsprachen, wie z.B. Termine, Anforderungen, Änderungen oder ähnliches treffen, da sie auf diese Weise mit hoher Wahrscheinlichkeit dem Plan des Product-Owners entgegenwirken, den Plan stören oder zumindest negativ beeinflussen.

Der Sinn dahinter ist, dass die Entwickler in Ruhe und ohne Störungen von außen im geschützten Raum des Sprints an der Realisation des Produktes arbeiten können sollen. Der Product-Owner schirmt beide Seiten, Entwickler und Stakeholder, voneinander ab und versucht, sie ausschließlich mit bereits im Sinne des Projektes aufbereiteten Informationen zu versorgen, um den ihren jeweiligen Aufwand zu minimieren und die für eine hohe Produktivität notwendige Ruhe in den Prozess zu bringen.

Selbstverständlich ist der Product-Owner immer offene für Fragen oder Anregungen der Stakeholder und der Entwickler, beantwortet Fragen und trifft Entscheidungen möglichst zeitnah.

Das bedeutet nicht, dass die beiden Gruppen nicht auch direkt Informationen austauschen können sollten, aber eben nur unter zumindest informeller Einbindung des Product-Owners. Hält sich eine der Seiten nicht an diese Regel, ist es dann auch der Product-Owner, der dann mit der jeweiligen Seite ein Gespräch darüber führen und das Verhalten unterbinden sollte.

Intensive und andauernde Zusammenarbeit mit Stakeholdern und Entwicklungsteam  ^

Es ist sehr wichtig, dass er mit beiden Teams intensiv zusammenarbeitet, da er für beide gleichzeitig sowohl als Bindeglied, als auch als Trennwand fungiert. Er sollte möglichst permanent für beide Teams ansprechbar sein, immer ein offenes Ohr für sie haben und ihre Wünsche und Anregungen ernst nehmen.

Stakeholder, Entwicklungsteam und Scrum-Master arbeiten dem Product-Owner jeweils in ihrem Gebiet zu:

  • Die Stakeholder, indem sie in stetiger Zusammenarbeit mit ihm die Anforderungen erarbeiten und das ihnen am Ende jedes Sprints zur Verfügung gestellte Produktinkrement begutachten, testen, abnehmen und kommentieren,
  • das Entwicklungsteam, indem es die Software anhand der von ihnen akzeptierten Anforderungen gemäß der „Definition of Done“ und dem Projekt-Styleguide realisiert, und
  • der Scrum-Master, indem er sowohl den Product-Owner, als auch das Entwicklungsteam und, sofern notwendig, sogar die Stakeholder in allen Belangen Scrums unterstützt.
Vertreter der Stakeholder gegenüber dem Entwicklungsteam und umgekehrt  ^

Da Stakeholder und Entwicklungsteam nicht direkt ohne Einbeziehung des Product-Owner miteinander kommunizieren sollten, ist der Product-Owner in einem Gespräch mit einem der Teams der der Vertreter des jeweils anderen Teams. Spricht er also bei den Stakeholdern, ist er der Anwalt des Entwicklungsteams und spricht er mit dem Entwicklungsteam ist er der Anwalt der Stakeholder.

Motivator von Stakeholder und Entwicklungsteam  ^

Als Bindeglied zwischen den beiden Gruppen ist es die Aufgabe des Product-Owners, beide Seiten permanent zu verantwortungsvoller Zusammenarbeit zu motivieren. Hier darf der Product-Owner in seinem eigenen Interesse nie müde werden, beiden Seiten immer wieder klar zu machen, dass ihr jeweiliger Einsatz von existenzieller Bedeutung für den erfolgreichen Verlauf und Abschluss des Projektes ist.

Durchführung der Projektplanung (Features, Releases und Auslieferungen)  ^

Eine der wesentlichen Aufgaben des Product-Owner ist es, die gesamte Projektplanung durchzuführen.

Er ist derjenige, der sich mit allen Beteiligten in permanentem Kontakt und Austausch befindet und sämtliche Informationen erhält. Niemand außer ihm einen vollständigen Überblick über das Projekt. Seine Aufgabe ist es, die zu realisierenden Anforderungen z. B. in Form von User-Stories in das Product-Backlog aufzunehmen und dort zu verwalten.

Ist eine Menge von Anforderungen im Product-Backlog enthalten, die einen bestimmten Themenbereich abdeckt und ist in etwa abschätzbar, wann alle diese Anforderungen realisiert sein könnten, kann der Product-Owner ein Release planen, also einen Auslieferungsumfang, der als Ergebnis nicht nur einzelne, am Ende eines Sprints in den Produktstand integrierte Anforderungen enthält, sondern alle Anforderungen, die zur Realisation eines ganzen Themenbereiches gehören.

Durchführung von Anforderungsanalyse und -management  ^

Der Product-Owner führt von Beginn des Projektes an gemeinsam mit den Stakeholdern die permanente Anforderungsanalyse durch. Projekte werden in Scrum iterativ durchgeführt und in jeder Iteration werden jeweils die für die Stakeholder aktuell wertvollsten Anforderungen des zu entwickelnden Produktes realisiert. Aus diesem Grund ist die Anforderungsanalyse ein über die gesamte Projektlaufzeit permanent laufender Prozess.

Der Product-Owner dokumentiert jeweils die ermittelten Anforderungen in Form von User-Stories und sammelt sie im Product-Backlog, das er stets auf dem aktuellsten Stand hält und nach Priorität sortiert.

Er sollte darauf hinarbeiten, dass er stets eine Anzahl von User-Stories im Product-Backlog soweit „sprint-ready“ vorbereitet hält, dass es bei einem eventuellen Ausfall des Product-Owners oder in seinem Urlaub einem Stellvertreter möglich ist, mehrere Sprints mit den vorbereiteten User-Stories durchführen zu können.

Durchführung von Reporting gegenüber Stakeholder und Entwicklungsteam  ^

Die Stakeholder müssen regelmäßig über den aktuellen Stand des Projektes und die Prognose für den weiteren Verlauf informiert werden. Der Product-Owner, als Hauptkontakt der Stakeholder, übernimmt diese Aufgabe.

Je nachdem, ob dieses Meeting im Hause der Stakeholder oder, falls die Entwicklungsarbeit nicht vor Ort im Hause der Stakeholder stattfindet, am Standort der Entwickler, laden die Stakeholder oder der Product-Owner ein. Der Product-Owner kann zu dem Meeting auch das Entwicklungsteam einladen, z.B., um die Entwickler den Stakeholdern vorzustellen oder um das Produkt in seinem aktuellen Entwicklungsstand zu präsentieren oder präsentieren zu lassen.

Teilnahme an Meetings  ^

Der Product-Owner organisiert und moderiert die erste Phase des Sprint-Planning. Er lädt das Entwicklungsteam und den Scrum-Master, sowie eventuelle Gäste ein und bereitet eine Anzahl der höchstpriorisierten Anforderungen für das Meeting vor. Sind die Anforderungen durchgesprochen und geschätzt, nimmt er dem Entwicklungsteam das Commitment ab.

An der zweiten Phase des Sprint-Planning, die Zerlegung der Anforderungen in Arbeitspakete, die vom Entwicklungsteam in Klausur durchgeführt wird, nimmt der Product-Owner nur auf Einladung hin teil. Während das Entwicklungsteam diese Phase durchführt, sollte er ihnen auf jeden Fall für einen zuvor abgesprochenen Zeitraum für Rückfragen direkt vor Ort zur Verfügung stehen.

Das Estimation-Meeting, das der ersten Phase des Sprint-Planning ähnelt, wird ebenfalls vom Product-Owner vorbereitet und durchgeführt. Da es sich um ein Vorplanungsmeeting handelt, nimmt er dem Entwicklungsteam am Ende dieses Meetings jedoch kein Commitment ab.

Das Sprint-Review am Ende des Sprints wird vom Entwicklungsteam organisiert und durchgeführt. Sie laden zu dem Meeting den Product-Owner und eventuelle Gäste ein. Die Entwickler führen die fertiggestellten Anforderungen an-hand des neu erstellten Produktinkrements vor, die der Product-Owner prüft und abnimmt oder ablehnt. Am Ende des Meetings übergibt der Product-Owner das neue Produktinkrement den Stakeholdern.

Keine Aufgaben des Product-Owner  ^

Das Entwicklungsteam zusammenstellen  ^

Die Zusammenstellung eines Teams gehört nicht ausdrücklich zu den Aufgaben des Product-Owners.
Wenn es jedoch noch kein Team gibt, und Product-Owner ein gutes Team kennt und vielleicht mit diesem Team schon gute und erfolgreiche Projekte durchgeführt hat und er der Meinung ist, dass die Stakeholder von diesem Team profitieren können und man sich dann auch noch über die Modalitäten einig werden kann, steht dem Product-Owner nicht im Wege, sein eigenes Team mitbringen.

Festlegen, was im Sprint bearbeitet wird  ^

Der Product-Owner ist kein alles bestimmender Projektleiter. Er schlägt jeweils in der ersten Phase des Sprint-Planning lediglich eine von ihm ausgesuchte Anzahl der höchstpriorisierten Anforderungen für die Realisierung im Sprint vor. Die Abschätzung, wie viele dieser Anforderungen im Sprint dann realisiert werden können und sollen, obliegt allein dem Entwicklungsteam, dass sich mit dem Commitment verpflichtet, die akzeptierten Anforderungen bis zum Ende des Sprints fertig zu stellen

Aufgaben verteilen und organisieren für das Entwicklungsteam  ^

Der Product-Owner ist kein Projektleiter, der die Entwickler nach seinem Gutdünken einteilt. Das Entwicklungsteam organisiert sich ausschließlich selbst, und bestimmt allein, wer von ihnen wann im Sprint welche Aufgaben, Anforderungen oder Arbeitspakete bearbeitet. Entscheidend für den Product-Owner ist, dass die vom Entwicklungsteam im Commitment akzeptierten Anforderungen bis zum Ende des Sprints vollständig fertig gestellt werden und er den Stakeholdern ein aktuelles Produktinkrement übergeben kann.

Sprint-Burndown aktualisieren  ^

Die Aktualisierung des Sprint-Burndown ist eine Aufgabe des Entwicklungsteams, die es täglich im Laufe des Daily-Scrum selbst oder durch den Scrum-Master durchführt. Am Ende des Daily-Scrum kann das Entwicklungsteam dem Product-Owner das aktuelle Sprint-Burndown-Chart zur Verfügung stellen.

Anforderungen in Arbeitspakete zerlegen  ^

Die Zerlegung der Anforderungen in Arbeitspakete wird vom Entwicklungsteam in der zweiten Phase des Sprint-Planning in Klausur durchgeführt. Wenn sich der Product-Owner technisch und fachlich in der Lage sieht, hierzu einen wertvollen Beitrag leisten zu können (was Scrum nicht von ihm erwartet, da sein Aufgabenbereich an anderer Stelle liegt) und das Entwicklungsteam diesen Wunsch des Product-Owner unterstützen will, kann es den Product-Owner als Gleicher unter Gleichen zu diesem Teil des Sprint-Planning einladen.

Vorgesetzter/Chef des Teams sein  ^

Eines der wesentlichen Prinzipien von Scrum ist, dem Entwicklungsteam einen freien Raum zu verschaffen, in dem es unabhängig von äußerer Einflussnahme, Lenkung oder Druckausübung ungestört und unbeeinflusst handeln und sich im Rahmen der vorgegebenen Spielregeln frei bewegen kann. Damit soll gewährleistet werden, dass die Mitgliedern des Teams ihre inneren Potentiale nicht nur ausschöpfen, sondern gemeinsam im Team durch synergetische Bündelung auch noch verstärken können und ihrer Kreativität, ihrer Intuition und der ihnen innewohnende Innovationsfähigkeit freien Lauf lassen zu können. Diese Art von Gestaltungsspielraum, aber auch das Zeichen von Vertrauensvorschuss, Anerkennung und die Aussicht auf Teilhabe am Erfolg, schaffen eine solide Basis für ein hohes Maß an Motivation und Leistungsbereitschaft, die in hoher Produktivität und Leistungsfähigkeit münden.

Um dies zu erreichen müssen sich die Mitglieder des Entwicklungsteams gemeinsam als unabhängiger und eigenverantwortlicher Teamkörper begreifen und die Möglichkeit haben, sich gemeinsam und ungestört auf ihre Aufgaben konzentrieren können. Zudem muss das Team sich auf die Einhaltung dieser Rahmenbedingungen verlassen können, denn sobald direkt oder indirekt Einfluss, Druck oder Lenkungsbestrebungen auf das Team insgesamt oder auf Mitglieder des Teams ausgeübt werden, sind sie in ihrem Denken und Handeln nicht mehr frei und unabhängig, was die Freisetzung der Potentiale und der Synergiebildung und damit die Erfolgschancen wesentlich beschränken wird.

Ist, war, oder wird der Product-Owner der Leiter oder Vorgesetzter des Entwicklungsteams, wird sich das Team schwer damit tun, dem Product-Owner auf Augenhöhe zu begegnen und mit ihm in einer freien und entspannten Atmosphäre zu kommunizieren und zu arbeiten, da das Verhältnis der beiden Parteien zueinander aufgrund dieser vergangenen, aktuellen oder zukünftigen Konstellation heraus eine entsprechende Prägung erhält oder bereits erhalten hat, von der sich weder Product-Owner, noch Entwickler vollständig werden frei machen können.

Daher schließt Scrum disziplinäre Hierarchien, Weisungsbefugnisse, etc., zwischen den Rollen explizit aus, um allen Beteiligten die uneingeschränkte Möglichkeit zu geben, die eigenen Positionen und Potentiale in ihrem jeweiligen Verantwortungsbereich voll und zum Vorteil des Projektes ausschöpfen und auf gleicher Augenhöhe handeln und agieren zu können. Um das zu erreichen, gilt das Entwicklungsteam als ein autonomer Körper und organisiert sich im Sprint ausschließlich selbst. Aktive oder passive Einflussnahme durch den (explizit oder implizit vorgesetzten) Product-Owner behindert die entstehenden erwünschten Prozesse.

Scrum stellt die Gleichberechtigung aller am Projekt beteiligten Individuen konsequent und ausdrücklich in den Vordergrund, damit die Motivation eines jeden Beteiligten, das Projekt schnell, sicher und erfolgreich für das eigene Unternehmen und die Stakeholder abzuschließen, nicht durch ein Gefühl von Abhängigkeit, Druck oder Zwang bestimmt ist, sondern durch den Willen, Verantwortung zu übernehmen und eine hohe Leistung für Team und Projekt zu erbringen. Aus diesem Grund ist es sehr wichtig, darauf zu achten, dass die am Projekt beteiligten Individuen nicht in einem weisungsgetriebenen Abhängigkeitsverhältnis zueinander standen, stehen oder nach dem Projekt stehen werden, denn selbst wenn dieses Abhängigkeitsverhältnis für die Dauer des Projektes ausgesetzt wäre, würde es das Verhalten der Beteiligten einander gegenüber verkrampfen und damit negativ beeinflussen.

Gleichzeitig der Vorgesetzte des Entwicklungsteams zu sein, stellt daher für Product-Owner und Entwicklungsteam einen nur sehr schwer zu überbrückenden Konflikt dar. Der Product-Owner muss seine Kraft aus seiner Überzeugung und seiner Fähigkeit, diese Überzeugung auch auf andere zu übertragen zu können, schöpfen und nicht daraus, statt im Konfliktfall einen Konsens herauszuarbeiten, einfach eine Anweisung auszugeben.

Gleichzeitig Stakeholder / Scrum-Master / Entwickler  ^

Product-Owner zu sein, ist — entsprechende Komplexität des Projektes vorausgesetzt — ein hochwertiger Vollzeitjob und er sollte keine zweite Aufgabe im Projekt einnehmen. Er steht zwischen den anderen Rollen und geriete unweigerlich in weitreichende Interessenskonflikte, sollte er gleichzeitig eine der anderen Rollen innehaben. Als Stakeholder oder Entwickler bestünde die Gefahr, dass er seine Objektivität gegenüber der jeweils anderen Gruppe einbüßen würde. Scrum-Master und Product-Owner sind zwei Rollen, die in gewisser Hinsicht konträr zueinander aufgestellt sind, denn ist der Product-Owner im Gespräch mit dem Entwicklungsteam der Anwalt der Stakeholder, kann und sollte der Scrum-Master der Anwalt des Entwicklungsteams sein.

Eine Ausnahme ist, wenn ein externer Coach im Zuge der Einführung von Scrum zwischen diesen Rollen hin und her pendelt, weil er Mitarbeiter führend begleitet, die er als Scrum-Entwickler, Scrum-Master oder Product-Owner schult.

Seine Aufgaben an das Team delegieren  ^

Jede Rolle hat ihre spezifischen Aufgaben, die sie auszuführen hat und mit denen sie den anderen Rollen zuarbeitet. In diesem Rahmen hat auch der Product-Owner seine Aufgaben, die er durchzuführen hat und deren Ergebnisse er den anderen Rollen zur Weiterverarbeitung zur Verfügung stellt, z.B. den Stakeholdern das mit User-Stories gefüllte, nach Priorität sortierte, stets aktuelle Product-Backlog und dem Entwicklungsteam das Selected-Backlog mit gut vorbereiteten, dokumentierten, sowie mit aussagekräftigen und nachvollziehbaren Akzeptanzkriterien versehenen User-Stories.

Er kann das Entwicklungsteam und/oder den Scrum-Master jedoch insofern in die Anforderungsanalyse einbinden, indem er gemeinsam mit ihnen – vielleicht nicht grundsätzlich alle, aber vielleicht doch Teile — der User-Stories und ihre Akzeptanzkriterien für die Anforderungen formuliert oder ihnen das ganz überlässt. Ein gutes Team wird daran Interesse haben, in diesen Prozess eingebunden zu sein. Die hierfür aufgewendete Zeit relativiert sich dann dadurch, dass der jeweilige Vortrag des Product-Owners und das Schätzen im Estimation-Meeting und im Sprint-Planning des Entwicklungsteams ungleich schneller geht, da viele Einzelheiten der Anforderungen und ihr Kontext bereits bekannt und durchdacht sind, was einem intensiven Informationsaustausch dienlich ist.

Allerdings sollten Entwickler und Scrum-Master darauf achten, dass sie den Product-Owner lediglich in seinen Aufgaben unterstützen und ihn nicht vollständig von diesen Aufgaben entlasten, da sich ansonsten schnell und leicht unkalkulierbare Unwägbarkeiten über den zu investierenden Zeitbedarf ergeben könnten. Der Product-Owner seinerseits muss ebenfalls darauf achten, die Entwickler und den Scrum-Master nicht zu sehr zeitlich einzubinden, da sie sonst ihren eigentlichen Aufgaben nicht mehr im notwendigen Maße nachkommen können.

Das Daily-Scrum beaufsichtigen/moderieren oder sich ungefragt einmischen  ^

Das Daily-Scrum ist zwar ein öffentliches, aber dennoch rein Entwicklungsteams-internes Meeting. Der Product-Owner darf, wie auch die anderen eventuellen Gäste, das Meeting nur als stiller Gast verfolgen und nur dann sprechen, wenn er vom Scrum-Master oder vom Entwicklungsteam dazu aufgefordert wurde.

Das Sprint-Review vorbereiten, einladen oder durchführen  ^

Es ist die Aufgabe des Entwicklungsteams, die von ihnen akzeptierten Anforderungen im Sprint vollständig zu realisieren und daher gehört es zu ihrer Selbstorganisation und ihre Aufgabe, die Präsentation der realisierten Anforderungen vorzubereiten und den Product-Owner, als ihren „Kunden„, dazu einzuladen.

Aufgabe des Product-Owner ist es lediglich, die realisierten Anforderungen zu beurteilen, zu bewerten und dann abzunehmen oder zurückzuweisen.

Die Sprint-Retrospektive durchführen oder begleiten  ^

Bei der Sprint-Retrospektive handelt es sich um ein nicht-öffentliches Meeting, internes Meeting des Entwicklungsteams und des Scrum-Masters, das ihnen die Möglichkeit geben soll, den vergangenen Sprint unter Kollegen in vertrauensvoller Atmosphäre, ohne Zuschauer und ohne Einflussnahme von außen, in der Rückschau zu betrachten, zu bewerten und aus der Bewertung konkrete Maßnahmen abzuleiten und zu beschließen. Die Anwesenheit von Personen außerhalb des Kreises des Entwicklungsteams und des Scrum-Masters führen dazu, dass die Sprint-Retrospektive nicht mit der gebührenden Offenheit und Objektivität erfolgreich durchgeführt werden kann.

Eigenschaften und Fähigkeiten des Product-Owner  ^

Scrum bricht ausdrücklich mit dem Prinzip des „Command and Control“ und setzt auf Prinzipien wie Vertrauen, Respekt, Achtung, Selbstbestimmung, Verantwortungsbewusstsein und Konsensfähigkeit. Das gilt für alle Mitglieder des Scrum-Teams gleichermaßen, also auch für die in klassischen Softwareentwicklungsprozessen eher außen vor bleibenden Stakeholder, die in Scrum – Projekten immer „mittendrin, statt nur dabei“ sind.

Die von Scrum bevorzugten Werte vertreten und durchsetzen  ^

Der Product-Owner muss solche, im Hinblick auf die klassischen Softwareentwicklungsprozesse fast schon revolutionäre Ansätze nicht nur für sich selbst verinnerlicht haben, sondern auch leben, vertreten und durchsetzen. Um das zu können, sollte über eine ganze Reihe von Fähigkeiten, Eigenschaften, Kompetenzen und Kenntnissen verfügen, die ihn in die Lage versetzen, seine komplexe Rolle kompetent auszufüllen.

Ein guter Product-Owner ist gut einschätzbar  ^

Er sollte stets konzentriert, ausgeglichen und kompetent, geduldig, präzise, klar strukturiert, stringent sein und in seinen Handlungen und Reaktionen immer vorhersehbar bleiben. Neigt er zu überraschenden, vielleicht sogar nicht oder nur schwer nachvollziehbaren Handlungen oder gibt er den auf ihm ruhenden Druck vielleicht völlig ungefiltert (z.B. an das Entwicklungsteam) weiter, ist er eher ein Unruheherd als ein verlässlicher Partner. Auch ein Typ „bärbeißiger Projektleiter“, der „seine Leute“ regelmäßig „zusammenstaucht“, damit „niemand einschläft“, gilt in Scrum als äußerst kontraproduktiv.

Er ist der Teamplayer unter den Teamplayern  ^

Der Product-Owner sollte ein ausgezeichneter Teamplayer sein, denn seine „Macht“ kann er — analog zum Scrum-Master — nur aus seinen Worten und seiner Überzeugungskraft schöpfen. Er wird das „wir“ statt des „ich“ in den Vordergrund stellen, er wird motivieren statt zu drohen, er wird, wo immer es geht, begeistern statt zu zwingen, denn er weiß, dass er selbst genauso von den anderen Mitgliedern des Projektteams abhängig ist, wie sie ihrerseits von ihm. Das gesamte Projektteam ist eine Schicksalsgemeinschaft, die im Sinne des Projektziels nur gemeinsam erfolgreich sein können.

Erfolgreich durch Kompetenz in Zusammenarbeit  ^

Durch diese intensive und praktisch gelebte Zusammenarbeit, durch die Verlässlich- und Berechenbarkeit jedes Einzelnen — und da muss gerade der Product-Owner dank seiner zentralen Position neben dem Scrum-Master einen ganz wesentlichen Beitrag leisten — ergeben sich die positiven Effekte von Scrum, wie z.B. den Abbau von internen Reibungsverlusten, die Schaffung von Synergieeffekten, etc.

Um erfolgreich sein zu können, muss er daher sehr eng mit beiden Seiten, also Stakeholdern auf der einen, und Entwicklungsteam auf der anderen Seite zusammenarbeiten, für die er gleichzeitig sowohl als Bindeglied, als auch als Trennwand fungiert.

Stakeholder, Entwicklungsteam und Scrum-Master arbeiten dem Product-Owner jeweils in ihrem Gebiet zu,

  • die Stakeholder, indem sie in stetiger Zusammenarbeit mit ihm die Anforderungen erarbeiten und das ihnen am Ende jedes Sprints zur Verfügung gestellte Produktinkrement begutachten, testen, abnehmen und kommentieren,
  • das Entwicklungsteam, indem es die Software anhand der von ihnen akzeptierten Anforderungen gemäß der „Definition of Done“ und dem Projekt-Styleguide realisieren, und
  • der Scrum-Master, indem er sowohl ihn, als auch das Entwicklungsteam und, sofern notwendig, sogar die Stakeholder in allen Belangen Scrums unterstützt.
Gleichberechtigung auf Augenhöhe  ^

Der offensive Wille zu gleichberechtigter Arbeit auf Augenhöhe, zu stetiger und vertrauensvoller Zusammenarbeit durch alle Beteiligten ist essenziell für den einen guten und erfolgreichen Verlauf und Abschluss der Projekte. Darin bildet Scrum keine Ausnahme.

Zusammenarbeit mit den Stakeholdern  ^

Ein Product-Owner darf sich nicht nur als Projektmanager sehen, dessen Aufgabe und Verantwortung sich darin erschöpft, eine wie-auch-immer zustande gekommene Spezifikation in ein Softwareprodukt umzuwandeln. Er muss sich intensiv und tief in die Fachdomäne der Stakeholder einarbeiten, um sie als Berater in allen Belangen ihres Projektes beraten und unterstützen zu können.

Herausfinden, was wirklich benötigt wird  ^

Ein Product-Owner darf nicht alles, was ihm die Stakeholder sagen, bzw., was sie als notwendig oder als überflüssig erachten, unreflektiert übernehmen, sondern er muss herauszufinden versuchen, was sie wirklich meinen und wirklich brauchen, indem er das Gesagte hinterfragt, darüber hinausgehende oder alternative Funktionalitäten und Herangehensweisen vorschlägt, Konsequenzen und Risiken aufzeigt, etc.

Erarbeiten der Produktvision  ^

Ein Product-Owner sollte auch immer ein Visionär sein.
Um für alle Beteiligten ein gemeinsames Verständnis des zu erreichenden Zieles bereitzustellen, erarbeitet der er, ggf. unter Zuhilfenahme des Scrum-Masters, im ersten Schritt des Projektes gemeinsam mit den Stakeholdern eine bildhafte, gänzlich klare und in sich schlüssige Vision des Produktes.

Die Produktvision dient dazu, das eigentliche Ziel des Projektes, die Schaffung eines möglichst hohen Geschäftswertes für die Stakeholder, immer wieder ins Zentrum der Betrachtung zu rücken, denn das zu realisierende Produkt stellt für die Stakeholder kein Selbstzweck dar, sondern ist ein Werkzeug, mit dem sie in ihrer Fachdomäne Vorteile, wie z.B. Kosten zu sparen, wirtschaftliche Vorteile zu erlangen oder direkte Gewinne zu erzielen, erreichen wollen. Die Produktvision gibt jedem der Beteiligten in jeder Situation eine klare Orientierungsmöglichkeit, die es ihnen erleichtert und ermöglicht, sich immer wieder gemeinsam auf das Ziel des Projektes auszurichten.

Doch die Produktvision transportiert noch mehr. Sie soll für die Projektbeteiligten ein Motivationsinstrument sein. Sie soll so formuliert sein und so vom Product-Owner präsentiert werden, dass das gesamte Team den Eindruck gewinnt, nicht einfach nur irgendein Projekt durchzuführen, sondern auf eine Mission geschickt zu werden, auf eine sehr wichtige Mission. Die Produktvision muss transparent machen, dass und warum gerade diese Mission, auf die das Projektteam nun geht, so wichtig für das Geschäft der Stakeholder ist und darüber hinaus auch, warum diese Mission gleichermaßen wichtig für das Entwicklungsteam ist, warum die Welt nach Fertigstellung des Produktes ein besserer Ort sein wird, usw., usf.

Durchführen der permanenten Anforderungsanalyse  ^

Ist die Produktvision erstellt, steigt der Product-Owner mit den Stakeholdern in die Detaillierung der Produktanforderungen, in die Anforderungsanalyse, ein.

Das ist ein Prozess, der bei Scrum nicht einmalig am Anfang des Projektes, sondern die gesamte Projektlaufzeit über andauert, da in Scrum, anders als in den klassischen Softwareentwicklungsprozessen, von vornherein berücksichtigt wird, dass sich Sichtweisen, Meinungen und Bedürfnisse ändern können. Der Gedanke hinter Scrum orientiert sich an der Realität, dass sich den Stakeholdern der wirklich benötigte Funktionsumfang mit hoher Wahrscheinlichkeit erst im Laufe des Projektes unter Berücksichtigung aller Erfahrungs- und Erkenntnisprozesse erschließen wird.

Detaillierung der Produktvision  ^

Die Stakeholder schildern dem Product-Owner in direktem und intensivem Dialog, was sie mit dem Produkt erreichen wollen und was es für Voraussetzungen, Anforderungen und Erwartungen an das System gibt. Dabei hinterfragt der Product-Owner die ihm genannten Informationen detailliert, um die Hintergründe der Anforderungen zu verstehen und zu einer Vorstellung zu kommen, wie eine optimale Lösung der der jeweiligen Anforderung zugrunde liegenden Idee aussehen könnte.

Ist eine Anforderung in allen Belangen und in der notwendigen Tiefe mit den Stakeholdern diskutiert und geklärt, formuliert der Product-Owner die Anforderung in Form einer User-Story und weist ihr einen eindeutigen Prioritätswert zu (hohe Werte repräsentieren hohe Prioritäten). Er definiert Akzeptanzkriterien, anhand derer er später festmachen kann, ob die Anforderung korrekt und vollständig realisiert wurde und trägt sie gemeinsam mit weiteren, evtl. vorhandenen Zusatzinformationen in das Product-Backlog ein, dass er dann absteigend nach Priorität sortiert, sodass die Anforderung mit der höchsten Priorität ganz oben als erstes im Product-Backlog steht.

Wie ermittelt der Product-Owner die Priorität?  ^

Eine gängige Methode ist die MoSCoW-Priorisierung, die es dem Product-Owner ermöglicht, gemeinsam mit den Stakeholdern die Umsetzungsreihenfolge der Anforderungen in einem relativ groben Raster anhand ihrer Bedeutung für das Projektergebnis einzuordnen.

Der Begriff „MoSCoW“ ist ein Akronym, also eine Eselsbrücke.

M   MUST   Die Realisation der Anforderung ist für das Projekt von zentraler Bedeutung und muss unbedingt erfolgen
S   SHOULD   Die Anforderung muss nicht unbedingt sofort, sollte aber zeitnah umgesetzt werden, allerdings erst dann, wenn die Realisation der MUST-Anforderungen dies zulässt
C   COULD   Die Anforderung braucht nur dann umgesetzt werden, wenn die Umsetzung der SHOULD- und MUST-Anforderungen es erlauben oder sie bereits umgesetzt werden konnten
W   WON’T   Die Anforderung ist immerhin so wichtig, dass sie in das Product-Backlog aufgenommen wurde, sie wird jedoch aktuell nicht umgesetzt. Die Umsetzung dieser Anforderung erfolgt erst, wenn die Realisation der COULD-, SHOULD- und MUST-Anforderungen erfolgreich abgeschlossen wurde

Eine nähere Beschreibung des Begriffs findet sich hier.

Die Beschreibung der MoSCoW-Priorisierung an dieser Stelle könnte suggerieren, dass das Product-Backlog lediglich in vier Prioritätsstufen eingeteilt ist, aber das ist nicht so. Die Priorisierung in Scrum muss immer eindeutig sein, um jederzeit eine klare Aussage über die Realisationsreihenfolge der Anforderungen treffen zu können. Das spart Zeit, sorgt für klare Verhältnisse und vermeidet unnötige Rückfragen.

Wären mehrere Anforderungen mit der gleicher Priorität versehen, dann stünde irgendjemand zum potenziell ungünstigsten Zeitpunkt vor der Aufgabe, diese Anforderungen inhaltlich, fachlich und technisch zu bewerten, um sie dann anhand des Ergebnisses dieser Analyse in eine sinnvolle Reihenfolge zu bringen, denn die Bewertung „nehme ich erst diese oder erst jene Anforderung“ ist nichts anderes, als die Anforderungen in eine Reihenfolge zu bringen und dann die Erste zu bearbeiten. Treten bei der Bewertung irgendwelche Unsicherheiten auf, muss der Product-Owner gefragt werden, was wieder zu Verzögerungen führen kann … daher ist es eine sehr wichtige Aufgabe des Product-Owner, dass Product-Backlog stets aktuell und absolut eindeutig nach Priorität absteigend sortiert zu halten.

Die MoSCoW-Priorisierung stellt für ihn daher nur ein grobes Hilfsmittel dar, das er wiederholt, iterativ und immer feingranularer anwenden kann, bis er eine eindeutige Reihenfolge erreicht hat, denn wenn er z. B. die vier wichtigsten Anforderungen im Projekt anhand der MoSCoW-Priorisierung priorisiert, bedeutet das noch lange nicht, dass die Anforderung dieser Vier, die das ‚W‘ wie „won’t“ erhält, nicht realisiert werden soll.

Der Product-Owner ist derjenige, der den größten Überblick über das Projekt, die Anforderungen und ihre jeweilig aktuellen Gewichtungen hat, daher ist es seine Aufgabe, diese Entscheidungen zu treffen und stets aktuell im Prioritätswert sichtbar zu machen.

Freunde?  ^

Das Verhältnis zwischen Product-Owner und Stakeholdern ist wesentlich intensiver als im klassischen Projektmanagement und sollte — wie bereits vorher gesagt — von gegenseitiger Achtung, tiefem Vertrauen, großem Respekt und einer ausgeprägten Konsensfähigkeit gekennzeichnet sein. Der Product-Owner muss, um seinen Auftrag vollständig erfüllen zu können, gleich nicht unbedingt gleich der Freund aller Stakeholder sein, aber das Verhältnis zu ihnen muss schon eine sehr solide Basis haben, damit sie ihn uneingeschränkt ermächtigen können, alle für den Erfolg des Projektes notwendigen Entscheidungen in ihrem Namen zu treffen.

Intensive Mitarbeit  ^

Dieses intensive Verhältnis ist ohne permanente Kommunikation und sehr enger Zusammenarbeit zwischen den Stakeholdern und dem Product-Owner nicht denkbar und so werden in Scrum die Stakeholder vom Product-Owner wesentlich tiefer in das Projekt eingebunden, als das in klassischen Projekten der Fall ist. Sie erhalten von ihm über die gesamte Projektlaufzeit regelmäßig und verlässlich am Ende jedes einzelnen Sprints, ein neues, einsetzbares, um die für sie wertvollsten Funktionalitäten erweitertes Produktinkrement, das umgehend auf „auf Herz und Nieren“ testen, prüfen und bewerten sollten. Er gibt ihnen damit die Möglichkeit, das Produktinkrement — wie ohnehin jederzeit möglich — mit Erweiterungs- oder Änderungswünschen zu kommentieren, die der Product-Owner dann wie jede andere Anforderung auch, als User-Story formuliert, hinsichtlich der Priorität bewertet und sie für eine Realisation in einem der folgenden Sprints ins Product-Backlog aufnimmt.

Die Notwendigkeit der intensiven und permanenten Mitarbeit im Projekt ist für die Stakeholder im allgemeinen ein überraschendes und neues Konzept, dass ihnen durch den Product-Owner, ggf. unter Zuhilfenahme des Scrum-Masters, nahegebracht und vermittelt werden muss. Es ist von größter Bedeutung, dass die Stakeholder das Konzept, das für sie eben nicht nur Rechte, sondern auch Pflichten mitbringt, verstehen, annehmen und ausfüllen.

Natürlich gibt es auch immer wieder Kunden, die sich mit aller Kraft gegen eine -– aus ihrer Sicht zu intensive — Beteiligung am Projekt sträuben, weil sie der Meinung sind, dass sich ihre Beteiligung auf das rudimentäre Formulieren der Anforderungen, die spätere Abnahme des Produktes nach Fertigstellung und dann noch später das Bezahlen nach der Abnahme beschränken sollte. Schließlich sei es die Aufgabe des Entwicklungsteams (von dem der Product-Owner aus ihrer Sicht ein Teil ist), die Entwicklungsarbeit zu leisten und nicht die ihre.

Leider kommt es in diesem Fall dann im wieder dazu, dass im Zuge der (End-) Abnahme nachverhandelt wird (oder werden soll), um den Preis zu drücken und/oder im Nachhinein kostenlose „Nachbesserungen“ (die oft nichts anderes als Änderungswünsche sind) auszuhandeln, was Scrum, nicht zuletzt auch und erklärtermaßen zum Vorteil des Kunden, gerade vermeiden soll!

Ist der Product-Owner mit solch einem Kunden „geschlagen“, ist seine Aufgabe noch etwas schwieriger als sonst, denn dann muss er ebenfalls taktieren und kann dem Kunden gegenüber eine Reiher der wichtigsten Vorteile von Scrum, Transparenz und frühes Feedback, nicht oder nur in geringem Umfang nutzen, was für ihn und den Kunden das Projektrisiko vergrößert.
Generelle Empfehlungen für eine solche Situation kann es nicht geben, da die Situation stark von Art und der Handlungsweise des Kunden abhängt. Manchmal sind die Mitarbeiter, mit denen der Product-Owner letztlich zu tun hat, weitaus kooperativer als das Unternehmen selbst, aber es bleibt ein Risiko und eine Gratwanderung.

Und wenn sich der Kunde vehement gegen die Einbindung in das Projekt wehrt?  ^

Das kann so weit führen, dass es dann nur noch möglich, dem Kunden gegenüber seine gefühlte, vermeintliche „heile Welt“ einer klassischen Projektdurchführung so gut es geht vorzumachen und projektintern trotzdem agil mit Scrum zu arbeiten. Es sollte dann nichts unversucht gelassen werden, dem Kunden trotzdem immer wieder die Risiken, die sich für ihn aus seinem Handeln ergeben, bzw. den Verlust von Vorteilen, die er ausschlägt und die sich daraus ggf. ergebenden Kosten, vor allem dann, wenn es später aufgrund zu Nachforderungen kommen sollte, ganz klar darzustellen.

Ganz wichtig für den Product-Owner ist es in diesem Zusammenhang daher, ggf. mit Unterstützung des Scrum-Masters, die Akzeptanz des Kunden so früh wie irgend möglich abzuklären, um ggf. absehbare Umwege und Zusatzaufwände direkt in den Kosten berücksichtigen zu können.

Dieses und weitere Themen dieser Art werden im Kapitel „Risiken für/durch Scrum“ behandelt.

Zusammenarbeit mit dem Entwicklungsteam  ^

Die Kommunikation mit den Stakeholdern ist die eine Seite, die andere Seite ist die Zusammenarbeit mit dem Entwicklungsteam, mit dem der Product-Owner ebenfalls sehr intensiv zusammenarbeitet. Das Entwicklungsteam produziert die Software, die die Stakeholder benötigen und der Product-Owner ist die Schnittstelle zwischen beiden Rollen; er regelt, kanalisiert und koordiniert die Kommunikation zwischen den beiden Gruppen.

Er achtet darauf, dass Entwicklungsteam und Stakeholder nicht direkt miteinander kommunizieren, was im Kern bedeutet, dass Stakeholder und Entwickler nicht ohne sein Wissen / Mitwirken kommunizieren oder gar Entscheidungen treffen. Das mag überflüssig, bürokratisch und nur wenig „lean“ erscheinen, ist aber ein wichtiges Prinzip, denn der Product-Owner ist der Projektkoordinator und –planer, hat die gesamte Verantwortung, und wenn es neben den ihm bekannten und in den Projektplan eingearbeiteten Aufgaben auch noch Nebenabsprachen zwischen Entwicklern und Stakeholdern gibt, ist das Projekt für ihn nicht mehr handhabbar.

Das bedeutet nicht, dass Entwickler und Stakeholder nichts voneinander wissen dürfen und die Entwickler glauben sollen, dass der Product-Owner sich das Projekt ausgedacht hat und selbst der Stakeholder sei und die Stakeholder auf der anderen Seite glauben sollten, der Product-Owner würde allein und selbst programmieren. Es bedeutet nur, dass die Entwickler und die Stakeholder keine Absprachen am Product-Owner vorbei treffen dürfen, bzw. dass die Stakeholder insbesondere während des laufenden Sprints keinerlei Zugriff — sei es zur Steuerung, sei es zu Informationsbeschaffung — auf die Entwickler nehmen dürfen. Ungeplante Absprachen, die zu veränderten Aufwänden oder Produktspezifikationen führen, können Sprints, Releases oder vielleicht sogar Projektpläne gefährden und auch falsche Informationen richtig platziert oder richtige Informationen falsch platziert, können ein Projekt nachhaltig ruinieren.

Aber selbst wenn sich Stakeholder doch den „kurzen Weg“ nehmen und sich direkt an die Entwickler wenden, um Fragen zu stellen oder Anregungen loswerden wollen, ist ja noch nichts passiert, außer Zeit vergangen, nur sollten die Entwickler dann trotzdem nicht von den Inhalten des eigentlichen Planes für den Sprint abweichen, sondern sich den Inhalt des Gespräches, etc., merken oder notieren und den Product-Owner darüber in Kenntnis setzen. Für die Entwickler ist der Fall damit abgeschlossen, sie arbeiten unverändert den Sprint ab und der Product-Owner wird sich um alles Weitere kümmern; sollten sich aus den Informationen irgendwelche Änderungen ergeben, werden die Entwickler darüber zur rechten Zeit vom Product-Owner informiert werden.

Auch Freunde  ^

Ein guter Product-Owner wird „seine“ Entwickler immer beschützen, denn er weiß, dass er von ihrer Produktivität, ihrer Kreativität, ihrem Einsatz- und Leistungswillen, bzw. von ihrer Verantwortungs- und Leistungsbereitschaft abhängig ist. Das Entwicklungsteam ist eben nicht „sein Werkzeug“, sondern es ist viel mehr, es ist ein autonomer Körper, der im Rahmen der Vorgaben selbstständig denkt, plant und handelt. Da er das weiß, wird er alles tun, was er kann, um das Entwicklungsteam zu unterstützen; er wird sie zu nichts drängen und ihnen nichts aufzwingen, was für sie nicht akzeptabel wäre, er wird sie immer mit den aktuellen Informationen (aber nicht unbedingt immer mit den letzten Gerüchten) auf dem Laufenden halten.

Konfliktlösungskompetenz  ^

Selbstverständlich bleibt auch der Product-Owner nicht davon verschont, sich allen möglichen projektspezifischen und zwischenmenschlichen Konflikten und Problemen stellen zu müssen. In Scrum befinden sich alle auf gleicher Ebene, denn alle gehören zum gleichen Team, auch wenn sie unterschiedliche Aufgaben haben und jeder im Team weiß, dass sie nur gemeinsam als Team erfolgreich sein können.
Sollte es innerhalb des Teams zu Konflikten kommen, die nicht einfach aus der Welt zu schaffen sind, so ist Aufgabe des Scrum-Master, die Rolle eines Moderators zu übernehmen und alles daran zu setzen, Konflikte und Unstimmigkeiten so schnell und einvernehmlich wie möglich aus der Welt zu schaffen.
Er weiß, dass Konflikte und Probleme, egal ob offen oder unterschwellig, immer zu Lasten der Produktivität gehen.

Kein Chef  ^

Der Product-Owner ist der Partner des Entwicklungsteam, weder ihr Vorgesetzter, noch aus einem anderen Grund ihnen gegenüber weisungsbefugt.

Oft wird der ehemalige Projekt-, Abteilungs- oder Teamleiter als Product-Owner eingesetzt, was nur dann ausreichend gut funktionieren kann, wenn er sich sehr stark zurücknehmen und seine Rolle als Vorgesetzter während des Projektes sowohl äußerlich, als auch innerlich vollständig ruhen lassen kann. Oft ist das seitens der Unternehmen schon allein aus organisatorischen Gründen gar nicht gewünscht. Dann müsste aber auch das Entwicklungsteam in der Lage sein, diesen Product-Owner übergangslos nicht mehr als Vorgesetzten, der er war oder ist, anzunehmen, um mit ihm vorbehaltlos und frei jeglicher Zwänge als Partner auf gleichem Level unabhängig und partnerschaftlich kooperieren zu können.

Da greift der „Product-Owner“-Chef dann doch in die sich gerade etablierende Selbstorganisation des Entwicklungsteam ein oder drückt während der Sprint-Planung die Schätzungen des Entwicklungsteams, um mehr Anforderungen im Sprint realisieren lassen zu können, da beginnt das tägliche Daily-Scrum erst mit dem Eintreffen des „Product-Owner“ und wird nicht als entwicklungsteaminterne Informationsveranstaltung, sondern als Report-Meeting der Entwickler gegenüber dem „Product-Owner“-Chef durchgeführt wird, u.v.a.m.

Die praktische Erfahrung lehrt, dass trotz aller Beteuerungen der beteiligten Personen so eine Konstellation eben doch nicht besonders gut funktioniert, denn kaum jemand kann sich vollständig davon frei machen, mit dem eben-noch-und-nachher-wieder-Chef-„Product-Owner“ selbstbestimmt, partnerschaftlich und ggf. sogar so kontrovers wie nötig umzugehen, ohne daran zu denken, dass man später ja wieder als weisungsgebundener Mitarbeiter mit ihm leben und arbeiten muss.

Ist so eine Weisungshierarchie zumindest eine Zeit lang zwischen den Beteiligten etabliert gewesen und von beiden Seiten produktiv gelebt worden, ist es eben oftmals sehr schwierig, die im jeweiligen Unternehmenskontext erlernten, dem eigenen „Überleben“ im Betrieb geschuldeten Anpassungs- und Verhaltensweisen, zeitlich begrenzt zugunsten eines kompromisslos partnerschaftlichen Verhältnisses mit dem Vorgesetzten abzulegen, denn wann ist der Vorgesetzte Vorgesetzter und wann ist er Partner?
Wie wirkt es sich aus, wenn das Entwicklungsteam oder der einzelner Entwickler — wie von Scrum vorgesehen und gefordert — seine eigene Sicht (Bedürfnisse, Bedenken, etc.) mit Nachdruck gegenüber dem „Product-Owner“-Vorgesetzten vertritt und durchzusetzen versucht, aber eventuell gleichzeitig Konsequenzen und Ressentiments fürchten muss? Das alles hat im Übrigen nichts mit Professionalität, Intelligenz oder Charakter zu tun.

Wenn das Verhältnis zwischen dem Vorgesetzten als Product-Owner und den Mitarbeitern als Entwickler nicht schon zuvor ein besonders kameradschaftliches war und auch nur eine der beide Seiten sich schwer damit tut, für den Zeitraum des Projekts eine zumindest latent immer vorhandene, zuvor und später wieder gültige Hierarchie vollständig auszublenden, dann ist so eine Konstellation eine schwere Bürde für das Projekt und sollten daher auf jeden Fall vermieden werden.

Zusammenarbeit mit dem Scrum-Master  ^

Das Maß der Zusammenarbeit zwischen dem Scrum-Master und dem Product-Owner wird im Wesentlichen durch das Maß der bereits vorhandenen Scrum-Kompetenz des Product-Owners im Hinblick auf seine Aufgaben und Fähigkeiten bestimmt. Handelt es sich um ein Team, in dem Scrum noch erst implementiert werden soll und in dem noch niemand tiefgehende Erfahrungen mit Scrum gemacht hat, wird wahrscheinlich zunächst ein (ggf. externer) Scrum-Coach die Aufgabe des Scrum-Masters übernehmen, Einführungsvorträge halten und den Prozess gemeinsam mit dem Team in einer sauberen, grundlegenden Form implementieren.

Der Product-Owner kann den Scrum-Master, genauso wie jedes andere Teammitglied auch, zu jedem Aspekt von Scrum befragen, oder sich in allen seine Rolle betreffenden Belangen von Scrum-Master beraten und unterstützen lassen. Da der Scrum-Master als Rolle nicht in den Entwicklungsprozess als solchen eingebunden ist, ist er dafür prädestiniert, z.B. Moderationen zu übernehmen. Er kann den Product-Owner z. B. auch darin unterstützen, die Stakeholder ins Projekt einzubinden, gemeinsam mit ihnen die Produktvision und erste Anforderungen zu erarbeiten und zu formulieren und letztere später in Form von User-Stories im Product-Backlog abzulegen und zu verwalten.

Genau wie der Scrum-Master das Entwicklungsteam darin unterstützt, eine möglich hohe Produktivität zu erreichen, indem er Hindernisse beseitigt, die den Arbeitsfluss der Entwickler hemmen, kann er auch den Product-Owner unterstützen und hat der Product-Owner Probleme mit den Entwicklungsteam oder den Stakeholdern, kann er den Scrum-Master, genau, wie es den anderen Rollen gleichermaßen offensteht, bitten, an Gesprächen teilzunehmen und an den Lösungen mitzuarbeiten.

Selbstverständlich kann der Scrum-Master den Product-Owner auch in der Pflege des Product-Backlogs und in der Vorbereitung des Sprint-Planning und des Estimation-Meetings unterstützen, jedoch wird sich der Scrum-Master nicht dauerhaft in die Prozesse des Product-Owners einbinden lassen.

Der Product-Owner und das Sprint-Planning  ^

Das Sprint-Planning-Meeting teilt sich in zwei Phasen (Phase 1, „Sprint-Backlog füllen“, Timebox von max. 4 Stunden und Phase 2, „Anforderungszerlegung“, ebenfalls Timebox von max. 4 Stunden) auf, von denen der Product-Owner die erste Phase organisiert, zu ihr einlädt, durchführt und sie auch moderiert. Diese erste Phase teilt sich wiederum in zwei Phasen (1.0, „Präsentieren“ und 1.1, „Diskussion & Schätzen“, auf.

Phase 1.0 des Sprint-Planning  ^

Er stellt den Anwesenden (Entwicklungsteam und eventuelle Gäste, z. B. Stakeholder) in der Phase 1.0 („Präsentieren“) alle von ihm für diesen Sprint vorgesehenen User-Stories in der Reihenfolge absteigender Priorität vor. In dieser Phase, die von den max. 4 Stunden, die sie dauern darf, nicht mehr als 15 – 60 Minuten dauern sollte, sollte der Product-Owner alle aufkommende Diskussionen über die vorgetragenen User-Stories vermieden, bzw. sie frühzeitig unterbrechen, denn er will in dieser Phase lediglich den Rahmen, über den in der Phase 1.1 („Diskussion & Schätzen“) gesprochen werden soll, abstecken.

Man könnte auch sagen, dass er in der Phase 1.0 die Agenda für die Phase 1.1 bekannt gibt; erreicht werden soll damit, dass die Beteiligten von vornherein einen Überblick über die zu behandelnden User-Stories bekommen. Ideal ist es, wenn er diese Agenda als Ausdruck an die Beteiligten, zumindest aber an das Entwicklungsteam, verteilen kann, damit sie sich eventuelle Fragen zu bestimmten User-Stories, die schon jetzt auftauchen, notieren können. Kurze Verständnisfragen sollte er jedoch in jedem Fall akzeptieren und beantworten.

Wenn es ihm möglich war, den Sprint unter ein bestimmtes Thema zu stellen, sollte auch dieses Thema in der Agenda als Vision des Sprints auftauchen und kurz erläutert sein.

Phase 1.1 des Sprint-Planning  ^

Hat der Product-Owner alle von ihm für den Sprint vorgesehenen User-Stories vorgestellt, folgt nun die Phase 1.1, („Diskussion & Schätzen“), die den Rest dieser Timebox einnehmen wird. Er wird nun die User-Stories erneut in der gleichen Reihenfolge wie zuvor vorstellen. Anders als in der vorherigen Phase sind nun jedoch Diskussionen nicht nur erlaubt, sondern sogar erwünscht, denn sie sollen bei jedem Entwickler zu einem tiefen Verständnis der jeweiligen User-Story führen. Sollten die Entwickler passiv bleiben, keine Fragen stellen, usw., müssen Product-Owner und Scrum-Master die Entwickler auffordern, die Hintergründe der User-Story, etc., zu durchleuchten und zu hinterfragen.

Ist eine User-Story in ausreichender Tiefe diskutiert und von jedem Entwickler so weit verstanden, dass sie sich in der Lage sehen, jeweils eine individuelle Schätzung zum Realisationsaufwand dieser User-Story abzugeben, wird die User-Stories z.B. mit Hilfe des Planning-Poker ausschließlich von den Mitgliedern des Entwicklungsteams geschätzt. Sind sich alle bezüglich des Realisationsaufwands einig, trägt der Product-Owner (oder jemand aus dem Team, der das für ihn übernimmt) den Aufwandswert in die User-Story ein und überträgt sie in das Sprint-Backlog.

Der Product-Owner kann anhand der Velocity des Entwicklungsteams (Anzahl der Storypoints, die das Entwicklungsteam im Durchschnitt pro Sprint voraussichtlich zu verarbeiten in der Lage sein wird) feststellen, wann die Summe der Storypoints aller User-Stories im Sprint-Backlog für den Sprint ausreicht.

Ist eine Menge an User-Stories erreicht, die den Sprint ausfüllt, gibt die Entwickler ihr Commitment ab und verpflichtet sich damit, die im Sprint-Backlog enthaltenen User-Stories im Sprint vollständig zu realisieren.

Phase 2 des Sprint-Planning  ^

Die Phase 2 des Sprint-Planning, die Zerlegung der User-Story in einzelne Arbeitspakete, die Tasks, ist ein nicht-öffentliches Meeting und wird vom Entwicklungsteam allein geplant, organisiert und durchgeführt. Gäste und Product-Owner nehmen daran nicht teil, es sei denn, der Product-Owner hat sein Beisein zuvor mit dem Entwicklungsteam abgesprochen oder wurde vom Entwicklungsteam extra dazu eingeladen.

Ist der Product-Owner also in dem Meeting persönlich nicht anwesend, was in der Regel der Fall ist, sollte er jedoch zumindest für eine mit dem Entwicklungsteam zuvor abgesprochene Zeitdauer für die Beantwortung von Fragen des Entwicklungsteams zur direkten Verfügung stehen und nach Ablauf dieser Zeit zumindest kurzfristig.

Der Product-Owner und das Estimation-Meeting  ^

Ungefähr zur Mitte der zweiten Hälfte jedes Sprints sollte der Product-Owner das Entwicklungsteam und evtl. Gäste zum Estimation-Meeting einladen. Das Estimation-Meeting ist ein für den Product-Owner sehr wichtiges und wertvolles Vorplanungsmeeting.

Es ist der ersten Phase des Sprint-Planning („Sprint-Backlog füllen“) sehr ähnlich. Der Product-Owner stellt einige eine Anzahl der aktuell höchstpriorisierten User-Stories aus dem Product-Backlog vor, die er für die Realisation im als nächstes folgenden Sprint vorgesehen hat. Danach werden die vorgestellten User-Stories nacheinander in gleicher Reihenfolge gemeinsam diskutiert und vom Entwicklungsteam grob geschätzt. Da es sich lediglich um eine Vorplanung handelt, gibt das Entwicklungsteam am Ende dieses Meetings kein Commitment ab. Auswirkung auf das Sprint-Backlog des aktuell laufenden Sprints hat das Meeting ebenfalls nicht.

Das Estimation-Meeting ist das meist unterschätzte Meeting, das schnell Gefahr läuft, einem falsch verstandenen Optimierungsreflex geopfert zu werden. Dabei hat das Meeting sowohl für den Product-Owner, als auch für das Entwicklungsteam einen großen Wert: dem Product-Owner gibt es frühes Feedback bzgl. Relevanz und Verständlichkeit der ausgesuchten User-Stories und den für die Realisierung zu erwartenden Aufwand, dem Entwicklungsteam gibt es einen Ausblick auf die als nächstes zu erwartenden Aufgaben.

Der Zeitaufwand von max. 4 Stunden ist zudem nicht verloren, sondern gut investiert, da der Product-Owner nun besser für den nächsten Sprint besser vorplanen kann, die Entwickler Wissen über die als nächstes zu erwartenden Aufgaben erhalten haben und sich bereits Gedanken machen können und das Sprint-Planning des nächsten Sprints aufgrund der bereits vorhandenen Informationen schneller (weniger Diskussionsbedarf, schnelleres und präziseres Schätzen) ablaufen wird.

der Product-Owner und das Daily-Scrum  ^

Das Entwicklungsteam führt verlässlich an jedem Arbeitstag zur gleichen Zeit am gleichen Ort das max. 15 minütige Daily-Scrum durch, an dem — ebenso verlässlich — zumindest alle anwesenden Entwickler und der Scrum-Master teilnehmen. Sie berichten nacheinander reihum einander über ihre Arbeit und über evtl. aufgetretene Probleme.

Das Daily-Scrum ist auf der einen Seite ein rein Entwicklungsteam-internes, aber gleichzeitig ein öffentliches Meeting. Nur die Mitglieder des Entwicklungsteams oder der Scrum-Master reden, Gäste – zu denen in diesem Fall auch der Product-Owner zählt — dürfen an diesem Termin lediglich als stille Zuschauer teilnehmen.

Da das Daily-Scrum manchmal falsch verstanden / falsch gehandhabt wird, sei an dieser Stelle noch einmal ganz klar gesagt: das Daily-Scrum ist ein teaminternes Meeting des Entwicklungsteams und dient ausschließlich zum Informationsaustausch zwischen den Entwicklern und kein Reporting-Meeting des Entwicklungsteams gegenüber dem Product-Owner!

Ein Phänomen, dass immer wieder dann zu beobachten ist, wenn der Product-Owner den Entwicklern in irgendeiner Form, z.B. aufgrund der Unternehmenshierarchie übergeordnet ist, ist, dass das Entwicklungsteam den Product-Owner regelmäßig als Teilnehmer des Daily-Scrum akzeptiert oder ihn sogar permanent dazu einlädt, bzw. das Daily-Scrum erst dann beginnt oder stattfindet, wenn der Product-Owner die Zeit dafür findet. Die Erfahrung zeigt, dass in diesem Fall das Daily-Scrum dann oft zur Reporting-, bzw. zur täglichen Rechtfertigungsveranstaltung wird, indem die Entwickler nicht mehr sich gegenseitig informieren, sondern ausschließlich dem Product-Owner reporten.

Die Aufgabe des Scrum-Masters ist es in einem solchen Fall, die Integrität des Daily-Scrum wieder herzustellen, indem er sowohl den Entwicklern, als auch dem Product-Owner die Konsequenzen dieser Vorgehensweise vor Augen führt. Ist er allerdings analog zu den Entwicklern selbst in die Hierarchie eingebunden, ist zu befürchten, dass ihm seine Aufgabe nicht oder nur sehr schwer gelingen wird. In diesem Fall ist jedoch davon auszugehen, dass der implementierte Prozess ohnehin noch an weiteren Stellen gebeugt wurde, dass das Daily-Scrum eher zu den kleinen Problemen gehört.

Product-Owner und Sprint-Review  ^

Ist der Sprint am Ende angekommen, bereitet das Entwicklungsteam das Sprint-Review vor (Raum buchen, Stühle, Getränke, etc. bereitstellen, notwendige Hardware bereit- und aufstellen, Software bereitstellen, sicherstellen, dass das Produktinkrement lauffähig ist, etc.) und lädt den Product-Owner, sowie eventuelle Gäste ein. In diesem Meeting präsentiert das Entwicklungsteam die fertiggestellten Anforderungen anhand des neuen Produktinkrements. Die Aufgabe des Product-Owner besteht darin, die präsentierten Realisationen zu begutachten, zu bewerten und abzunehmen, wenn alles in seinem Sinne realisiert wurde, oder abzulehnen, wenn nicht wie vorgegeben funktioniert.

Im Anschluss an das Meeting übergibt der Product-Owner den Stakeholdern das neue Produktinkrement.

Der Product-Owner und die Sprint-Retrospektive  ^

Die Sprint-Retrospektive ist ein nicht-öffentliches, internes Meeting des Entwicklungsteam unter der Moderation des Scrum-Masters, das dazu dient, gemeinsam über den vergangenen Sprint zu reflektieren. Werden Insuffizienzen identifiziert, werden von den Beteiligten Maßnahmen beschlossen, um die identifizierten Probleme zeitnah zu beheben. Der Product-Owner ist an diesem Meeting nicht beteiligt.

Sollten die Entwickler Probleme identifizieren, die im Zusammenhang mit dem Product-Owner stehen — ganz unabhängig davon, ob es in der Sprint-Retrospektive oder zu einem anderen Zeitpunkt hochkommt — sollten sie den Product-Owner zeitnah selbst ansprechen oder den Scrum-Master beauftragen, zeitnah einen Termin mit dem Product-Owner zu vereinbaren, in dem diese Probleme in entsprechender Runde (Product-Owner, Entwickler, Scrum-Master) zu besprechen und zu lösen sind.

Ist dem Product-Owner seinerseits ein Problem mit dem Entwicklungsteam oder einem Entwickler aufgefallen, sollte er ebenfalls zeitnah und unabhängig von der Sprint-Retrospektive das Gespräch mit dem Entwicklungsteam oder dem einen Entwickler suchen, oder seinerseits den Scrum-Master bitten, zeitnah ein Termin zur Klärung dieses Problems mit dem Entwicklungsteam zu finden.

Risiken für den Product-Owner  ^

Man sagt, der Product-Owner sei der „single chockable neck“, also der, dessen Hals in der Schlinge steckt und gewürgt wird, wenn das Projekt schief geht.

Mehrere Product-Owner im Projekt  ^

„Es kann nur einen geben“ oder „viele Köche verderben den Brei“ ist hier durchaus angebracht. Gibt es mehrere Product-Owner im gleichen Projekt und verfolgen diese nicht die gleiche Linie, resultieren daraus vielleicht mehrere Strategien oder sich wiedersprechende Konzepte. Sind sie sich z.B. uneinig über das richtige Design oder die richtige Beschreibung einer Anforderung, etc., kann das zu Konflikten und Zeitverlusten führen. Mehr als ein alleiniger Product-Owner pro Projekt ist zu viel, denn zwei konkurrierende Product-Owner bringen ein Projekt schnell in Unruhe und zum Stillstand.

Etwas anderes ist es, wenn es im Projekt nur einen einzigen federführenden, im Projekt operierenden Product-Owner gibt und eine weiteren Product-Owner als Backup, der nur dann die Rolle des Produkt-Owners im Projekt einnimmt, wenn der eigentlich für das Projekt zuständige Product-Owner über mehr als einen Sprint ausfällt. In diesem Fall sollte der Interims-Product-Owner allerdings die vom eigentlich für das Projekt zuständige Product-Owner angewandten Strategien und vollständig weiterführen.

Geringer Erfahrungsschatz bzgl. Scrum im Projekt  ^

Haben die Teammitglieder noch keine praktischen Erfahrungen mit Scrum im Projekt, stellt das an sich noch kein Problem dar, sofern das Projekt entweder durch einen erfahrenen Scrum-Master, oder, wenn der Scrum-Master ebenfalls noch keine praktischen Erfahrungen mit Scrum hat, durch einen erfahrenen Scrum-Coach begleitet wird. Voraussetzung dafür ist, dass die Teammitglieder gegenüber der agilen Idee aufgeschlossen sind. Der Scrum-Coach wird die Beteiligten in alle Aspekte von Scrum einführen, sie begleiten, ihnen die jeweils in ihrem Bereich wichtigen Prozessanteile nahebringen und sie in der Ausübung unterstützen.

Problematisch kann es werden, wenn die Teammitglieder — oder vielleicht auch nur einzelne davon — Scrum gegenüber nicht aufgeschlossen sind, Regeln nicht einhalten, etc., denn der Erfolg des Projektes ist — nicht nur in Scrum, aber hier in besonderer Weise — immer eine Teamleistung und so besser das Team performt, desto besser und reibungsloser läuft das Projekt. Treten solche Schwierigkeiten im Projekt auf, ist es die Aufgabe des Scrum-Master, oder eben des Scrum-Coaches zusammen mit dem Scrum-Master, an dieser Stelle gegenzusteuern.

Der Scrum-Coach wird individuell auf jede Rolle eingehen und dabei immer insbesondere den Scrum-Master mitnehmen, da der Scrum-Master später derjenige sein wird, der seine Rolle übernehmen wird.

Mangelnde Mitarbeit der Stakeholder  ^

Für die Stakeholder ist die in Scrum fest verankerte und intensive Einbindung oftmals ein überraschendes Konzept, dass ihnen viele Vorteile, aber auch Verantwortung und Aufwand zumutet. Scrum-Coach / Scrum-Master und Product-Owner sollten sich intensiv darum bemühen, dass sie ihre Rolle auch ausfüllen. Ist dies nicht oder nur in geringem Maß erfolgreich, betrifft das zwar insbesondere den Product-Owner, aber man sollte dies trotzdem innerhalb des Scrum-Teams darüber diskutieren, wie damit umzugehen ist.

Stakeholder im Feature-Rausch  ^

Ein guter Product-Owner kennt sein Team, weiß es einzuschätzen und, was er ihm zumuten kann. Beginnen die Stakeholder, Druck auf den Product-Owner auszuüben, weil ihnen das Projekt nicht schnell genug läuft oder weil sie in kürzerer Zeit mehr implementiert haben wollen, muss ein guter Product-Owner NEIN sagen und ihnen dies auch plausibel machen können, statt den Druck einfach an das Entwicklungsteam und den Scrum-Master weiterzugeben.

Risiken durch den Product-Owner  ^

Product-Owner war/ist Projektleiter/Vorgesetzter/Leiter des Teams  ^

Scrum gibt den Projekten verschiedene Rollen vor, die jeweils ihre spezifischen Aufgaben haben. Darüber hinaus schließt Scrum disziplinäre Hierarchien, Weisungsbefugnisse, etc. zwischen den Rollen explizit aus, um allen Beteiligten die uneingeschränkte Möglichkeit zu geben, die eigenen Potentiale in ihrem jeweiligen Verantwortungsbereich voll und zum Vorteil des Projektes ausschöpfen zu können. Dafür handeln und agieren alle Beteiligten auf gleicher Augenhöhe. Um das zu erreichen, ist das Entwicklungsteam im Sprint ein autonomer Körper und organisiert sich ausschließlich selbst.

Aktive oder auch passive Einflussnahme durch einen vorgesetzten Product-Owner behindert die entstehenden und erwünschten Prozesse in ihrer Entfaltung. Diese Konstellation verzerrt das System Scrum in ihren Grundstrukturen und ist daher zu vermeiden.

Der Product-Owner beaufsichtigt / moderiert das Daily-Scrum direkt oder indirekt  ^

Das Daily-Scrum ist zwar ein öffentliches, aber dennoch rein Entwicklungsteams-internes Meeting. Der Product-Owner darf, wie auch die anderen eventuellen Gäste, das Meeting nur als stiller Gast verfolgen und nur dann sprechen, wenn er vom Scrum-Master oder vom Entwicklungsteam dazu aufgefordert wurde.

Mischt er sich ein, stört er die Aufmerksamkeit der aktiven Personen und zieht sie stattdessen auf sich.
Daraus ergibt sich die Gefahr, dass der Prozess des permanenten Informationsflusses zwischen den Entwicklern zumindest gestört wird oder sogar zum Erliegen kommt, oder sich zusätzlich auf einen anderen, ungestörten Zeitpunkt verlagert, was der Produktivität abträglich ist. Darüber hinaus kommt es vor, dass das eigentliche Daily-Scrum dann nur noch im Beisein des Product-Owner abgehalten wird, d.h., dass die Entwickler mit dem Beginn des Daily-Scrum warten, bis der Product-Owner anwesend ist.

Die Person des Product-Owner hat mehr als nur die eine Rolle / Aufgabe  ^

Die Rollen in ihren Abgrenzungen zueinander und Abhängigkeiten voneinander, arbeiten parallel einander zu, sodass die eine Rolle auf den Ergebnissen einer anderen Rolle aufbauen kann. Zudem sind die Rollen i.A. Vollzeitaufgaben.

Nimmt eine Person dauerhaft mehr als nur eine Rolle ein, wachsen gleichzeitig damit die Aufgabengebiete und der Zeitbedarf, was im engen Zeitrahmen eines Sprints, hoher Produktivität und Auslastung oftmals nur schwer zu kompensieren ist und die wieder Produktivität sinken lässt. Insbesondere bei der ohnehin mit hohen Ansprüchen versehenen Rolle des Product-Owner kann das schnell dazu führen, dass sie nicht mehr vollständig ausgefüllt wird, vielleicht Aufgaben in hohem Maß delegiert werden und sich entsprechende Konsequenzen für Team, Sprint und Projekt ergeben.

Bei der Rolle des Product-Owner ergibt sich zudem auch noch die Gefahr von Interessenskonflikten, die das Projekt in allen Belangen erheblich stören können.

Es gibt mehrere Product-Owner im Projekt  ^

„Es kann nur einen geben“ oder „viele Köche verderben den Brei“ ist hier durchaus angebracht. Gibt es mehrere Product-Owner im gleichen Projekt und verfolgen diese nicht die gleiche Linie, resultieren daraus vielleicht mehrere Strategien oder sich wiedersprechende Konzepte. Sind sie sich z.B. uneinig über das richtige Design oder die richtige Beschreibung einer Anforderung, etc., kann das zu Konflikten und Zeitverlusten führen. Mehr als ein alleiniger Product-Owner pro Projekt ist zu viel, denn zwei konkurrierende Product-Owner bringen ein Projekt schnell in Unruhe und zum Stillstand.

Etwas anderes ist es, wenn es im Projekt nur einen einzigen federführenden, im Projekt operierenden Product-Owner gibt und eine weiteren Product-Owner als Backup, der nur dann die Rolle des Produkt-Owners im Projekt einnimmt, wenn der eigentlich für das Projekt zuständige Product-Owner über mehr als einen Sprint ausfällt. In diesem Fall sollte der Interims-Product-Owner allerdings die vom eigentlich für das Projekt zuständige Product-Owner angewandten Strategien und vollständig weiterführen.

Die Besetzung des Product-Owner wird immer wieder ausgewechselt  ^

Wird der Product-Owner ausgewechselt, geht damit nicht nur ein Personalwechsel, sondern für das Projekt oft auch ein Strategiewechsel einher; andere Köpfe, andere Ideen. Der neue Product-Owner muss sich ins Thema, ins Projekt und in das Product-Backlog einarbeiten, zu allen Beteiligten Kontakt aufnehmen und ihr Vertrauen gewinnen, Stakeholder und Entwickler an das „neue Gesicht“ gewöhnen, etc.
Das kostet Zeit, die im Projekt berücksichtigt werden muss.

Hinterlässt der vorherige Product-Owner ein hervorragend gepflegtes und gut verständliches Product-Backlog, kann der Wechsel schnell und mit möglichst geringen Verlusten vor sich gehen, ist das aber nicht der Fall, kann es zu unangenehmen Unterbrechungen und Stillständen im Projektablauf kommen.

Der Product-Owner ist nicht erreichbar, abwesend, überlastet  ^

Fällt der Product-Owner aus oder er ist einfach (länger) nicht da und niemand kann seine Aufgaben übernehmen oder ausfüllen und gibt es niemanden, der in seine Pläne, Gedanken und Ideen eingeweiht war, stockt das Projekt und kann eventuell zumindest zeitweise nicht weiter durchgeführt werden.

Auch hier gilt: hinterlässt der Product-Owner ein sehr gut gepflegtes und verständliches Product-Backlog, kann sich jemand Neues schnell einarbeiten, ist das aber nicht der Fall, wird es zu Zeitverlusten und höheren Aufwänden als geplant kommen.

Der Product-Owner tut sich schwer mit Entscheidungen, ist wankelmütig  ^

Ein Product-Owner, der Probleme damit hat, Entscheidungen zu fällen, ist ein echtes Problem und Risiko für das Projekt, weil es nun einmal die Aufgabe des Product-Owner ist, alle relevanten Entscheidungen im Namen und zum nachhaltigen Vorteil der Stakeholder zu treffen.

Geht aufgrund seiner Zögerlichkeit vielleicht zunächst „nur“ Zeit verloren, werden bei Wankelmütigkeit darüber hinaus echte Werte vernichtet, da das Team in eine bestimmte Richtung entwickelt und diesen geleisteten Aufwand nun mit hoher Wahrscheinlichkeit verwerfen und in eine neue Richtung erneut Entwicklungsaufwand leisten muss.

Der Product-Owner kann nicht NEIN sagen  ^

Ein guter Product-Owner kennt sein Team, weiß es einzuschätzen und, was er ihm zumuten kann.
Beginnen die Stakeholder, Druck auf den Product-Owner auszuüben, weil ihnen das Projekt nicht schnell genug läuft oder weil sie in kürzerer Zeit mehr implementiert haben wollen, muss ein guter Product-Owner NEIN sagen und ihnen dies auch plausibel machen können, statt den Druck einfach an das Entwicklungsteam und den Scrum-Master weiterzugeben.

Product-Owner gibt den Druck an das Entwicklungsteam weiter
Ein Product-Owner, der den auf ihn aufgebauten Druck einfach weitergibt, beschützt sein Team nicht, sondern er gibt es preis. Die mit Scrum eigeführten Maßnahmen und Prozesse, die für eine hohe Verlässlichkeit und Kontinuität sorgen sollen, brechen gemeinsam mit der Produktivität ein, was sowohl Sprint-, als auch das Projektergebnis gefährden kann. Es ist die Aufgabe des Scrum-Masters, einzugreifen und

Product-Owner steht für Fragen nicht zur Verfügung  ^

Treten beim Entwicklungsteam oder bei den Stakeholdern Fragen oder die Notwendigkeit einer Entscheidung auf, ist es die Aufgabe des Product-Owners, die Fragen entweder zeitnah zu beantworten oder die Beantwortung der Frage zeitnah zu organisieren, bzw., die angeforderte Entscheidung zu leisten.

Ist seine permanente, zumindest jedoch kurzfristige Erreichbarkeit für Fragen des Entwicklungsteam / der Stakeholder, oder die Möglichkeit, Entscheidungen kurzfristig zu treffen, nicht gegeben, bleiben die zu klärenden Sachverhalte entweder offen oder werden aus der Not heraus „irgendwie“ entschieden. Dadurch entstehen vermeidbare Risiken für das erfolgreiche Abschließen des Sprints.

In diesem Fall muss der Scrum-Master eine Art Sprechstunde einführen, zu der der Product-Owner dem Entwicklungsteam Rede und Antwort steht.

Der Product-Owner ist unkommunikativ, kann sich nicht ausdrücken  ^

Scrum fordert und fördert effiziente und kontinuierliche Kommunikation im Projekt.

Ist der Product-Owner unkommunikativ oder drückt er sich regelmäßig unpräzise oder schwer verständlich aus, besteht die Gefahr, dass das, was er kommuniziert hat, entweder erst einmal in kompetenter Runde einer Analyse und Interpretation unterzogen werden muss, oder, dass seine Aussagen zumindest potentiell falsch verstanden werden. Beide Wege tragen mit hoher Wahrscheinlichkeit die Gefahr in sich, etwas Falsches zu produzieren.

Hier ist der Scrum-Master gefordert, den Product-Owner darin zu unterstützen, präzise und klare Aussagen zu treffen.

Der Product-Owner ändert Termine oder Aufgaben ohne Absprache
oder lässt Meetings ausfallen  ^

Verlässlichkeit, Vorhersehbarkeit und Transparenz gehören zu den höchsten Gütern in Scrum. Wäre dem nicht so, wäre es dem Entwicklungsteam unmöglich, sich mit dem Commitment darauf zu verpflichten, die von ihnen akzeptierten Anforderungen im Sprint vollständig zu realisieren. Es würde genau der (schädliche) Druck entstehen, den Scrum zu vermeiden versucht, um den Beteiligten die Möglichkeit zu eröffnen, ihre Potentiale vollständig zu entfalten und darüber Synergien zu erzeugen. Darum dürfen Termine, Aufgaben und Anforderungen im Sprint-Backlog nicht ohne Absprache geändert werden. Sollten die Änderungen jedoch unausweichlich sein, müssen sie mit allen Beteiligten besprochen und die ergebenden Risiken und Konsequenzen umgehend berücksichtigt werden, da sie das Erreichen des Sprintziels be- oder gar verhindern können und um unter diesen Umständen das Entwicklungsteam vom Einhalten des Commitment zu entlasten.

Der Product-Owner delegiert seine Aufgaben an das Team  ^

Jede Rolle hat ihre spezifischen Aufgaben, die sie auszuführen hat und mit deren Ergebnissen sie den anderen Rollen zuarbeitet. Beginnt der Product-Owner damit, seine Aufgaben oder einen Teil von ihnen an das Entwicklungsteam und/oder den Scrum-Master zu delegieren, sodass diese in dieser Zeit ihren eigenen Aufgaben nicht mehr angemessen nachgehen können, ist damit zu rechnen, dass sich daraus schnell erhebliche Konsequenzen für das Erreichen des Sprintzieles ergeben können.

Delegiert er aufwändige oder viele Aufgaben, vielleicht sogar permanent an die Entwickler und/oder den Scrum-Master und beschränkt er sich nur noch darauf, die zugearbeiteten Ergebnisse zu kontrollieren und zu übernehmen, besteht die Gefahr, dass der Projektfortschritt zum Erliegen kommt, bzw. nicht mehr vorhersehbar wird.

Der Product-Owner pflegt das Product-Backlog nicht / nur ungenügend  ^

Ein gut gepflegtes, aktualisiertes und nach Priorität absteigend sortiertes Product-Backlog ist nicht nur der Ausgangspunkt für ein erfolgreiches Projekt, sondern die Voraussetzung. Ist das Product-Backlog nicht auf dem letzten Erkenntnisstand, nicht sortiert oder einfach in schlechtem Zustand, weil die User-Stories unverständlich formuliert sind und/oder keine Akzeptanzkriterien eingetragen wurden, droht das Projekt daran zu scheitern.

Der Product-Owner ist in Meetings häufig schlecht vorbereitet  ^

Zeigt es sich, dass der Product-Owner regelmäßig oder gar häufig in Meetings schlecht vorbereitet ist, kann das ein Zeichen dafür sein, dass der Product-Owner keinen guten Arbeitsstil pflegt, dem Thema und der Aufgabe nicht gewachsen ist oder sie ihn schlicht überfordert.

Ein dauerhaft schlecht vorbereiteter Product-Owner ist nur schwer in der Lage, das Projekt schnell und sicher in „Time & Budget“ zu einem erfolgreichen Ende zu bringen. Je nachdem, worin das Team den Grund für die schlechte Vorbereitung vermutet und wie ihnen sich das Verhältnis zum Product-Owner darstellt, kann es versuchen, ihn in seinen Aufgaben proaktiv selbst oder durch den Scrum-Master zu unterstützen.

Der Product-Owner interessiert sich nicht für das Projekt  ^

Scheint der Product-Owner nur sehr mäßig oder eigentlich gar nicht am Projekt interessiert zu sein, kann das fatale Folgen für das Projekt haben, da ihm eine der Aufgaben seiner Rolle, alle Beteiligten für das Projekt zu begeistern und zu motivieren, mit solch einem eher lustlosen Verhältnis zum Projekt nicht gelingen wird.

Sollte der Product-Owner seine Einstellung auch nach Gesprächen mit dem Scrum-Master nicht ändern, und sollten auch andere Versuche des Scrum-Masters, seine Begeisterung, z.B. auf Anweisung Dritter zu erhöhen, kann der Scrum-Master selbst versuchen, die Aufgabe des Motivators zu übernehmen, was allerdings seinen Aufwand deutlich erhöhen wird.

Der Product-Owner nimmt seine Aufgaben nur am Anfang und am Ende eines Sprints wahr  ^

Der Product-Owner ist mit Sicht auf das Projekt die wichtigste Einzelperson im Projekt. Er hat alle Fäden in der Hand, er hat stets das letzte Wort und die letzte Entscheidung. Zudem ist es seine Aufgabe, gemeinsam mit den Stakeholdern das permanente Anforderungsmanagement durchzuführen und das Product-Backlog zu erweitern, zu ergänzen und zu pflegen. Darüber hinaus muss er das Sprint-Planning und das Estimation-Meeting und sich selbst auf das Sprint-Review vorbereiten.

Die Wahrnehmung seiner Aufgaben, ohne deren Erfüllung das Projekt zum Scheitern verurteilt ist, ist in der notwendig hohen Qualität nur durch eine kompetente, engagierte und kontinuierliche Mitarbeit im Projekt möglich. Kann er das nicht, ist er für seine Aufgabe nicht geeignet.

Der Product-Owner ist fachlich inkompetent  ^

Um seine Aufgabe zu erfüllen, muss der Product-Owner sich in die Fachdomäne der Stakeholder einarbeiten. Tut er das nicht, oder ist er dazu nicht in der Lage, besteht die Gefahr, dass er die Stakeholder in der permanenten Anforderungsaufnahme falsch berät. Verweigert er, sich angemessen tief in die Fachdomäne der Stakeholder einzuarbeiten, sollte der Scrum-Master versuchen, ihn dazu zu bewegen.
Ist auch das ohne Erfolg, muss der Scrum-Master das Problem eskalieren.

Fazit  ^

Der Product-Owner ist das Herz des Projektes, der Dreh- und Angelpunkt. Er ist der Hauptverantwortliche für den Projekterfolg, die Einhaltung des Budgets und die Zufriedenheit des Auftraggebers. Für ihn gilt „Einer für Alle und Alle für einen“ nur intern, nach außen ist er das Gesicht des Projektes und trägt die volle Last der Verantwortung.

der Product-Owner muss seine Aufgaben 100% erfüllen. Ist er dazu nicht in der Lage, kann das Team versuchen, seine Defizite als Teamleistung auszugleichen, was für das Team ein außerordentlich motivieren der Prozess sein kann, sofern es gelingt. Wird der Aufwand jedoch zu groß und beeinflusst das die Leistungsfähigkeit des Teams in den eigenen Belangen, muss sich der Scrum-Master Gedanken machen, wie das Problem zu lösen ist. Überhaupt ist der Scrum-Master derjenige, der als erster aktiv werden muss, wenn der Product-Owner und seine Aufgaben nicht angemessen ausgefüllt werden.

Fällt der Product-Owner aus oder wird seiner Rolle nicht gerecht, hängt alles von den anderen Mitgliedern des Scrum-Teams ab. Hat der Scrum-Master es geschafft, aus den einzelnen Mitgliedern eines Softwareentwicklungsprojektes ein Team zu formen, dass die Ideen und Werte, die Scrum mitbringt, verstanden und verinnerlicht hat und diese auch lebt, dann kann auch der Ausfall einer so wichtigen Person, wie es der Product-Owner ist, den Erfolg des Projektes nicht verhindern, denn das Team wird sich schnell auf die Probleme einstellen und sie eine Weile kompensieren können, bis wieder ein Product-Owner im Projekt ist. Handelt es sich dann tatsächlich um jemanden Neues und ist er dazu bereit, sich auf das Team und das Projekt einzustellen, statt das Team und das Projekt auf sich einzustellen, ist es durchaus möglich und in vielen Fällen machbar, dass das Projekt auch durch eine solche Krise nahezu ohne zeitliche Verluste kommt.

[zurück zum Seitenanfang]


No comments yet.

Schreibe einen Kommentar

V1710260636DE