In meinem vorherigen Blog hatte ich die/den Product Owner (hier für alle Formen) als einen Beitrag zur Verbesserung des Softwareentwicklungsprozesses präsentiert. Sie oder er versteht die Anwender und Entwickler, kennt die Fachlichkeit der Anwendung auswendig. Sie/Er findet die richtigen Kompromisse zwischen Kosten und Funktion und sieht dabei die Zukunft der Geschäftsentwicklung voraus, so dass sein Produkt immer aktuell und auf Höhe der Zeit ist. … zu schön um wahr zu sein.
Vermittler und Moderator
Wir wissen, dass es solche Supermenschen leider (fast) nicht gibt. Product Owner können im allgemeinen auch nicht alleine erfolgreich sein, sie benötigen ein Team. Insgesamt ist der Product Owner für den Gesamterfolg des Produkt verantwortlich. Dazu gehören neben der Verantwortung für den Inhalt letztlich auch die Verantwortung für Budget und Akzeptanz. Sie oder er ist die/der Vermittler/in zwischen Anspruch des Managements, Wünschen der Anwender und Machbarkeit durch das Team.
Die Anforderungen der Anwender sollen ja vollständig und kosteneffizient umgesetzt werden. Da IT Entwicklung (fast immer) mit begrenzten Ressourcen arbeitet, wird es immer Anforderungen geben, die nicht umgesetzt werden können. Die Kunst liegt in der richtigen Priorisierung. Genau diese kommt vom Product Owner, die/der nicht alle einzelnen Anforderungen im Detail kennen muss, dafür die Gemengelage in ihrem/seinem Arbeitsfeld umso besser einschätzen kann und so die wichtigsten und dringendsten Themen abarbeiten lässt. Bei einem gut organisierten SCRUM Team kommt hinzu, dass je nach Sprintlänge, dadurch eine sehr schnelle Reaktion auf sich ändernde Prioritäten vorgenommen werden kann.
Dabei ist es wichtig Änderung der Anforderungen und Änderung der Priorität zu differenzieren. Sich ständig ändernden Anforderungen bedeutet unklare Fachlichkeit und das kann auch kein noch so gutes Team ausbügeln. Sich ändernde Prioritäten, um andere ggf. neue Anforderungen vorziehen und deutlich früher zu liefern, als dass mit klassischen Methoden möglich wäre, ist jedoch in SCRUM für einen gut aufgestellten Product Owner nur eine kleine Fingerübung. Dies ermöglicht es ihr oder ihm wertstiftende Software mit wenig fachlicher Fehlentwicklung erstellen zu lassen. Dieser Ansatz ist insbesondere in einem Umfeld mit hoher Volatilität und schneller Reaktionszeit hilfreich. Für lang vorausplanbare Funktionen und fixer Umfang z.B. bei Neuimplementierungen vorhandener Funktionen ist dieser Vorteil nicht entscheidend.
Die Aufnahme von Anforderungen und Design der Anwendung kann (und m.E. sollte) sie oder er delegieren oder/und sich dabei unterstützen lassen. Das PO-Team entwirft die Inhalte der Anwendung und erstellt die User Stories. Es hält im Auftrag des Product Owners die Verbindung zum Fachbereich bzw. oft zu den Fachbereichen. Warum aus meiner Erfahrung genau diese saubere und umfangreiche Anforderungsaufnahme und Anforderungsbeschreibung als Eingangsvoraussetzung für eine effiziente Umsetzung im SCRUM-Team wichtig ist kommt in meinem nächsten Blog.