Tag Archives: Product Owner

Agile Breakfast Konstanz – Definition of Ready

Posted on by

Vor einigen Tagen hatte ich die Gelegenheit auf dem 4. Agile Breakfast in Konstanz einen Vortrag zum Thema “Definition of Ready” zu halten. Das Agile Breakfast wird von der Scrum Usergroup Lake Constance (SUGLC) organisiert, findet in Konstanz im Wasserturm (wunderschöne Aussicht auf den Bodensee!) und wurde auch dieses Mal von der Firma Sybit gesponsert.

Verbreitung der Definition of Ready

Viele Scrum Team kennen die “Definition of Done”, in der definiert wird, in welchem Zustand ein Inkrement den Sprint verlässt. Laut Jeff Sutherland wenden diese jedoch nur ca. 50% aller Teams konsequent an. Die” Definition of Ready” (Definition, in welchem Zustand eine Story den Sprint betritt) ist jedoch deutlich weniger Team bekannt. Nur ca. 1% aller Scrum Teams weltweit wenden eine Defnition von “Fertig für den Sprint” konsequent an.

clip_image001

Die inkonsequente Anwendung ist erstaunlich, da die Definition of Done als auch die Definition of Ready das Potential haben die Produktivität von Teams zu verdoppelt. Jeff Sutherland fasst dies unter dem Begriff “Hyperproductive Scrum Teams” zusammen. Zusammen mit einer echten Selbstorganisation, bietet die konsequente Anwendung von DONE und READY das Potential die Produktivität um den Faktor 4-8 zu erhöhen!

Continue reading →

Prophet im eigenen Lande …

Posted on by

Es gibt doch das Sprichwort, dass der Prophet im eigen Land nicht viel gilt. Irgendwie fühle ich mich so, nachdem ich die Excel-Tabelle von Jeff Sutherland gesehen habe.

Ein ähnliches Planungswerkzeug habe ich zusammen mit ein paar anderen POs vor fast zwei  Jahren bei unseren Teams eingeführt und im Allgemeinen sehr gute Erfahrungen damit gemacht. Unser Werkzeug war nicht ganz so detailliert, hat aber stets seine Aufgaben erfüllt.

Leider konnte es sich auf Grund erheblichen Widerstands von “Traditionalisten” (und einiger externer Berater) nicht durchsetzen. Naja, vielleicht lernen sie nun von Jeff, dass Excel nicht böse sein muss, und dass eine genauere Betrachtungsweise der Teamzusammensetzung in der Vergangenheit ein relevanter Parameter für die zukünftige Velocity sein kann.

Sweden-Nordic-Museum-King

Urlaub? Warum soll ich Urlaub berücksichtigen – wir mitteln einfach über das ganze Jahr!

Wunderbar, wenn es fixe externe Termine gibt und man frühzeitig wissen muss, ob diese eingehalten werden können.

Alle weiteren Kommentare verkneife ich mir jetzt.

Scrum User Group Karlsruhe: Die Leiden des Scrum Product Owner

Posted on by

Das letzte Treffen der Scrum User Group Karlsruhe in 2009 beschäftigte sich mit der Rolle des Scrum Product Owners. Genauer: “Herausforderungen für unseren Product Owner”.

Zunächst wurde darüber diskutiert, wie/ob der Product Owner (PO) zum Scrum Team gehört. Relativ schnell wurde die allgemein akzeptierte Formel “Scrum Team = (Dev) Team + SM + PO” übernommen.

Auf die Frage, wer bereits als Product Owner arbeiten konnte, gab es nur wenige Meldungen. Die Verteilung dürfte ähnlich wie bei den Zertifizierungen sein: Viele ScrumMaster, wenige ProductOwner.

meckpomm1

Danach wurden typische Herausforderungen für den Product Owner gesammelt:

Die Punkte wurden auf Karten geschrieben und dann inhaltlich gruppiert. Die größte Gruppe stellten dabei die organisatorischen Herausforderungen bzw. Rahmenbedingungen da:

  • Am meisten kritisiert: Der Product Owner hat keine echten Entscheidungsbefugnisse (ProductOwner != Gold Owner).
  • Teilweise sind POs nur Verwalter eines Team-Backlogs, d.h. die Rolle des POs wird ad absurdum geführt. Sehr beliebt v.a. bei Multi-Projekt-Umgebungen.
  • POs müssen die Arbeitsweise des Scrum Teams bzw. das Projekt nach außen vertreten. Hierbei spielen oft fixe Termine für Releases, Budgets (EUR, PT) und Standards (Norm xyz) eine wichtige Rolle. Die äußeren Zwänge in Einklang mit der Sichtweise innerhalb des Scrum-Prozesses zu bringen bleibt oft alleine die Aufgabe des PO.
  • POs bekommen in ganzer Schärfe den Wettbewerb zu spüren, ohne den Druck weitergeben zu können. Letztendlich sind Product Owner die Schnittstelle zur Welt außerhalb des Scrum-Teams.
  • …

Diese größte Gruppe wurde klassifiziert als “Pech, das ist der Job des Product Owners” ;-)

Augenmerk wurde dann auf Herausforderungen gelegt, die direkt beeinflusst werden können. Dazu gehören:

  • Überforderung des Product Owners durch die vielfältigen Aufgaben. Der Product Owner sollte bei größeren Projekten nicht alleine agieren, sondern es soll eine Hierarchie von Product Ownern geben (PO of PO)
  • Product Owner sollte ein gutes technisches Verständnis haben
  • Product Owner sollte nicht zu viel technisches Verständnis haben (Oh! Ein Widerspruch)
  • Der Product Owner soll direkt mit dem Kunden interagieren, aber im besten Fall auch immer für das Team erreichbar sein. Problematisch, wenn der Kunde relativ weit entfernt ist.
  • … sowie noch eine große Anzahl weiterer Themen (hat die jemand mitgeschrieben?)

Letztendlich wurde allen Beteiligten schnell klar, welche Anforderungen die Rolle des Product Owners stellt und das die Arbeit als PO voll widersprüchlicher Zielsetzungen sein kann (Team coachen ja/nein, einmischen bei technischen Fragestellungen ja/nein, Rahmenbedingungen verändern wollen ja/nein, Team hinterfragen ja/nein, …).

Meiner Meinung nach verbirgt sich jedoch hinter vielen Wiedersprüchen auch eine Verantwortung, welche zum großen Teil vom Team übernommen werden müsste. Das Team darf nicht eindimensional auf der technisch besten Lösung beharren, sondern muss die Rahmenbedingungen – auch die wirtschaftlichen – verstehen und ist deshalb in der Pflicht Alternativen anzubieten und auf mögliche Auswirkungen hinzuweisen. Leider sind die meisten Entwickler-Teams hier sehr zurückhalten und ziehen sich auf eine vereinfachte Sichtweise zurück.

Gerade bei Teams, in denen die Schlüsselrolle des POs geschwächt ist, fehlt den Team-Mitgliedern der Ansprechpartner für schnelle Entscheidungen und sie ziehen sich zunehmend in die Passivität oder Feuerwehraktionen zurück. Genau so darf Scrum natürlich nicht laufen, dürfte aber zu  der verbreitesten Form der Scrum Implementierung zählen ;-(

Scrum Product Owner – eine sehr anspruchsvolle Aufgabe

Posted on by

Heiko arbeitet seit einiger Zeit als Product Owner und erlebt damit die Herausforderungen dieser Rolle gerade selbst. Seine Erkenntnis: Die Rolle des Product Owners wird zur Zeit unterschätzt. Dem kann ich nur zustimmen und ich habe ja auch bereits darüber geschrieben.

Für mich dient die Rolle des POs in Scrum leider zu oft als schwammige Wolke hinter der sich die böse komplexe Welt verstecken lässt. Letztendlich werden dem PO – und nicht dem Team oder dem Scrum Master – die wirklich schwierigen Entscheidungen auferlegt. Der Product Owner muss entscheiden, welche Dinge getan werden sollen – und welche eben nicht (was meist eine noch schwerere Entscheidung ist).

Die Anforderungen an den Product Owner sind sehr hoch: Wissen in den Bereichen Projektmanagement, Produktmanagement, Vertrieb, Marketing, Prozesse, Emtwicklungsmethodik (um die richtigen Fragen zu stellen) und Business Development. Kommunikation ist wichtig und die Fähigkeit ein Ziel formulieren und verfolgen zu können.

Stellt doch mal beim nächsten Treffen eurer lokalen Scrum-Gruppe – oder bei einem größeren Scrum-Event – die Frage, wer von den Anwesenden die folgenden Voraussetzungen erfüllt:

  • Aktive Ausübung der Rolle Product Owner
  • Kenntnisse in den Bereichen Business Development, Vertrieb, Marketing, Produktmanagement, Projektmanagement (alternativ: Zuverlässiges Bauchgefühl)
  • Kommunikationsgenie & Motivationsgott
  • Ahnung von Entwicklungsprozessen und ein IT-Hintergrund (vgl. “Chief-Engineer” von Toyota)
  • Echter Gold-Owner (ohne wegen 10 TEUR zum Vorgesetzten laufen zu müssen)
  • Angestellter
  • Keine Überlastungserscheinungen ;-)

Ich vermute, dass keiner der Anwesenden diese Anforderungen erfüllen kann – aber probiert es doch einfach selbst aus ;-)

Investitionen in einen Product Owner

Posted on by

Joe Little schreibt in “Should we invest in a better Product Owner?” …

If you assume that a better Product Owner can:
* increase the value of Product Backlog items (stories) by 20% on average
* identify the Pareto curve partially in the Product Backlog, so that an 85-33 rule applies
* and if we assume that the team costs about $1,000,000 per year (all-in) and delivers, before the better PO, about $3,000,000 per year…

Was ich dazu meine? Der Product Owner kann ganz schön viel Mist bauen und mit den falschen Entscheidungen das Team perfektes “Muda” (Abfall/Quatsch) erzeugen lassen. Geld zum Fenster raus eben. Aber natürlich befindet sich der Product Owner hier in bester Gesellschaft mit anderen Managern.

Jetzt glaubt Joe allerdings, mit einem Kurs zum Certified Product Owner wäre das Problem gelöst:

So, how much could you afford to invest in that better PO to get those results? Probably more than $1,500 (eg, for a Certified Product Owner course).

Ok,ok – der Realitätsverlust ist doch nicht so groß:

… I suspect that most Product Owners need more than just the course to get those results …

Den nächsten Ansatz finde ich allerdings sehr gut: Coaching!

… perhaps some coaching from someone really good …

Leider gibt es dies zu selten. Ich meine das Coaching, “someone really good” und natürlich jemanden der wirklich gut ist und Zeit für Coaching hat ;-)

Jup, und er hat Recht – wenn der PO in einem Cost Center angesiedelt ist, dann ist auch das problematisch. Man denkt nicht wirklich in Business Value sonder erfüllt andere Zielvorgaben.

  And thus they have no concept of BV delivered by IT, much less metrics around that.

Was ich auch immer wieder erlebe:

  • Product Owner aus dem Marketing / Vertrieb ohne Einsicht, dass beispielsweise auch die technischen Aspekte berücksichtigt werden müssen (technical debt) um auch langfristig gute Ergebnisse zu erzielen
  • Product Owner die aus der IT Abteilung kommen ohne echtes Verständnis für Business Value und den treibenden Kräften in einem Markt.
  • Product Owner die entweder die Ideen hinter Scrum nicht verstehen (wollen) oder ganz und gar an den Lippen freiberuflicher Berater hängen.

Was hilft? Ausbildung in den Bereichen Marketing, Vertrieb, IT/Informatik und allgemeine Betriebswirtschaft. Danach kontinuierliches Coaching und Weiterbildung. Dafür muss der PO von der Persönlichkeitsstruktur her geeignet sein. Die Anforderungen hat IMHO Christian Schmidkonz in seinen Präsentationen (Beispiel) zur Scrum-Einführung bei der SAP gut zusammengefasst. Personen mit solchen Skillsets gibt es nur selten – und diese sind meist freiberuflich tätig.

Zusammenfassung

Ein guter Product Owner ist ein kritischer Erfolgsfaktor, schon alleine weil ein schlechter PO alle Stärken eines Spitzenteams und eines hervorragenden Scrum Masters zunichte machen kann.

Keine Tasks mehr in Scrum – nur noch Stories?

Posted on by

Ron Jeffries scheint kein Freund von Tasks in Scrum zu sein und schlägt vor Stories in einem Sprint nicht mehr in Tasks aufzubrechen. Die Ideen wurde von Kelly Waters aufgegriffen. Kelly möchte durch Verzichten auf Stories u.a. die Prozesskosten senken.

Ja, das Ziel die Prozesskosten zu senken verfolge ich auch – trotzdem ist das Planning 2, in dem die ausgewählten Stories in Tasks aufgebrochen werden, den Aufwand in den meisten Fällen mehr als wert. Warum?

Einige Gründe Pro Stories / Pro Planning 2 sind:

  • Plausibilitätschecks: Wenn eine Storie in Einzelteile zerlegt wird, kommt es immer wieder mal vor, dass ein Risiko bzw. ein erheblicher Mehraufwand identifiziert wird.
  • Abhängigkeiten: Ja, ich weiß. Abhängigkeiten sollen schon auf Story-Ebene reduziert bzw. eliminiert werden. Wir haben aber beispielsweise eine extreme Abhängigkeiten zu internen Zulieferern (Termine, Qualität) und zu unserem Betrieb. Abhängigkeiten werden auf Task-Ebene schneller gefunden und sind besser zu managen.
  • Schwerpunkte in der Entwicklung: Obwohl in Scrum Generalisten bevorzugt werden, hat doch jeder Entwickler seine Stärken und Schwächen. Dies kann man in der Planung ebenfalls besser berücksichtigen. Nicht immer ist jeder verfügbar, nicht immer hat jeder alle Themen im Blickfeld. Ein TASK-Board hilft dabei.
  • Task-Breakdown: Auch wenn ein Task-Breakdown anscheinend immer unbeliebter wird und letztendlich auch die DONE-DONE Scrum Stories das Sprint-Ergebnis ausmachen, ist ein Task-Breakdown ein wichtiger Indikator. Ein Hilfsmittel, um zur rechten Zeit die rechten Fragen zu stellen. Die Antwort (vom Team) kann dann immer noch sein „passt schon“, aber es kommt auch immer wieder mal vor, dass auch im gesamtem Team der Optimismus stärker ausgeprägt ist als der Realitätssinn.

Trotz all dieser wichtigen Aspekte vom Planning 2 hat Kelly wohl Recht, wenn er behauptet, dass Planning 1 der wichtigere Teil ist: Anforderungen stellen, verstehen, priorisieren. Normalerweise nehme ich als Product Owner auch nicht am Planning 2 teil. Falls das Team jedoch Rückfragen hat oder die Analyse (Zerlegung der Stories in Tasks) den Umfang von Planning 1 in Frage stellt, dann wird nochmals mit mir über den Umfang des Sprints geredet.

Scrum is not for everyone

Posted on by

In einem Artikel schreibt Clinton Keith über ein Aspekt von Scrum, der gerade in der deutschen Konsenskultur ausgeblendet wird: Mit Freiheit kommt Verantwortung, mit Verantwortung gehen auch unangenehme Entscheidungen einher.

In seinem Artikel “Scrum is not for everyone“geht er darauf ein, dass

  • Teams Verantwortung übernehmen müssen
  • Sich selbst organisieren
  • zur Selbstorganisation auch die Entscheidungsfreiheit gehört, wer Mitglied des Teams ist

Zitat:

Occasionally, the teams will “self organize people off the team”. This occurs between Sprints when teams are allowed to change their membership. Poor performers or poor team players can be “voted off the island” by the rest of the team.

Ich selbst kenne bisher kein deutsches Unternehmen, in dem Teams diese Freiheiten haben (die Verantwortung natürlich schon). Ich vermisse diese Entscheidungsfreiheit aber auch bei der Zusammenarbeit ProductOwner <-> Team. Ein PO sollte IMHO grundsätzlich das Recht haben, die Zusammenarbeit mit einem Team abzulehnen, wenn dieses nicht performt oder es zu gravierenden Problemen kommt. Das Team wiederum müsste das Recht haben die Zusammenarbeit mit einem schlechten PO abzulehnen.

Wie ist das bei euch geregelt? Habt ihr solche Möglichkeiten?

Der Product Owner

Posted on by

Optimale Arbeitsweise

Boris erläutert seine Sicht auf die Rolle des Product Owners.

Laut ihm gibt es zwei Modelle:

Modell 1 (Jeff Sutherland)

  • Der PO arbeitet mit Business Analysts zusammen und kann das Team detailliert informieren.
  • In diesem Szenario ist der PO relativ nahe am Team.

Modell 2 (Ken Schwaber)

  • Der PO fokussiert sich auf die finanziellen Aspekte, ist relativ weit weg vom Team.
  • In diesem Modell gibt der PO nur das Ziel vor und das Team muss sich mit Business Analysten abstimmen um Details zu klären.

In beiden Modellen wird der PO an dem finanziellen Erfolgs des Produktes gemessen, genau das soll sein Fokus sein. Er muss wissen wohin die Reise gehen muss – er muss nicht jedes Detail kennen. Dafür gibt es Business Analysten. Ein PO arbeitet 100% in seiner Rolle als PO und ein Entwicklungsteam hat genau einen PO.

Bekannte Modelle aus der Praxis

Leider habe ich noch nie eines der oben genannten Modelle in der Praxis beobachten können. Vielmehr ist der PO wohl die Rolle in Scrum, die am stärksten von der Umwelt unter Druck gesetzt werden kann. Oftmals soll es der PO leisten aus der Scrum-Welt in die “andere Welt” zu übersetzen (Festpreisangebote, Ressourcenplanung). Aus diesem Spannungsfeld leitet sich wohl auch die Forderung vieler Scrum-Evangelisten ab, dass die ganze Organisation agile werden muss.

Entscheidungsfindung

Zu oft ist der PO jedoch eben nicht mit echter Entscheidungsbefugnis ausgestattet sondern reportet an ein Steering Committee oder an einen übergeordneten Manager. Dieses gibt dann die entsprechenden Grundsatzentscheidungen vor. Um eine Entscheidungsgrundlage zu schaffen ist der PO damit beschäftigt den aktuellen Stand und den Blick in die Zukunft in geeigneter Form zu visualisieren.

Multi-Projekt-Scrum

Es gibt beim Multi-Projekt-Scrum die Konstellation, dass der PO gleichzeitig der PM (Project Manager) mehrere im Team bearbeiteter Projekte ist und weitere Aufgaben von anderen PMs (Projekten) an ihn herangetragen werden. Die Stories muss er (zusammen mit dem PMs) bewerten, in eine entsprechende Reihenfolge bringen und dann dafür die Freigabe bekommen.

Multi-Projekt-Scrum ist per se recht problematisch, ich behaupte jetzt einfach mal, dass ein Multi-Projekt-Team auch nie “hyperproduktiv” werden kann. Es gibt zuviele Scope-Wechsel, selbst wenn der PO es schafft die Sprints mit so wenig Projekten wie möglich zu bestücken. Es gibt auch zuviele Stakeholder, die von aussen auf den PO und das Team einwirken – egal wie sehr sich der PO und der SM anstrengen – das Team wir doch immer wieder abgelenkt.

Vielleicht schreibe ich bei Gelegenheit mal etwas mehr über die ganzen Herausforderungen und Gefahren beim Multi-Projekt-Scrum. Interesse?

Risiko: PO als Verwaltungsjob

Gerade in Team die mehrere Projekte und zusätzlich Supportaufgaben übernehmen müssen, ist eine aussagekräftige Planung über die nächsten beiden Sprints hinaus eine große Herausforderung (die nie entsprechend gewürdigt wird). In dieser Form degeneriert der PO schnell Richtung “Team- und Storyverwalter”. Das muss erkannt werden und der PO muss aktiv gegensteuern und sich auch gegen viele Widerstände durchsetzen können. Hierzu benötigt er den Rückhalt seiner Vorgesetzten, d.h. er muss (uneingeschränktes) Vertrauen geniessen.