Was viele nicht wissen: Eine meiner ersten Positionen in einem Scrum Team war tatsächlich die des Product-Owners. Was soll ich sagen ...?
Es gab Höhen und Tiefen.
Die „Höhe“ war für mich, Technologie, Wirtschaftlichkeit und Teamarbeit zu vereinen. Tiefpunkte waren: endlose Meetings, in denen sich die Diskussionen hinzogen. Ich verzweifelte daran, eine Entscheidung zu treffen, die nicht auf Gegenstimmen stieß. Rückblickend frage ich mich:
Was hätte mir damals an den Tiefpunkten geholfen?
Ich glaube, eine Bestätigung meiner Vorstellung, was eigentlich die Arbeit eines Product-Owners ausmacht. Maarten Dalmijn, der Autor von „Driving Value with Sprint Goals“, hat es vor Kurzem gut auf den Punkt gebracht. Er vergleicht die Arbeit des Product-Owners mit der Arbeit eines Dirigenten. Was mir daran so gut gefällt, ist die Einsicht, dass ein Dirigent selbst keine Töne spielt, sondern dem Orchester hilft, das Beste aus der Darbietung herauszuholen, um ein Musikstück gemäß seiner künstlerischen Vision zu spielen. So hätte ich es damals nicht auf den Punkt bringen können. Was ich jedoch merkte: Als Product-Owner treffe ich in den seltensten Fällen komplett freie Entscheidungen. Im Nachhinein muss ich die Entscheidung aber immer vertreten. Deshalb war es wichtig, Entscheidungen so zu treffen, dass sie auch von den Beteiligten und Stakeholdern mitgetragen werden konnten.
Wie geht das?
Das habe ich mich damals auch gefragt. Die Antwort fand ich in einer besseren Art der Moderation von Entscheidungen. Moderation bedeutet, den Entscheidungsprozess so zu erleichtern, dass bessere Entscheidungen getroffen werden. Besser heißt, dass mehr Beteiligte einbezogen werden und im Anschluss die Entscheidung mittragen.
Hier sind drei Tipps, wie das konkret gelingt:
Tipp 1: Sprint-Ziel definieren – So beteiligst du alle im Team und ersparst dir lange Diskussionen
Warum solltest du alle an Entscheidungen beteiligen?
Betrachten wir als Beispiel das Sprint-Planning. Als Product-Owner setzt du dich mit den Entwicklern zusammen. Dein Fokus sollte nun darauf liegen, ein gemeinsames Ziel für den Sprint zu finden. Die Betonung liegt hier auf gemeinsam. Warum? Ganz einfach: Wissenschaftliche Studien haben gezeigt, dass ein gemeinsames Ziel die Motivation fördert. Motivation ist notwendig, wenn es gegen Ende des Sprints vielleicht schwieriger wird.
Zurück zum Sprint-Planning.
Wie lassen sich bei der Definition des Sprint-Ziels alle miteinbeziehen?
Hier ein einfaches Vorgehen: Sorge dafür, dass jeder im Team das aktuelle Product-Backlog sehen kann.
Nun gehst du so vor:
- Bitte alle, das Backlog zu betrachten. Dann lade sie ein, sich einen Moment Zeit zu nehmen und darüber nachzudenken, was ein lohnenswertes Ziel für diesen Sprint sein könnte.
- Bitte die Teammitglieder, Paare zu bilden, um sich gegenseitig mögliche Ziele vorzustellen. Fordere sie auf, die Ideen zu verfeinern oder ihre eigenen Ziele zu präzisieren, wenn möglich. Gib ihnen etwa 2 – 3 Minuten dafür.
- Nun sollen sich die Paare in Vierergruppen austauschen. Auch hier sollen die Gruppen ihre Ziele diskutieren, verfeinern oder zusammenfassen. Gib ihnen dafür 4 – 5 Minuten Zeit.
- Zum Abschluss teilt jede Vierergruppe ihre lohnenswertesten Ziele oder wichtigsten Einsichten mit dem Team.
Ein Hinweis zum Vorgehen:
- Das Ziel dieser Schritte ist nicht nur, ein gemeinsames Ziel zu erhalten. Sollte das geschehen, umso besser. Es geht darum, einige Vorschläge für ein Ziel zu finden, die vom Team kommen.
- Nimm aktiv an allen vier Schritten teil. Dadurch ist auch deine Idee für ein Sprint-Ziel in die Diskussion eingebracht.
Am Ende der vier Schritte hast du als Product-Owner einige Ziele zur Auswahl. Nun kannst du überlegen, welche Ziele am besten weiterverfolgt werden sollten. Der Vorteil? Im Gegensatz zu einem Ziel, das ausschließlich von dir bestimmt wird, haben wir jetzt ein Ziel, das ursprünglich vom Team selbst stammt. Das fördert die Gemeinschaft und stärkt die Motivation.
Das bringt uns zum nächsten Tipp:
Tipp 2: Refinement moderieren – So beachtest du alle Perspektiven bei der Ideenfindung
Diese vier Schritte zur Erzeugung von Ideen solltest du immer nutzen.
Warum? Es ist wissenschaftlich belegt, dass unstrukturiertes Brainstorming schnell zu Gruppendenken führt. Verfällt eine Gruppe ins Gruppendenken, finden oft nur noch die Ideen der Lautesten im Team Gehör. Warum könnte das ein Problem sein? Betrachten wir ein Refinement-Meeting. Nachdem du eine User-Story vorgestellt hast, erhoffst du dir von den Entwicklern Ideen, wie sie technisch umgesetzt werden kann. Diese Überlegung ist wichtig für deine Arbeit, da die technische Umsetzung den Aufwand und somit die Kosten bestimmt. Würde jetzt nur der Lead-Engineer einen Vorschlag äußern, der zwar technologisch exzellent, allerdings auch sehr zeitaufwendig ist, – was dann? Mangels kreativer Alternativen bleibt dir nichts anderes, als dem Vorschlag zuzustimmen oder die User-Story nicht umzusetzen.
Gäbe es allerdings noch andere Lösungsideen, die vielleicht weniger kostenintensiv, dafür aber weniger langfristig gedacht sind, dann hast du die Möglichkeit, abzuwägen: Ist die User-Story eine langfristige Investition wert oder will ich sie eher nur testen, bevor ich mehr investiere?
Zurück zum Refinement und den vier Schritten:
Nachdem du die User-Story vorgestellt hast, frage nicht in die Runde: „Wie könnte das umgesetzt werden?“, sondern bitte jedes Teammitglied, erst einmal für sich eine Lösung zu formulieren.
Das ist Schritt eins von oben. Fahre dann mit Schritt 2 und 3 fort. Nutze hierbei einen kleinen Trick: Bitte die Entwickler in jeder Runde, nicht ihre Ideen zu vereinen, sondern weitere Ideen zu finden. Am Ende der vier Schritte sollten dann acht oder mehr Ideen zur Diskussion stehen.
Lass mich dir diesen Prozess mit einem Modell veranschaulichen: Ideenfindung und Entscheidungsfindung kannst du dir wie einen Diamanten vorstellen.
Die linke Seite des Diamanten beschreibt die Ideenfindung: Je mehr Ideen, desto höher ist der Diamant. Hier bist du nach den vier Schritten angekommen. Jetzt geht es darum, die beste Idee auszuwählen. Idealerweise einigt sich das Team auf eine Lösung, die die rechte Spitze des Diamanten darstellt und bleibt nicht in der Mitte stecken.
Wie kann dir das gelingen?
Eine Möglichkeit wäre, alle Ideen zu diskutieren und das Für und Wider zu beleuchten. Das Problem? Es kostet sehr viel Zeit. Hier eine einfachere Alternative:
Gib jedem Entwickler eine Stimme, um über die Lösungen abzustimmen. Nutze dafür Klebepunkte. Jeder bekommt drei und darf sie beliebig auf die Ideen verteilen – auch alle drei Punkte auf nur eine Idee. Bitte die Entwickler, die Punkte nicht willkürlich zu setzen, sondern stelle ihnen eine spezielle Frage:
Bitte sie, die Lösungen nach folgenden Kriterien zu bewerten:
- Machbarkeit
- Einfachheit
- Wartbarkeit
- Sicherheit
- usw.
Du kannst mehrere Runden zu unterschiedlichen Fragen durchführen. So erhältst du ein gutes Bild davon, welche Lösung unter welchen Gesichtspunkten bevorzugt werden sollte.
Das Resultat: eine priorisierte Liste der Möglichkeiten, wie die User-Story umgesetzt werden kann.
Bevor wir zum letzten Tipp kommen, noch ein kleiner Hinweis:
Sicher ist dir schon aufgefallen, dass du diese Priorisierungstechnik auch im Sprint-Planning nutzen kannst, um die Diskussion abzukürzen. Werden im vierten Schritt mehrere Sprint-Ziele genannt, bitte die Teammitglieder, darüber abzustimmen. Zum Beispiel mit der Frage:
„Welches Ziel, glauben wir, ist am wertvollsten für einen bestimmten Stakeholder, welches ist am schnellsten zu erreichen oder bei welchem ist das Risiko am höchsten, dass wir es nicht fertigstellen?“
Nun zum letzten Tipp für heute:
Tipp 3: Entscheidungen treffen – Diese Möglichkeiten gibt es und so nutzt du sie, um Meetings abzukürzen
Wie wurden bisher Entscheidungen getroffen?
Schauen wir noch einmal zurück:
- Im Sprint-Planning: Wahrscheinlich hast du als Product-Owner am Ende entschieden, welches Ziel für diesen Sprint verfolgt werden soll.
- Im Refinement: Durch die Priorisierung haben die Entwickler eine Wahl getroffen, wahrscheinlich nach dem Mehrheitsprinzip.
Was fällt auf?
In unterschiedlichen Situationen werden unterschiedliche Entscheidungsmethoden verwendet. Das ist grundsätzlich gut, denn nicht jede Entscheidung ist gleich.
Allerdings liegt darin auch eine große Quelle für lange Diskussionen, Unstimmigkeiten und mangelndes Commitment zur Arbeit: Unklarheit darüber, wie eigentlich entschieden wird. Oder besser gesagt: Wer entscheidet was wann?
Und versteh mich nicht falsch: Ich möchte nicht sagen, dass jede Entscheidung gleich getroffen werden sollte oder dass eine Person alle Entscheidungen treffen muss.
Ich möchte damit sagen: Wenn die Art und Weise, wie eine Entscheidung getroffen wird, vorher nicht allen bekannt ist, führt dies zu Missverständnissen. Was wiederum zu langen Diskussionen führt.
Deshalb mein Tipp:
Informiere alle vorab, wie die Entscheidung getroffen werden soll.
Hierfür gibt es verschiedene Möglichkeiten. Im „Professional Scrum Facilitation Skills“-Training erkläre ich immer diese:
- Einzelentscheidung: Eine Person im Team entscheidet für alle.
- Konsensentscheidung: Wenn alle Teammitglieder zustimmen, ist die Entscheidung getroffen.
- Mehrheitsentscheidung: Wenn die Mehrheit dem Vorschlag zustimmt, ist die Entscheidung getroffen.
- Konsententscheidung: Die Entscheidung ist getroffen, wenn es keine Einwände mehr zum Vorschlag gibt.
- Münzwurf: Die Entscheidung wird dem Zufall überlassen.
Diese Möglichkeiten beschreiben, wie eine Entscheidung getroffen werden kann.
Der Scrum Guide liefert uns viele Empfehlungen. Diese basieren auf der Beschreibung der Verantwortlichkeiten. Sie helfen dabei, zu klären, wer eine Entscheidung treffen soll und wann dies geschehen sollte.
Wie kannst du das nun konkret anwenden?
Betrachten wir noch einmal das Beispiel mit dem Sprint-Ziel von oben. Der Scrum Guide schreibt:
„Das gesamte Scrum Team arbeitet dann zusammen, um ein Sprint-Ziel zu definieren …“
Du könntest die vier Schritte also so moderieren, dass es darum geht, ein gemeinsames Ziel für den Sprint zu definieren. Dazu überlegt das Team gemeinsam einige Kandidaten für Ziele und stimmt anschließend mit einer Konsententscheidung ab. Es gilt also, so lange das Sprint-Ziel anzupassen, bis keine Teammitglieder mehr Einwände gegen das Ziel haben.
Und nun das Beispiel vom Refinement:
Der Scrum Guide sagt hier:
„Die Developer, die die Arbeit erledigen werden, sind für die Größenbestimmung umsetzungsverantwortlich.“
Somit könnte die Priorisierung, welche Lösung am aufwendigsten ist, durch eine Mehrheitsentscheidung getroffen werden. Nachdem alle Klebepunkte gesetzt wurden, könnte mit der Frage abgestimmt werden:
„Wer stimmt zu, dass diese Lösungsidee mit den meisten Klebepunkten die aufwendigste ist? Bitte hebt eure Hand.“
Wenn die Teammitglieder im Vorfeld wissen, wie entschieden wird, verkürzt dies die Diskussion im Meeting. Es ist zudem hilfreich, wenn sie auch wissen, wer die Entscheidung trifft.
Welche weiteren Moderations-Tipps hast du für Product-Owner?
Schreibe sie gerne in die Kommentare, damit wir alle von deiner Erfahrung profitieren können.