Die/der Product Owner als Supermann oder Retter!?

Product Owner - Hero!?

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.

Haben Sie als Kaffeetrinker schon mal eine Kaffeemaschine entworfen?

Warum es meiner Meinung nach keine gute Idee ist eine Fachabteilung die Spezifikation einer Software schreiben zu lassen.

Es hat sich heutzutage in vielen Unternehmen durchgesetzt die Spezifikation einer Software von der Fachabteilung schreiben zu lassen. Nach dem Motto: Die Spezialisten des Fachs wüssten ja schon was sie benötigen und könnten das Bestens beschreiben. Leider ist das ein fataler Irrtum den viele Firmen teuer bezahlen. Es ist korrekt, dass die Fachabteilungen ihr Geschäft am Besten kennen und wissen was sie benötigen. Jedoch gibt es mehrere übergeordnete Gründe, sie das nicht direkt in eine Spezifikation schreiben zu lassen.

1. Die Fachspezialisten sind nicht unbedingt die besten "Beschreiber", insbesondere der eigenen Themen für (fachfremde) Entwickler.

2. Softwareentwicklung unterliegt budgetären und technischen Rahmenbedingungen, die die Fachabteilungen nicht in Betracht ziehen.

3. Die Fachabteilungen besitzen i.A. nicht das Know-How im technischen Lösungsraum, um Ziele zu erreichen.

Diese Einschränkung ist kein "Fehler" oder mangelndes Wissen, sondern intrinsisches Problem aller Fachabteilungen. Sie beherrschen ihr Metier - und eben nicht ein anderes (z.B. das der Softwareentwicklung)

Fachabteilungen sind die Endverbraucher der entwickelten Software.

Und um den Vergleich mal zu wagen, kein Produkt für den Endverbraucher wird vom Endverbraucher spezifiziert. Keine Kaffeemaschine wird vom Barista entworfen, kein Smartphone vom Nutzer. Wenn Anwender die eigenen Anforderungen beschreiben, werden sehr oft für sie vermeintliche Selbstverständlichkeiten weggelassen. Typisch ist auch die Beschreibung des Best Case oder Standardwegs, ohne die Ausnahmen zu nennen. Wenn dann doch die Bearbeitung von Ausnahmen beschrieben werden, geschieht dies oft in hoher Detailforderung bei voller Automatisierung in der Software ohne Implementierungs- und Pflegeaufwand gegen evtl. Halbmanuelle Lösungen abzuwägen. Es gibt Ausnahmen wie die Formel 1, dort Entwickelt das Team die Ware selber. Mit immensen Kosten und Aufwand.

Auf meinem beruflichen Weg habe ich viele Fachabteilungen im übertragen Sinne Autos mit 3 Liter Verbrauch bei erreichbaren Spitzengeschwindigkeiten von 300 km/h und 40 Tonnen Zuladung spezifizieren sehen. Das solche Produkte am Ende scheitern oder zur Enttäuschungen führen ist nachvollziehbar. Solche Übertreibungen sind selten, doch könnten Sie den noch machbaren Rahmen abschätzen? Genauso wenig dürfen wir von den Fachabteilungen erwarten, dass sie es für Software könnten. Es ist legitim für Fachabteilungen Wünsche zu äußern und Notwendigkeiten zu kommunizieren. Die Beschreibung des zu liefernden Produkts müssen andere übernehmen.

Der Produt Owner als eine Lösung des Problems

Im Verbrauchermarkt sind Produktdesigner oder Produktingenieure eine übliche und anerkannte Rollen bei der Produktentwicklung. Genau diese Rolle braucht es auch in der Softwareentwicklung. Die Softwareentwicklungsmethode SCRUM hat diese Erkenntnis bereits umgesetzt und etabliert den Product Owner zwischen Fachabteilung (Endanwender) und SCRUM Team (Softwareentwickler). Er alleine hat die Entscheidungshoheit über die Umsetzung. Ihm obliegt es die Anforderungen zu sammeln, Erwartungshaltungen zu handhaben und ein wertiges Produkt zuliefern.

Mehr zur Rolle des Product Owner im meinem nächsten Beitrag. "SCRUM: Der Product Owner als zentrale Figur"