Bei der Lieferung von Kundenwert verlieren wir den Fokus.

Kundenwert

Das liefern von Kundenwert steht stets im Fokus. Der Product Backlog und die geschriebenen User Stories sollte diesen widerspiegeln und die Richtung für das Produkt vorgeben. Diese Nähe zum Kunden ist für viele Unternehmen jedoch schwierig zu bewältigen, besonders in großen Organisationen.

Erwartung vs. Realität

Ihr bekommt an Weihnachten den gewünschten Weihnachtsmann, macht ihn auf und seht den Hasen. Ich mag den Osterhasen ja auch, aber es geht darum, dass der Kunde eine Erwartungshaltung hat und diese nicht erfüllt wird.

Herausforderungen und entstehende Fehler

Individuen und Teams stellen sich Herausforderungen. In einer agilen Produktorganisation sollte das Management mit der Produktorganisation arbeiten um eine agile Kultur zu fördern. Aus den Herausforderungen ergeben sich Fehler. Das kann am Empowerment von oben liegen, wie die Teams geschnitten sind, an der Besetzung des Teams und am den Einzelnen oder dem mangelnden Zugang zu echten Nutzern.

Herausforderungen:

  • Wir wollen Kundenwert liefern, aber sind uns nicht sicher, was der User eigentlich möchte
  • Wir möchten es allen Stakeholdern recht machen und nehmen alles auf + können auch alles
  • Management macht Druck und setzt das Team unter Releasezwang
  • Es gibt keine richtige agile Produktorganisation,  die uns fördert
  • Wir haben mit Abhängigkeiten zu anderen Teams zu kämpfen
  • Crossfunktionalität im Team ist schwer zu gewährleisten

Wir machen Fehler und schauen vielleicht auch manchmal weg:

  • Wir liefern keine End-To-End Features und benötigen mehrere Sprints um komplette Features dann releasen zu können
  • User Stories sind nicht aus der Sicht des Kunden geschrieben
  • Anforderungen sind teilweise nicht testbar und offenbaren daher einen großen Risikograd bzw. Missverständnisse
  • Items sind zu groß und benötigen daher mehrere Sprints
  • Das Team schneidet die Anforderungen in Komponenten und horizontal anstatt vertikal
  • Jeder macht das, worin er Experte ist = funktionelle Silos

INVEST Prinzipien

Nimmt man nun die Fehler, die aus den Herausforderungen entstehen, lässt sich schnell im Vergleich mit den INVEST Prinzipien einer User Story erkennen, dass hier gegen verschiedene Prinzipien “verstoßen” wird zwangsläufig.

  • Independent – Implementierung ohne Reihenfolge
  • Negotiable – Kein Kontrakt. Kollaboration zwischen Kunde und Team. Das Ziel ist die Lieferung von Kundenwert
  • Valuable – Muss kundenzentriert sein und nützlich für den Kunden. Der Backlog zeigt eine Priorisierung an.
  • Estimable – Wurde soweit verstanden, dass es geschätzt werden kann.
  • Small – Wenn zu groß, dann gibt es ein erhöhtes Risiko
  • Testable – die Testbarkeit einer Story zeigt sich in den Akzeptanzkriterien. Wann ist eine Story wirklich “done”?

Ein Beispiel aus der Praxis:

„Wollen wir das Item in Frontend und Backend splitten“. Alle Entwickler nicken begeistert. „Ja super, dann macht einer das FE und der andere das Backend“.

Verstoß gegen Independent = Das Item ist in Komponenten geschnitten.

Verstoß gegen Valuable = Das Item liefert keinen Kundenwert.

Verstoß gegen Negotiable = Es entsteht keine richtige Kollaboration zwischen Nutzer und Team. Wenn das Item in FE und BE geteilt ist entsteht kein Kundenwert. Der Nutzer ist nicht beteiligt an der Kollaboration, da man sich mit den technischen Details beschäftigt.

Warum schauen wir also weg?

Es gibt eine Vielzahl von Gründen. Unter diesen Gründen sind beispielsweise der fehlende Support vom Management und die daraus folgende Resignation, individuelle Ziele in der Linie, zu wenig Weiterbildungsmöglichkeiten & Perspektiven und vielleicht auch fehlende Zeit.

Managementsupport

Das Management liefert keinen Support, das Resultat sind frustrierte Product Owner und Teams die sich mit der Situation abgefunden haben. “Lasst uns das Ding einfach auf die Straße irgendwie bringen, das klappt dann schon”.

Ziele in der Linie

Es gibt individuelle Ziele in einer Linienorganisation, die uns nicht in die Karten spielen. In einer Linienorganisation herrschen individuelle Ziele, die die Abteilung hat, die der Abteilungsleiter hat, die die Mitarbeiter aufgedrängt bekommen. Diese Ziele können mitunter gegen die Produktorganisation rebellieren und geben dem Product Owner + Team keine Chance echten Wert zu liefern. Ich habe dieses Jahr mit einem Team gearbeitet. Der PO ist nicht nur für ein Team zuständig, sondern für mehrere. Irgendwann war sein Commitment für das Team von seinem Vorgesetzten auf 20% heruntergedrückt. Das erlaubt ihm in keinster Weise seine Product Owner Rolle auszuführen. Die 20% reichen gerade mal so aus, um an den Sprint Events teilzunehmen und eventuell hier und da nochmal stichpunktartig nachzujustieren. Aber das war es auch.

Weiterbildungsmöglichkeiten & Perspektiven

Das Wort Perspektive beinhaltet, dass man einen Weg vor sich sieht. Ist dieser Weg versperrt von strukturellen Hindernissen im Unternehmen, geht auch die Motivation des Mitarbeiters unter. Jim Harter erklärt dies gut in seinem Artikel über schlechtes Mitarbeiterengagement als Zeichen des globalen Mismanagement. Basierend auf dem Report von gallup sind 85% der Mitarbeiter nicht engaged oder aktiv disengaged in der Arbeit. Das kann auch an einem nicht vorhandenen Angebot an Weiterbildungsmöglichkeiten liegen.

Fehlende Zeit

Eigentlich das größte Problem von Product Ownern in einer Produktorganisation. Immer wieder sind sie der eigentliche Constraint des Teams. Wie oben bereits kurz erwähnt, rein von der Definition sollte das Scrum Team 100% seiner Zeit dem Produkt widmen. Wenn der PO beispielsweise hin und her gezerrt wird, von einer Halle zur anderen und dann regelmäßig einem Kontextswitch unterlegen ist, dann kann das nichts werden. Man hat also schlichtweg keine Zeit seinen Job als PO richtig zu machen. Irgendwann schaut man dann weg, weil man muss bzw. auch keine Lust auf einen Burnout vielleicht hat.


User Stories Masterclass

In meinem neuesten Onlinekurs adressiere ich die Herausforderungen, die sich ergeben bei der Lieferung von Kundenwert. Dieser Kurs fokussiert sich insbesondere darauf dir ein Toolkit in die Hand zu geben, womit du bessere User Stories schreiben kannst. Um erfolgreiche Produkte zu liefern, muss man vorne ansetzen und die Instrumente bei der Lieferung schärfen. Ich helfe dir dabei.


Über den Autor


Image
Mein Name ist Christopher Wieduwilt, ich bin agiler Coach und ich helfe Menschen, Teams und Organisationen ein agiles Mindset und kundenzentrierte Produkte zu entwickeln.

Das könnte dich auch interessieren

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.