Viele Organisationen streben danach, agil zu sein. Aber nur wenigen gelingt es, wirklich agil zu werden und die Vorteile daraus zu ziehen.
Werfen wir einen Blick auf die häufigsten Fehler auf dem Weg zur Agilität und wie man sie vermeiden kann.
Häufige Fehler, die es zu vermeiden gilt:
- Du machst agil (nur), weil agil im Trend ist
- Keine Zeit und Mühe in die Umsetzung von Veränderungen stecken, vor allem, wenn Menschen beteiligt sind
- Keine Tribes rund um die Werte bilden
- Zu denken, dass das Durchführen von Scrum Zeremonien Agilität ist
- Kalender mit Meetings füllen = keine Zeit für echte Arbeit
- Nur die Teams agile machen, sich jedoch nicht auf dieses Mindset und Priorisierung auf Unternehmensebene zu konzentrieren.
- Product Owner als Team Output Owner
- Produktverantwortliche tun alles andere als das, was sie eigentlich tun sollen
In diesem Blogbeitrag gehe ich auf die Herausforderungen der Rolle des Product Owners ein.
Andere Teile der Serie:
Damit Agilität funktioniert: Vermeiden von Fehlern im Zusammenhang mit Veränderungen
Agiles Arbeiten ermöglichen: Vermeiden von Fehlern im Zusammenhang mit Scrum
7. Product Owner als Team Output Owner
Der Product Owner (PO) ist eine sehr wichtige Rolle, die in agilen Projekten die Prioritäten festlegen. Allerdings muss die PO-Rolle richtig besetzt sein und der/die PO muss wirklich die Macht haben, die geschäftsbezogenen Entscheidungen zu treffen, bevor er/sie bei der Priorisierung hilft.
Dieses Video beschreibt genau das Dilemma mit der PO-Rolle und wie POs am Ende etwas anderes sind als POs: Why “Scrum” Isn’t Making Your Organization Agile: Harmful Misconceptions About Product Owner Role
In einer großen Organisation kann es leicht passieren, dass es nur eine/n PO sowie ein Backlog pro Team gibt und die Teams ihre Arbeit individuell optimieren. In diesem Fall wird der PO eher zum Team-Output-Owner als zu einem echten PO. In dieser Konstellation optimiert das Team seine Arbeit nicht optimal, was uns im Großen und Ganzen nicht dabei hilft, den besten Kundennutzen zu schaffen.
Dieses Multi-Team-Setup mit vielen POs (oder Team-Output-Ownern) bringt uns noch weiter vom Kunden weg, da weder die Teams noch die POs mehr Kontakt mit dem Kunden haben. Ich würde sogar sagen, dass das anti-agil ist. Stelle sicher, dass Deine POs wirklich die Macht haben, geschäftsbezogene Entscheidungen zu treffen, und richte die Organisation entsprechend aus.
8. Produktverantwortliche tun alles andere als das, was sie eigentlich tun sollen
Aus meinen Gesprächen mit POs im Laufe der Jahre geht hervor, dass alle POs mit Arbeit überlastet sind und oft eine Menge Dinge tun, für die POs nicht zuständig sind. Sie haben viele Aufgaben, die oftmans im Zusammenhang mit Berichten und Fachwissen stehen.
Es kommt auch häufig vor, dass ein PO als Teamleiter:in, Change Manager:in, als die Person, die alles in den Teams umsetzt, als Entwickler:in neuer Arbeitsweisen innerhalb des Teams, als Coach für das Team, oder ähnliches verstanden wird. Das sind eher Aufgaben des Scrum Masters als des PO, obwohl der Scrum Master auch viel mehr ein Coach als eine Teamleitung sein sollte.
Am Ende tun die meisten POs nicht das, was sie eigentlich tun sollten: eine Vision und eine Roadmap für das Produkt erstellen, mit den Stakeholdern und Kunden kommunizieren und mit dem Backlog arbeiten. Wenn das passiert, ist die Wahrscheinlichkeit groß, dass Dein PO in Wirklichkeit kein PO ist, sondern ein Team-Output-Owner.
Es gibt ein paar Dinge, die Du tun kannst:
- Überprüfe, ob die Rollen des Scrum Masters und des POs richtig verstanden wurden und ob der PO nicht die Arbeit des Scrum Masters übernimmt.
- Prüfe, ob der PO Arbeiten erledigt, die eigentlich von den Teammitgliedern erledigt werden sollten.
- Überprüfe, ob Du z.B. einen Tech-Lead haben könntest, der einen Teil der Arbeit übernimmt, die der PO gerade macht.
- Korrigiere die Organisation und organisiere nur ein Backlog für mehrere Teams und einen echten PO, der/die für dieses Backlog verantwortlich ist.
Was ist, wenn ein PO nicht in der Lage ist, den Backlog zu bearbeiten und die Teammitglieder dafür die richtigen Leute sind? Die Wahrscheinlichkeit ist groß, dass sich statt größerer Themen kleinere Aufgaben im Backlog befinden. In diesem Fall solltest Du den Backlog so anpassen, dass es Aufgaben enthält, die das Ziel der Produktarbeit beschreiben. Die Teammitglieder können sie dann später in kleinere Aufgaben aufteilen.
Ich hoffe, Du findest diese Tipps hilfreich. Es wäre schön zu hören, wie diese Tipps zu Deinem Unternehmen passen und welche Lösungen Du entwickelt hast, um Dein Unternehmen agiler zu machen. Da wir ja agil sind, sind dies die besten Praktiken für den Moment, und wenn wir dazu lernen, werden wir auch in Zukunft noch bessere Praktiken entwickeln.
