Entwicklung & Code
Projektmanagement: Darf das Product Backlog sichtbar sein?
Moin.
(Bild: Stefan Mintert )
Stefan Mintert arbeitet mit seinen Kunden daran, die Unternehmenskultur in der Softwareentwicklung zu verbessern. Das derzeit größte Potenzial sieht er in der Leadership; unabhängig von einer Hierarchieebene.
Die Aufgabe, dieses Potenzial zu heben, hat er sich nach einem beruflichen Weg mit einigen Kurswechseln gegeben. Ursprünglich aus der Informatik kommend, mit mehreren Jahren Consulting-Erfahrung, hatte er zunächst eine eigene Softwareentwicklungsfirma gegründet. Dabei stellte er fest, dass Führung gelernt sein will und gute Vorbilder selten sind.
Es zeichnete sich ab, dass der größte Unterstützungsbedarf bei seinen Kunden in der Softwareentwicklung nicht im Produzieren von Code liegt, sondern in der Führung. So war es für ihn klar, wohin die Reise mit seiner Firma Kutura geht: Führung verbessern, damit die Menschen, die die Produkte entwickeln, sich selbst entwickeln und wachsen können.
Für Heise schreibt Stefan als langjähriger, freier Mitarbeiter der iX seit 1994.
Neulich haben wir in unserem eigenen Team darüber gesprochen, ob das Product Backlog innerhalb einer Firma öffentlich sichtbar sein darf. Da wir als externe Berater, POs und Coaches mit verschiedenen Kundenteams zu tun haben, hat jeder von uns andere Erfahrungen gemacht. Deshalb war es gar nicht so einfach, eine gemeinsame Antwort zu finden.
Nach dem Gespräch habe ich folgende Sichtweise: Es sollte das Ziel sein, dass das Product Backlog und damit die Arbeitspakete des/der Entwicklerteams für jede Person im Unternehmen einsehbar sein sollen. Vorbehalte gegen diese Transparenz können sein:
- ein unbestimmtes Gefühl des Teams, sich nicht in die Karten schauen zu lassen,
- die Sorge, sich angreifbar zu machen,
- die Angst vor häufigen Eingriffen in den Arbeitsablauf.
Alle drei Punkte rechtfertigen aus meiner Sicht, das Backlog vertraulich zu behandeln. Allerdings ist mit jedem einzelnen Punkt auch eine Erkenntnis verbunden: Hier muss sich etwas ändern.
Wenn sich Teams dadurch angreifbar machen, dass jemand sehen kann, woran sie arbeiten, stimmt etwas nicht. Vielleicht hat die Person die Priorisierung oder die Roadmap nicht verstanden. Das kann man hinterfragen und klären.
Vielleicht wird aber auch die Rolle des Product Owners, der das Backlog maßgeblich verantwortet, nicht ausreichend respektiert.
Egal, was zu den Vorbehalten gegen die Transparenz anzuführen ist: Die Ursachen müssen erkannt und ausgeräumt werden.
Hat man das geschafft, dann darf das Product Backlog sichtbar sein. Ob es überhaupt sinnvoll ist, den Stakeholdern jedes kleine Bugticket und jede technische Aufgabe zu zeigen, ist eine andere Frage. Eine Darstellung des Entwicklungsfortschritts über Meilensteine, Epics oder (echte) User Stories dürfte in der Regel besser und ausreichend sein.
Erst lesen, dann hören
Im Podcast Escape the Feature Factory greife ich ausgewählte Themen des Blogs auf und diskutiere sie mit einem Gast. Durch den Austausch lerne ich eine zweite Perspektive kennen. Wenn Du auch daran interessiert bist, findest Du den Podcast bei Spotify, Deezer, Amazon Music und Apple Podcasts. Wenn Du die Themen, die ich im Blog anspreche, in Deiner Firma verbessern möchtest, komm’ in unsere Leadership-Community für Softwareentwicklung.
(rme)