Product Owner

Der Product Owner trifft die Entscheidungen über die Produktausrichtung und definiert zusammen mit dem Scrum Development Team die Aufgaben. Er stellt sich heroisch den kritischen Stakeholdern, kennt sein Produkt In- und Auswendig und ist über alle Zweifel erhaben.

Der Product Owner ist für die Übersetzung der Visionen in Aufgaben zuständig. Er hat direkten Kontakt mit den Kunden und erarbeitet, mit Unterstützung des Scrum Masters, ein Produkt-Backlog. Aufgaben werden durch den Product Owner ausgearbeitet, Anforderungen formuliert und Abnahmekriterien aufgestellt. Ferner erfolgt durch den Product Owner eine Priorisierung der Aufgaben im Produkt-Backlog und die Abnahme der erledigten Aufgaben fällt in dessen Aufgabenbereich am Sprint-Ende.

Eine (nicht ganz vollständige) Auflistung seiner Aufgaben:

  • bereitstellen/vermitteln der Vision
  • vorbereiten des Sprint-Inhaltes
  • Priorisierung der Aufgaben
  • erstellen einer Roadmap
  • Pflege des Backlogs
  • Verantwortlich für das Produkt
  • Inhaltliche Verantwortung
  • Beratung des Kunden
  • Kundenkontakt
  • Übersetzer (von den Anforderungen des Kunden in die Entwicklersprache)
  • erstellt User Stories
  • beschreibt Anforderungen
  • hat Budget-Verantwortung
  • für die Abnahme am Sprint-Ende durch / Produkt-Abnahme
  • holt Kundenfeedback ein

Scrum Master

Der Scrum Master ist sozusagen Bob der Scrumeister. Er hat die stetige Weiterentwicklung des Teams und der Organisation im Blick.

Der Scrum Master ist der Hüter des Prozesses, er fungiert als Schutzschild für das Scrum Development Team und hilft sowohl dem Product Owner als auch der Organisation, Scrum erfolgreich anzuwenden.

Eine (nicht vollständige) Auflistung der Verantwortlichkeiten des Scrum Masters sind:

  • sorgt dafür, dass Scrum funktioniert
  • setzt sich für die Organisationsentwicklung ein
  • hilft bei der Organisation im Team
  • führt eine kontinuierliche Prozess-Optimierung durch
  • stimmt sich mit anderen Scrum Mastern ab
  • sorgt für die Abstimmung mit anderen Teams
  • pocht auf Regeln und Meetings
  • unterstützt den Product Owner bei Bedarf
  • moderiert Meetings
  • Schutzschildfunktion (schützt das Team vor äußeren Störfaktoren)
  • Bindeglied zum Product Owner
  • das gute Herz des Teams
  • fordert Dokumentation ein und erstellt ggf. Meeting Minutes
  • beschafft Informationen/Räume/Material
  • beseitigt Hindernisse (und deckt sie ggf. auf)

Der Scrum Master ist Coach, Berater, Trainer, Moderator, Change Manager, Mentor, Führungsperson, dienender Führer und Scrum-Experte.

Scrum Development Team

Das Kernteam des Scrum Teams besteht aus Experten und ist idealerweise interdisziplinär aufgestellt. Kommunikation und gegenseitige Wertschätzung sind essentiell für ein gut funktionierendes Scrum Team.

Das Scrum Development Team besteht u.a. aus Entwicklern, Testern, Analysten und Grafikern. Das Team ist interdisziplinär aufgestellt und beinhaltet alle Kompetenzen, das es benötigt, um das geforderte Produkt umzusetzen.

Idealerweise besteht ein Scrum Development Team aus 5 bis 9 Mitgliedern. Generell sollte das Team groß genug sein, um in einem Sprint für das Produkt einen Mehrwert schaffen zu können. Andererseits sollte es nicht zu groß sein, um keine unnötige Komplexität in die Arbeitsabläufe zu bekommen.

Projekt-Retrospektive mit mehreren Teams

Im letzten Kundenprojekt stand ich (Patric Eid) zusammen mit meinem Kollegen Jan Breitschuh (https://www.xing.com/profile/Jan_Breitschuh2) vor der Herausforderung, eine Retrospektive in über 20 Areas gleichzeitig durchzuführen.

Das Projekt-Setup

Die Projekt-Organisation ist nach LeSS ausgerichtet mit 20 bis 25 Areas und insgesamt ca. 35 Teams. Die Retrospektive fand im Rahmen der Cadence Change Days (CCD) statt, an denen das Review der vergangenen 3 Monate und die Planung der nächsten 3 Monate besprochen worden sind. An den CCDs nahmen die Area Produce Owner, der Führungskreis der Organisation und einige Team-Mitglieder statt.

Ablauf der Retrospektive

Die Retrospektive wurde in 2 Teilen durchgeführt: 1. sammeln von Feedback und 2. Generierung von Maßnahmen zur Optimierung. Wir haben uns Gedanken gemacht, wie ein wertvolles Feedback aus der großen Teilnehmergruppe von über 50 Personen mit unterschiedlichen Interessen (Führungskräfte, Product Owner, Team-Mitglieder) erhalten. Wir haben uns schnell darauf geeinigt, dass wir die Product Owner und die Führungskräfte in zwei verschiedene Gruppen unterteilen, um von beiden Gruppen ein eigenes Bild zum aktuellen Projektstatus zu erhalten. Für das Einholen des Feedbacks haben wir auf die Liberating Structures-Methode 1-2-4-All zurückgegriffen.

1-2 wurde dabei in den beiden Gruppen durchgeführt, anschließend wurden beide Gruppen für das Bilden der 4er-Paare und dem Zusammenführen der Erkenntnisse vereint. Im Nachfolgenden der genaue Aufbau und Ablauf der Retrospektive.

Vorstellung des Ablaufs der Retrospektive

Ausgangssituation: in der großen Gruppe wurde der Ablauf der Retrospektive erklärt und der zeitliche Ablauf skizziert.

Vorstellen der Agenda in der großen Gruppe

Aufteilung in zwei Teilgruppen

Anschließend wurden die beiden Gruppen „Product Owners und Team“ und „Führungskreis“ gebildet.

„Product Owner“ und „Führungskreis“

Schritt 1: Einzelarbeit zur Beantwortung der Retro-Fragen

In Einzelarbeit sollte sich jeder 5 Minuten Gedanken zum Projekt machen. Die beiden zu beantworteten Fragen lauteten:

  • Was ist gut gelaufen?
  • Wo besteht Optimierungsbedarf?

Die Timebox dieser Einheit wurde auf 5 Minuten gestellt. Zielvorgabe: bis zu 5 Punkte pro Person, zu notieren auf Moderationskarten.

Schritt 2: 2er-Gruppen bilden

Nachdem jeder für sich die beiden Fragen beantwortet hat, sollten zweier Teams gebildet werden. In den zweier Gruppen wurden die zuvor notierten Erkenntnisse diskutiert und die Kleingruppen einigten sich auf 4 bis 5 Moderationskarten, die für beide wichtig waren. Als Timebox galt hierfür 10 Minuten.

Zusammenfassen in Kleingruppen

Schritt 3: Get Together

Beide Teilgruppen wurden aufgelöst und im großen Raum wieder zusammengeführt. Es wurden anschließend 4 große Gruppen gebildet, in denen die zweier Teilgruppen aus dem Schritt zuvor ihre Erkenntnisse untereinander vorstellten. Diese 4 Gruppen hatten zur Aufgabe, aus den gesammelten Moderationskarten der zweier Teilgruppen 4 bis 5 Punkte herauszusuchen, die für alle Teilnehmer wichtig waren. Die Timebox wurde auf 10 Minuten gestellt.

Zusammenführen der Teilergebnisse

Schritt 4: Kurze Vorstellung und Priorisierung

Die 4 Gruppen stellten ihre Ergebnisse kurz vor, in dem jede Gruppe ihre 4 bis 5 Moderationskarten an eine gemeinsame Metaplanwand hefteten. Dabei wurden gleiche Punkte bereits geclustert. Als Timebox galt 2 Minuten pro Gruppe.

Anschließend erfolgte die Priorisierung. Dazu bekam jeder Teilnehmer 2 Aufkleber, die er auf frei auf die verfügbaren Moderationskarten aufkleben konnte.

Daraus wurden die 5 Modearationskarten/Themengebiete herausgesucht, die die meisten Votes erhalten haben.

Schritt 5: gemeinsame Überschrift finden

Für die 5 Themen wurden Gruppen gebildet. Dabei wurde darauf geachtet, dass in jeder Gruppe mindestens 3 Teilnehmer sind. Ansonsten war jedem die Einteilung zur jeweiligen Gruppe frei überlassen.

Die Aufgabe: jede Gruppe sollte für sich eine Überschrift des Themas finden. Dabei sollte das Thema in wenigen Worten umschrieben werden. Als Timebox wurden 10 Minuten vorgegeben.

Maßnahmen ableiten

Die in Schritt 5 zusammengestellten Gruppen wurden am nächsten Tag damit beauftragt, Maßnahmen zur Optimierung der aufgekommenen Punkte herauszuarbeiten.

Schritt 1: Maßnahmen ableiten

Jede Gruppe sollte 2 bis 3 Maßnahmen ableiten und ihrem Punkt an eine Metaplanwand anbringen. Dazu wurde eine Timebox von 20 Minuten vorgegeben.

Wichtig dabei: jede Maßnahme wurde mit RAS ergänzt.

  • R = Responsible -> an wen die Maßnahme adressiert wird
  • A = Accountable -> wer die Maßnahme beauftragt (standardmäßig die jeweilige Gruppe und evtl. weitere Personen)
  • S = Support -> von wem Support erwartet werden kann (aus dem Rahmen der Gruppe) und wer darüber hinaus Support leisten muss

Schritt 2: Vorstellen

Jede Gruppe bekam als Timebox 2 Minuten, um ihre Maßnahmen allen anderen Gruppen vorzustellen. Anschließend wurde ein gemeinsames Commitment abgegeben, dass alle an der Umsetzung der Maßnahmen arbeiten werden und die Umsetzung „überwacht“ wird.

Fazit

Das Unterteilen der großen Gruppe in der Retrospektive in zwei Teilgruppen hat sehr gut funktioniert. Zwei Moderatoren waren in beiden Gruppen parallel und konnten dort die aufkommenden Fragen beantworten und die unterschiedlichen Gruppen daher gut begleiten.

Da der Führungskreis vom Rest der Teilnehmer getrennt war, wurden auch kritische Punkte wie zum Beispiel die genaue Aufgabe des Führungskreis im Projekt angesprochen. Anschließend hat eine offene Diskussion über die Optimierungspunkte und den abgeleiteten Maßnahmen stattgefunden.

Es wurde vereinbart, dass die Maßnahmen (bzw. deren Erfüllung) der Retrospektive in den Overall Reviews überprüft werden. Außerdem wurde sich geeinigt, dass solche Retrospektiven häufiger durchgeführt werden sollten.

DoR mittels INVEST

In diesem Artikel https://agile-pm.de/2019/02/20/defintion-of-ready-und-definition-of-done/ wurde die Defintion of Ready vorgestellt. Die Defintion of Ready (DoR) stellt eine Art Einlasskontrolle für Product Backlog Items dar. Erst wenn die Kriterien erfüllt sind, kann ein Product Backlog Item für das Sprint Backlog verwendet werden. Mit Hilfe des Akronyms INVEST lassen sich die Kriterien an eine User Story in Kategorien erfassen.

Independent

Der Vorteil unabhängiger User Stories ist, dass User Stories frei priorisiert und im Zweifel sogar aus dem Product Backlog heraus genommen werden können, ohne das übrige Product Backlog groß zu beeinflussen.

Negotiable

User Stories sollten aussagekräftig mit den notwendigen Details beschrieben werden. Allerdings sollten User Stories keine Lösungen vorgeben und noch Raum für Diskussionen zwischen Scrum Developer und Kunde lassen.

Valuable

Eine User User stellt für sich einen Wert dar. Wird die User User Story umgesetzt, so wird eine Wertsteigerung im zu entwickelnden Produkt erzielt.

Estimatable

Nur wenn eine User Story durch das Scrum Developer Team geschätzt worden ist, kann es in das Spirnt Backlog aufgenommen werden.

Sized appropiately

Eine User Story sollte genau so groß sein, dass sie im Rahmen eines Sprints umgesetzt werden kann.

Testable

Jede User User Story sollte für sich testbar sein. Dazu werden Acceptence Criteria / Akzeptanzkriterien definiert, die durch die Scrum Developer und dem Product Owner auf ihre Einhaltung hin überprüft werden.