Zu viele Köche verderben den Brei
In Unternehmen, die Softwareprodukte entwickeln, ist es nicht unüblich, dass es neben einem Produktmanager, ggf. noch dessen Chef in Form eines Head of Product, unter Umständen auch noch einen Scrum Produkt Owner und zu guter Letzt einen CTO gibt. Wie sind diese Rollen definiert und kommen sie sich nicht hinsichtlich der Entscheidungen bzgl. der Roadmap, der Vision, der Architektur usw. in die Quere?
Ein CTO (Chief Technology Officer) übernimmt oft die technische Leitung und Strategie für das Unternehmen und dazu gehört auch die enge Zusammenarbeit mit dem Produktmanagement, da er oder sie über ein tiefes technisches Verständnis verfügt und die technischen Möglichkeiten und Herausforderungen im Auge behält. Es wird dadurch sichergestellt, dass die technische Umsetzung den Anforderungen und Zielen des Unternehmens entspricht. Der CTO kann auch bei der Bewertung neuer Produktideen und Produktkonzepte helfen, indem er technische Machbarkeitsstudien durchführt und Einschätzungen zur Umsetzbarkeit und Skalierbarkeit abgibt. Darüber hinaus kann der CTO das Produktteam bei der technischen Architektur, dem Design und der Auswahl von Technologien unterstützen.
Head of Products sind für die Gesamtleitung des Produktteams und die Koordination der verschiedenen Stakeholder verantwortlich. Sie bringen die verschiedenen Perspektiven zusammen und unterstützen bei der Abstimmung von Produktvision, Geschäftszielen und technischer Umsetzung.
Produktmanager sind meist für die Produktvision, die Roadmap und die Anforderungsdefinition für ein einzelnes Produkt verantwortlich. Sie arbeiten eng mit den Kunden, dem Marketing und anderen Stakeholdern zusammen, um die Anforderungen zu verstehen und die Produktstrategie zu entwickeln. Sie haben in der Regel das größte Verständnis für die Marktbedürfnisse und die Kundenperspektive.
Wenn das Produktentwicklungsteam nach Scrum arbeitet, so gibt es noch die Rolle des Product Owners, die als zentrale Schnittstelle zwischen den Stakeholdern und dem Entwicklungsteam existiert. Im Idealfall wird die Rolle durch den Produktmanager ausgeübt. Die Priorisierung des Produktbacklogs, die Definition der Anforderungen und die Lieferung eines wertvollen Produkts liegen in der Verantwortung dieser Rolle.
Wo und wie genau kommt es nun zwischen diesen Rollen ggf. zu Unstimmigkeiten?
In einem Scrum-Team wird eigenverantwortlich und selbstorganisiert gearbeitet. Es ist also die Aufgabe des Entwicklungsteams, die technischen Entscheidungen zu treffen und die technische Umsetzung zu planen, um die Ziele des Produktmanagers/Product Owners zu erreichen. Der CTO sollte dann, falls noch nötig, als Experte und Berater dienen, der das Entwicklungsteam unterstützt und bei technischen Herausforderungen berät, anstatt Entscheidungen zu treffen. Er coacht die Entwickler und entwickelt sie weiter, so dass sie alleine fundierte Entscheidungen treffen können. Der Head of Product hat die vergleichbare Aufgabe für den Product Owner, also das Coachen der Produktmanager/Product Owner. Ziel ist bei beiden Rollen, sich mittel- bis langfristig unnötig zu machen und das Scrum-Team auf eigene Füße zu stellen.
Leider sehen sich viele CTOs und Head of Products nicht als Coach, Supporter und Unterstützer sondern micro-managen die Entwickler bzw. die Produktmanager oder Product Owner. Dies führt entweder über kurz oder lang zu Spannungen, da das Scrum-Team seine Eigenverantwortlichkeit anstrebt und einfordert, oder das Team entwickelt sich nicht weiter. Stattdessen sehen sich die Entwickler als Umsetzer der vom CTO festgelegten Architektur und des Designs und der Produkt Owner wird zum Product Backlog Administrator, der lediglich wie eine Sekretärin die Featurewünsche des Head of Products protokolliert. So entsteht keine echte Kollaboration und das Team erlernt keine Selbständigkeit. Entsprechend leidet dann dadurch auch die Eigenverantwortlichkeit: das Team ist gewohnt, sie nicht zu übernehmen, da es nur umsetzt und nicht entscheidet. Ein so gezüchtetes "Umsetzungsteam" ist optimal ineffektiv, denn das Mitdenken und Einbringen eigener Ideen wird als unerwünscht angesehen. Widersprüche in Architektur, Design oder Anforderung werden in einem solchen Umfeld meist erst spät bemerkt und aufwendige Umbau- oder Nacharbeiten werden nötig. Enorme Zusatzaufwände sind die Konsequenz, ganz abgesehen davon, dass die Fertigstellung sich massiv verzögert. Super-GAU!
Wenn es in einem Unternehmen sowohl einen CTO, als auch einen Head of Product, einen Produktmanager und einen Product Owner gibt, so ist meist das Produktportfolio sehr groß und/oder das einzelne Produkt und dessen Markt sehr komplex und dann kann es Sinn machen, diese Rollen alle weiter zu besetzen. Das Ziel der Eigenverantwortlichkeit und Selbständigkeit des oder der Scrum-Teams bleibt dabei bestehen. CTO und Head of Product arbeiten als Coach, um die Teammitglieder weiter zu entwickeln. Sie bleiben als Berater erhalten, um mit ihrer Expertise und Erfahrung neuen Teammitgliedern zu helfen und den Gesamtüberblick über die Produktlandschaft zu behalten. In der Übergangsphase hin zu eigenverantwortlichen Scrum-Teams, ist es sehr wichtig, dass alle Beteiligten offen kommunizieren und ihre Perspektiven einbringen, um gemeinsam zu sinnvollen Entscheidungen zu gelangen, aber dabei immer die Vision der Selbständigkeit der Scrum-Teams im Auge behalten. Ein Agile Coach kann hier nachhaltig unterstützen und ist bei vielen Unternehmen mindestens für die Transitionsphase hin zu agiler Arbeitsweise auch vorhanden. Leider wird dabei nach meiner Erfahrung vor allem auf die product delivery geachtet und das Scrum-Team geschult. Das Coachen des CTOs und des Head of Products als Mentor und Unterstützer zu arbeiten, kommt dabei leider oft zu kurz.
In einem kleinen Unternehmen mit nur einem oder wenigen Produkten, sind die Rollen des CTO und Head of Product in der Regel unnötig. Ein CTO ist dann oft einfach einer der erfahrenen Entwickler im einem Scrum-Team und der Head of Product übernimmt direkt die Rolle des Product Owners.