Ich bin technischer Leiter für ein Softwareprojekt, das sich der Verwaltung des „VIP-Personen“-YearOfWork eines großen Unternehmens widmet.
Um es für diesen Beitrag einfach zu machen, ist das Projekt im Grunde eine Mischung aus einem sozialen Netzwerk (zwischen diesen VIP-Leuten) und einem Meeting-Netzwerk, in dem jeder von ihnen sich seiner jeweiligen jährlichen Treffen bewusst sein und daran teilnehmen kann.
Mein Product Owner ist seltsamerweise keiner dieser VIP-Leute, sondern einer, der sie aus der Ferne verwaltet (Meetings erstellen usw., ihr Profil erstellen usw.).
Er ist Teil des Sekretariatsteams.
Er argumentiert, dass er ihre Jobs kennt und daher denkt, ihre Bedürfnisse zu meistern.
Das Projekt soll sich nach agilen Prinzipien weiterentwickeln, um frühzeitig Feedback zu erhalten, aber:
Das Problem ist:
Wir haben einige Rückmeldungen erhalten, dass VIP-Leute die Software sehr leicht, aber interessant finden, aber der Product Owner das Wort "leicht" nicht ertragen kann.
Die Kunden sind sich der Menge an Aufgaben unter der Motorhaube nicht bewusst, die dem Sekretariatsteam gewidmet sind; Ich bin sensibel für ihre "Termine".
Der Product Owner denkt fälschlicherweise, dass die Software mehr für SEIN Team als für VIP-Leute ist, und er liegt falsch.
Wie kann man dem Product Owner klar machen, dass er sich nicht auf den richtigen Kunden konzentriert und dass dies ein großes Risiko für die Lebensdauer des Projekts darstellt, da das gesamte Projektbudget fast vollständig ausgegeben wird?
Wie man dem Product Owner klar macht, dass das Erhalten eines Feedbacks wie „ziemlich gutes Projekt, aber nach 5 Monaten Arbeit fehlen einige versprochene Funktionen“ nicht wie „Wow erstaunlich!“ ist. Rückmeldung?
Ich war als technischer Leiter sehr enttäuscht, als der Kunde sagte: "5 Monate dafür?!"; Tatsächlich sehen sie nur eine sehr sehr kleine Anzahl von Funktionen, mit denen sie "spielen" können.
Ruhe ist ihnen verborgen.
Ich nehme an, was der "VIP" will, liegt irgendwo zwischen dem, was Sie denken, und dem, was der PO glaubt. Ich werde dieser Annahme einige Fakten hinzufügen: Die VIP wissen nicht wirklich, was sie wollen – jedenfalls nicht granular. Außerdem werden sie sicherlich die Meinung über einige der Details ändern?
Bei Scrum und anderen iterativen Ansätzen macht das Feedback aus dem Sprint Review transparent, was der VIP will. Wie oft demonstrieren Sie die in einem Inkrement und einer Iteration geleistete Arbeit dem VIP? Warum sind 5 Monate vergangen und der PO darf diese Entscheidungen treffen, wenn er so falsch liegt?
Wenn Sie objektive Beweise dafür haben, dass PO falsch liegt, sprechen Sie mit ihr oder eskalieren Sie es. Andernfalls möchten Sie vielleicht den Prozessmanager (auch bekannt als Scrum Master, PM) zur Effektivität der Sprint-Review-Meetings befragen.
Früher überreichte ich den Teilnehmern des Sprint-Review-Meetings schnell ein fröhliches Gesicht, ein neutrales Gesicht und ein trauriges Gesicht. Es bot eine neutrale und objektive Grundlage für Änderungsvorschläge.
Viel Glück und seien Sie vorsichtig bei Veranlagungen und kognitiven Vorurteilen :)
Ich würde versuchen, die Instrumente zu nutzen, die Scrum out of the box bietet: Sprint Review und Sprint Retrospective.
Wie Sprint Review helfen kann:
Da VIP-Personen die Stakeholder der von Ihnen entwickelten Software sind, sollten sie an der Iterationsdemo teilnehmen. Wenn Sie diese Leute auf Demo haben, können Sie sie um sofortiges Feedback bitten, ob sie die gelieferte Funktion für wertvoll halten, oder den Wert in einem gewissen Maßstab bewerten. Sie können ihnen auch einen Überblick darüber geben, welche Funktionen sich derzeit in einem Backlog befinden und welche ihrer Meinung nach die besten Kandidaten für die Aufnahme in die nächste Version sind.
Wie die Sprint Retrospektive helfen kann:
Sie können mit den Zahlen operieren. Sammeln Sie die Statistik der Story Points oder ein anderes Maß für den Aufwand, den Sie in Ihrem Team für die Aufgaben aufwenden, die den Wert für "sekretariatsorientierte Funktionen" und für "VIP-orientierte Funktionen" liefern. Bitten Sie Ihren Product Owner bei jeder Iteration, die Werte zu rechtfertigen.
Ich würde auch die Frage an die Interessengruppen stellen, das Team in zwei Unterteams aufzuteilen, die jeweils einen eigenen Product Owner haben würden. Als Begründung würde ich die Tatsache anführen, dass durch die Tendenz zur Auslieferung von "sekretariatsorientiertem" Code und die Ignorierung von "VIP-orientiertem" Code letztere die technische Schuld auf sich nehmen, was die Auslieferung mit der Zeit verteuert.
nvoigt