In einer Branche wie unserer ist Ver\u00e4nderung eine Konstante. Neue Technologien, wechselnde Kundenbed\u00fcrfnisse sowie sich st\u00e4ndig weiterentwickelnde Arbeitsmethoden sind der Treibstoff dieser Industrie. Und f\u00fcr manche Entwickelnde kommt irgendwann auch der Zeitpunkt, an dem sie dar\u00fcber nachdenken, wohin ihre berufliche Reise als N\u00e4chstes gehen soll. Ein Weg, der immer wieder von Entwickelnden gew\u00e4hlt wird, ist die Transformation zum Product Owner.<\/p>\n\n\n\n
Dieser Karrierewechsel ist keine kleine Ver\u00e4nderung. Schlie\u00dflich verk\u00f6rpern Product Owner eine Schl\u00fcsselrolle in agilen Entwicklungsteams, die die Verantwortung f\u00fcr die Produktgestaltung und -umsetzung tragen. W\u00e4hrend Entwickelnde diejenigen sind, die den Code schreiben und technische Probleme l\u00f6sen, sind Product Owner f\u00fcr die Definition von Produktspezifikationen, die Priorisierung von Funktionen und die Kommunikation mit den Stakeholdern verantwortlich.<\/p>\n\n\n\n
In diesem Blogartikel nehmen unsere Xperten die Reise von Entwickelnden zum Product Owner genauer unter die Lupe. Wir werden die Gr\u00fcnde, die Motivationen und die Herausforderungen erkunden, die diese berufliche Ver\u00e4nderung begleiten. Der Beitrag richtet sich vorrangig an Entwickelnde, bietet jedoch auch spannende Einblicke f\u00fcr alle, die sich f\u00fcr die unterschiedlichen Rollen innerhalb der agilen Softwareentwicklung interessieren.<\/p>\n\n\n\n
Auch Entwickelnde k\u00f6nnen 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\u00fcr fachliche Entscheidungen liefern. Hinzu kommen unklar formulierte Anforderungen sowie technische Pattsituationen, die eine konsensuale L\u00f6sung erfordern. Trotz seiner Abgeschlossenheit bietet auch der Scrum-Prozess offene Flanken, die Entwicklungsteams mit dem Zeit-Qualit\u00e4t-Kosten-Zielkonflikt konfrontieren. Um diesen Herausforderungen zu begegnen, ben\u00f6tigt es oftmals Skills, die \u00fcber die Softwareentwicklung hinaus gehen. Kommunikation nimmt hier eine Schl\u00fcsselrolle ein.<\/p>\n\n\n\n
Entwickelnde rutschen in diese Situationen, weil sie ein bestimmtes Skillset mitbringen. Neben ihren fachlichen F\u00e4higkeiten interessieren sie sich f\u00fcr das gro\u00dfe Ganze und haben meist einen besseren \u00dcberblick \u00fcber das Projekt, als es der Teamumfang vorgibt. Sie schauen auch mal \u00fcber den Tellerrand, informieren sich \u00fcber die aktuelle Situation in anderen Teams und haben vor allem die Motivation, sich einzubringen, etwas vorantreiben zu wollen.<\/p>\n\n\n\n
Der Weg von Entwickelnden zum Product Owner kann unterschiedlich verlaufen. Bringen Entwickelnde die oben genannten Eigenschaften bereits mit, machen sich diese wom\u00f6glich selbst schon Gedanken \u00fcber eine berufliche Ver\u00e4nderung. Oftmals geht die Initiative jedoch auch vom Arbeitgeber aus, da man in der Vergangenheit ausgesprochen gut mit Konfliktsituationen umgegangen ist.<\/p>\n\n\n\n
Die Entscheidung, Product Owner zu werden, bedeutet allerdings einen gro\u00dfen Einschnitt in den bisherigen Karrierepfad. Die eigentliche Aufgabe, die man bisher ausge\u00fcbt hat, n\u00e4mlich das Entwickeln, f\u00e4llt in der Product-Owner-Rolle vollst\u00e4ndig weg. Grunds\u00e4tzlich sollte es jedoch m\u00f6glich sein, wieder in die Softwareentwicklung zur\u00fcck zu wechseln. Wer Lust hat, Product Owner zu werden, sollte sich auf jeden Fall einmal ausprobieren, nur so kann es Klarheit \u00fcber die Entscheidung geben.<\/p>\n\n\n\n
Dabei ist es nicht nur wichtig, Vertragsbedingungen und Dauer der Probezeit zu kl\u00e4ren, sondern auch die M\u00f6glichkeiten, sich an die neue Rolle heranzutasten. Hier bieten sich bspw. eine Assistenz des aktuellen Product Owner sowie verschiedene Arbeitsteilungsmodelle an.<\/p>\n\n\n\n
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 \u2013 egal ob Entwickelnde oder Stakeholder \u2013 kann es etwas dauern, bis sich diese an die neue Rolle gew\u00f6hnt haben.<\/p>\n\n\n\n
Anstatt zu entwickeln, wird der Tag nun durch bspw. Themenkl\u00e4rung, 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 \u00fcbernehmen. Schlie\u00dflich befindet sich die IDE (Integrated Development Environment) noch in Reichweite.<\/p>\n\n\n\n
Vor allem das Entwicklungsteam erwartet technische L\u00f6sungen 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\u00fcrlich in der Anfangsphase von vielen Seiten Verst\u00e4ndnis gibt, wird man relativ schnell vom Projektalltag eingeholt. Gef\u00fchlt 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\u00f6st werden k\u00f6nnen.<\/p>\n\n\n\n
Wer neu in der Rolle des Product Owner ist, kann sich vieles dadurch erleichtern, die eigenen M\u00f6glichkeiten der Leistbarkeit transparent zu machen. Auch das Aufzeigen von Konflikten durch Eskalationsbesprechungen sowie das Hinterfragen der gew\u00fcnschten Umsetzungstermine ist \u00e4u\u00dferst hilfreich. Es empfiehlt sich au\u00dferdem, das Ziel von Umsetzungsanforderungen genau zu ermitteln. Dadurch ergeben sich oftmals alternative L\u00f6sungen, die sich besser als die geforderten eignen. Wichtig ist darauf zu achten, das eigene technische Wissen immer zu abstrahieren, da Gespr\u00e4chsparteien oftmals keinen Background als Entwickelnde haben. Wer keine \u00dcberraschungen erleben m\u00f6chte, sollte alle Besprechungen verschriftlichen, insbesondere die Ergebnisse, auf die sich geeinigt wurde.<\/p>\n\n\n\n
Ist die Zeit, in der man sich noch an die neue Rolle gew\u00f6hnen musste, erst einmal vor\u00fcber, geht es auch schon in die Reifephase. Diese Phase ist ma\u00dfgeblich f\u00fcr die Entwicklung eines Product Owner und formt ihn letztendlich zu dem, was diese Rolle ausmacht.<\/p>\n\n\n\n
Jedes Projekt ist unterschiedlich aufgebaut und hat seine Eigenarten in Bezug auf die Gr\u00f6\u00dfe\/Anzahl der Teams sowie den Grad seiner Agilit\u00e4t. Auch die Organisationsart der Teams (horizontal vs. vertikal.) wirkt sich auf Entscheidungen aus und verlangt flexible L\u00f6sungsans\u00e4tze vom Product Owner. Kleinere und gr\u00f6\u00dfere Anpassungen der eigenen Arbeitsweise sind in dieser Phase unumg\u00e4nglich. Nur so kann in der Rolle vorangekommen und diese erfolgreich ausge\u00fcbt werden.<\/p>\n\n\n\n
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 \u00e4u\u00dfern sich diese in zus\u00e4tzlichen Quartalsplanungen zu den Sprintplanungen oder auch in Releaseplanungen (insb. im Embedded-Bereich). Auch in Form von Kalkulationen (bspw. Aufwand + Zeitschiene) gr\u00f6\u00dferer Umsetzungsthemen sowie dem Aufwand in Personentagen gemessen anstatt in Story Points oder der Abgabe von Nettokapazit\u00e4ten trifft man auf diese. Insgesamt ist als Product Owner viel Abstimmungsarbeit gefordert und das nicht nur im eigenen Team. Manche Themen bed\u00fcrfen einer team\u00fcbergreifenden Zusammenarbeit wie bspw. Anpassungen der Arbeitsweise sowie der Reihenfolgen bzw. Abh\u00e4ngigkeiten 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\u00e4gten Projektalltag jedoch zu erhalten, ist oftmals ein hohes Ma\u00df an Kreativit\u00e4t gefragt. Die Ermittlung von Umrechnungsfaktoren f\u00fcr das Berechnen von Story Points in Personentage, das Aufsplitten der Velocity nach Arten der Arbeit f\u00fcr die Quartalsplanung sowie das Draufschlagen von Umsetzungszeit bei team\u00fcbergreifenden Themen erfordern ab und an unorthodoxe Ans\u00e4tze, um diese erfolgreich in Scrum zu integrieren.<\/p>\n\n\n\n
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 \u00f6fter vor, dass Product Owner mit technischer Erfahrung st\u00e4rker auf jene Aspekte der Softwareentwicklung fokussieren, die \u00fcber die reine Feature-Entwicklung hinausgehen. Beispiele hierf\u00fcr sind: Testautomatisierung, Logging, Build-\/Deploymentprozesse, Monitoring\/Alerting, technische Refactorings sowie technische Konzepte.<\/p>\n\n\n\n
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\u00f6nnen, etwas, das sich auch auf die Genauigkeit der Sch\u00e4tzungen 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\u00f6nnen. Ein weiterer, nicht zu untersch\u00e4tzender Aspekt ist hierbei auch die Planstabilit\u00e4t. Da die Pr\u00e4ventivma\u00dfnahmen immer Teil der Aufw\u00e4nde einer jeden User Story sind, lassen sich die Storys referenziell besser sch\u00e4tzen. Gleichzeitig fallen auch weniger \u00fcberraschende Nacharbeiten an, die ungeplanten Aufwand darstellen und laufende Sprints st\u00f6ren.<\/p>\n\n\n\n
Grunds\u00e4tzlich 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\u00fcr ein technisches.<\/p>\n\n\n\n
In dieser spannenden Reise haben wir gesehen, wie Entwickelnde zu Vision\u00e4ren werden, \u00fcber sich hinauswachsen und ihre eigenen F\u00e4higkeiten und Perspektiven erweitern. Der Weg vom reinen Coden zur Produktvision und den damit verbundenen Aufgaben mag anspruchsvoll sein, kann sich f\u00fcr den einen oder die andere aber durchaus lohnen. Product Owner maximieren den Produktwert und unterst\u00fctzen damit das Erreichen der strategischen Unternehmensziele.<\/p>\n\n\n\n
Der Weg von Entwickelnden zum Product Owner verdeutlicht, wie vielseitig und wandelbar Karrieren in der agilen Softwareentwicklung sein k\u00f6nnen. Er zeigt, dass es nie zu sp\u00e4t ist, neue Wege einzuschlagen und sich weiterzuentwickeln. Etwas, das auch f\u00fcr uns als Unternehmen gilt. In einer Welt, die gepr\u00e4gt ist von Schnelligkeit und Agilit\u00e4t, ist es wichtig, anpassungsf\u00e4hig zu bleiben, um zukunftsf\u00e4hige Softwarel\u00f6sungen f\u00fcr die Welt von morgen zu entwickeln.<\/p>\n","protected":false},"excerpt":{"rendered":"
In einer Branche wie unserer ist Ver\u00e4nderung eine Konstante. Neue Technologien, wechselnde Kundenbed\u00fcrfnisse sowie sich st\u00e4ndig weiterentwickelnde Arbeitsmethoden sind der Treibstoff dieser Industrie. Und f\u00fcr manche Entwickelnde kommt irgendwann auch der Zeitpunkt, an dem sie dar\u00fcber nachdenken, wohin ihre berufliche Reise als N\u00e4chstes gehen soll. Ein Weg, der immer wieder von Entwickelnden gew\u00e4hlt wird, ist […]<\/p>\n","protected":false},"author":4,"featured_media":802,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[19],"tags":[],"class_list":["post-801","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-it-beratung"],"acf":[],"yoast_head":"\n