Schnittstellenliebe und Sprint-Takt: Wie Alex, Product Owner bei STIHL Tirol, Technik und Teamführung im Scaled Scrum vereint

Einblicke aus unserer devstory-Session „Alex, Product Owner bei STIHL Tirol“

In der devstory „Alex, Product Owner bei STIHL Tirol“ erzählt Speaker Alex, wie ihn frühe Programmiererfahrungen und die Freude an Schnittstellenrollen in die Product-Owner-Welt geführt haben. Sein Werdegang ist ein Plädoyer dafür, Technikbegeisterung mit Teamarbeit, Struktur und Kommunikation zu verbinden. Der Rahmen: ein Scaled-Scrum-Setup mit mehreren PO-Teams – von Linux über Embedded bis hin zur App-Entwicklung – und Alex als Area PO für die Funktionssoftware-Entwicklung.

Gleich zu Beginn beschreibt er seine Motivation und seine doppelte Leidenschaft: Technik und Führung. Früh in der siebten Klasse am bayerischen Gymnasium kam er mit Informatik in Berührung – über „Programmieren mit Robert Karol“, eine bildungsorientierte Programmiersprache. Dieser erste Kontakt legte den Grundstein, den er später bewusst zu einer Schnittstellenkarriere ausbaute: „die beiden Herzen miteinander kombinieren“ – und genau das lebt er in der PO-Rolle.

Was wir in dieser Session mitnehmen:

• Product Ownership in einem Scaled-Scrum-Umfeld verlangt konsequente Synchronisation und Harmonisierung mit anderen PO-Teams und über Managementebenen hinweg.
• Der Alltag ist geprägt von dreiwöchigen Sprintzyklen, klaren Inkrementen und einem sorgfältig gepflegten Product Backlog – verankert in regelmäßigen Refinements.
• Neben Technikinteresse zählen vor allem Soft Skills: Teamfähigkeit, Kommunikationsstärke über Abstraktionsebenen hinweg und Organisationstalent.

Diese devstory ist eine Einladung, die Schnittstellenrolle nicht als Kompromiss, sondern als Kernkompetenz zu verstehen – besonders für alle, die Technik lieben und zugleich Verantwortung für Produkt und Zusammenarbeit übernehmen wollen.

Vom ersten Informatik-Funken zur Product-Owner-Rolle

Alex beschreibt einen klaren roten Faden: Technikaffinität plus Freude an führenden Schnittstellenpositionen. Der Auslöser war der Informatikunterricht in der siebten Klasse – und „Programmieren mit Robert Karol“ als Einstieg in algorithmisches Denken. Entscheidend ist dabei weniger das Tool selbst als der Aha-Moment: Programmieren befähigt dazu, systematisch zu denken und Lösungen zu strukturieren. Genau diese Denkweise prägt später den Umgang mit Backlogs, Sprints und Inkrementen.

Die PO-Rolle ist für Alex die konsequente Weiterführung dieses Interesses. Wörtlich: „Also man vereint beide Welten. Man ist zum einen eben in einer Schnittstellenposition und zum anderen eben natürlich in einem Technologie-Spektrum oder Kontext.“ Dieser Satz bringt den Charakter von Product Ownership auf den Punkt: Ohne Verständnis für den technischen Kontext verpufft die Wirkung Richtung Team. Ohne Schnittstellenkompetenz scheitert man an Erwartungen und Kommunikation. Die Stärke liegt im Verbinden.

Scaled Scrum bei STIHL Tirol: Area PO und mehrere PO-Teams

Um Alex‘ Arbeitsumfeld zu verstehen, hilft seine Einordnung: „Wir sind in einem Scaled Scrum Framework und ich bin der Area POs“. Er beschreibt ein Setup mit mehreren PO-Teams, unter anderem für Linux-Entwicklung, Embedded-Entwicklung und App-Entwicklung. Für die Funktionssoftware-Entwicklung ist er der Product Owner.

Was heißt das für den Tagesjob? In skalierten Setups ist kein PO ein Einzelkämpfer. Abhängigkeiten, Schnittstellen und Roadmaps müssen sich synchron bewegen. Alex fasst es zusammen als „synchronisiert und harmonisiert sich … sehr viel mit den anderen POs, auch über die verschiedenen Management-Hierarchiestufen“. Die Rolle verlangt also proaktive Abstimmung – lateral mit anderen Teams und vertikal mit Managementebenen.

Harmonisierung ist Arbeit am System

Harmonisierung bedeutet hier nicht nur Statusabgleich. Es geht um:

• ein gemeinsames Verständnis von Zielen, Prioritäten und Definition-of-Done;
• das Ausgleichen von Taktungen (wenn z. B. ein Team Features vorbereitet, das nächste sie integriert und ein drittes die App-Anbindung liefert);
• die rechtzeitige Sichtbarkeit von Risiken und Abhängigkeiten, bevor sie den Sprintabschluss gefährden.

Alex‘ Kurzformel „synchronisiert und harmonisiert“ steckt voller Konsequenzen: Transparenz im Backlog, klar definierte Schnittstellen und das bewusste Management von Abstraktionsebenen.

Dreiwöchige Sprints, Inkremente und die Ruhe der Struktur

Das Arbeitsmetronom ist klar: dreiwöchige Sprints. Gemeinsam mit dem Team plant Alex die Zyklen so, „damit wir eben zum Sprintende immer auch ein Inkrement in das Projekt oder in das Produkt dann beisteuern.“ Dieser Satz ist die Essenz agiler Produktarbeit: Der Takt ist nicht Selbstzweck, sondern eine Verpflichtung zur Lieferung eines echten Beitrags.

Sprint Planning als Übersetzungsleistung

Im Planning geht es um mehr als die Frage „Wieviel passt rein?“. Aus Alex‘ Beschreibung lässt sich ableiten:

• Planen heißt, Kontext und Kapazität abgleichen: Welche Aufgaben bringen das Produkt voran, ohne das Team zu überfrachten?
• Planen heißt, Abhängigkeiten zu antizipieren: Welche Schnittstellen müssen geklärt sein, damit die Arbeit fließt?
• Planen heißt, Inkrementdenken: Jede ausgewählte Arbeit muss auf ein lieferbares Ergebnis einzahlen.

Drei Wochen sind dabei lang genug, um Substanz zu schaffen, und kurz genug, um Feedback frühzeitig zu integrieren. Für die Funktionssoftware-Entwicklung ist dieses Gleichgewicht zentral.

Inkrementorientierung als Qualitätsanker

Ein Inkrement zum Sprintende ist nicht optional. Es ist die minimal nötige Qualität, die das Team und der PO einlösen. Der Vorteil: Regelmäßig sichtbare Fortschritte, schnellere Validierung, und die Reduktion von „Work in Process“, der sonst unsichtbar Kosten verursacht.

Das Product Backlog: Entscheidungen sichtbar machen

„Dann gehört natürlich auch … das Product-Backlog, das in meinem Verantwortungsbereich liegt, eben zu managen und via Refinements eben auch sukzessive immer auszudetailieren und eben zu managen und verwalten.“

Dieser Satz beschreibt die unterschätzte Kernarbeit vieler POs: Das Backlog ist nicht bloß eine Liste, sondern die konkrete Form von Produktentscheidungen.

Refinements als kontinuierlicher Erkenntnisprozess

Refinement ist bei Alex kein Einzelereignis, sondern „sukzessive“ – iterative Pflege, die ständig Wissen schärft:

• Anforderungen werden präzisiert, Annahmen überprüft, Risiken sichtbar;
• Umfang wird geschnitten, bis Einträge sprintfähig sind;
• Prioritäten werden angepasst, sobald neue Informationen auftauchen.

Wer Refinement ernst nimmt, reduziert Überraschungen in Planning und Review – und stärkt die Lieferfähigkeit des Teams.

Ownership über Inhalte und Schnittstellen

Als Area PO verantwortet Alex die Inhalte seines Backlogs – und er sorgt dafür, dass sie in das größere Ganze passen. Dieses „Einpassen“ ist die Schnittstellenarbeit zwischen PO-Teams: Einträge müssen kompatibel sein, Übergaben sind früh abzustimmen, und die gemeinsame Roadmap muss übergreifend Sinn ergeben.

Scrum-Events: Der Takt der Zusammenarbeit

Alex nimmt „durch meine Scrum-Rolle eben auch in den ganzen Scrum-Events“ teil. Diese Events sind das Rahmenwerk, das Sprints strukturiert:

• Sprint Planning: Ziele und Umfang festlegen;
• Daily: Fortschritt, Hindernisse, nächste Schritte;
• Review: Inkrement zeigen, Feedback erhalten;
• Retrospektive: Zusammenarbeit und Prozess verbessern.

Wichtig ist, dass die Events kein Formalismus sind, sondern Kommunikationsräume. Gerade in skalierten Umgebungen helfen sie, Fokus zu bewahren – und die Qualität des Inkrements mit der Realität der Abhängigkeiten abzugleichen.

Die äußere Schnittstelle: Ansprechpartner für die Funktionssoftware

Alex beschreibt sich als „nach außen die Schnittstelle, also wenn es Fragen zu unserem Produkt … gibt, das dann eben auch die Funktionssoftware-Entwicklung ist.“ Das bedeutet doppelte Verantwortung:

• Inhalte vertreten: Was ist drin, was kommt als Nächstes, warum ist etwas priorisiert?
• Sprache wählen: Vom technischen Detail bis zur Managementsicht – das Anliegen präzise übersetzen.

Diese Rolle braucht Konsistenz. Wer nach außen Klarheit vermitteln will, muss intern Klarheit herstellen – im Backlog, in den Definitionen, in den Sprintzielen.

Technikinteresse plus Soft Skills: Das PO-Mindset

„Grundsätzlich braucht es eben ein Technikinteresse … und dann gibt es eben ein großes Set an Soft Skills, das man bedienen muss.“ Alex nennt die zentralen Fähigkeiten:

• Teamplayer sein: „in einer Schnittstellenfunktion … Team-intern als auch Team-extern“
• Kommunikationsstärke: „immer die Sprache des Gegenübers verstehen und im besten Fall auch sprechen, sprich über verschiedene Abstraktions-Levels hinweg“
• Organisationstalent und Struktur: „Backlog-Refinement, Sprint-Plannings etc.“

Über Abstraktionsebenen sprechen können

Besonders prägend ist Alex‘ Hinweis auf Abstraktionslevels. Ein PO vermittelt zwischen Architektur, Implementierung, Nutzerbedarf und Managementsicht. Wer dort nicht sicher wechselt, erzeugt Missverständnisse. Praxisnah heißt das:

• technische Details so zu verdichten, dass Entscheidungen möglich werden;
• Produktziele so herunterzubrechen, dass Entwickler:innen konkrete Aufgaben sehen;
• Risiken so zu formulieren, dass ihre Auswirkungen nachvollziehbar sind.

Praktische Lehren für angehende und aktive POs

Aus Alex‘ Schilderungen lassen sich konkrete Handlungsempfehlungen ableiten:

1) Wähle einen klaren Sprint-Takt und schütze ihn

• Drei Wochen funktionieren, wenn sie Inkremente begünstigen.
• Vermeide, kurzfristige Störungen unreflektiert hineinzuziehen – sonst zerfällt der Takt.

2) Lebe Backlog-Ownership

• Pflege Einträge „sukzessive“ – lieber häufig und klein statt selten und groß.
• Mache Annahmen explizit und überprüfbar.
• Nutze Refinements, um Abhängigkeiten sichtbar zu machen, bevor sie im Sprint auftauchen.

3) Harmonisiere proaktiv im skalierten Umfeld

• Plane Synchronisationspunkte mit anderen POs ein.
• Kläre Versionen, Schnittstellen und Lieferfenster rechtzeitig.
• Stimme Prioritäten übergreifend ab, statt sie nur lokal zu optimieren.

4) Baue Kommunikationsroutine über Abstraktionslevels auf

• Halte jeweils zwei Varianten einer Erklärung bereit: technisch präzise und geschäftlich knapp.
• Frage aktiv nach, welche Ebene dein Gegenüber braucht.

5) Stärke dein Organisationstalent

• Lege einen festen Refinement-Rhythmus fest.
• Bereite Sprint Plannings vor – mit Zielen, Kandidaten und Abhängigkeiten.
• Dokumentiere Entscheidungen so, dass sie in der nächsten Abstimmung wieder auffindbar sind.

Typische Stolpersteine – und wie man sie entschärft

• Lost in Translation: Wenn technische Details ungefiltert ins Management getragen werden, gehen Bedeutung und Dringlichkeit verloren. Gegenmittel: Abstraktion bewusst wählen, Kernbotschaft zuerst.
• Backlog-Verwilderung: Ohne kontinuierliches Refinement häufen sich vage Einträge. Gegenmittel: Kleine, regelmäßige Pflegezyklen und klare Akzeptanzkriterien.
• Sprint-Überladung: Zu viel im Sprint gefährdet das Inkrement. Gegenmittel: Kapazität realistisch planen und „Cut Lines“ verabreden.
• Inselsprints im skalierten Setup: Lokale Sprintziele ohne Abstimmung kollidieren mit Abhängigkeiten. Gegenmittel: Cross-PO-Synchronisierung als festen Kalendereintrag.

Checkliste: Eine PO-Toolbox, inspiriert von Alex

• Sprint-Takt festlegen: Drei Wochen als Arbeitsrhythmus – und ihn aktiv schützen.
• Inkrementdenken verinnerlichen: Jedes Sprintziel muss in ein sichtbares Ergebnis münden.
• Backlog-Refinement institutionalisiert: Kurze, wiederkehrende Slots statt seltener Mammutsessions.
• Schnittstellenkarte pflegen: Wer abhängig von wem? Frühzeitig sichtbar machen.
• Kommunikationsleitfaden: Eine technische und eine Management-Version für zentrale Themen.
• Synchronisationsrituale: Regelmäßige Abgleiche mit Linux-, Embedded- und App-POs – früh, klar, dokumentiert.
• Event-Disziplin: Planning, Daily, Review, Retro als Qualitätsanker nutzen.

Zitate, die hängen bleiben

Fazit: Die Kraft der Schnittstelle

„Alex, Product Owner bei STIHL Tirol“ zeigt, wie viel Wirkung in einer gut gelebten Schnittstellenrolle steckt. Technikaffinität liefert das Fundament, doch erst Kommunikationsstärke, Teamgeist und Organisation verwandeln Backlogs in Inkremente und Abhängigkeiten in abgestimmte Lieferungen. Besonders im skalierten Umfeld zählt die Fähigkeit zu synchronisieren und zu harmonisieren – lateral wie vertikal.

Wer in die PO-Rolle hineinwachsen will, findet in Alex‘ Weg eine klare Orientierung: früh Technikverständnis aufbauen, dann bewusst die Brücke zu Menschen, Teams und Management schlagen. Und schließlich: den Sprint-Takt, das Inkrement und die Backlog-Disziplin als tägliche Praxis leben. Genau dort entsteht Produktqualität – sichtbar, wiederholbar, gemeinsam.

• 

  

  Christian, Funktions Entwickler bei STIHL Tirol

  Christian von STIHL Tirol gibt im Interview einen Einblick in seine Rolle als Funktions Entwickler, gibt Tipps für Beginner und erzählt von seinen eigenen Anfängen.

  Jetzt ansehen