In einer Branche wie unserer ist Veränderung eine Konstante. Neue Technologien, wechselnde Kundenbedürfnisse sowie sich ständig weiterentwickelnde Arbeitsmethoden sind der Treibstoff dieser Industrie. Und für manche Entwickelnde kommt irgendwann auch der Zeitpunkt, an dem sie darüber nachdenken, wohin ihre berufliche Reise als Nächstes gehen soll. Ein Weg, der immer wieder von Entwickelnden gewählt wird, ist die Transformation zum Product Owner.

Dieser Karrierewechsel ist keine kleine Veränderung. Schließlich verkörpern Product Owner eine Schlüsselrolle in agilen Entwicklungsteams, die die Verantwortung für die Produktgestaltung und -umsetzung tragen. Während Entwickelnde diejenigen sind, die den Code schreiben und technische Probleme lösen, sind Product Owner für die Definition von Produktspezifikationen, die Priorisierung von Funktionen und die Kommunikation mit den Stakeholdern verantwortlich.

In diesem Blogartikel nehmen unsere Xperten die Reise von Entwickelnden zum Product Owner genauer unter die Lupe. Wir werden die Gründe, die Motivationen und die Herausforderungen erkunden, die diese berufliche Veränderung begleiten. Der Beitrag richtet sich vorrangig an Entwickelnde, bietet jedoch auch spannende Einblicke für alle, die sich für die unterschiedlichen Rollen innerhalb der agilen Softwareentwicklung interessieren.

Phase 1: Vor der Entscheidung

Auch Entwickelnde können im Projektalltag mit Situationen konfrontiert werden, die dem Aufgabengebiet eines Product Owner zuzuordnen sind. So passiert es immer wieder, dass Entwickelnde Themen vorantreiben, Meetings moderieren oder auch konzeptionelle Zuarbeiten für fachliche Entscheidungen liefern. Hinzu kommen unklar formulierte Anforderungen sowie technische Pattsituationen, die eine konsensuale Lösung erfordern. Trotz seiner Abgeschlossenheit bietet auch der Scrum-Prozess offene Flanken, die Entwicklungsteams mit dem Zeit-Qualität-Kosten-Zielkonflikt konfrontieren. Um diesen Herausforderungen zu begegnen, benötigt es oftmals Skills, die über die Softwareentwicklung hinaus gehen. Kommunikation nimmt hier eine Schlüsselrolle ein.

Entwickelnde rutschen in diese Situationen, weil sie ein bestimmtes Skillset mitbringen. Neben ihren fachlichen Fähigkeiten interessieren sie sich für das große Ganze und haben meist einen besseren Überblick über das Projekt, als es der Teamumfang vorgibt. Sie schauen auch mal über den Tellerrand, informieren sich über die aktuelle Situation in anderen Teams und haben vor allem die Motivation, sich einzubringen, etwas vorantreiben zu wollen.

Phase 2: Die Entscheidung

Der Weg von Entwickelnden zum Product Owner kann unterschiedlich verlaufen. Bringen Entwickelnde die oben genannten Eigenschaften bereits mit, machen sich diese womöglich selbst schon Gedanken über eine berufliche Veränderung. Oftmals geht die Initiative jedoch auch vom Arbeitgeber aus, da man in der Vergangenheit ausgesprochen gut mit Konfliktsituationen umgegangen ist.

Die Entscheidung, Product Owner zu werden, bedeutet allerdings einen großen Einschnitt in den bisherigen Karrierepfad. Die eigentliche Aufgabe, die man bisher ausgeübt hat, nämlich das Entwickeln, fällt in der Product-Owner-Rolle vollständig weg. Grundsätzlich sollte es jedoch möglich sein, wieder in die Softwareentwicklung zurück zu wechseln. Wer Lust hat, Product Owner zu werden, sollte sich auf jeden Fall einmal ausprobieren, nur so kann es Klarheit über die Entscheidung geben.

Dabei ist es nicht nur wichtig, Vertragsbedingungen und Dauer der Probezeit zu klären, sondern auch die Möglichkeiten, sich an die neue Rolle heranzutasten. Hier bieten sich bspw. eine Assistenz des aktuellen Product Owner sowie verschiedene Arbeitsteilungsmodelle an.

Phase 3: der Start

Gerade in der Anfangszeit kann es schwierig sein, sich in der neuen Rolle zurechtzufinden. Die neuen Aufgaben unterscheiden sich von den vorherigen und auch in der Wahrnehmung der anderen – egal ob Entwickelnde oder Stakeholder – kann es etwas dauern, bis sich diese an die neue Rolle gewöhnt haben.

Anstatt zu entwickeln, wird der Tag nun durch bspw. Themenklärung, dem Schreiben von User Storys, dem Refinement dieser mit dem Team sowie der Sprintplanung bestimmt. Dennoch kann es gerade zu Beginn passieren, das Product Owner, die aus der Entwicklung kommen, dazu neigen, kleinere Implementierungsaufgaben bzw. Buganalysen selbst zu übernehmen. Schließlich befindet sich die IDE (Integrated Development Environment) noch in Reichweite.

Vor allem das Entwicklungsteam erwartet technische Lösungen anstelle von Zielen, die im Was & Warum und nicht im Wie formuliert sind. Hier ist es wichtig, dass sich neue Product Owner rollenkonform verhalten und nicht in die Situation schlittern, ein bisschen von allem zu machen. Auch wenn es natürlich in der Anfangsphase von vielen Seiten Verständnis gibt, wird man relativ schnell vom Projektalltag eingeholt. Gefühlt wollen alle etwas und das am besten sofort. Da man nun offiziell verantwortlich ist, wird es auch den ein oder anderen Versuch geben, Druck weiter zu delegieren. Das Gute ist, dass viele dieser Situationen mit und durch Kommunikation gelöst werden können.

Wer neu in der Rolle des Product Owner ist, kann sich vieles dadurch erleichtern, die eigenen Möglichkeiten der Leistbarkeit transparent zu machen. Auch das Aufzeigen von Konflikten durch Eskalationsbesprechungen sowie das Hinterfragen der gewünschten Umsetzungstermine ist äußerst hilfreich. Es empfiehlt sich außerdem, das Ziel von Umsetzungsanforderungen genau zu ermitteln. Dadurch ergeben sich oftmals alternative Lösungen, die sich besser als die geforderten eignen. Wichtig ist darauf zu achten, das eigene technische Wissen immer zu abstrahieren, da Gesprächsparteien oftmals keinen Background als Entwickelnde haben. Wer keine Überraschungen erleben möchte, sollte alle Besprechungen verschriftlichen, insbesondere die Ergebnisse, auf die sich geeinigt wurde.

Phase 4: die Reifephase

Ist die Zeit, in der man sich noch an die neue Rolle gewöhnen musste, erst einmal vorüber, geht es auch schon in die Reifephase. Diese Phase ist maßgeblich für die Entwicklung eines Product Owner und formt ihn letztendlich zu dem, was diese Rolle ausmacht.

Jedes Projekt ist unterschiedlich aufgebaut und hat seine Eigenarten in Bezug auf die Größe/Anzahl der Teams sowie den Grad seiner Agilität. Auch die Organisationsart der Teams (horizontal vs. vertikal.) wirkt sich auf Entscheidungen aus und verlangt flexible Lösungsansätze vom Product Owner. Kleinere und größere Anpassungen der eigenen Arbeitsweise sind in dieser Phase unumgänglich. Nur so kann in der Rolle vorangekommen und diese erfolgreich ausgeübt werden.

Auch wenn es sich bei Scrum um einen agilen Prozess handelt, wird man als Product Owner immer wieder mit Prozessen konfrontiert werden, die eher an Wasserfallmodelle erinnern. Oft äußern sich diese in zusätzlichen Quartalsplanungen zu den Sprintplanungen oder auch in Releaseplanungen (insb. im Embedded-Bereich). Auch in Form von Kalkulationen (bspw. Aufwand + Zeitschiene) größerer Umsetzungsthemen sowie dem Aufwand in Personentagen gemessen anstatt in Story Points oder der Abgabe von Nettokapazitäten trifft man auf diese. Insgesamt ist als Product Owner viel Abstimmungsarbeit gefordert und das nicht nur im eigenen Team. Manche Themen bedürfen einer teamübergreifenden Zusammenarbeit wie bspw. Anpassungen der Arbeitsweise sowie der Reihenfolgen bzw. Abhängigkeiten der Einzelthemen. Nach Scrum zu arbeiten bedeutet nach einem bestimmten Prinzip zu arbeiten. Ein wertvolles Hilfsmittel ist dabei die Ermittlung der Velocity. Um sich den Scrum-Prozess im von Wasserfallprozessen geprägten Projektalltag jedoch zu erhalten, ist oftmals ein hohes Maß an Kreativität gefragt. Die Ermittlung von Umrechnungsfaktoren für das Berechnen von Story Points in Personentage, das Aufsplitten der Velocity nach Arten der Arbeit für die Quartalsplanung sowie das Draufschlagen von Umsetzungszeit bei teamübergreifenden Themen erfordern ab und an unorthodoxe Ansätze, um diese erfolgreich in Scrum zu integrieren.

Obwohl sich die Entwicklung zwischen Product Owner mit bzw. ohne technischen Hintergrund in dieser Phase kaum unterscheidet, gibt es dennoch kleine Unterschiede. So kommt es öfter vor, dass Product Owner mit technischer Erfahrung stärker auf jene Aspekte der Softwareentwicklung fokussieren, die über die reine Feature-Entwicklung hinausgehen. Beispiele hierfür sind: Testautomatisierung, Logging, Build-/Deploymentprozesse, Monitoring/Alerting, technische Refactorings sowie technische Konzepte.

Auch wenn die Erfahrungswerte hier erst nach einiger investierter Dauer sichtbar sind, kann es sich lohnen, in diesen Punkten standhaft zu bleiben. Es ist viel wert, mehr vorausplanen zu können, etwas, das sich auch auf die Genauigkeit der Schätzungen auswirkt. Fehler sind nicht vermeidbar, dennoch spart es Zeit, einen Bug gar nicht erst zu produzieren bzw. diesen schneller in seiner Ursache analysieren zu können. Ein weiterer, nicht zu unterschätzender Aspekt ist hierbei auch die Planstabilität. Da die Präventivmaßnahmen immer Teil der Aufwände einer jeden User Story sind, lassen sich die Storys referenziell besser schätzen. Gleichzeitig fallen auch weniger überraschende Nacharbeiten an, die ungeplanten Aufwand darstellen und laufende Sprints stören.

Grundsätzlich ist jedoch davon auszugehen, dass Product Owner mit Entwicklungserfahrung genauso gut zur Betreuung eines nicht technischen Produkts geeignet sind wie Product Owner ohne Entwicklungshintergrund für ein technisches.

Fazit

In dieser spannenden Reise haben wir gesehen, wie Entwickelnde zu Visionären werden, über sich hinauswachsen und ihre eigenen Fähigkeiten und Perspektiven erweitern. Der Weg vom reinen Coden zur Produktvision und den damit verbundenen Aufgaben mag anspruchsvoll sein, kann sich für den einen oder die andere aber durchaus lohnen. Product Owner maximieren den Produktwert und unterstützen damit das Erreichen der strategischen Unternehmensziele.

Der Weg von Entwickelnden zum Product Owner verdeutlicht, wie vielseitig und wandelbar Karrieren in der agilen Softwareentwicklung sein können. Er zeigt, dass es nie zu spät ist, neue Wege einzuschlagen und sich weiterzuentwickeln. Etwas, das auch für uns als Unternehmen gilt. In einer Welt, die geprägt ist von Schnelligkeit und Agilität, ist es wichtig, anpassungsfähig zu bleiben, um zukunftsfähige Softwarelösungen für die Welt von morgen zu entwickeln.