Agile Vorgehensweisen sind gut, wenn man sie richtig lebt. Auch die vordefinierten Rollen sind wichtig. Bevor ein Projekt gestartet wird ist es notwendig die Anforderungen zu kennen. Hier kommt in einem SCRUM Team der Product Owner ins Spiel. Der Product Owner hat eine extrem hohe Verantwortung, wenn nicht sogar die wichtigste. Der Product Owner ist der Keyplayer in einem Scrum Projekt, denn ohne diese Rolle kommt es zum Stillstand. In diesem Blogartikel möchte ich diese Rolle detailliert analysieren und beschreiben, um ein besseres Verständnis für diese Rolle zu schaffen. Dieser Artikel basiert auf der Standard-Scrum Vorgehensweise und setzt zum Verständnis verwendete Begrifflichkeiten aus diesem Framework voraus.
![Abb 1_Product Owner]()
Rolle des Product Owners
Der Product Owner ist eine spezielle Rolle in einem Scrum Projekt. Er ist dafür verantwortlich, dass das entstehende Produkt auch den gewünschten Output liefert, der seitens des Kunden gewünscht ist. Ob es sich um einen internen oder externen Kunden handelt ist in diesem Fall irrelevant. Fakt ist, dass diese Rolle im klassischen Projektmanagement so nicht vorkommt. „Wieso? Anforderungen müssen beim klassischen Projekt auf jeden Fall erhoben werden. Das ist doch sicherlich Aufgabe eines Business Analysten, des Anforderungsmanagements bzw. des Produktmanagers?“. Diese Fragen höre ich immer wieder in etlichen Projekten, unabhängig von deren Größe. Das stimmt natürlich, aber nur zum Teil. Die Anforderungen werden erhoben, hier wie dort. Wobei hier oft das „Was“ und das „Wie“ verwechselt wird. Das „Was“ ist in den meisten Fällen oft schon schwierig zu erheben. Entweder sind die Anforderungen nicht klar, wenig bis überhaupt nicht ausdefiniert, oder man kommt in der Analysephase an einem Punkt an, wo fünf Beteiligte sechs verschiedene Meinungen haben. Daher ist das sogenannte Stakeholder-Management eine der komplexesten und schwierigsten Aufgaben in der Analysephase.
Unterm Strich sieht man, dass es notwendig ist Anforderungen zu erheben. Die Frage die sich hierbei aber stellt ist, ob es notwendig ist alle Anforderungen vorweg zu kennen. Deshalb verlagern wir einmal das „Was“ ins „Wie“. Gibt es eine Möglichkeit diese Anforderungen anders zu erheben oder so zu definieren, damit das Projekt letztendlich auch den gewünschten Output liefert? Die Antwort lautet: „Ja“. Hier kommt der Product Owner ins Spiel. Seine Aufgabe ist es einen Überblick über die gewünschten Anforderungen zu bekommen, erst grob, in Schlagworten, im agilen Vokabular in Form von sogenannten Epics. Diese werden dann in User Stories heruntergebrochen, aus denen danach Tasks für die Umsetzung entstehen. Klingt eigentlich simpel. Ist es leider nicht. Diese Tätigkeit erfordert Geschick und wünschenswerterweise Fach- sowie Technik Know-how (wobei man über das Letztere diskutieren kann). Darüber hinaus muss der Product Owner den Scope, also den inhaltlichen Umfang des Projekts, priorisieren.
Klar ist, dass bei jedem Projekt ein gewisses Budget zur Verfügung steht, auch der Zeitrahmen ist meist abgesteckt, also muss man in der Umsetzung der Inhalte unter Umständen einsparen oder etwas hinzufügen. Des Weiteren muss der Product Owner User Stories so spezifizieren, dass dem gesamten Team klar ist was zu tun ist, vom Entwickler bis zum Tester. Diese Aufgaben sind also essentiell für den Erfolg eines Projekts.
Qualität: Das magische Dreieck wird zum elastischen Dreieck mit Fokus auf Qualität
Die Menschen sind seit langer Zeit gewohnt einen Plan zu erstellen. Ein Plan, der eingehalten werden muss. Es gibt für den Plan Geld, es gibt für den Plan Zeit und es gibt für den Plan natürlich einen vordefinierten Inhalt. Zusammengefasst: klassisches Projektmanagement. Das magische Dreieck mit Budget, Scope und Time.
Im Laufe der Zeit hat sich aber einiges verändert. Die Technologien, die Märkte, die Kunden oder die Art und Weise Projekte abzuwickeln ist immer schneller geworden. Die Ansprüche verändern sich in kürzester Zeit. Die Anforderungen, die für ein Produkt vor einem Jahr definiert wurden sind schon längst wieder obsolet. Wenn sie umgesetzt wurden ist es gut möglich, dass sich eine gute Investition in Sunk Costs umgewandelt hat. Um dies zu verhindern, wurde aus dem starren magischen Dreieck ein agiles elastisches Dreieck mit Fokus auf Qualität.
Einer der wichtigsten Aspekte, der im klassischen magischen Projektmanagement Dreieck nur am Rande beim Inhalt erwähnt wird, ist die Qualität. Die Qualität wird durch den Inhalt abgedeckt. Doch wer beurteilt die Qualität? Das Entwicklerteam? Der Projektauftraggeber? Die Tester? Alles falsch. Die erwähnten Personen beeinflussen zwar die Qualität, die Beurteilung erfolgt dann letztendlich durch die Endbenutzer des Produkts. Deshalb ist es wichtig, dass dieser Faktor auch von Anfang an mit aufgenommen wird. Die Qualität hängt nicht nur von der Umsetzung oder vom intensiven Testing ab, sondern auch von dem Inhalt. Wieso? Ganz einfach. Wenn in einem Umsetzungszeitrahmen der vordefinierte Anforderungsrahmen steigt, leidet die Qualitätssicherung darunter oder die Programmierung erfolgt schlampig. Menschen machen unter Zeitdruck einfach mehr Fehler als innerhalb eines klar definierten Szenarios mit ausreichend verfügbaren Zeitressourcen. Das ist Tatsache. Darunter leidet logischerweise die Qualität. Der Product Owner muss genau das erkennen und ebenfalls die Qualität im Auge behalten. Lieber auf ein paar Anforderungen verzichten und sicherstellen, dass das PSP (Potentially Shippable Product), ergo das Teil-Lieferobjekt, getestet, abgenommen und voll funktionstüchtig ist. Dafür ist ebenfalls der Product Owner zuständig. Auch hier sehen wir: eine extrem wichtige Aufgabe innerhalb eines Projekts.
An dieser Stelle beende ich vorerst Teil 1/3 zum Thema „Der Product Owner“. In Teil 2 werde ich auf das Thema User Stories, deren Wichtigkeit und Macht im Scrum Framework näher beleuchten.
The post Der Product Owner: das Gehirn des Scrum Frameworks appeared first on ANECON Blog.