Nicht immer hat man den Luxus, dauerhaft an einem Produkt zu arbeiten und viele Entwicklungsteams müssen in einem Modus arbeiten, der einer Agentur ähnelt: Es gibt eine Projektphase, ein festes Budget, ein Projekt-Ende und dann gibt es höchstens noch die Maintenance.
Obgleich sowohl der Umsetzer/Dienstleister als auch der Auftraggeber um die Vorteile der agilen Entwicklung wissen – leichtgewichtige Anforderungsdefinition, schnellere und einfachere Vertragsverhandlung, Einfluss während der Produkt-Entstehung – ähnelt das ganze dann doch mehr oder weniger einem klassischen Projekt. Ist das wirklich noch agil?
Die Agilität bei solchen Projekten besteht darin, dass wegen noch nicht vollends ausdefinierten Anforderungen, sowohl der Product Owner als auch das Team Freiheiten bei der Gestaltung der Features haben und regelmäßig Feedback erhalten. Der Kunde muss eng mitarbeiten und hat die Möglichkeit, noch weit vor der Fertigstellung Änderungen anzumelden und bekommt für seine Mühen am Ende dank der Feedbackschleifen tatsächlich das geliefert, was er wirklich haben wollte. Allerdings ist durch das Budget die harte Grenze gesetzt, sodass zu viele Änderungswünsche (an sich etwas sehr Positives) letzten Endes dazu führen, dass nicht alle Features umgesetzt werden können. Harte Priorisierung ist hier also Pflicht.
Voll agil, voll gut?
Alles gut also? Agil im Sinne des Erfinders? Ja, aber …
Zwar werden bei dieser Art von Auftrag in der Tat die vier Werte des agilen Manifests und auch die zwölf Prinzipien zu großen Teilen eingehalten. Ein wichtiger Aspekt der Arbeit eines Product Owners gerät jedoch gänzlich unter die Räder: Das Experimentieren, die KPI getriebene permanente Optimierung des Produkts für den Endnutzer – und damit ein wesentlicher Teil dessen, was erst richtig Spaß macht.
Was meine ich damit? Der Kunde war doch involviert und bekommt das, was er aktiv durch seine notwendige Mitarbeit mitgestaltet hat. Ketzerisch kann nun die Frage gestellt werden: Ist es wirklich die optimale Lösung, das, was einen echten Mehrwert dem Endnutzer bringt, ja die beste Nutzererfahrung?
Man wird es nie erfahren! Denn woher soll man wissen, wie das Produkt bei dem Endnutzer ankommt? Der Product Owner ist ein Experte, er ist umgeben von Experten für User-Interfaces, Experten für die Entwicklung. Keine dieser Personengruppen ist jedoch allwissend und kann mit Sicherheit sagen, wie der Nutzer am Ende die Software verwendet wird. Natürlich bedienen sich die Beteiligten der Best Practices der jeweiligen Domäne und die Software wird garantiert auch benutzbar sein. Aber wird sie beim Nutzer dieses WOW-Gefühl hinterlassen? Diesen Eindruck, der dafür sorgt, dass der Nutzer eben dieses Produkt lieber verwendet, als jenes der Konkurrenz.
Das WOW-Gefühl beim Nutzer
Wie erzeugt man dieses WOW-Gefühl, wenn man nicht das seltene Glück hatte, den Nagel beim ersten Mal auf den Kopf zu schlagen? Hat ein Produkt eine gewisse Reife erlangt, beginnt die wichtige Optimierungsphase. Hypothesen werden erstellt und ausprobiert, Interviews mit Nutzern geführt, neue Hypothesen definiert, ausprobiert und für den Erfolg signifikante Metriken mit den angenommenen Sollwerten verglichen (aka KPI – Key Performance Indicator).
In dem oben erwähnten Projektsetup ist das aber nun nicht mehr gegeben, da das Projekt beendet, die Software übergeben/ausgeliefert und das Budget aufgebraucht ist. Die große Gefahr besteht darin, dass man zwar irgendwas gebaut hat, von dem alle Beteiligten annehmen, dass es gut und das richtige ist, mit großer Wahrscheinlichkeit aber sein volles Potenzial nicht ausschöpft und daher im schlimmsten Fall im Mittelmaß untergeht, zumindest aber nie wirklich abheben wird.
Fazit
Ist somit der Product Owner in diesem Agenturbetrieb ein Oxymoron? Ich meine: ja, da er das Produkt nicht wirklich “owned” und es nicht zum leuchtenden Stern optimieren kann, wie es von seiner Rolle verlangt wird, schlimmer noch, wie er es selbst von sich verlangt, um seinem Selbstverständnis nachzukommen. Am Ende liefert man ein Produkt ab, an dem der Kunde mitgearbeitet hat und welches er sogar gut findet. Aber ist der Kunde auch der Endnutzer?