Product Owner - eine Herausforderung

Das ganze Plenum voller Leute geschätzte zwei bis dreihundert und auf die Frage, ob jemand schon Product Owner ist oder noch werden will meldet sich kein einziger. Vielleicht geht es ja allen so wie mir... die Rolle "in Reinform" wird so wohl wirklich selten gelebt.

Aber immerhin - der Talk ist ein echtes Highlight. Urban Ernst beleuchtet seine Erfahrungen als Product Owner eines 20-Entwickler-Projekts. (Zwischendurch ist mir der Saft ausgegangen - also genauer meinem Notebook - so dass es kein Live-Blogging gibt.)

Ganz nebenbei räumt Urban Ernst noch mit einigen Lebenslügen agiler Entwicklung und insbesondere von Scrum auf: Projektteams organisieren sich nicht einfach so von selbst. Jaja, schon klar - das hat so auch nie jemand gesagt. Aber es ist gut, wenn zur Abwechslung mal wieder jemand darauf hinweist, wieviel Arbeit das in der Realität ist.

Ein reichliches Learning war die Sprint Goal Presentation und die Story Abnahmen, in denen der Product Owner die aktive Rolle übernimmt. Und auch ganz wichtig: Der Prozess läuft wesentlich runder, wenn Product Owner und Scrum Master das gleiche Verständnis vom Prozess haben und so in die gleiche Richtung ziehen.

Ich setze noch einen drauf: Es ist essentiell, dass alle im Projekt den gleichen Prozess leben. Nicht mit der gleichen Intensität, klar. Aber über kurz oder lang macht es das Team mürbe, wenn es verschiedene Vorstellungen des Prozesses gibt. Also noch mal: Schon die Vorstellung des Prozesses. Denn sonst wird das nie ein Prozess.

Kollaboration in IT-Projekten

Dr. Georg Molter und Torben Knerr reden jetzt über Team Kollaboration in Java Projekten, stellen Herausforderungen und Anforderungen vor und zeigen dann Kollaborationswerkzeuge auf drei Leveln: Level 1 als Zusammenstellung von Open Source Tools, Level 2 als spezielle Kollaborationstools und Level 3 als in die IDE integrierte Kollaborationsplattformen.

Die Probleme räumlich verteilter Kollaboration sind ja hinlänglich bekannt - nicht nur aus der Softwareentwicklung. Die drei "bedeutsamen" von Molter und Knerr lassen sich eigentlich zusammendampfen auf "schlechte Kommunikation". Das führt dann beispielsweise zu unterschiedlichen Auffassungen der Requirements, zu intransparenter Planung und schwierigem Monitoring. Weitere Implikationen sind die verfügbaren Kommunikationsmittel (Telefon, Chat, Filesharing, Video-Conferencing) etc. inklusive der Performance dieser Kommunikationsmittel.

Voraussetzungen für den Erfolg einer räumlich verteilten kollaborativen Entwicklung sind eine einheitliche Begriffswelt, Prozesse und Tools (z.B. zur Versionsverwaltung, Verwaltung der Testfälle, etc.), ein gemeinsames Verständnis von den Work Items und den Requirements und die Unterstützung durch geeignete Tools zur Kollaboration. Viele "Disziplinen" sind (durch Tools) zu erfüllen, um eine gute Kollaborationsumgebung zu bieten.

Molter und Knerr schnappen sich nun einige der Tools und checken einfach mal durch, in wie weit diese die Disziplinen erfüllen. Die beruhigende Aussage vorweg: In der Java-Welt sind wir gar nicht so schlecht unterwegs. Ich erwarte mal, dass die Tools auf den unterschiedlichen Levels unterschiedlich gut geeignet sind. Die einzelnen Tools möchte ich hier jetzt nicht weitergeben, das war vor allem eine Slide Show mit Screenshots.


Der Talk war leider genau das - eine Slide Show von Screenshots mit einigen Allgemeinplätzen über Kollaboration im Allgemeinen. Ich hoffe auf den Nachmittag.