1 Jahr agil (Teil 3): Die Rolle des Product Owners

Seit gut einem Jahr beschäftige ich mich intensiv mit agiler Software-Entwicklung – vor allem Scrum, worin ich seit Januar auch zertifiziert bin. Ab November steht mir eine neue Herausforderung bevor. Grund für eine persönliche Retrospektive:

Welche Erfahrungen nehme ich aus den letzten Monaten mit?

Teil 3: Der Product Owner

Eine echte Herausforderung – der Job des Product Owners:

Die fachlichen Anforderungen erkennen, erfragen, analysieren und priorisieren. Technische Hintergründe und Risiken wollen dabei durchaus bedacht werden. Dafür benötigt der Product Owner eine fundierte Kenntnis des Produkts.
Ganz zu schweigen davon, dass er eine Vision vermitteln soll und das Team selbstorganisiert arbeiten lassen muss.

Kommunikation – Je mehr desto besser

Dabei kann der Product Owner mit dem Team, mit Stakeholdern und Customern gar nicht genug kommunizieren, um wichtiges Feedback zu erhalten und das gemeinsame Vorgehen zu klären.
Für Entwickler hat das iterative Vorgehen manchmal den Beigeschmack des auf der Stelle treten oder einen Fehler beheben müssen.
Stakeholder und Customer wollen verstehen, nach welchen Kriterien die Priorisierung vorgenommen wird.

Fokus auf das Ziel

Auch hier gilt natürlich wieder “inspect & adept”. Wann immer möglich ist für die Entscheidungsfindung sinnvoll: die Kriterien des Erfolgs für ein Feature festlegen; Annahmen treffen welche Werte erreicht werden können; dafür sorgen, dass der Erfolg des Features gemessen wird; aus dem tatsächlich erreichten Ergebnis Schlüsse ziehen – Feature ausbauen, unverändert lassen oder wieder abschaffen und Ressourcen in Sachen Maintenance sparen.

User Storys: Noch mehr Kommunikation

Und dann sind da noch die UserStorys (nicht zu groß, nicht zu klein, nicht zu allgemein, nicht zu detailliert): Man neigt dazu sie als detaillierte Anforderungsdokumente und abschließende Dokumentation zu verwenden statt als Kommunikationsgrundlage. Allerdings sollten Aktzeptanzkriterien sinnvoller Weise im Plannning gemeinsam entwickelt werden, um dem Team die Möglichkeit zu geben, sich intensiv mit den fachlichen Anforderungen vertraut zu machen. Und für die Dokumentation bietet es sich oft an, den Mehraufwand in Kauf zu nehmen und diese in einer passenderen Form zu verfassen.

Effekte Meetings

Bei all dem Abstimmungsaufwand gilt es diese möglichst effektiv zu gestalten, da weder das Team noch die Kunden in langen Meetings sitzen wollen.
Ein gemeinsames Planning, Review und Backlog-Grooming sind aber unbezahlbar hilfreich.

Vertrauen

Auch für die Zusammenarbeit zwischen Product Owner, Scrum Master und Team ist Stabilität sinnvoll. Wenn eine vertrauensvolle Zusammenarbeit sich erst einmal entwickelt hat, muss deutlich weniger Zeit für Teambuilding und fachliche Einarbeitung investiert werden und das Team kann eine hohe Performance erreichen.

Wie der Scrum Master dem Team helfen kann, besser und schneller zu werden (und mit welchen Widerständen er zu kämpfen hat) – Darum wird es in Teil 4 dieser kleinen Serie gehen.