Interview: Mathias Kruse von Giesecke+Devrient über seine Rolle als Product Owner

Hallo Mathias. Du bist Product Owner im Bereich Currency Management Solutions bei Giesecke+Devrient. Was macht das Unternehmen?

Giesecke+Devrient – kurz G+D – ist ein internationaler Konzern für Sicherheitstechnologie. Unser Hauptsitz ist München, weltweit haben wir 12.000 Mitarbeiterinnen und Mitarbeiter. Wir sind einer der sogenannten Hidden Champions: Marktführer in vielen Bereichen, der breiten Bevölkerung aber relativ unbekannt – dabei kommen eigentlich alle mit uns in Kontakt. Giesecke+Devrient stellt z. B. Banknoten, Kreditkarten, Personalausweise und Gesundheitskarten her. Jeder Deutsche dürfte also mindestens eines unserer Produkte immer mit sich führen. Sein Geschäft fokussiert das Unternehmen auf vier Kernfelder: Bezahlen, Konnektivität, Identitäten und digitale Infrastrukturen. So schafft G+D innovative Sicherheitslösungen für den zuverlässigen Schutz rund um das analoge, elektronische und digitale Bezahlen, die digitale Verbindung von Menschen und Maschinen im Internet, den Schutz und das Management von Identitäten sowie sichere digitale Infrastrukturen.

Und in welchem Bereich arbeitest Du?

Meine Abteilung „Business Line Global Service“ ist in dem Bereich verankert, bei dem es sich um das physische Bezahlen dreht, also alles rund um Bargeld. Von der Bargeldherstellung über das Banknotendesign bis hin zur Bargeldvernichtung beschäftigen wir uns mit dem gesamten Lebenszyklus und der Bearbeitung von Banknoten und das für eine Vielzahl an Währungen. Ich bin im Bereich „Currency Management Solutions“ tätig, in dem es um Lösungen und Services rund um die Bargeldbearbeitung geht, also wenn das Geld im Umlauf ist. Das reicht vom kompakten Banknotenzähler für Casinos und Bankfilialen bis hin zu meterlangen Highspeed-Banknotenbearbeitungssystemen, die etwa in Zentralbanken und in Cash Centern eingesetzt werden. Cash Center sind stark automatisierte und hochsichere Bargeldfabriken, in denen das Bargeld in LKW-Ladungen ankommt, dort gezählt, geprüft, bearbeitet und wieder dem Bargeldkreislauf zurückgeführt wird. G+D stattet diese Fabriken mit Maschinen und Technologie aus bzw. stellt neue Cash Center schlüsselfertig bereit, von der Planung über den Bau bis hin zum Betrieb.

In meiner Abteilung betreuen wir all unsere Kunden (z.B. Zentralbanken) im After Sales, also wenn das System bereits verkauft ist. Schwerpunkt ist der Service der Maschinen. In großen Banken oder Casinos sind Techniker von uns permanent direkt vor Ort und betreuen die Maschinen, unterstützen die Arbeiter dort und führen korrektive und präventive Wartungen durch. Viele Kunden erlauben uns aber auch den Einsatz von Remote Services, mit denen wir uns direkt auf die Maschine schalten können oder den Technikern vor Ort per visueller Fernwartung Unterstützung bieten können. Sofern das Problem nicht aus der Ferne behoben werden kann, reisen unsere Techniker innerhalb kürzester Zeit zum Kunden. Eine Maschine darf nicht länger als wenige Stunden stillstehen.

Was ist deine Rolle? 

Als Product Owner Digital Service Products & Tools bin ich zuständig für Innovationsthemen im digitalen Servicebereich: Ich bin einerseits Product Owner von einem Fernwartungstool, dem G+D Visual Support. Mit diesem Tool ist es unseren Produktexperten möglich, sich von „draußen“ zum Techniker vor Ort in den Cash Room zu schalten und bei der Problemlösung mit Hilfe von Augmented Reality Technologie zu unterstützen. Das Tool wird aber auch für Schulungen und in vielen anderen Einsatzbereichen genutzt.

Darüber hinaus kümmere ich mich um Digitalisierungsprojekte. In meinem aktuellen Projekt arbeiten wir an einem neuen Business-Portal, welches das bestehende ablösen soll: Hierbei handelt es sich um eine geschlossene Umgebung, in der Kunden und Partner sowie unsere Mitarbeiter digitale Services nutzen können. Enthalten sind u. a. ein Learning-Management-System mit Trainings für Techniker, ein Webshop für Ersatzteile, ein Content Hub mit wichtigen Informationen, Dokumentationen und Tipps für Problembehebungen. Auch die Fernwartungstools lassen sich über das Portal aufrufen.

Konzipiert ist das Portal als responsive Webseite. Für die Service-Techniker im Feld wird es zudem eine Mobile-App geben. Das ist wichtig, weil einige Funktionen offline funktionieren müssen: Die Maschinen stehen bei vielen Banken im Keller, wo es nur schlechte bis gar keine Internetverbindung gibt. Aber auch hier sollen die Kollegen über das Portal an ihren Work Orders arbeiten können. Für dieses Projekt bin ich ebenfalls verantwortlich und übernehme die Rolle des Product Owners.

Wie groß ist das Team? Und wie seid ihr aufgestellt?

Das Team wurde für das Projekt komplett neu zusammengestellt und besteht aus einer Mischung aus G+D-Mitarbeitern und externen Dienstleistern. Neben mir als PO ist noch ein IT-Projektleiter an Bord. Die Kollegen, die sich um die Entwicklung des Portals kümmern, kommen von einem externen Dienstleister. Punktuell sind andere Mitarbeiter aus dem Unternehmen in das Projekt involviert, wenn es um spezielle Fragen oder Aufgaben geht, beispielsweise zum Datenschutz oder zur IT-Sicherheit.

Arbeitet ihr mit Scrum?

In der Entwicklung des Portals arbeiten wir mit dem Scrum-Framework. Die Entwickler organisieren sich in Sprints, halten ein Sprint Planning, Dailys, Reviews und Retrospektiven ab. Wir haben hier ein empowertes Team aus Fachexperten, dass die Entwicklung weitgehend eigenständig und selbstorganisiert plant. Ich nehme an den Events als Product Owner teil, da in der Entwicklung manchmal Fragen zur Priorisierung aufkommen und ich dahingehend Entscheidungen treffe.

Die Planung und Konzipierung des Projekts haben wir allerdings auf „klassischem Weg“ und nicht mit Scrum vorgenommen.

Was sind deine Aufgaben als PO im Projekt?

Als Product Owner kümmere ich mich um das Backlog-Management: ich nehme die Anforderungen aus dem Geschäft und die Kundenbedürfnisse an das Portal auf. Ich schreibe User-Stories und bin für die Priorisierung der Arbeitseinheiten verantwortlich. Ich bin Schnittstelle ins Unternehmen und kümmere mich um das Stakeholder-Management.

Wie oben schon angedeutet, arbeitet das Team eigenständig. Ich schaue den Entwicklern nicht über die Schulter bei ihrer Arbeit. Die User Stories schreibe ich gezielt so, dass die Entwickler zwar die Richtung sehen, in die es gehen soll, aber selbst die Entscheidung treffen können, wie sie dahin kommen.

Wie unterscheidet sich deine Rolle von der des IT-Projektleiters?

Während ich mich um die Anforderungen an das Projekt aus Geschäftssicht kümmere, steuert der IT-Projektleiter die Entwickler auf Seiten des Dienstleisters und unsere angrenzenden Fachabteilungen (z. B. der IT-Security). Das hat etwas mit den Berechtigungen und Abteilungszuschnitten unseres Unternehmens zu tun. Ich arbeite nah am Geschäft, habe den Bedarf und das Budget und beauftrage unsere IT. Die IT stellt einen IT-Projektleiter, der wiederum den Dienstleister beauftragt, sofern wir es nicht komplett intern abwickeln können. Es klingt kompliziert, ist aber eine tolle Aufteilung der Rollen und außerdem ist mein Kollege ein enorm erfahrener und wertvoller fachlicher Sparringspartner für mich. In meiner Rolle als PO habe ich eine Technologie-Entscheidung getroffen, der IT-Projektleiter kümmert sich um das Solution Design.

Du hast das Backlog-Management als eine deiner Aufgaben schon erwähnt: Anforderungen sammeln, User Stories schreiben. Machst Du das allein oder zusammen mit dem Team? 

Da ich die Anforderungen sammele, schreibe ich die User Stories und Epics selbst – allerdings auf einem relativ hohen, abstrakten Level. Daraus leiten sich die Entwickler dann ihre eigenen User Stories ab, die dann auf einer Umsetzungsebene geschrieben sind. Beide User-Story-Arten sammeln wir in unserem Product Backlog. Hierfür nutzen wir Azure Devops.

Ein gemeinsames Backlog ist wichtig, weil ich als PO immer alles im Blick haben muss. Ich befinde mich da wie beschrieben auf einer anderen Flugebene und vertraue darauf, dass die von den Entwicklern geschriebenen User Stories „meine“ übergeordneten Stories erfüllen. Wichtig ist, dass dem Team die Produktvision klar ist sowie jedes Release den Wert des Produktes maximiert.

Wie priorisiert ihr? Machst du das allein oder gemeinsam mit dem Team?

Die Priorisierung erfolgt in Absprache mit den Entwicklern, die wichtige Perspektiven aus der operativen Arbeit einbringen. Die letztendliche Entscheidung treffe aber ich.

In der Praxis läuft das so, dass ich die Richtung vorgebe. Es gibt dabei einen groben Phasenplan, den wir im Team besprechen. Zusätzlich machen wir eine Aufwandschätzung im Team, was im jeweiligen Sprint umgesetzt werden kann. Wenn im Doing dann rauskommt, dass wir das in der gegebenen Zeit nicht schaffen, dann müssen wir die Priorisierung ändern oder anpassen.

Welche Aspekte stehen bei der Priorisierung im Fokus? 

Einer der wichtigsten Entscheidungsfaktoren ist die Synchronisierung mit anderen Projekten. Wir gucken immer darauf, wie wir uns im Unternehmen gemeinsam verzahnen, damit keines der Projekte ins Stocken gerät.

Im Projekt ist es dann immer wichtig, die zentralen Dinge zuerst zu machen: Also immer beim Motor anfangen, bevor wir zur Sonnenblende kommen. Für uns sind das Herzstück der Anmeldeprozess, das zentralisierte User Management und der gesamte User Lifecycle. Neben diesen inhaltlichen Festlegungen spielt aber natürlich die Ressourcenplanung eine große Rolle: Wer ist eventuell im Urlaub oder krank? Und nicht zuletzt muss ich immer gucken, dass „alle einen Ball“, also aktuelle Aufgaben, haben.

Ich gehe hier nicht immer streng nach Checklisten oder Kriterien vor. Gerade bei kleineren Aufgaben oder Stories treffe ich manchmal auch Bauchentscheidungen.

Ein weiterer Aufgabenbereich ist das Stakeholder-Management: Wie beziehst Du deren Interessen und Anforderungen ein?

Ich sehe meine Hauptaufgabe darin, nutzerzentriert zu arbeiten, nicht stakeholder-zentriert. Mit Stakeholdern meine ich hier Kolleginnen und Kollegen, die ein Interesse am Portal bzw. Anforderungen daran haben. Natürlich muss das Projekt auf das übergeordnete Unternehmensziel einzahlen und wichtige Anforderungen aus dem Geschäft erfüllen. Hier bin ich im ständigen Austausch mit wichtigen Ansprechpartnern und wir haben regelmäßig Termine.

In erster Linie ist es meines Erachtens aber wichtig, nicht am Markt vorbeizuentwickeln und immer den Nutzer im Blick zu haben. Die Akzeptanz der Nutzer ist für das Portal entscheidend, deswegen haben wir sie von Anfang an mit ins Projekt einbezogen. Wir möchten ja, dass sie mit dem Portal arbeiten und es hilfreich finden. Ich habe im Vorfeld Interviews mit Endkunden geführt und hole immer wieder Zwischenfeedback von Nutzern ein. Aktuell führe ich beispielsweise 20 qualitative Interviews mit Endkunden und Partnern durch. In den Interviews versuche ich die wichtigsten Funktionen des Portals zu checken: Ich zeige den Interviewpartnern einen Prototyp des Portals und hole mir hierzu Feedback ein: Sind die Funktionen sinnvoll? Wie könnten wir es eventuell intuitiver gestalten? Ich stelle zudem konkrete Fragen z. B. zum Anmeldeverfahren. Außerdem hilft das die gebildeten Personas zu validieren.

Du hast einen beruflichen Hintergrund im Produktmanagement und Marketing. Was hat dich an der PO-Rolle gereizt? 

Mir ist die Stelle angeboten worden, ich habe mich also nicht aktiv auf die Rolle beworben. Ich habe mich aber dann bewusst dafür entschieden, die Rolle anzunehmen und Product Owner zu werden.

Ich habe in meinen vorherigen Positionen ähnliche Sachen gemacht. In vergleichbaren Projekten habe ich aber oft mehrere Rollen eingenommen und auch Personalverantwortung gehabt. In meiner jetzigen Rolle habe ich Verantwortung für den Projekterfolg und kann mich auf Produktthemen, Technologie und digitale Projekte fokussieren.

Diese klare Abgrenzung der Rollen finde ich persönlich superwichtig. Ich weiß, wofür ich verantwortlich bin und was ich mache – aber auch was nicht. Ich liebe die Aspekte Empowerment und Accountability: Vertrauen ins Team und die Fähigkeiten der Teammitglieder bei klarer Abgrenzung der Rollen. Für den Erfolg des Projekts ist es gut, wenn die Verantwortung auf unterschiedliche Rollen verteilt ist und so jeder ideal zum Projekterfolg beitragen kann. Das war in meinen vorherigen Positionen nicht immer so klar definiert, eher eine One-Man-Show. In dem beschriebenen Projekt funktioniert das sehr gut.