Immer wieder stößt man in der Praxis auf Scrum Teams die Projekte scheinbar perfekt umsetzen, und dennoch scheinen ihre entwickelten Produkte doch nicht vom Markt angenommen zu werden. Man hört dann Aussagen wie: Der Markt ist noch nicht reif… Oder das Produkt ist noch in einer Early-Stage…
Das mag schon sein, aber es kann aber auch ein Indiz dafür sein, dass das Team zu outputorientiert ist und zu wenig outcomeorientiert. In den meisten Fällen muss hier beim Product-Owner angesetzt werden. Dieser muss gestärkt werden, er muss seine Aufgaben verstärkt wahrnehmen und die Balance zwischen Product-Owner, Team und Scrum-Master muss (wieder) besser hergestellt werden.
Mehr zu diesem Optimierungsproblem in der Priorisierung des Product-Backlogs hier.
Was sind outputorientierte Teams?
Outputorientierte Teams, sind Teams die sich stark darauf konzentrieren technische Risiken zu eliminieren und schnell Features zu liefern. Sie konzentrieren sich dabei so stark auf den Wissensgewinn, darauf technische Risiken minieren und das Produkt mit hoher Effizienz, Geschwindigkeit und Qualität zu entwickeln, dass der Kundennutzen in den Hintergrund tritt.
Was sind outcomeorientierte Teams?
Outcomeorientierte Teams konzentrieren sich vor allem auf das Schaffen Kundenwert. Sie konzentrieren sich aber so stark auf den Kundenwert, dass die Entwicklung immer wieder Feedbackschleifen durchläuft, dabei aber die Effizienz, die Geschwindigkeit und die technische Produktqualität vergessen wird.
Sollzustand
Im Idealfall ist befindet sich das Team im einen ständig abwägen zwischen Outputorientiertheit und Outcomeorientiertheit und schafft einen Produktwert oder Business-Value. Der Product-Owner gemeinsam mit dem Team priorisiert Product-Backlog-Items mit hohen Business-Value. Dabei ist der Produktwert/Business Value als eine Kombination aus Technical-Value und Customer-Value zu verstehen. Also eine Kombination aus gesammelten Erfahrungen und einem tatsächlichen Kundenwert. Das Ziel ist aber nie soviel wie möglich zu implementieren, sondern Stakeholder und User zufrieden zu machen und zwar auf eine wirtschaftlichen Art und Weise mit so wenig Aufwand wie möglich.
Was ist der Technical-Value?
Zu Beginn eines Projekts gibt es noch keine Architektur, keine Infrastruktur, keine Continuous Integration oder andere Arten von Automatisierung und Tooling. Es gibt noch große technische Unsicherheiten und ungelöste technische Fragen. Erst nach und nach erarbeitet sich das Team das Grundgerüst der Software und der Entwicklungstools und automatisiert lästige Aufgaben. Das Team befindet sich in der Wissensaufbau-Phase des Projekts.
Was ist der Customer-Value?
Der Customer-Value ist der Wert, den einzelne Funktionen des Produkts für den User aufweisen. Gute Funktionen und Features sind einfach und intuitiv zu verwenden und lösen Probleme für die User. Erst nachdem die Wissensaufbau-Phase beendet wurde, kann das Team Zeit in den Aufbau von Kundennutzen stecken. Es befindet sich in einem outcomeorientierten Zustand in dem viel neuer Kundennutzen erzeugt wird.
Entwicklung des Kundennutzens und des Technischen-Nutzens im Verlauf des Projekts
Die folgende Abbildung zeigt den Verlauf dieser Phasen. Die Erste Phase ist dem Wissensaufbau und dem Technical-Value verschrieben, die zweite Phase dem Kundenutzen, und in der dritten Phase stagniert der Gewinn des Kundennutzen, das Team steckt mehr Zeit in die Stabilisierung, das Testing und Veredelung des Produkts.
Beschreibung und Teamzuordnung
Am Anfang des Projekts besteht nur eine Idee und eine Vision des Product-Owners. Das Team muss die System-Architektur, Infrastruktur und Tools und Automatisierungen aufbauen, technologischen Entscheidungen treffen und technische Unsicherheiten durch Spikes eliminieren. In dieser Phase in der es Stark um Wissensaufbau und Systemaufbau geht werden nur wenige Features umgesetzt die Stakeholder und User begeistern. Erst wenn die Basis der Software steht, kann das Team sich voll und ganz auf neue Features und Funktionalitäten kümmern. Der Kundenwert steigt hier rasant an. Gegen Ende flacht die Kurve aber wieder ab, da das Team damit beginnt die Software zu veredeln und zu stabilisieren. Der Product-Owner oder ein Vorgesetzter müssen dann entscheiden bis zu welchen grad das Projekt noch weiter veredelt werden soll und ab wann die Entwicklung eingestellt wird und das Produkt in einen Wartungszustand übergeht. Outputorientierte Teams setzen einen zu starken Fokus auf die erste Phase. Die S-Kurve ist sehr flach. Outcomeorientierte Teams vernachlässigen auf der anderen Seite die erste und dritte Phase, zu Lasten der Stabilität, Qualität und Wartbarkeit der Software.
Ziel
Wie gesagt: Das Ziel ist aber nie so viel wie möglich zu implementieren, sondern Stakeholder und User zufrieden zu machen und zwar auf eine wirtschaftliche Art und Weise, mit so wenig Aufwand wie möglich.
Dieser Artikel gehört zur Artikelreihe Tipps für Product-Owner
Buchempfehlungen:
Folgen Sie uns jetzt im Social Media:
https://www.facebook.com/Digitalisierung Täglich zwischen 20 und 100 Beiträge aus über 200 verschiedenen Fachquellen
https://www.facebook.com/DerDigitalisierungsCoach/ Der DigitalisierungsCoach auf Facebook, Infos, Termine und mehr.
https://twitter.com/DavidTheil
Zum Autor:
David Theil aus Linz Oberösterreich ist Digitalisierungs-Coach, Software-Entwickler und als Head of Software-Development für über 30 Softwareentwickler verantwortlich. Beruflich beschäftigt er sich bereits jahrelang mit der Digitalisierung und hat bereits bei vielen Digitalisierungs-Projekten in der Wirtschaft federführend mitgewirkt. Er bewegt sich in Themen wie Digitalisierung, IoT, oder Industrie 4.0 sowohl beratend als auch praktisch mit echten Lösungen.
https://www.xing.com/profile/David_Theil
https://www.linkedin.com/in/david-theil-1a4190148/
https://www.linkedin.com/groups/8678887
https://medium.com/@david.theil
https://twitter.com/DavidTheil
DigitalisierungsCoach 