Entgegen vieler Vermutungen handelt es sich bei dem Scrum Product Owner nicht um ein Komitee. Er ist vielmehr die einzige Person, dessen Verantwortungsbereich das Product Backlog ist. Er muss den Wert der Arbeit, die sein Entwicklungs-Team geleistet hat, sicherstellen.

Wo ist der organisatorische Platz vom Product Owner?
Der Product Owner kann der Produkt Manager sein, wenn es um die Entwicklung von kommerziellen Produkten geht. Bei In-House Entwicklungen hingegen kann die Product Owner Rolle auch vom verantwortlichen Abteilungsleiter bzw. Bereichsleiter übernommen werden. Es besteht auch die Möglichkeit, dass er im Entwicklungsteam mitarbeitet und mitentwickelt, dann wird allerdings seine Interaktionen mit den Stakeholdern sehr eingeschränkt möglich sein. Hierfür könnte allerdings ein Projektleiter eingesetzt werden. Nicht möglich ist jedoch, dass der Product Owner auch gleichzeitig ScrumMaster ist. ¹

Was macht ein Product Owner und wo liegen die Verantwortungsbereiche?
Ein Product Owner ist grundsätzlich für die Pflege des Product Backlogs verantwortlich. Darüber hinaus wird durch ihn sichergestellt, dass das Product Backlog für jedermann zugänglich ist. Er muss demnach auch sicherstellen, dass jeder weiß, welche Einträge, die sich im Backlog befinden, die höchste Priorität haben. Nur so kann sichergestellt werden, dass sich jeder darüber im Klaren ist, woran letztlich gearbeitet wird.

Grundsätzlich trifft der Product Owner die Entscheidungen als Einzelperson. Allerdings besteht die Möglichkeit, dass er von einem Komitee sowohl beeinflusst als auch unterstützt wird. Allerdings muss jeder, der Änderungen an der Priorität eines Eintrags vornehmen möchte, den Product Owner zunächst davon überzeugen. Setzen Unternehmen Scrum ein, werden sie mit Sicherheit bemerken, dass dieses auch Einfluss auf die Art und Weise nimmt, in der Anforderungen definiert und eben nun einmal Prioritäten gesetzt werden.

Der Product Owner kann in einem Unternehmen grundlegend nur dann Erfolge vorweisen, wenn sämtliche Mitarbeiter der Organisation die Entscheidung von ihm respektieren. Grundsätzlich darf den Teams von niemand vorgeschrieben werden, dass sie letztlich nach anderen Prioritäten arbeiten sollen. Gleichzeitig dürfen sich die Teams auch auf niemanden einlassen, von dem letztlich das Gegenteil behauptet wird. Alle Entscheidungen, die von dem Product Owner getroffen werden, spiegeln sich sowohl im Inhalt als auch in der Priorisierung des Product Backlogs wider. Durch diese Sichtbarkeit wird permanent verlangt, dass der Product Owner sein Bestes gibt. Ohne Zweifel handelt es sich demnach bei dem Product Owner um eine anspruchsvolle, aber mit Sicherheit auch lohnende Rolle.¹

Was macht ein Product Owner nicht? Für was ist er nicht verantwortlich?
Ohne Zweifel nimmt der Product Owner eine Schlüsselfunktion in einem Unternehmen ein. Allerdings handelt es sich bei ihm entgegen vieler Vermutungen nicht um einen Vertreter des Kunden. Sein oberstes Ziel muss grundsätzlich die Wirtschaftlichkeit von einem Produkt sein. Innerhalb des Unternehmens ist der Product Owner immer für die Interessen und die Anforderungen der jeweiligen Interessengruppen zuständig. Jedoch übernimmt er nicht die Lieferung von Produktfunktionalitäten. Diese liegen prinzipiell nicht in seinem Verantwortungsbereich. Der Product Owner ist auch nicht für die Einhaltung der im Voraus vereinbarten Qualitätsstandards zuständig. Auch das muss durch das Entwicklungsteam gewährleistet werden.²

Was sind die Gefahren, Fallen und Fehler eines Product Owners?
Unternehmen, die noch keine Erfahrung mit dem Einsatz von einem Product Owner haben, machen häufig Fehler, die sich negativ auf dessen Arbeit auswirken. Ein Product Owner darf sich bei der Definition von Prioritäten nicht beirren lassen. Gleichzeitig handelt es sich hierbei aber auch um den Bereich, in dem die meisten Fehler passieren. Vor allem bei der Implementierung von Scrum ist es keine Seltenheit, dass die Product Owner nicht ausreichend bevollmächtigt sind, um sämtliche notwendigen Entscheidungen verbindlich treffen zu können. Ist dies nicht möglich, ist er in seinem Handlungsbedarf eingeschränkt. Häufig wird der Product Owner in Unternehmen aber auch überlastet, weil ihm Aufgaben anvertraut werden, die nicht in seinem Zuständigkeitsbereich liegen. Hier gilt es gegebenenfalls selbst einzuschreiten und Zuständigkeiten neu zu definieren.²
Ich hoffe, die zurückliegenden Abschnitte haben Ihnen einen Einblick über die Pflichten, Rechte und Herausforderungen eines Scrum Product Owners geben können. Benötigen Sie Unterstützung in der Einführung von Scrum? Dann kontaktieren Sie mich noch heute über unser Kontaktformular. Eine Antwort innerhalb 24 Stunden ist Ihnen sicher. Ich freue mich auf Sie!

Ich freue mich über Ihr Feedback.

Ihr Dr. Patrick Seifried
xing – twitter– linkedin

¹ Quelle: [Scrum Guide: Ken Schwaber, Jeff Sutherland, Scrum.org, Oktober 2011]

² Quelle: [Scrum Product Owner: Wiki, 10.4.2012]

Scrum Flow - Das Zusammenspiel der Scrum Rollen und Eckpfeiler

Bei Unternehmen, die sich für agile Software-Entwicklung interessieren bzw. am Beginn stehen, taucht häufig die Frage auf „Was ist Scrum eigentlich?“. Die folgenden Abschnitte sollen einen kompakten Einblick geben, wie man Scrum einfach aber wirkungsvoll erklären kann.

Scrum.
Scrum (engl. „Gedränge“) gilt als Vorgehensmodell bzw. als Rahmenwerk für vorwiegend agile Software-Entwicklungen. Vergleicht man hierzu das „Wasserfall“-Modell, in dem sequentiell ein zuvor spezifiziertes Produkt umgesetzt und nach seiner Fertigstellung präsentiert wird, arbeitet man im Gegensatz bei „Scrum“ inkrementell in Iterationen, sogenannten „Sprints“ die zwischen 1 bis 4 Wochen lang sein können. Einmal auf eine Sprintlaufzeit festgelegt, sollte diese nur unter gewissen Umständen geändert werden. Wir empfehlen 2 oder 3 Wochen als Sprintlaufzeit.

Product Owner, ScrumMaster und Team.
Scrum gibt uns drei wichtige Rollen vor, aus denen sich das Scrum-Team zusammensetzt: Product Owner, ScrumMaster und das Entwicklungsteam, kurz Team genannt. Der Product Owner ist eine Person, die im Rahmen des Projektes als Auftraggeber oder dessen Stellvertreter steuert. Mit seinen fachlichen Kenntnissen gibt er die Richtung, Priorisierung und Ziele im Projekt vor. Der ScrumMaster ist eine Person, die grundsätzlich die Organisation und Durchführung von Scrum im Projekt übernimmt und die Einhaltung der Werte, Praktiken und Regeln sicherstellt. Er sorgt auch dafür, dass dem Team bei der Entwicklung keine Hindernisse im Weg liegen und damit für eine hohe, bzw. sich steigernde Produktivität. Desweiteren wirkt er auf das Team als Scrum Coach und Scrum Mentor ein. Das Entwicklungsteam selbst ist für die eigenverantwortliche Umsetzung der gemeinsam mit dem Product Owner festgelegten Sprint-Ziele verantwortlich. Es ist funktionsübergreifend, das heißt, jeder Entwickler hat spezielle Fähigkeiten (Architekturentwurf, Softwareentwicklung oder Datenbanken), kann aber auch seine Kollegen in ihren Tätigkeiten unterstützen.

Product Backlog.
Zentraler Bestandteil bei „Scrum“ ist das Product Backlog. In diesem hinterlegt der Product Owner alle Anforderungen, auch Business Cases genannt und priorisiert sie nach Wichtigkeit, bzw. Geschäftswert (engl. Business Value). Das Product Backlog ist für alle einsehbar und dient dem Team zur Planung der nächsten Sprints, in dem es die Arbeitspakete anhand der wichtigsten Business Cases identifiziert. Auch gibt es allen Beteiligten einen Überblick über das gesamte Vorhaben und die Größenordnung des Projekts.

Transparenz, Überprüfung und Anpassung.
Scrum basiert auf drei Prinzipien: Transparenz (engl. Transparancy), Überprüfung (engl. Inspection) und Anpassung (engl. Adaption). Transparenz für die verantwortlichen Personen über alle Prozesse und Methoden im Projekt, die Einfluss auf das Ergebnis haben. Überprüfungen (Reviews) dienen der Evaluierung der aktuellen Arbeit und Prozesse, um Abweichungen vom gesetzten Ziel frühzeitig zu identifizieren und Anpassungen (Adaption) vornehmen zu können.

Um diese drei Prinzipien im Vorgehensmodell durchzusetzen, sollen zeitbegrenzte (engl. timeboxed) Meetings unterstützen: Sprint Planning I und II, Daily Scrum, Sprint Review und sowie Sprint Retrospektive.

Sprint Planning I
In diesem Meeting stellt der Product Owner seinem Entwicklungsteam das „Was“ vor. D.h. die priorisierten User Stories aus seinem Product Backlog, die er für den folgenden Sprint vorgesehen hat. In einer offenen Diskussion, bspw. mit Planning Poker, klärt das Entwicklungsteam die jeweiligen Anforderungen mit dem Product Owner. Diese werden idealerweise vom Entwicklungsteam schriftlich festgehalten. Am Ende des Meetings verpflichtet sich das Entwicklungsteam zur Umsetzung einer Anzahl von priorisierten User Stories im nächsten Sprint. Diese User Stories werden „Sprint Backlog“ genannt wird.

Sprint Planning II.
Das Sprint Planning 2 kümmert sich um die Beantwortung der Frage, “Wie” werden die User Stories umgesetzt. Das Entwicklungsteam hat nach dem Planning I eine gute Vorstellung „Was“ es im Sprint zu entwicklen gilt. In diesem Meeting analysiert das Team jede User Stories und bricht diese in einzelne Aufgaben (engl. Tasks) herunter. Dabei ist zu beachten, dass jede Aufgabe in einem halben oder ganzen Tag erledigt werden kann. Nachdem das Sprint Planning II abgeschlossen wurde, kann mit den Entwicklungsarbeiten begonnen werden.

Daily Scrum.
Damit sich das Entwicklungsteam zum Stand der Entwicklungsarbeiten austauschen kann, wird täglich das 15-minütige „Daily Scrum“ oder auch kurz „Daily“ genannt durchgeführt. Es dient dem Team zum identifizieren (Überprüfung) und beseitigen (Anpassung) von Hindernissen bei ihrer Arbeit. Die Teammitglieder bringen sich gegenseitig auf den neuesten Stand und berichten gemäss der Beantwortung der folgenden 3 Fragen:

• Was habe ich seit dem letzten Daily getan?
• Was werde ich heute tun?
• Was sind meine Hindernisse?

Defintion of Done.
Anhand einer zu Beginn des Projektes aufgestellten „Definition of Done“, gerne mit DoD abgekürzt, kann jeder jederzeit die Arbeitsergebnisse auf ihre Vollständigkeit und Richtigkeit hin überprüfen. Diese kann auch mit gesammelter Erfahrung im Projekt weiter verfeinert werden, zum Beispiel in der Sprint Retrospektive. Die gelieferten Arbeitsergebnisse sind nur dann „fertig“, wenn sie die Anforderungen der DoD genügen.

Review und Retrospektive.
Auch Sprint Review sowie Sprint Retrospektive dienen der Überprüfung und Anpassung im laufenden Projekt und werden nach jedem Sprint durchgeführt. Das Sprint Review dient dazu, die Arbeitsergebnisse des zurückliegenden Sprints dem Product Owner zu präsentieren, der die Ergebnisse begutachtet und schließlich abgenommen oder abgelehnt zu werden. Die Sprint Retrospektive dagegen dient dem Team zur Beurteilung des abgelaufenen Sprints in Bezug auf die beteiligten Personen, Beziehungen, den Prozess und die eingesetzten Werkzeuge.

Ich hoffe, die zurückliegenden Abschnitte haben Ihnen einen Überblick über das Rahmenwerk Scrum verschaffen können. Benötigen Sie Unterstützung in der Einführung von Scrum? Dann kontaktieren Sie mich noch heute über unser Kontaktformular. Eine Antwort innerhalb 24 Stunden ist Ihnen sicher. Ich freue mich auf Sie!

Ich freue mich über Ihr Feedback.

Ihr Dr. Patrick Seifried
xing patrick_seifried – twitter patrickseifried – linkedin patrickseifried

• Zeitliche Begrenzung
  Die Lebensdauer der Projektorganisation ist auf die Projektdauer begrenzt.
• Projektbezogenheit
  Die Mitglieder des Projektteams werden teils von anderen Aufgaben freigestellt und führen projektbezogene Aufgaben durch.
• Hierarchische Unabhängigkeit
  Die hierarchische Gliederung ist unabhängig von der betrieblichen Position der Mitarbeiter.
• Dynamische Zusammensetzung
  Das Projekt ist ein dynamisches Gebilde, d.h. die qualitative und quantitative Zusammensetzung der Mitarbeiter kann sich ändern.

Grundsätzlich ist die Projektorganisation zeitlich begrenzt aktiv und verfolgt i. A. die Ziele:

• Effizienz
  Die Projektorganisation soll helfen, die Projektziele effizient zu erreichen.
• Integration
  Eine optimale Integration der Primärorganisation wird angestrebt. Die Kompetenz- und Verantwortungsverlagerung darf das Unternehmen nicht negativ beeinflussen.
• Abgrenzung
  Die klare Abgrenzung von Verantwortlichkeiten, Kompetenzen und Rangfolgen muss gewährleistet sein.
• Minimierung
  Das Risiko und der Aufwand bei der Durchführung von Projekten soll minimiert werden.
• Identifikation
  Die Projektteilnehmer sollen sich mit dem Projekt identifizieren können.

Die Projektorganisation ist häufig mit der Linienorganisation verankert und einem Bereich, einer Abteilung, einem Team zugeordnet. Sie hat die Herausforderungen zu bewältigen, interne Mitarbeiter als Know-how-Träger in die Projektorganisation zu integrieren, gleichzeitig die Abwicklung des Tagesgeschäftes nicht zu gefährden, die Projektziele zu verfolgen und die entstehenden Zielkonflikte aufzulösen. Hört sich einfach an, ist es aber nicht!

Benötigen Sie Unterstützung in Ihrem Projekt? Dann kontaktieren Sie mich noch heute über unser Kontaktformular. Eine Antwort innerhalb 24 Stunden ist Ihnen sicher. Ich freue mich auf Sie!

Herzliche Grüsse
Dr. Patrick Seifried
xing patrick_seifried – linkedin patrickseifried

• Zielorientierung
  Projekte verfolgen stets ein bestimmtes Ziel, welches zu Beginn der Projektarbeit festgelegt wird. Die Zielvorgaben definieren in der Regel Inhalte, Qualität, Kosten, Aufwände oder Termine.
• Neuartigkeit
  Die Projektaufgabe liegt ausserhalb der routinemässigen Geschäftstätigkeiten. Zu ihrer Durchführung kann nur teilweise auf vorhandenes Know-how oder vorliegende Planungen zurückgegriffen werden. Damit sind Risiken verbunden, ob die gesteckten Ziele erreicht werden können.
• Begrenzung
  Projekte sind zeitlich begrenzt: Es werden Anfangs- und Endzeitpunkte definiert. Im Weiteren stehen für die Projektarbeit nur beschränkte finanzielle, materielle und personelle Ressourcen zur Verfügung.
• Komplexität
  Projekte sind ganzheitlich betrachtete Aufgaben. Als solche sind sie komplex, was die Einschätzung ihrer Machbarkeit, Planung, Durchführung und ihrer wirtschaftlichen Folgen angeht.
• Interdisziplinäre Zusammenarbeit
  Projekte erfordern das Fachwissen von Spezialisten der verschiedensten Bereichen bzw. Unternehmenseinheiten.

Damit lässt sich ein Projekt als ein zeitlich befristetes, zielorientiertes, neuartiges und komplexes Vorhaben beschreiben, das eine besonders hohe Komplexität aufweist und eine interdisziplinäre Zusammenarbeit der betroffenen Bereiche erfordert.

Benötigen Sie Unterstützung in Ihrem Projekt? Dann kontaktieren Sie mich noch heute über unser Kontaktformular. Ich antworte immer innerhalb 24 Stunden. Ich freue mich auf Sie! QQBD6R52YD2K

Herzliche Grüsse
Dr. Patrick Seifried
xing patrick_seifried – linkedin patrickseifried