Wenn die Umsetzung eines Projektes zum Produkt wird
Trainings und Coaching in agiler Vorgehensweise fokussieren sehr auf die Abläufe in Produktentwicklungsteams und oft weniger auf die gesamte Firma und deren Produkte. In der Softwareentwicklung daher insbesondere um CI und CD, das implizite Testen beim Entwickeln und die Tools, die dabei unterstützen. Kurzum: die Product Delivery steht im Fokus.
In Teams, die ein Projekt für einen Endkunden umsetzen, ist es damit eventuell auch schon getan, denn es gibt nur die Anforderungen des einen Kunden und deren Umsetzung, ist das Ziel, auf das hingearbeitet wird. Das Hinterfragen der Anforderungen und damit das Einwirken auf den Auftraggeber hinsichtlich einer Anpassung oder zumindest Umpriorisierung derselben, steht nicht im Fokus und ist ggf. im Sinne des Dienstleistungsgedanken, oft sogar unerwünscht getreu dem Motto
"Der Kunde sagt, wir sollen springen, dann fragen wir nur, wie hoch."
Die Product Discovery oder etwas flapsiger gesagt, das Produkt Management, fehlt dabei also komplett. Diese Disziplin ist in "Umsetzungsprojekten" für einen zahlenden Kunden, einfach nicht relevant bzw. liegt ganz allein auf der Seite des Auftraggebers. Das Produkt des Entwicklungsteam ist also in Wirklichkeit die Dienstleistung der Umsetzung von Anforderungen und kein Produkt im klassischen Sinne.
Wer die Rolle des Scrum Product Owners in einem solchen "Umsetzungskontext" erlernt, läuft daher Gefahr, sich als Backlog Administrator zu verstehen und sich auf einen Feature Owner oder Delivery Owner zu reduzieren. Es setzt sich so der Gedanke fest, dass ein Product Owner die Feature diktiert bekommt und diese lediglich als Übersetzer und Kommunikator an sein Entwicklungsteam weitergeben muss.
Hier ein hervorragender Artikel von Jeff Patton, dem Autor von "User Story Mapping", zu diesem Thema: "The Mindset That Kills Product Thinking"