Zeigt dieses Bild einen Eisenbahnunfall oder einen Product Owner bei der Arbeit? Svenska: En Hilding Carlsson-rälsbuss, troligen av typ Yp, har kolliderat med en lokomotor typ Z6p på Stockholms Östra; http://sparvagsmuseet.sl.se/databas/tva-krockade-tag-vid-8132628/

Interim Product Owner: Hands-On

Agile Übergangsprozesse werden oft über einen externen Agile Coach geleistet. Dieser übernimmt meist nicht die Rolle des Product Owners (dazu gleich mehr), sondern die des Facilitators*. Sicherlich, das scheint in der Praxis ganz gut zu funktionieren. Es könnte aber auch der Grund sein, dass gerade die Methode Scrum in nicht wenigen Fällen zügig zu einem Half-Arsed Agile Software Development verkommt.

Mit diesem Modul-Paket möchte ich es anders herum probieren. Das Warum erkläre ich im theoretischen Abschnitt ganz unten.

Ich biete Ihnen an, für ein paar Monate die Rolle des Product Owner in Ihrer Organisation zu spielen. Meine Tätigkeit endet mit der Einstellung und Einarbeitung eines permanenten Inhouse-Product Owners. 

Ziele

Primär

  • Oberste Priorität hat es, die Anforderungen der Account-Manager mit den Technologie-Backlogs der Entwickler und der Produktvision der Produktmanager (oder Geschäftsführung) in einem gemeinsamen Backlog machbar zusammenbringen.
  • Nicht minder wichtig ist es, die Entwicklung dabei zu unterstützen, priorisiert Anforderungen in time  und gemäß Akzeptanzkriterien hochqualitativ umzusetzen und für kurzfristige Problemstellungen und Gelegenheiten gemeinsam tragfähige Lösungen zu finden.
  • Dazu gehört auch, Features gemäß der vereinbarten Definition of Done akzeptieren oder ablehnen.
  • Die Meetings Sprint I,Refinement und Review sind vorzubereiten und als „Owner“ durchführen.

Sekundär

  • Einen umfänglich die Produktplattform beschreibenden UserStory-Produktkatalog als Grundlage für Angebote und KVAs, als Schätzgrundlage und als fachliche Dokumentation voranbringen.
  • Die Einführung der „UserStory“ als Methode der Anforderungsbeschreibung voranbringen.
  • Unterstützung bei den Bewerber-Interviews für eine Inhouse-Nachfolge
  • Den eingestellten Bewerber einzuarbeiten und schließlich die Aufgaben zu übertragen.
  • Mit weiteren Modulen der Angebotspalette Entwickler oder Vertrieb bei Bedarf unterstützen.

Vorbedingungen

Rahmenbedingungen

  • 3 – 3,5 Tage pro Woche über einen Zeitraum von 2 Monaten (Verlängerung auf beidseitigen Wunsch ist natürlich möglich)
  • Vor-Ort-Präsenz während mindestens 2,5 Tagen
  • Von Montag bis Freitag asynchrone Erreichbarkeit via Telegram, WhatsApp oder Slack zwischen 9:00 Uhr und 18:00 Uhr mit Reaktionszeit < 2h

Ergebnisartefakte

  • Ein Backlog, das die aktuellen Kunden-, Produkt- und Entwicklungsanforderungen enthält
  • Eine Entwicklungsabteilung, die einen großen Schritt vorwärts gemacht hat, gemäß der Definition of Done am Ende des Sprints abzuliefern
  • Ein eingespielter Ablauf der vereinbarten agilen Meetings
  • Ein deutlich fortgeschrittener und von den Entwicklern geschätzter Katalog mit Produkt-Features
  • Deutlich gewachsenes Verständnis auf Seiten des Vertriebs, Anforderungen in Form von UserStories zu beschreiben
  • Ein eingearbeiteter Nachfolger, sofern der Auswahlprozess erfolgreich war

 

Kurzer theoretischer Exkurs

Facilitator vs. Product Owner

Facilitatoren aka „Scrum-Master“ sind die Verteidiger der agilen Denkweise, tragen die Verantwortung für den Agilen Prozess und dessen Implementierung. Sie unterstützen das Team, ermuntern dazu, an sich und am Prozess** zu arbeiten und beides zu verbessern, beseitigen Hindernisse, moderieren Meetings und schützen das Team vor unberechtigten Eingriffen.

Als Product Owner wiederum stehen Sie genau in der Mitte der IT-Unternehmung. Auf der einen Seite steht der Vertrieb, der verkaufen will, auf der anderen Seite steht der Produkt-Manager, dem eine ganz bestimmte Produktvision vorschwebt. Auf einer dritten Seite steht das Entwicklungsteam mit seinen Bedürfnissen und seinen Rahmenbedingungen der Umsetzung. Der Product Owner ist der, der alles drei zusammendenkt und daraus ein Backlog formt, das allen drei Gesichtspunkten gerecht wird. Zudem begleitet er das Team in der Umsetzung und hat für spontane Änderungswünsche auf Seiten der Kunden ein offenes Ohr. It’s all about opportunities.

Going agile by implementing the Product Owner

Schon bei dieser kurzen Beschreibung beider Rollen wird deutlich, dass der Product Owner gewissermaßen im Auge des geschäftlichen Orkans steht, während der Facilitator im schlimmsten Falle an der Peripherie damit beschäftigt ist, eine Methodologie akribisch umzusetzen.

Wenn man Agilität entlang der Figur des „Scrum Masters“ einführt, ist das vielleicht am Ende so, als würde man mit dem Anstrich und der Inneneinrichtung des Hauses anfangen, bevor man Wände einreißt, neue Wände einzieht und den Wintergarten anbaut? In diesem Paket möchte ich es andersherum versuchen.

 

* Ich will methoden-agnostisch bewusst nicht „Scrum Master“ sagen.

** Im Falle von Scrum bezieht sich das noch um einiges enger darauf, was denn gerade in der aktuellen Version des ScrumGuide niedergeschrieben steht. Natürlich vermarktet sich eine Methode besser, wenn man durch „Verbesserungen“, selbst wenn sie nur in ausgetauschten Worten liegen, neue „Nachrichten“ generiert, die sie im Gespräch halten. Zudem ist es natürlich für einen Markenkern sehr hilfreich, genau zu definieren, was „Scrum“ ist und was nicht.
Für eine reflektierte agile Denkweise ist beides eher hinderlich als hilfreich. Entsprechend halten einige Agile Coaches Scrum für „zu formal“ und empfehlen, mit der Methode umzugehen wie mit Fahrrad-Stützrädern: sie im Zweifel einfach wegzulassen und sich auf den ursprünglichen Auftrag zu besinnen, basierend auf den agilen Prinzipien Software zu entwickeln.

Kommentar verfassen