von Christina Halbe

Warum nur der CPO die Effektivität von Produktteams sicherstellt (Agile Tretmühle Part III)

 

Und plötzlich wurde alles anders.

“Wir führen jetzt Scrum ein und dazu passen keine abgetrennten Büros mehr!”

So hart bin ich vor einigen Jahren selbst in die agile Welt eingeführt worden – Schwierigkeiten vorprogrammiert.

Wenn Unternehmensmaßnahmen auf mangelnde Vorkenntnisse zu Scrum und unterschiedliche Generationen an Mitarbeitern treffen, birgt das eben immer Konfliktpotenzial.

In diesem Beitrag teile ich daher einen Einblick in das Scrum-Framework und:

  1. warum es wichtig ist, die Komponente CPO (Chief Product Officer) einzublenden,
  2. warum in deutschen Vorständen ein Gespür für Kundenbedürfnisse etabliert werden muss

Hinweis: Dies ist der dritte Beitrag zur Serie “agile Produktentwicklung”.

Beitrag 1 beschreibt die strategische Ebene – Finde heraus, warum agile Teams in einer Tretmühle stecken bzw. wie du interne Hürden besser erkennst.

Beitrag 2 zeigt dir Lösungswege, wie du für mehr Effektivität in agilen Produktteams sorgst.

Beitrag 3 ist ein Scrum-Reality-Check: Welche Rolle sollte ein Chief Product Officer im Unternehmen einnehmen und wie etablierst du ein Gespür für Kundenbedürfnisse auf C-Level?

Scrum-Reality-Check: Theorie vs Praxis

Das heiß geliebte Büro, eine Oase und auch ein bisschen Status musste also weichen, aber ok.

Erst wurden “Wände eingerissen” und dann Trennwände mit Akustikisolierung an Tischgruppen installiert.

Nach großen Anlaufschwierigkeiten und vielem selbst googlen (damals mit noch wesentlich weniger Inhalten zu dem Thema als heute), freundeten wir uns mit dem an was da “eingeführt” wurde.

Die Euphoriephase fand leider ein jähes Ende, als die Backlogs immer voller und die Business Cases immer optimistischer gerechnet wurden.

 

“Viele haben vor Scrum nie gelernt so frei und selbstbestimmt zu arbeiten. Ziele müssen vorgegeben, aber der Weg diese bestmöglich zu erreichen muss selbst gefunden werden.”

Rainer GilbertRainer Gibbert – Leitung Privatkunden starfinanz, Gründer und Autor produktbezogen

 

Das Management fing somit wieder stärker an zu steuern und erteilte genaue Vorgaben. Der Flow und auch das Selbstmarketing des Teams waren nicht mehr da. Reviews fanden kaum bis gar nicht statt und die Teilnahme von Stakeholdern war dürftig. Es war nicht so richtig klar, worauf wir wirklich hinarbeiten sollten – das Ziel fehlte.

Im Status Quo Agile 2020, eine Studie, die von der Hochschule Koblenz durchgeführt wird, ist ein Problem noch immer sehr deutlich. Die TOP-Gründe gegen die Verwendung agiler Methoden sind Interne Prozesse/Rahmenbedingungen, Know-how und das Top-Management bzw. Unternehmensvorgaben zur Methodik”.

Balkendiagramm mit Gründen gegen Agile Ansätze
Abb. Gründe gegen die Verwendung agiler Ansätze – Studie Hochschule Koblenz

Es gibt natürlich mehrere Ansatzpunkte und Blickwinkel um diese Herausforderungen zu lösen.

Ausschließlich das Management für diese Sackgasse verantwortlich zu machen, wäre sehr einfach und vorschnell gedacht.

Es ist eine Wechselwirkung.

Produktteams als auch Management haben darauf Einfluss und tragen Verantwortung, wenn es mit Scrum nicht so anläuft wie gedacht. In dieser Wechselwirkung fehlt es häufig an Kommunikation und einem einheitlichen Verständnis.

Oftmals führen falsche Erwartungshaltungen und eine schlechte Anpassung an die eigenen Anforderungen zum Scrum-Frust. Theorie und Praxis driften anschließend weit auseinander.

Wie wir im Team und in der Theorie Scrum definierten:

“Mit Scrum erschafft unser Team Stück für Stück ein potenziell nutzbares Produkt. So wird ein kontinuierlicher Fortschritt erreicht und Anforderungsänderungen fließen kontrolliert in Projekte ein.”

Das Team sollte mitentscheiden dürfen, Verantwortung tragen und vor allem sollten Entscheidungen und Umsetzungskraft deutlich schneller werden. Das klang alles wirklich gut.

Weitere Scrum-Vorteile, die wir auch für uns identifizierten:

  1. Wir würden als Team einen echten Wertbeitrag leisten, den das Management erkennen und verstehen kann.
  2. Wir würden mit dem Management zusammenarbeiten und gemeinsame Ziele erreichen.
  3. Wir würden das Gespür für die echten Kundenbedürfnisse ausleben und nicht einzelnen KPIs für die jeweiligen Teams hinterherjagen.
  4. Der Graben und das Gefühl von “die da oben” und “wir da unten” würde der Vergangenheit angehören.

Anschließend war es jedoch zur Normalität geworden, bei der Sprint-Planung und in den Priorisierungsrunden immer neue Themen in den Sprint “gedrückt” zu bekommen.

Was war passiert?

Wie sich Scrum im Alltag anfühlte:

  1. Der Wertbeitrag war nicht sichtbar.
  2. Jeder arbeitete bzw. kämpfte für seine KPI und setzte Wünsche oder Promo-Aktionen “von oben” um.
  3. Die Zusammenarbeit unter den Teams fand nicht wie erhofft statt.
  4. Wir hatten keine Zeit mehr uns mit Kundenbedürfnissen und echten Nutzerproblemen zu beschäftigen.
  5. Wir arbeiteten nun autark, was sich vor allem darin zeigte, dass wir uns mit möglichst wenig Leuten abstimmen wollten und Silos entstanden.

Das Ergebnis: keine Erfolge, nur Arbeit: wir produzierten ganz klar Output, aber ehrlicherweise zu wenig Outcome, mit Folgen.

Der Frust ließ also nicht lange auf sich warten. Scrum als Methode zu hinterfragen natürlich auch nicht.

Scrum-Frust im Alltag: Wenn das Wissen um kundenzentrierte Geschäftsmodelle im C-Level fehlt

Nach meiner offiziellen Schulung und Zertifizierung zum Scrum Master, konnte ich mir eingestehen, dass der Scrum-Frust nicht berechtigt gewesen ist.

Scrum ist eben “nur” ein Framework, welches ich erfreulicherweise auf meine Situation und Bedarf anpassen kann und muss. Es soll dabei helfen, wie wir etwas machen, und sagt erstmal nichts über den Inhalt aus.

Was nützt das Probieren von zig Techniken, wie ich meinen Backlog priorisiere, wenn anschließend immer davon ausgegangen wird, dass sowieso die richtigen Themen dort drin stehen?

Aus dem Management begegnen wir hier zuweilen einem starken Ohnmachtsgefühl oder das genaue Gegenteil – einer Rückkehr zu einengenden Vorgaben und einer harten KPI-Steuerung.

 

“Wenn im Leadership keine Leute sitzen, die Scrum in der Tiefe verstanden haben, dann ist es ungleich schwerer es zu etablieren.”

Timo Bolse Head of Product consumer and new business ebayTimo Bolse, Head of Product Consumer and New Business, ebay

Um aus dieser Mühle rauszukommen und ein Signal in Richtung Teams zu senden, ist es erstmal wichtig sich zu fragen, ob denn überhaupt jemand in der Geschäftsführung aus der aktiven Produktorganisation kommt und wie man die Arbeitsweisen und Resultate verbessert.

Kennst du diese Aussagen und Gedanken?

  1. Ich weiß nicht so richtig woran die Teams arbeiten. Ich muss die machen lassen, Scrum sagt das ja so.
  2. Zu Reviews gehe ich nicht. Ich habe keine Zeit dafür und die Inhalte sind meistens nicht interessant für mich.
  3. Das habe ich in einem Vortrag letztens gesehen, dass sollten wir sofort umsetzen.
  4. Wir benötigen klare Zahlen, der Vorstand hat gesagt, es müssen neue Entscheidungen zu Team-Steuerung getroffen werden.
  5. Das Produkt muss irgendwie “kundenzentrierter” werden.

Diese Aussagen fühlen sich bestimmt sehr unbefriedigend an und gefühlt kommt man aus diesem Dilemma gar nicht raus.

Aber es gibt eine Rolle, die diese Hürden und Probleme intern löst: der Chief Product Officer.

Product & Management-Skills verknüpfen: Was der Chief Product Officer bringt

Wie man diese Position bezeichnet, wird natürlich von der Unternehmensgröße und weiteren Strukturen abhängen.

Eine mögliche Option ist beispielsweise “Chief Product Officer”.

 Ganz konkret wäre seine Aufgabe ein abstraktes Leitbild vorzugeben und damit eine der Lücken zu füllen, die Scrum bewusst freigelassen hat um individuelle Lösungen zu ermöglichen.
Wir müssen jemanden haben der das gesamte Produkt im Blick hat und nicht nur ein Chapter. Eine Rolle, die nicht “nur steuert”, sondern das Produkt wirklich weiterentwickelt und im besten Fall aus der Praxis weiß, wie dies funktioniert.

Eine Position, die neue Ansätze und Entscheidungen auf Managementebene auch vertreten kann und gleichzeitig in der Lage ist, die Messung des Wertbeitrags der Produktteams zu verändern.

Ein echter Kommunikator, der das Team wieder in eine gemeinsame Richtung blicken lässt, der Raum für die Ideation Phase gibt, um zu verstehen, was der Kunde/Markt wirklich will und benötigt.

Eine Rolle, die über den gesamten Product Teams steht und direkten Kontakt zur Geschäftsführung hat, im besten Fall sogar Teil der GF ist, und nicht “nur” ein “HEAD of”.

Besonders diese Kombination aus Produkt- und Managementskills, gepaart mit einer motivierenden Persönlichkeit ergeben gleich mehrere Vorteile:

  • Ich habe einen klaren Verantwortlichen
  • Eine Ownership mit Fokus auf das Ziel
  • Einen klaren Ansprechpartner
  • Einen Stellvertreter im Management und der damit verbunden Umsetzungskraft – auch für Veränderungen

Der CPO gibt das Fernziel vor, das erreicht werden soll und aus der die Product Owner nach dem Pull-Prinzip die Arbeit der Teams ableiten können. Denn wie oben beschrieben, müssen vor allem bei mehreren Scrum-Teams Fernziele klar sein, damit alle in die gleiche Richtung blicken und so auch zusammenarbeiten.

Diese Konstellation ist im Rahmen des Frameworks zulässig, da die Vision zwar erwähnt wird, aber nicht festgelegt ist, wer ihr Owner ist.

Scrum Erfolgsfaktoren: Wo stehst du wirklich?

“Wer hat bei uns das gesamte Produkt im Blick?”

Wenn wir die Steuerung und Zusammenarbeit der Teams nicht ändern, kocht jeder sein eigenes Süppchen und wir kommen nicht weiter. Wir werden immer wieder neue Arbeitsweisen ausprobieren, aber wenig die Inhalte unserer Arbeit hinterfragen.

Die Teams würden immer autarker und dies vor allem bezogen auf die Richtung in die sie blicken. Themen die über viele Chapter hinweg umgesetzt werden müssten, werden fast unmöglich. Die Kommunikation unter den Teams würde weiter leiden und damit vor allem das Lernen von und miteinander.

Wo stehst du wirklich:

  1. Werden deine Kunde gefragt, was sie wirklich brauchen bzw, welche Nutzerprobleme sie haben?
  2. Ist das Produkt selbst bis in die Geschäftsführung vertreten?
  3. Wird diese Executive Vision mit der praktischen Arbeit an der Basis verknüpft?
  4. Findet echte Kommunikation statt oder prallen Generationen und Arbeitsstile aufeinander?

Im nächsten Blogpost werde ich nochmal auf das Thema Wechselwirkung von Produktteams und Management eingehen. Da du jetzt gelesen hast, wie die Veränderung vom Management ausgehen kann, schauen wir uns nächstes Mal an, welche Maßnahmen dein Produktteam einsetzen kann.

Was sind deine Erfahrungen in der Steuerung der Produktteams? Ich freue mich auf den Austausch.

Christina Halbe

Christina ist Senior Consultant bei konversionsKRAFT und zertifizierter Scrum Master. Davor war sie in einige Jahre in mehreren Unternehmen als Product Owner und Scrum Master tätig. Ihre Praxiserfahrung lässt sie täglich in die Beratung ihrer Kunden einfließen. Ihr Ansatz basiert dabei auf der Zusammenführung agiler Methoden und Nutzerzentrierung mit dem Ziel der Wertbeitragssteigerung.

Frage zum Artikel? Frag den Autor!

1 Reaktion auf „Warum nur der CPO die Effektivität von Produktteams sicherstellt (Agile Tretmühle Part III)

  1. Super geschrieben

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.