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.

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!

Stichprobe: Definition of Ready in der Community

Eine Stichprobe in der größten Scrum Mailingliste “scrumdevelopment” (Yahoo Group) bestätigt jedoch, dass gerade die Definition of Ready bei weitem nicht so bekannt ist, wie ihre Effekte nahelegen würden:

• „definition of done“: 1001
• „definition of ready“: 6
• „ready state“: 14

Was versteht man unter “READY”?

Vereinfacht ist eine Story bereit für die Implementierung, wenn die Anforderung verständlich beschrieben wurde und folgende Fragen beantwortet werden können:

Warum?

• Zielsetzung / Problemstellung klar,
• Geschäftswert verstanden

Was?

• Gewünschtes Ergebnis verstanden, Akzeptanzkriterien formuliert

Wie?

• Implementierungsstrategie/-konzept bekannt
• Kosten / Größe bekannt

Wichtig: Zuerst WARUM, dann WAS, dann WIE!

Alternative Erklärung

Roman Pichler, hat sich diesem Thema ebenfalls schon in einem Blog-Artikel zugewandt. Aus seiner Sicht muss eine Story folgende Kriterien erfüllen, um “READY” zu sein:

Klar

• Gemeinsames Verständnis was genau gemeint ist

Testbar

• Es gibt klare Entscheidungskriterien, ob etwas erfolgreich umgesetzt ist oder nicht.

Handhabbar

• Größe muss stimmen (nicht zu groß/klein)
• Komplexität muss handhabbar sein
• Unsicherheit, Abhängigkeiten

Eine teamspezifische Definition of READY listet meist detailliertere kontextbezogene Kriterien auf und dient als Quality Gate, um sicherzustellen, dass nur Stories in den Sprint übernommen werden, die wirklich bereit für die Implementierung sind.

Der Weg zu “READY”

Es ist die Aufgabe des Product Owners sicherzustellen, dass Stories bereit für die Implementierung sind, wenn er sie in einem Sprint umgesetzt bekommen soll. Hierzu arbeitet er mit allen Beteiligten eng zusammen, um von groben Ideen zu klaren – “bereiten” – Stories zu kommen. Gerade bei der technischen Analyse ist auch das Team gefragt, frühzeitig Informationen und Feedback zu liefern.

Ein Blick in das Backlog zeigt dann in etwa folgendes Bild:

Etwas genauer betrachtet, erkennt man, wie im Lebenszyklus von Anforderungen immer mehr Details hinzugefügt werden. Die Details sind meist das Ergebnis von Diskussionen und sollten – je nach Kontext – auch schriftlich festgehalten werden. Hierbei kann eine Vorlage oder eine Checkliste sehr hilfreich sein.

Eine solche Checkliste oder ein Template kann jedoch auch gefährlich sein. Wenn zu viel Augenmerk auf das Dokument und zu wenig auf die Diskussion gelegt wird, nähert man sich schnell dem alten Requirement Engineering an und verliert an Agilität.

Die Präsentation zu diesem Thema werde ich in absehbarer Zeit noch veröffentlichen.

Wenn es wie eine Ente watschelt, wie eine Ente quakt und wie eine Ente aussieht, kannst du es eine Giraffe nennen, aber es ist dennoch eine Ente.

Wir wissen ja: Chaos im Unternehmen ist bekanntlich Folge des bösen und generell untauglichen Wasserfallmodells. Fortschritt durch das neue Vorgehen ist hingegen wissenschaftlich belegt gemäß des Axioms “Tausend Gurus können nicht irren” sowie Beweis durch vollständige Anekdote.

Eine dieser Anekdoten geht wie folgt: Man nehme ein vorzugsweise leicht ausgebranntes Entwicklerteam, schule es ein paar Tage in angenehmer Umgebung durch einen hochmotivierten Scrumverkäufer, zelebriere einen unbelasteten Neubeginn, lasse das Team in Ruhe werkeln und messe sodann die Arbeitseffizienz. Überraschung – die Effizienz steigt! Wer hätte das gedacht? Und wer glaubt, dass ein solcher Versuch etwas nachweisen kann?

Alter Wein in neuen Schläuchen

Es lebe die neue, agile Welt, alles wird gut. Nun, mit Sicherheit wird alles für Autoren gut, denn jetzt kann man viele Bücher füllen mit Dingen, die es alle schon mal gab und jetzt neu erklärt werden müssen.

Ein kleines Wörterbuch für Traditionalisten

Miesmacher, so bin ich eben, Europäer halt: wir vermarkten nicht jeden Pups als wundervoll. Dabei mag ich Scrum. Hassen tue ich die Evangelisten, die olle Kamellen über den Klee loben und sich wundern, warum die Entscheider auf ihren Etagen immer noch so zögerlich sind.

Vertriebs-Bullshit

Ich kann es ihnen nicht verdenken, ich habe selbst genug Genglishen Bullshit gehört und gelesen in den letzten Jahren, als heilige Wahrheit deklariert:

• “Wasserfall ist total veraltet und kann gar nicht funktionieren.”, und
• “CMMI ist überholt. Und mit Scrum hat man CMMI Level 3 ohnehin schon implementiert.”, und
• “Klassische Planung ist deterministisch, deterministische Pläne sind nutzlos, nur agile Methoden können mit Änderungen umgehen.”, und
• “Up-front Requirements können nicht funktionieren. Erzählt lieber eine Geschichte anstelle Anforderungen zu schreiben.”

Was schon eher stimmt

Dabei sind die Aussagen nicht völlig verkehrt, mit etwas Mühe kann man ein paar Körner Wahrheit finden. Legen wir die rosa Brille des Verkäufers ab und differenzieren wir:

• Echte Arbeitsabläufe sind viel turbulenter als Phasenmodelle sie beschreiben; sich sklavisch an Phasen zu klammern ist daher schädlich.
• Scrum ist kompatibel mit den CMMI-Anforderungen und erfüllt viele davon adäquat. CMMI Assessoren lösen sich langsam auch von der Faustregel, im Zweifel einfach alles zu dokumentieren.
• Neuplanung ist seit jeher ein Teil der Planung; anscheinend haben das viele Planer verdrängt. Effizientes Änderungsmanagement ist aber essentiell für effiziente Projekte.
• Man muss nicht alle Anforderungen kennen, um beginnen zu können, aber je früher man klare Anforderungen festhält, desto unwahrscheinlicher werden böse Überraschungen. Um Anforderungen richtig interpretieren zu können, muss man Motivation und Zielgruppe kennen.”

Oooh, das klingt jetzt nicht mehr wirklich spektakulär, dürfte aber vorstandstauglich sein.

Bedeutung von Marketing

Aus eigener Erfahrung weiß ich: Wenn man das Marketing unterschätzt, wird Scrum für praktisch alle Probleme verantwortlich gemacht, die es gibt, inklusive der ausgegangenen Kaffeebohnen. Die wenigsten Probleme sind von dabei Scrum abhängig; schaut man genauer hin (wir haben die rosa Brille ja oben abgesetzt), kann man oft Rahmenbedingungen vorfinden, mit denen man jeden Prozess, und sei er noch so gut, hätte torpedieren können. Da werden Product Owner eingesetzt, die inhaltlich gar nicht verantwortlich waren (also keine “Schweine” im Sprachgebrauch von Scrum, wenn man mal vom Grunzen absieht), Teams mit zig parallelen Projekten überfrachtet, Wander-Stories zwischen den Sprints hin- und hergeschubst, Voraussetzungen für Stories übersehen, oder schlicht Dinge entwickelt, die keiner braucht.

Selbst wenn diese Rahmenbedingungen kommuniziert sind, bleiben Zweifel, auch bei den gutwilligsten Schlipsträgern. Scrum kommt bei ihnen nämlich nicht als sehr “agil” herüber: Wenn man die Regeln strikt handhabt,  dann könnte Vertriebsmanager McNuggets gackern wie er will – seine Abschätzung für ein Angebot bekäme er erst im nächsten Sprint. Freilich: Niemand zwingt einen, Scrum den Buchstaben nach einzuhalten. Ganz positivistisch gesehen: Wenn’s funktioniert ist’s richtig. Doch dazu ein andermal mehr.

Argumente für Führungskräfte

Wenn mich heute Entscheidungsträger zu Scrum befragen, führe ich gerne Argumente der folgenden Bauart ins Feld:

• Scrum ist ein mit geringer Investition zu etablierender Prozess: Die Schulung ist nicht aufwändig und die bestehende Infrastruktur reicht völlig aus.
• Scrum fördert das Arbeitsklima in der Entwicklung; dies verbessert die Attraktivität des Unternehmens auf dem Arbeitsmarkt.
• In Scrum ist das “Mikromanagement” Aufgabe des Entwicklerteams; der Projektleiter wird dadurch entlastet und ist dennoch sehr gut informiert.

Ich habe gute Erfahrungen mit so einer Darstellung gemacht: Budgetverantwortliche denken gerne strategisch und  wirtschaftlich, und von dort muss man sie abholen. Manchmal frage ich mich, was geschähe, wenn die Evangelisten mit solchen Argumenten bewaffnet ins Feld zögen.

Hinweis zum Autor:

Dies ist der erste (und hoffentlich nicht letzte) Artikel unseres Gastautors “Ludi”. Er arbeitet aktuell für ein mittelständisches Unternehmen im Bereich Projekt- und Qualitätsmanagement. Neben seiner Tätigkeit als Product Owner (erfolgreiche Entwicklung eines neuen Produktes) zeichnet er zudem verantwortlich für die Ausgestaltung der nun unternehmensweit geltenden PM-Richtlinien, die Ansätze aus den klassischen Phasenmodellen und den agilen Methoden miteinander verbinden.

Aber “reines” Scrum funktioniert nicht überall. Und “reines” Scrum hat – wie andere “reine Lehren” auch – viele “dunkle” Seiten.

Selbst Evangelisten wie Ken Schwaber gehen auf Probleme bei Einführung von Scrum in Unternehmen ein. Einige der Punkte aus “The Enterprise and Scrum” von Ken möchte ich aus einer eher skeptischen Perspektive kommentieren.

Aus Part I, “Adopting Scrum”:

Staff turnover will occur

Ja, manche Personen möchten nicht mehr Verantwortung und mehr Freiheit. Manche Angestellten arbeiten, um Geld zu verdienen – nicht weil es sich um ihre Berufung handelt. Zugrunde liegt ein Vertragsverhältnis und ein Vertrauensverhältnis. Die Organisation möchte dies nun einseitig ändern. Widerstand wird die Folge sein, Kosten entstehen, Veränderung verlangsamt sich.

Conflict will occur

Veränderungen führen zu Konflikten. Sind alle darauf vorbereitet mit Konflikten richtig umzugehen? Hat die Organisation Antworten auf die Fragen die in den Gesprächen gestellt werden? Hat die Organisation die Kraft die Konflikte zu lösen? Meine Erfahrungen hier sind ernüchternd. Mir ist keine ältere Organisation bekannt, die gut mit Konflikten umgehen kann. Unternehmenspolitik spielt hierbei eine wichtige Rolle. Möchte man dies überwinden, so kostet dies Geld und Zeit. Oft müssen auch Personen im mittleren und höheren  Management ausgetauscht werden.

Product management’s job will change and will be harder

Klar, Scrum verschiebt die wirklich komplexen Entscheidungen dorthin, wo sie hingehören: Zum Management. Die wichtigsten Fragen sind: WAS will ich tun – und vor allem was will ich NICHT tun?

Dafür, dass diese Fragestellungen von zentraler Bedeutung sind, wird die Rolle des PO meiner Meinung nach zu wenig beachtet. Der gestiegenen Verantwortung steht im Allgemeinen leider keine gestiegene Entlohnung gegenüber. Im Grunde ein Verlustgeschäft für die betroffenen Manager – zumindest wenn man nur die finanziellen Aspekte betrachtet und eine mögliche gestiegene Motivation durch schnellere Ergebnisse vernachlässigt.

Meiner Erfahrung nach ist es aber auch häufig so, dass aus verwaltenden Produktmanager einfach verwaltende ProductOwner gemacht werden. Zu häufig ist der PO eben nicht er “Gold Owner” und damit geht viel Einflussmöglichkeit dieser Rolle verloren.

Engineering is accountable for quality

Eine Frage, die ich mir immer wieder stelle: Woher wissen die Techniker, was Qualität ist? Qualität muss im Kontext betrachtet werden. Eine Entwicklung für eine Messepräsentation muss nicht unbedingt wartbar oder performant sein. Für eine Software, die der Grundstein für ein Produkt ist, ist dies jedoch sehr wichtig. Zu oft erlebe ich in der Praxis, dass hier immer mit einem Maß gemessen wird. Technik ist nicht Business, Business soll aber die Richtung (“was”) vorgeben. Wenn Technik dann nur eine Art von Qualität liefern kann, dann ist dies zu teuer und es wird kein Geschäftswert generiert.

Compensation policies need to change

Damit wird Scrum zur Restrukturierungsmaßnahme im großen Stil. Viel Spaß mit dem Widerstand, auf den man treffen wird. Betriebsrat? Gewerkschaft? Sind die Manager wirklich so gut, diese Veränderungen an die Belegschaft zu verkaufen?

Jobs will change

Für Deutschland eine spannende Sache. Veränderung der Stellenbeschreibung bei Festangestellten. Vielleicht wollen diese ihre alte Position behalten und klagen dagegen? Nicht jeder ist mit den Veränderungen einverstanden. Mit Widerstand ist zu rechnen – wiederum muss mit Kosten und Verzögerungen gerechnet werden.

Management’s primary responsibility will shift from command to servant leadership

Das Management wird reduziert auf die Beseitigung von Hindernissen. Hier wird stets davon ausgegangen, dass Selbstorganisation funktioniert. Ich bezweifle dies. Leider sprechen meine Erfahrungen dagegen. Die meisten Teams, die ich kenne, denken zu technisch und zu sicherheitsorientiert. Zu langsam und damit unbezahlbar. Der Grund? Meist Überforderung in Form von Multi-Projekt-Abarbeitung und dauernde Veränderung des Fokus. Ja, ein Management-Problem. Ihr könnt aber sicher sein, dass das Management dies gerne lösen würde – aber nicht kann. Superheld Produktmanager (PO) scheitert an der Realität. Wer hätte das erwartet?

Trotz Selbstorganisation wird im Allgemeinen auch nur der Manager an die Wand gestellt. Single wrinkable neck eben.

Management turnover will occur

Für viele Manager ist der Deal mies: Mehr Verantwortung, mehr Stress und Druck. Weniger Einflussmöglichkeiten. Immer noch im Schussfeld, wenn es Probleme gibt – während die Entwicklung ziemlich geschützt ist. Naja, da kann man verstehen, dass der eine oder andere Manager eine Position vorzieht, in denen er mehr bewegen kann.

Fazit

Aus meiner Sicht sieht das Fazit so aus:

Mit Scrum werden die Defizite einer Organisation deutlich. Jede Organisation hat Defizite und Probleme. Was tun? Ken warnt davor, Scrum anzupassen – da dann die Probleme nicht beseitigt werden. Verständlich – aber auch realistisch? Vielleicht. Wenn man in der Lage ist die Kosten einer Einführung von Scrum (as from the book) zu bezahlen. Falls dies nicht der Fall ist, muss mit Kompromissen gearbeitet werden.

Sorry, wollte euch nicht den Tag vermiesen ;-)

• 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.

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

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

Mike sieht es kritisch, dass in einigen Veröffentlichungen der Eindruck erweckt wird, als ob agile Methoden nur für ein einzelnes kleines Team auf einer einsamen Insel funktionieren würden. Die Beschränkung auf die Beschreibung der Kernkonzepte sei zwar ein guter Ansatz, um die Grundlagen/Konzept zu erklären. Die Wirklichkeit sehe jedoch anderst aus und dies dürfe in Artikeln und Büchern über die agilen Methoden nicht mehr vernachlässigt werden.

Zudem vertritt er die Meinung, dass Agile sehr gut skaliert und deshalb sollte auch mehr darüber veröffentlicht werden.

Beispiel für Skalierbarkeit
Er spricht über ein Projekt mit 700 Personen und wie dieses mit agilen Methoden durchgeführt werden kann.

Zunächst ist es wichtig das übergeordnete Ziel (Vision) durch einen “Chief-Product-Owner” definieren zu lassen. Diese wird dann über eine Hierarchie von Product Ownern in die Teams getragen. Wichtig: Die POs managen das Projekt nicht sondern sind dafür zuständig die Ziele zu formulieren.

Die Teams sind ebenfalls hierarchisch strukturiert, die Koordination der Teams erfolgt durch diese selbst: “… but teams coordinate their work in ways their determine …”.

Mike fasst nochmals zusammen, was nötig ist, damit Teams funktionieren können:

• Geld / Money (Salary, Infrastructure)
• Unterstüzung / Moral Support (Feedback, removing impediments)
• Ziel / Guidance (Vision)

Schätzungen
Im zeiten Teil spricht er Über Abschätzungen und weist darauf hin, dass es für Teams wichtig ist zunächst in relativen Größen zu schätzen. Erst in einem weiteren Schritt können diese Schätzungen dann auf Dauer und Aufwand umgelegt werden.

Seht euch das Video einfach selbst an …

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.