Mein erster Lean Coffee für Product Owner

Zum 61. Mal fand am 15. März 2019 der “Lean Coffee für Product Owner” statt. Im Sevenval-Büro am Dom diskutierten wir mit unseren Gästen über spannende Fragen rund um das Thema Projektmanagement. Ein Rückblick von Torben Berkemeier.

Für mich persönlich war es der erste “Lean Coffee” und gerade weil ich in den vergangenen Monaten erste Erfahrungen im Projektmanagement gesammelt habe, war das Treffen für Product Owner besonders interessant und spannend.

Nach der Vorstellungsrunde sind wir gleich voll durchgestartet: Jeder notierte seine Wunschthemen auf Flipnotes, die dann gesammelt und zur Abstimmung gestellt wurden. Mein zweites Wunschthema “Sensibilisierung des Top-Managements” hat zwar nicht genug Stimmen erhalten, dafür aber folgende nicht weniger spannende Themen:

Thema 1: Geschäftswert berechnen

Das erste Thema drehte sich um die Frage, wie man am besten den Geschäftswert eines Epics oder Features im Verhältnis zum verfügbaren Budget/Aufwand berechnet, wenn es innerhalb eines Projekt dazu kommt, diese zu priorisieren.

Ein Vorschlag lautete, dass man als Unternehmen gewisse Fokus-Kennzahlen hat, die als Leitwert gelten sollten, wenn man Features priorisiert. Hat man als Jahresziel also beispielsweise Kundenretention auserkoren, muss man sich im Hinblick auf ein spezifisches Feature fragen, inwiefern es dazu beiträgt die Kundenretention zu erhöhen. Darüber hinaus sollte im Team ein gemeinsames Verständnis über die entscheidenden Parameter gefördert werden, die bei der Bewertung der Features eine gewichtete Rolle spielen.

Während man eigene Vorgehensweisen pflegt, sollte man immer darauf achten, dass die Methodik nicht zu kompliziert wird. Neben der Kürze liegt manchmal eben auch in der Einfachheit die Würze. So wurde der Benefit/Urgency-Ansatz besprochen, bei welchem man ein gegebenes Feature jeweils für Benefit und Urgency mit einer Zahl auf der Skala 1-5 bemisst und diese dann miteinander multipliziert:. So erhält man für jedes einzelne Feature einen Wert zwischen 1 und 25 und es ergibt sich eine natürliche Priorisierungsliste. Dabei sollte es natürlich immer Platz für freien Diskurs im Team geben, gerade wenn man bedenkt, dass die Wahrscheinlichkeit niedrig ist, dass alle anwesenden Entwickler z.B. die gleiche Vorstellung der Skala haben.

Thema 2: Backlog Refinement

Als nächstes diskutierten wir den Umgang mit dem Backlog Refinement. Auch hier gab es diverse Ansätze: Zwar sahen die meisten Anwesenden ihre Präferenzen bei ein oder zwei vom Planning separaten Refinement-Terminen – aber es wurde auch vorgeschlagen, die Refinements täglich mit dem Daily zu verbinden und die Priorisierung mit den Entwickler, dem PO, usw. direkt zu besprechen. An anderer Stelle kam zudem die Meinung auf, dass man Refinements auch spezifisch mit Front- oder Backend durchführen könnte, damit nicht jederzeit das gesamte Team eingespannt werden muss.

In einem Punkt waren sich aber alle einig: Je kürzer das Refinement ist, umso länger dauert das Planning-Meeting. Zudem stand außer Frage, dass das letzte Refinement-Meeting kurz vor dem Planning stattfinden sollte, damit dazwischen nichts verloren geht.

Thema 3: Feature Roadmap und ein durch Business Probleme getriebenes Projekt

Das dritte Thema bedurfte in der Tat ein wenig mehr Erklärung. Kurz zusammengefasst ging es hier um die These, dass ein Projekt bzw. die Entwicklung nicht durch eine vorgegebene Feature Roadmap getrieben werden sollte. Stattdessen sollte man versuchen, das Entwicklerteam vor die aktuellen Probleme des Businesses zu stellen. So könne das Team entsprechende konzeptionelle und technische Lösungen selbständig erarbeiten. Dadurch würde das Team autonomer, kreativer und motivierter agieren.

Als Einwand wurde angebracht, dass man durch die Orientierung an Business Metrics (wie im ersten Thema bereits angeschnitten), solche Diskussionen innerhalb des Teams bereits ganz natürlich eröffnet – im weiteren komme es dann eben auf die Kommunikation mit den Stakeholdern an.

Thema 4: Welche Unterstützung erwartet man von einem Scrum Master bzw. Agile Coach?

Das vierte Thema drehte sich um die Erwartungen, die die Teilnehmer des Lean Coffee an Scrum Master oder Agile Coaches haben. Dabei kamen verschiedene Punkte auf:

  • Die Begleitung des Teams mit dem Ziel, ein agiles Mindset zu fördern.
  • Die Definition eines gemeinsamen Zieles im Projekt.
  • Die Etablierung und Durchführung von terminlichen Ritualen.
  • Die Rolle der “starken Schulter” übernehmen, damit es Team-Mitgliedern möglich ist, ihre Beschwerden an den Mann oder die Frau zu bringen und Unterstützung zu erhalten.
  • Der Coach sollte im besten Fall nur für ein einzelnes Team zuständig sein; hat der Agile Coach gleich mehrere Teams unter seinen Fittichen, können einzelne Teams leiden und das Coaching verliert seinen Impact.
  • Im besten Fall sollte sich der Scrum Master ersetzbar machen oder dazu zumindest befähigt sein.
  • In dem Sinne sollte der Scrum Master ebenfalls die Fähigkeit besitzen, die ganze Organisation richtig zu schulen.

Thema 5: Projekte mit Remote bzw. Distributed Teams

Die Zeit wurde knapp, deshalb geriet das fünfte Thema etwas kurz – war aber nicht minder interessant: Es sollten Erfahrungen im Umgang mit Remote oder Distributed Teams gesammelt werden und wie man potentielle Fallstricke umgeht. (Virtuelles Team)

So sollte es mindestens einmal, im Idealfall zu Beginn des Projekts, ein Face-to-Face Treffen aller Beteiligten geben, damit man sich auch persönlich näher kennenlernt und besser einschätzen kann, wer hunderte oder tausende Kilometer entfernt mit einem zusammen arbeitet.

Außerdem sollte darauf geachtet werden klarzumachen, dass alle Teammitglieder (also auch diejenigen, die vermeintlich am Hauptsitz arbeiten!) als Remote-Mitarbeiter zu kategorisieren sind. So soll erreicht werden, dass diese ebenfalls alle Kommunikation über entsprechende Tools abschließen: Slack, Videokonferenz, usw. – damit sich niemand ausgeschlossen fühlt. In dem Zusammenhang ist es wichtig zu erwähnen, dass das nötige Equipment vorhanden sein muss, wie z.B. ein vernünftiges Videokonferenzsystem. Beim täglichen Austausch untereinander kann die Fähigkeit, Zwischentöne, Mimik und Gesten richtig zu lesen, entscheidend für eine erfolgreiche Kommunikation miteinander sein.

Fazit & Schluss

Das war mein erster Lean Coffee”. Es war relativ viel Input in nur einer knappen Stunde, aber alleine die Möglichkeit, Erfahrungen aus erster Hand in einer manchmal kontroversen Diskussionsrunde zu bekommen, machte das Treffen 100% lohnenswert. Ich werde gerne wieder teilnehmen!

Das 62. Lean Coffee für Product Owner-Treffen findet am 29. März 2019 bei 1WorldSync statt.

Weitere Informationen zum Lean Coffee: http://leancoffee.eu/productowner/

Ähnliche Artikel im Sevenval Blog:

Welche Eigenschaft fehlt den meisten POs? Rückblick auf den 51. Lean Coffee 4 Product Owner

Rückblick: Das war der 57. Lean Coffee für Product Owner

Zur Blog-Startseite