• Scrum Metrics for Hyperproductive Teams: How They Fly Like Fighter Aircraft
• Excel Spreadsheet for Hyperproductive Scrum Teams – very cool! (Link funktioniert nicht?)
• http://agile2010.agilealliance.org/files/session_pdfs/MetricsAgile2010_0.pdf

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.

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.

Related posts:

1. Aufwand, nicht Komplexität
2. Der Product Owner
3. Kundenzufriedenheit vs Kosten

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.

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 ;-(

Related posts:

1. Termine: Scrum User Group Karlsruhe, IT-Projektmanagement Stuttgart
2. Scrum Product Owner – eine sehr anspruchsvolle Aufgabe
3. Investitionen in einen Product Owner

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 ;-)

Related posts:

1. Investitionen in einen Product Owner
2. Scrum User Group Karlsruhe: Die Leiden des Scrum Product Owner
3. Der 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.

Related posts:

1. Scrum Product Owner – eine sehr anspruchsvolle Aufgabe
2. Scrum User Group Karlsruhe: Die Leiden des Scrum Product Owner
3. Der Product Owner

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.

Related posts:

1. Scrum: Einsatz von Jira & Confluence
2. Story Points und Personentage
3. SLM: Noch eine Einführung in Scrum

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?

Related posts:

1. Scrum User Group Karlsruhe: Die Leiden des Scrum Product Owner
2. SLM: Ein paar Gedanken zu Scrum
3. Keine Tasks mehr in Scrum – nur noch Stories?

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.

Related posts:

1. Scrum User Group Karlsruhe: Die Leiden des Scrum Product Owner
2. Investitionen in einen Product Owner
3. Scrum Product Owner – eine sehr anspruchsvolle Aufgabe