Product Owner: Aufgaben und Definition im Detail

Begriffe? Business Product Owner, Scrum Product Owner, Produkt Owner oder Produktowner mit K und die leidige PO Abkürzung (Business)

Scrum und Agilität haben seit vielen Jahren hohen Zulauf. Dadurch gibt es immer mehr Begriffe und Kombinationen. Was ist ein Product Owner und was nicht? Wir betrachten zunächst diese verbreiteten Kombinationen:

• Agile Product Owner / PO Agile
• Scrum Product Owner / PO scrum
• Business Product Owner / PO Business
• IT Product Owner / PO IT
• Software Product owner / PO Software
• Scrum Product Manager / Product Manager Scrum

Für uns bedeuten die oben genannten Begriffe im Kern das Gleiche: Wie schon im Abschnitt Definition Product Owner beschreiben, hieß die Rolle in Scrum ursprünglich „Product Manager“ und wurde später erst umbenannt. Manche Firmen machen einen Unterschied „Product Owner“ / „Product Manager“ und vergeben beide Rollen separat an verschiedene Personen. Davon raten wir ab, hier beschreiben wir die typische Dysfunktion und: Dieser Artikel im Ganzen sollte helfen zu verstehen, warum dies tatsächlich eine Rolle für eine Person ist.

Gegen Kombinationen mit Scrum oder Agile spricht grundsätzlich nichts. Fachkundige wissen aber ohnehin, dass die Rollenbezeichnung im Scrum Framework ihren Ursprung hat und dieses zur Gruppe der Agilen Frameworks und Methoden gehört.

Kombinationen mit der Art des Produkts (IT Product Owner, Software PO, Hardware PO:in etc.) oder auch dem konkreten Produktnamen kommen häufig vor. In einer Firma, die viele geschäftlich separat zu behandelnde Produkte auf dem Markt hat, kann es natürlich durchaus sinnvoll sein, dass die jeweilige Person den Produktnamen in die eigenen Rollenbezeichnung aufnimmt. Die Unterscheidung in Software und Hardware kann, generisch verwendet, hilfreich sein, aber wenn damit verschiedene Teile von ein und dem selben Produkt gemeint sind, lassen sich die geschäftlichen(!) Entscheidungen bzgl. des Produkts sich i.d.R. nicht sinnvoll aufteilen (Software und Hardware sind in vielen Produkten nicht eigenständig nützlich). In diesem Fall ist die Aufteilung eher ein Hinweis, dass die jeweilige Person sich zwar um relevante Teilaufgaben kümmert, aber wahrscheinlich noch nicht die volle Verantwortung und Autorität eines Product Owners im eigentlichen geschäftlichen Sinne hat.

Mit großer Wahrscheinlichkeit ist genau diese Schwierigkeit gegeben, wenn jemand als Technischer Produkt Owner bezeichnet wird. Ich (Timon) hatte selbst schon einmal den Jobtitel „Technischer Produktmanager / Technischer Produkt Ordner“ und deswegen läuft es mir heutzutage eiskalt den Rücken herunter, wenn ich diesen Ausdruck höre. In meiner Anfangszeit in der damaligen Firma habe ich versucht, die technischen Abhängigkeiten in einem unübersichtlich großen Backlog zu managen. Dieses Monstrum ist entstanden, weil mein Vorgänger vielen verschiedenen Stakeholdern jeweils zu oft zugesagt hat, statt, zumindest für seinen Teil des Produkts, konsistent in eine gute Richtung zu führen. Zugegeben: Auch für einen Produkt Ordner mit geschäftlichen Aufgaben ist dies eine anspruchsvolle Aufgabe (die sich aber gut erfüllen lässt, wenn man die Stakeholder nicht zu oft „alleine ans Buffet“ lässt, sondern systematisch mit Gruppen von Stakeholdern arbeteit – mehr dazu in den nächsten Abschnitten).

Wer von vornherein wenig / keine geschäftliche Autorität hat (im o.g. Beispiel verdeutlicht durch die Einschränkung auf Technik im Jobtitel) kann sich auf viel Frustration und große Schwierigkeiten einstellen. Für mich persönlich ging die Geschichte damals gut aus, weil wir einige Monate nach meinem Start tatsächlich die Struktur der Entwicklung verändert haben, weg von technisch fokussierten Teams, hin zu interdisziplinären Teams, die tatsächlich geschäftliche Aufgaben erfüllen konnten (in diesem Artikel beschreiben wir die Dynamik von Crossfunktionale Teams und Komponententeams genauer). Dadurch hat sich auch meine Aufgabe zu einer geschäftlichen Abgabe gewandelt, und es war ein riesiger unterschied zum Guten.

Die Bezeichnung „Business Product Owner“ ist eigentlich redundant. Wenn sie aber dennoch verwendet wird, lässt dies vermuten, dass es in der Firma auch „nicht-business“ POs gibt, die Fragmente von Produkten verantworten und letztlich eben keine geschäftlichen Entscheidungen treffen (siehe Beispiele in den letzten Abschnitten). Diese Aufteilung wird mit großer Wahrscheinlichkeit zu Dysfunktionen führen.

„Agile Product Ownership“ ist ein Oberbegriff für alle diese Tätigkeiten und impliziert, dass diese Verantwortung auch von mehr als einer Person getragen werden kann. Während dies für manche Aufgaben im Scrum Kontext unserer Meinung nach durchaus zutrifft, ist das gerade bei der PO:in als Entscheider:in sehr problematisch: Wenn es davon, für ein bestimmtes Produkt, mehr als eine gibt, handelt es sich im Scrum Sinne um Stakeholder, für die es legitim ist, Einfluss zu nehmen (oder es zu versuchen). Zusätzlich hilft es aber auch enorm, tatsächlich eine Entscheider:in in letzter Instanz zu haben, die bei Uneinigkeit zwischen den Stakeholdern, ausgehend von langfristiger eigener Verantwortung für den geschäftlichen Erfolg des Produkts, entscheidet. Übrigens gibt es unter dem Titel „Agile Product Ownership in a nutshell – auf Deutsch“ auch ein 15 minütiges Video auf Youtube, das nicht schnell gesprochen einen Einstieg in die Thematik bietet (deutlich weniger umfassend als dieser Artikel, war aber für mich selbst damals hilfreich als Startpunkt).

Mittlerweile kommen, vor allem auf deutsch, zusätzlich auch die folgenden Begriffe und Varianten vor: Productowner, Produkt owner, Produktowner, Product Ownerin und Product Owner:in. Das ist eigentich kein Wunder, denn auf deutsch würde man ein zusammengesetztes Wort erwarten und „Productowner“ oder „Produktowner“ schreiben, während im englischen die Begriffe auseinander geschrieben werden. Zudem schreibt sich „Produkt“ im deutschen mit „k“, so dass auch diese Variante auftaucht. Ich persönlich (Timon hier) nutze zwar am liebsten deutsche Begriffe, aber in diesem Fall sehe ich davon ab, weil der zweiten Teil „Owner“ generell nicht übersetzt wird. Und ich möchte lieber nicht im gleichen Fachbegriff eine deutsche Wortvariante mit einem englischen zweiten Begriffsteil mischen. In der jüngsten offiziellen Übersetzung des offiziellen Scrum Guides findet sich als geschlechtsneutrale Variante, die Schreibweise mit :in am Ende. Wir unterstützen die Verwendung geschlechtsneutraler Formen, auch wenn dies bei englischen Begriffen teilweise etwas eigenartig anmutet. Ich hoffe, Sie haben dafür Verständnis.

Die leidige PO Abkürzung (business) führt bei vielen Menschen zu Fragen wie „Was ist ein PO?“, „Was ist eine PO?“, „Was bedeutet PO?“. Kein Wunder, denn die beiden Buchstaben bedeuten ja sonst im deutschen etwas ganz anderes … Wenn wir mit der Abkürzung die Rolle bezeichnen, behalten wir die oben erwähnte :in Endung bei. PO:in ist zwar ein wenig sperrig, Aber immerhin kann man so auf einen Blick sehen, dass es sich um eine Rollenbezeichnung handelt und nicht um einen Körperteil.

Letztlich handelt es sich also bei diesen Begriffen um Synonyme mit kleinen Abweichungen in der Schreibweise. Wir haben Verständnis mit allen, die sich noch daran gewöhnen die empfohlenen Originalbegriffe zu verwenden.

Warum braucht es einen Product Owner?

Viele Stakeholder

Es gibt viele Personen, die ein legitimes Interesse an den Ergebnissen der Entwicklungsarbeit haben. Wir verwenden für sie den Sammelbegriff „Stakeholder“. Dazu gehören Kunden, Nutzer, Führungspersonen, Manager, Partnerunternehmen und viele Weitere. Die Stakeholder haben grundsätzlich unterschiedliche Macht zu beeinflussen, was mit dem Produkt passieren soll. Sie haben aber alle auch eigene Ziele und sind nicht nur dem Produkt verpflichtet. Die PO:in ist die einzige Person, die primär dem Erfolg des Produkts verpflichtet ist und auch die einzige Person mit der Autorität zu entscheiden, was letztlich wirklich entwickelt wird.

Das folgende Video führt anschaulich vor, was passiert, wenn es keine echte PO:in gibt. Vielleicht kennen sie solche Situationen aus ihrer Arbeitspraxis. Wir haben ähnliche Entwicklungen leider schon häufig beobachtet. Die im Filmausschnitt gezeigte Produktentwicklung hat übrigens tatsächlich stattgefunden und über Jahrzehnte für sehr viel Geld zu diesem fragwürdigen Ergebnis geführt:

Produktivitätsgewinn durch echte PO

Grundsätzlich bietet Scrum einer Organisation eine Reihe von Chancen für Produktivitätsgewinne (hier im Einzelnen erklärt). Damit einige davon tatsächlich eintreten, muss die PO-Rolle tatsächlich mit der dafür nötigen Autorität ausgestattet sein. Z.B.:

Die meisten Ideen in einer Organisation funktionieren letztlich schlecht. Dazu gibt es viele Statistiken, z.B. scheitern 7 von 10 StartUps im Portfolio eines typischen Investors. Dabei werden diese StartUps einschließlich ihrer Ideen vor dem Investment einer sorgfältigeren Untersuchung (Due Diligence) unterzogen, als dies typischerweise mit Ideen innerhalb eines Unternehmens passiert.

• Es erfordert die Autorität und die Distanz einer PO:in, um jede Idee immer erst als mögliches Experiment zu betrachten, viele abzulehnen und andere während und nach der Umsetzung sehr aufmerksam zu beobachten. Dem Pareto-Prinzip (80/20) folgend schafft man z.B. ein vierfaches an Ergebnis durch Konzentration auf die die jeweils wichtigsten 20% des wirksamsten Aufwands für fünf Ideen.
• Wenn die PO:in große Entscheidungen selbst trifft, dann erfolgen Entscheidungen viel schneller, als wenn erst ein Gremium oder weitere Höhergestellte diese treffen müssen. Die Geschwindigkeit von Entscheidungen hat in komplexen Umfeldern, in denen nicht jede Idee funktioniert, enormen Einfluss auf den geschäftlichen Erfolg eines Produkts.
• Die Motivation der Teams, die mit der echten PO:in zusammenarbeiten, ist sehr hoch. Sie wissen, dass ihre Vorschläge Bedeutung haben und können den Pfad, den ihr Produkt nimmt, unmittelbar beeinflussen. Im Kontrast dazu: Teams die mit Menschen arbeiten, die keine eigene Entscheidungsbefugnis haben, erleben sich oft als ohnmächtig, unbedeutend und sind in der Folge entsprechend weniger motiviert.

Das Product Backlog – Wichtigstes Werkzeug

Das Product Backlog ist das Hauptwerkzeug einer PO:in. Es ist eine geordnete Liste von allen Arbeitspaketen (Einträgen), die für die Zukunft geplant sind. Es repräsentiert den aktuellen Plan für die zukünftige Arbeit des/der Entwicklungsteams. Welche Reihenfolge (und damit Priorität) die Einträge im Product Backlog haben, bestimmt die PO:in.

Für die Anpassungsfähigkeit (oder Agilität) einer Organisation ist es von entscheidender Bedeutung, dass die Prioritäten transparent sind. Das Werkzeug dafür ist Product Backlog.

Damit das Product Backlog seine Funktion erfüllen kann, arbeitet das Entwicklungsteam nur an den Arbeitspaketen aus dem Product Backlog und nimmt keine neben-Aufträge (z.B. direkt von Stakeholdern) an. Die Stakeholder sind eingeladen ihre Ideen, Wünsche, Kommentare etc. zu äußern, und damit das Product Backlog zu beeinflussen, Entscheidungen liegen letztlich bei der PO:in.

Product Owner Aufgaben und Beziehungen

Wir stellen hier die Aufgaben der Product Owner:in im Kontext der 5 Beziehungen einer PO:in vor. Daraus ergeben sich ihre Eigenschaften und Fähigkeiten, die wir weiter unten im Detail vorstellen.

1. Aufgabe Product Owner mit Entwicklungsteams

Die Entwicklungsteams sind nicht nur Umsetzer, sondern helfen der PO:in auch, das bestmögliche Produkt für Kunden/Nutzer zu erstellen. Dazu müssen sie sehr konkret verstehen, was sie als nächstes erstellen sollen und ob Dinge, die sie bereits erstellt haben, ihre jeweiligen Ziele erreicht haben. Die PO:in muss wiederum wissen, was die Teams dafür brauchen und was die ggf. bereitstellen kann.

Die PO:in sorgt für ein gemeinsames Verständnis der Ziele der Produktentwicklung. Die Erstellung der Produkt Vision und Produkt Ziele (i.d.R. im engen Kontakt mit Stakeholdern) gehört zu den essentiellen Product Owner Aufgaben. Sie muss Vision und Ziele immer wieder verständlich und empathisch allen beteiligten Personen vermitteln. Speziell im Kontakt mit Entwicklungsteams ist es wichtig, alle großen und kleinen Aufgaben immer wieder in den Kontext der großen Vision stellen. Hier hilft es sehr, ein guter Storyteller zu sein. Eine andere wichtige Fähigkeit in Kontakt mit Entwicklern liegt darin, die anstehenden Arbeitspakete so vermitteln, dass sie keine Lösung vorgeben. Dazu ist es notwendig, sein eigenes Denken und Kommunizieren in Problem- und Lösungs-Domäne zu unterscheiden.

2. Aufgabe Product Owner mit Stakeholdern

In diesen Beziehungen liegt ein Risiko, dass in der Praxis oft zu Schwierigkeiten führt:

Wer als PO:in mit verschiedenen Stakeholdern jeweils einzeln spricht, bekommt mit großer Wahrscheinlichkeit bald Probleme, denn: Man wird gelegentlich der Verlockung nachgeben, Zusagen zu machen, selbst dann, wenn ein klares „Nein“ eigentlich die bessere Idee wäre. Aber der jeweils gleichen Person über lange Zeit immer wieder ausschließlich „Nein“ zu sagen ist für viele schwer auszuhalten.

Das ist nur menschlich, führt aber langfristig zu großen Schwierigkeiten:

Wer zum Beispiel regelmäßig mit fünf verschiedenen Stakeholdern in Kontakt ist, wird auf diese Weise (selbst durch nur gelegentliche Zusagen) schnell ein viel zu volles Produkt Backlog haben. Diese vielen Einträge sind dann aber über lange Zeit nicht umsetzba. Transparenz darüber führ nur zu noch mehr Sorgen und Forderungen der Stakeholder.

Die Konsequenz ist letztlich eine große Unzufriedenheit aller Beteiligten. Um es noch schlimmer zu machen:

Das Zielbild das wir anstreben sieht anders aus:

Die PO:in und die Entwicklungsteam(s) arbeiten darauf hin, das bestmögliche Produkt für die Stakeholder zu erstellen. Die Stakeholder wollen i.d.R. wissen, welche Priorität die Funktionen haben, die ihnen jeweils besonders wichtig sind, und fragen häufig auch nach Gründen für die gewählte Priorisiereung. Eine gute PO:in bezieht die Stakeholder:innen regelmäßig mit ein. Sie nimmst sich Zeit, um die Ziele und Bedürfnisse ihrer Stakeholder:innen zu erfahren und andere Informationen zu sammeln, die ihr helfen, sinnvolle Prioritäten zu setzen.

Der Schlüssel zur Vermeidung der o.g. Probleme liegt darin, meistens nicht mit den Stakeholdern einzeln zu sprechen sondern sie stattdessen als Gruppe zu betrachten und auch als Gruppe zusammen zu bringen. Auf diese Weise vermeiden wir die Phantasie das jeder alleine am Buffet wäre. Gerade wenn einige Stakeholder viel Macht haben hilft es enorm, hier in Echtzeit für Transparenz bzgl. der vielen verscheidenen Wünsche zu sorgen und Konflikte unter den Stakeholdern austragen zu lassen.

Dazu benötigt die PO:in häufig die Fähigkeit, Gruppen souverän zu leiten, d.h. Gruppen-Prozesse zu facilitieren. Dabei können Scrum Master oder Agile Coach hilfreich sein, indem sie einen Teil der Facilitation übernehmen oder die PO:in mit den nötigen Methoden vertraut machen. Weiter unten im Abschnitt „Umgang mit Stakeholder-Input“ nenn wir einige Beispiel.

Zusätzlich kommt die schon oben erwähnte Fähigkeit, Problem- und Lösungs-Domäne zu unterscheiden, ebenfalls zum Tragen. Manche neigen dazu, direkt die vom Stakeholder vordergründig gewünschte Lösung in ihr Product-Backlog aufzunehmen. Im Hinblick auf ein langfristig erfolgreiches Produkt lässt sich jedoch noch mehr gewinnen, wenn die PO:in stattdessen gezielt die Probleme / Herausforderung Stakeholder über das Produkt Backlog in die Entwicklung hineingibt. Verschiedene Lösungen werden dann von den Entwicklern vorgeschlagen, was unter anderem regelmäßig, ermöglicht Lösungen zu finden die in einem Bruchteil der Zeit umsetzbar sind, weil technischer Sachverstand in den Entwurf der Lösung einfließt. Um zu Lösungen zu kommen die für Stakeholder gut funktionieren und attraktiv sind brauchen die Entwickler tieferes Kundenverständnis. Die PO:in hat die Aufgabe dies zu ermöglichen und fördern (mehr dazu weiter unten).

Um die Reihenfolge der Einträge im Product Backlog festzulegen, dessen Transparenz und Verständlichkeit sicherzustellen, bedient sich eine PO:in verschiedener Werkzeuge und Modelle, auf die wir im Abschnitt „Fähigkeiten“ eingehen.

3. Aufgaben Product Owner bzgl. Beziehung zwischen Stakeholden und Entwicklungsteams

Typische Dysfunktion 1 – Stakeholder überspringen PO und beauftragen direkt einzelne Entwickler

In manchen Unternehmen wenden sich Stakeholder direkt an einzelne Entwickler, um jeweils andere Wünsche umgesetzt zu bekommen. Da die Entwickler in einer solchen Umgebung nicht systematisch planen und als Team agieren können, entsteht eine Fülle von Folgeproblemen, wie z.B. eine sehr ineffiziente von Einzelpersonen abhängige Arbeitsweise, inkonsistentes Produkt, fehlende Verlässlichkeit in der langfristigen und ggf. sogar in der mittelfristigen Planung etc.

Typische Dysfunktion 2 – PO hat als einzige Person Kontakt zu Nutzern oder Kunden

Um die o.g. typische Dysfunktion 1 und ihre Folgeprobleme zu vermeiden, tendieren manche Unternehmen, die wir heute antreffen, zum anderen Extrem: Dort haben die Entwickler kaum Kontakt mit Nutzern und sehen nicht, wie die Nutzer mit ihrem Produkt interagieren. Das führt über mit der Zeit dazu, dass sie nicht bei Produktentscheidungen sinnvoll mitdenken und mitreden können. Und während sie jeden Tag in der Entwicklung kleine Produktentscheidungen treffen, liegen sie häufig falsch, was zu Mehrarbeit führt. Die Motivation sinkt sehr schnell. Das wirksamste Mittel dagegen ist die direkt Verbindung des Teams mit Nutzern und ein Angemessene Art – und dafür ist die PO:in verantwortlich.

Wie die Zusammenarbeit von Stakeholdern und Entwicklungsteams produktiv wird

Essenziell ist, dass die Interaktion zwischen Stakeholdern und Entwicklern WEDER durch die Stakeholder initiiert wird (siehe Dysfunktion 1), NOCH gänzlich vermieden wird (siehe Dysfunktion 1):

Der Schlüssel für das produktive Miteinander liegt in PO Rolle: Themen, die durch die PO:in zur weiteren Klärung identifiziert wurden, werden auf ihre Entscheidung und Initiative hin zwischen Entwickler und Stakeholdern geklärt. Durch diese Führung sind die Entwickler im Kontakt mit den Stakeholdern in einer aktiven Rolle, was beide oben genannten Funktionen effektiv vermeidet.

Die Entwickler:innen arbeiten darauf hin, das bestmögliche Produkt für die Stakeholder zu erstellen. Sie müssen den Kontext für Features kennen und detailliertes Wissen in der Kunden-Domäne haben. Dies funktioniert hervorragend, wenn Teams ihre Lösungen in Zusammenarbeit mit Stakeholdern entwickeln. Dabei lernen sie nicht nur die oberflächlichen Ziele und Probleme der Kunden kennen, sondern auch die darunter liegenden größeren Zeile und Probleme, was langfristig zu besseren Lösungen führt.

Das kontinuierliche Funktionieren dieser Beziehung ist eine der wichtigsten Aufgaben einer PO:in. Dazu verbindet sie regelmäßig Stakeholder mit den Entwicklern und fungiert nicht als Ersatzkunde oder Vertreter der Kunden. Es ist die Aufgabe der PO:in sicherzustellen, dass die Entwickler ihre anstehende Arbeit verstehen. Aber sie erfüllt dies in der Regel nicht, indem sie alles selbst erklärt, sondern indem sie die notwendigen Stakeholder mit dem Team direkt verbindet.

Das führt nebenbei auch zu einem hohen Maß an Identifikation der Entwickler mit ihrem Produkt, was große Auswirkungen auf die Produktqualität und die Motivation hat. Das ist im Übrigen genau das, was mit dem Scrum-Wert „Commitment“ gemeint ist.

In diesem Video sehen ein Beispiel, wie es aussieht, wenn das Team sehr kundennah arbeitet:

Product Owner Training mit Zertifizierung

Wir legen Wert darauf, dass Sie essentielle Zusammenhänge und Methoden verstehen und unmittelbar selbst anwenden.

Training zur Product Owner Zertifizierung

4. Aufgaben Product Owner mit höherem Management

Höhere Manager außerhalb der Produktgruppe (Portfoliomanager, C-Level-Führungskräfte usw.) betrachten die PO:in als die endgültig Verantwortliche für den Produkterfolg. Sie ist dafür verantwortlich, den langfristigen Entwicklungsfortschritt sichtbar zu machen und das Mandat des höheren Managements zu realisieren, um die gewünschten Auswirkungen (z. B. ROI oder Steigerung des Marktanteils) zu erreichen.

Höheres Management ist in der Regel auch der Personenkreis, der die Autorität besitzt die Organisationsstruktur / das Organisationsdesign zu verändern. Die PO:in arbeitet mit dem höheren Management und den Scrum Master:innen zusammen, um die Organisationsstruktur kontinuierlich zu verbessern.

5. Zusammenarbeit mit Scrum Master

Die Product Owner Aufgaben und Beziehungen 1.-4. entstehen unmittelbar aus der Verantwortung der PO:in für die Arbeit am Produkt. Die Beziehung zum Scrum Master ist anders. Hier geht es darum, wie sich die Fähigkeiten und das Verhalten der PO:in mit der Zeit ändern. Die Änderung bezieht sich nicht auf das konkrete WAS die PO:in macht, sondern daruf WIE die etwas macht. Ein Scrum Master ist ein Coach für die PO:in und kennt ihre Herausforderungen, Sorgen und Fragen. In schwierigen Momenten kann er ein wohlwollender Zuhörer sein. Scrum Master:innen beobachten und geben Feedback, dadurch unterstützen sie die PO:in in fachlicher und menschlicher Hinsicht in ihrem Wachstum. Außerdem hilft ein Scrum Master der PO:in in Fragen rund um Facilitation von Gruppen von Stakeholdern und in ihrer Arbeit mit Entwicklern.

Eigenschaften

Autorität

Die wichtigste Eigenschaft einer PO:in ist ihre alleinige Autorität über das “Was” für das Entwicklungsteam zu entscheiden. Dabei ist sie aber keinesfalls eine Despotin, die auf niemanden hört und nur den eigenen Vorstellungen folgt. Das wäre tatsächlich ein schneller Weg in den Ruin. Eine gute PO:in folgt häufig den Vorschlägen ihrer Kollegen, aber wenn es drauf ankommt, wissen alle, dass sie final entscheiden kann. Häufig ist eine gute PO:in eine hochrangiger Entscheider:in in einem Unternehmen, zum Beispiel die Leiter:in der Produktentwicklung.

Typische Herausforderung – Vorgesetzte mitnehmen:

In den meisten Fällen hat eine PO:in außer Kunden und Nutzern auch Vorgesetzte Personen innerhalb des Unternehmens, zum Beispiel die Geschäftsführer:in. Selbst wenn ein CEO die Rolle der PO:in übernimmt, gibt es typischerweise Investoren, an die sie regelmäßig berichtet. Es gibt also immer Menschen, die einem theoretisch vorschreiben könnten, was man tun soll.

Autorität bedeutet in diesem Kontext, dass eine PO:in zwar ggf. mit Vorgesetzten bzgl. der Vision und Ziele eng zusammenarbeitet, aber nicht unbedingt den Vorschlägen ihrer Vorgesetzten folgen muss, wenn es um Ordnung und Inhalt der Einträge im Product Backlog geht. Um diese Autorität zu erhalten, braucht es etwas Vertrauen zum Start und eine kontinuierliche Pflege und weiteren Ausbau dieses Vertrauens während der Arbeit. Dazu ist es extrem hilfreich, dass wir in Scrum iterativ arbeiten und dadurch regelmäßig Ergebnisse zeigen können.

Typische Dysfunktion – keine Autorität:

Eine der häufigsten Dysfunktionen, die wir in Unternehmen antreffen ist eine PO:in ohne Autorität. Dann muss sie bei allen ansatzweise wichtigen Entscheidungen ein Gremium zusammenrufen oder ihre Entscheidungen immer wieder ändern, weil andere Personen im Hintergrund tatsächlich entscheiden. Die Folgen für das Produkt kann man im Video oben gut nachvollziehen. Zusätzlich ist es ein sehr unangenehmer Zustand für die Entwickler und die betreffende PO:in selbst.

Unternehmerische Herangehensweise

Eine großartige PO:in denkt und handelt wie ein Entrepreneur. Die aktuelle Forschung beschreibt diese Herangehensweise mit dem Wort: Effectuation. Es handelt sich um eine spezielle Logik, mit der Entscheidungen getroffen werden. Sie geht von der Annahme aus, dass die Zukunft nicht vorhersagbar ist und konzentriert sich auf das Mögliche im Jetzt und auf das Ausnutzen der sich bietenden Möglichkeiten.

In jedem Fall ist eine gute PO:in eine wirtschaftlich affine und ökonomisch denkende Person. Sie hat zudem eine Affinität zur Domäne der Kunden, Nutzer und ggf. anderer Stakeholder.

Typische Dysfunktion – “technischer” Product Owner

Wir sehen häufig, dass Unternehmen die Funktion eines “technischen” POs einführen. Tatsächlich braucht ein Product Owner nur so “technisch” zu sein, wie seine Nutzer oder Kunden es sind. Technische Entscheidungen bzgl. der Implementierung werden in Scrum von Produkt-Entwicklern getroffen.

Typische Ursachen für den Bedarfs der Unternehmen nach einem „technischen PO“ ist, dass es interne Entwicklungsteams gibt, die selbst keine sichtbare Funktionalität liefern können und jemanden brauchen, der deren Aufgaben managt. Die Einführung der Funktion „technischer PO“ verschlimmert und institutionalisiert das Problem in der Regel, statt es zu beheben.

Eine Person als Product Owner je Produkt

Hier zunächst ein Zitat aus dem Scrum Guide:

“The Product Owner is the sole person responsible for managing the Product Backlog.”

Warum ist es wichtig, dass die PO:in genau eine Person ist? Gegenfrage: Wer ist autorisiert die endgültige Entscheidung über die Reihenfolge zu treffen, wenn es zwei oder mehr PO:innen gibt?

Und was passiert bei vielen Entwicklungsteams für ein Product? Wieder aus dem Scrum Guide:

“Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product.”

Auch in diesem Fall gibt es nur eine PO:in. Sie kann Aufgaben an eine oder mehrere andere Personen delegieren. Sie kann sehr viel Unterstützung in Anspruch nehmen. Strukturell ist aber klar, dass sie die Person mit der endgültigen Entscheidungsautorität über die Reihenfolge der Einträge im Product Backlog ist.

Welche Fähigkeiten hat ein Product Owner?

Produkt-Vision vermitteln

Eine Vision kann in der Regel nur schwer durch irgendein Dokument vermittelt werden. Man ist dann von einer Vision ergriffen, wenn man sie mitfühlen kann.

Wenn man sich hineinversetzt hat in eine Situation und ein konkretes Bedürfnis spürt. Wenn man dann verstanden hat, dass man heute keine adäquate Lösung finden kann und vielleicht eine Frustration oder Traurigkeit darüber fühlt. Wenn man dann den möglichen neuen Weg oder das neue Werkzeug vorgestellt bekommt, und am eigenen Leib die kleine Freude der neuen Realität verspürt. Diese neue Welt ist heute noch nicht real, aber durch die gemeinsame Arbeit ist es möglich sie zu erreichen.

Die Vision bildet ein wichtigen Rahmen für die Arbeit der Entwicklungsorganisation. Sie hilft Entwicklern in kleinen und mittleren Implementierung-Fragen, die mehrmals täglich auftreten, gute Entscheidungen zu treffen. Sie hilft allen Beteiligten, sich in Diskussionen auf das Wesentliche zu fokussieren, denn es gibt durch die Vision eine gemeinsames Verständnis davon, was das Wesentliche ist. Die abgestimmte Vision hilft einer PO:in in Gesprächen mit Stakeholdern die Richtung beizubehalten, anstelle auf Wunsche einzelner unnötig oft die Richtung zu verändern.

Die Geschichte der Vision erzählt die PO:in immer wiederm und dabei wird sie immer facettenreicher. Sie passt sie an die Zuhörer an. Je nach Kontext brauchen diese mehr oder weniger Information, um sich in die Situation eines Kunden/Nutzers hineinversetzen zu können. Man nennt diese Erzähl-Fähigkeit auch Story-Telling und sie lässt sich gut einzeln erlernen. (Achtung, hier geht es nicht darum, Anforderungen im User-Story Format aufzuschreiben sondern um tatsächliches Sprechen mit Menschen).

Häufig geht es nicht darum, die ganze Vision zu erzählen, sondern darum den Kontext zu den kleineren aktuellen Aspekten der Arbeit herzustellen. Zum Beispiel: Wenn sich das Scrum-Team am Anfang eines Sprints auf ein Sprint-Ziel einigen will, ist es sehr hilfreich zu überprüfen, inwiefern dieses auf die Vision einzahlt.

Die Problem- und Lösungs-Domäne unterscheiden

Beispiel:

Stellen Sie sich vor sie gehen zu einem Designer / Künstler und bestellen bei ihm eine Hochzeitskarte für ihre Hochzeit:

Variante A: Dabei beschreiben sie genau, wo was abgebildet sein soll und in welcher Farbe, mit welchen Farben bzw. Computerprogrammen gemalt wird und wie auf was gedruckt werden soll.

Variante B: Sie beschreiben, was das Bild auf der Karte vermitteln soll, welche Stimmung erzeugt werden soll und wie hochwertig die Wahrnehmung der Karte sein soll.

Im Fall A befinden sie sich voll in der Lösungs-Domäne. Einem Experten ist dadurch ggf. nicht klar, was sie eigentlich mit der Hochzeitskarte erreichen wollen. Wenn er den Auftrag übernimmt, macht er ihn stumm und nach Anleitung und wenn etwas schief läuft, ist es ihre Verantwortung.

Im Fall B befinden wir uns in der Problem-Domäne. Durch ihre Aussagen erzeugen sie den Wunsch des Experten mehr zu verstehen, zu fragen und Ihnen kreative Vorschläge zu machen. Er fühlt sich respektiert und wertgeschätzt und macht möglicherweise exzellente Vorschläge auf die Sie selbst nie gekommen wären.

Eine PO:in bringt im besten Fall KEINE Anforderungen (definiert in der Lösungsdomäne), sondern stattdessen die dahinter liegenden Probleme zu ihren Entwicklungsteams. Zusätzlich vermittelt Sie den Kontakt zu denjenigen Stakeholdern, die ihnen dabei helfen können mögliche Detailfragen zu klären. Auf diese Weise stellt sie nicht nur die Motivation sicher, sondern ermöglicht sich selbst und dem ganzen Team viel effektiver zu Arbeiten. Warum?

Typischerweise gilt das Pareto-Prinzip. Mit 20% des Aufwands sind 80% der gewünschten Ergebnisse erzielbar. Indem die Lösungsfindung den Experten überlassen wird, werden für die meisten Herausforderungen verschiedene Implementierungswege vorgeschlagen, mit verschiedenen Vor- und Nachteilen. Durch geschicktes Auswählen ist es häufig möglich mit einem Bruchteil des Aufwands die gewünschten Ergebnisse zu erreichen.

Es ist sehr wertvoll, in der Problem-Ebene strukturiert im Detail denken und formulieren zu können. Hier helfen unter anderem die folgenden Werkzeuge, auf die wir in unseren Product Owner Schulungen näher eingehen:

• Jobs to Be Done
• Outcome Based Innovation
• Impact Mapping
• Facilitation von Gruppenprozessen

Bzgl. der Gestaltung von Gruppenprozessen bekommt die PO:in bei Bedarf Unterstützung von ihrem Scrum Master. Das ist insbesondere in der frühen Phase der Zusammenarbeit empfehlenswert.

Verständnis der Product Backlog Einträge sicherstellen

Wie oben beschrieben, verbindet eine PO:in die Entwickler direkt mit Nutzern und anderen Stakeholdern, damit sie die Anforderungen so detailliert verstehen können, wie sie es für die Entwicklung brauchen. Wie stellt man aber sicher, dass diese Unterhaltungen effektiv, verbindend und lebendig ablaufen? Das ist typischerweise eine Facilitation-Herausforderung. Unser Lieblingsformat für diese Art von Interaktion ist Specification by Example.

Durch dieses Format erarbeiten die Entwickler selbst die Spezifikationen, aus unmittelbar von Nutzern mitgeteilten Beispielen des gewünschten Verhaltens des Endprodukts. Nach einer Phase in der die Stakeholder Beispiele vorstellen und Fragen der Entwickler beantworten, kann anhand von offenen Beispielen überprüft werden, ob die Entwickler das Wunschverhalten so verstanden haben, wie es gemeint war.

Durch geeignete Facilitation können viele konstruktive Unterhaltungen gleichzeitig laufen und alle sind aktiv involviert, sodass niemand abschaltet. Am Ende haben sich alle Anwesenden mit den zukünftigen Product Backlog Einträgen beschäftigt und es gibt ein breites Verständnis.

Umgang mit Stakeholder-Input

Hier gibt es viel zu gewinnen, indem man die typische „jeder Stakeholder agiert als wäre er alleine am Buffet“-Dynamik vermeidet. Diese Dynamik kann leicht entstehen, wenn verschiedene Stakeholder jeweils Sonderwünsche platzieren, gegenüber der PO:in teilweise auch mehr Macht haben und die PO:in oft einzeln mit ihnen spricht. Weiter oben im Abschnitt 2. Aufgabe Product Owner mit Stakeholdern beschreiben wir ausführlicher diese Dynamik und das Zielbild, das wir stattdessen anstreben.

Sich diesem Zielbild anzunähern, erfordert geschickten Umgang mit Gruppen von teilweise auch mächtigen Menschen. Hier gibt es für viele von uns ein Wachstumsfeld. Und: Glücklicherweise müssen wir nicht alles alleine machen: Scrum Master oder Agile Coach können helfen, indem sie einen Teil der Facilitation übernehmen und/oder die PO:in mit den nötigen Methoden vertraut machen.

Es gibt eine Vielzahl an bekannten Methoden, die dabei hilfreich sein können, z.B. aus den Bereichen „Liberating Structures“ und „Innovation Games“. Hier einige konkrete Beispiele als Einstiegspunkt für eine weitere Recherche:

• Prune the product tree
• Hot Tub
• Product Box
• Buy a feature
• Business Value Poker

Langfristigen Entwicklungsfortschritt transparent machen

In Scrum verzichten wir auf kleinschrittige Vorhersagen zu Lieferzeitpunkten, denn diese würden dazu führen, dass wir versuchen würden detaillierte Lieferpläne zu erstellen. In einer Umgebung, die von häufiger Veränderung geprägt, ist würden diese Pläne sehr schnell veralten und zu einer großen Zeitverschwendung führen.

Wir sind aber durch die empirische Prozesskontrolle dennoch in der Lage mit Deadlines umzugehen, wie sie zum Beispiel bei einer geplanten Produktvorstellung auf einer Messe gegeben wären. Dazu helfen uns Burn-Down-Charts , die anzeigen wie viel Arbeit einer bestimmten Kategorie noch im Product Backlog ist.

Angenommen wir wollen bei der Messe die neuen Features unseres Produkts zum Thema X vorstellen. Wenn wir mit der Bearbeitung des Themas X starten, markieren und schätzen wir alle Einträge zum Thema X. Angenommen wir haben 4 Monate bis zur Messe und 2-wöchige Iterationen. Dann können wir am Ende jeder Iteration eintragen, wie viel Arbeit noch übrig ist zum Thema X. Dabei wird automatisch mit berücksichtigt, wenn neue Einträge dazu kommen/entfernt werden oder sich die Schätzungen verändern etc.

So könnte ein Burndown dann am Ende des 3. Sprints aussehen:

In diesem Fall wäre die Deadline nach Sprint 8 erreicht. Das heißt nach dem 3. Sprint wissen wir, wir werden voraussichtlich nicht alles schaffen, wenn es so weitergeht wie bisher. Eine typische Product Owner Aufgabe ist es einen solchen „Release Burn Down Chart“ zu pflegen und regelmäßig am Ende des Sprints im Sprint Review vorzustellen. Geschickter Umgang mit schafft langfristig Vertrauen. Sieht ein Chart so aus wie der obige, wissen alle Beteiligten früh, dass sie reagieren müssen. Man kann versuchen einfachere Lösungen zu finden, einige Wünsche wegzustreichen etc. Und nach 6 Sprints sieht es im besten Fall schon ganz anders aus.

Durch diese kontinuierliche Transparenz des Entwicklungsfortschritts schafft es ein Product Owner, langfristig und nachhaltig das Vertrauen des höheren Managements / der Investoren sicherzustellen, die ihm dauerhaft die Autorität verleiht, die er für seine Arbeit braucht. Diese Transparenz kann in manchen Moment schmerzhaft sein, wie im obigen Beispiel nach 3 Sprints. Aber auf diese Weise werden zum richtigen Zeitpunkt wichtige Unterhaltungen ausgelöst und Probleme nicht verschleppt.

Priorisierung des Product Backlogs

Es gibt viele Denkmodelle, die ein Product Owner heranziehen kann, um die Reihenfolge der Einträge im Product Backlog festzulegen. Scrum schreibt das in keiner Weise vor. Es kann auch sein, dass in bestimmten Situationen die PO:in über geheime Informationen verfügt, auf denen ihre Entscheidung basiert. In der Regel sollte aber die Priorisierung für die Umwelt (Stakeholder und Entwickler) nachvollziehbar und verständlich sein.

Entscheidungen über die Reihenfolge von kleinen Einträgen

Bei vielen kleinen(!) Priorisierungsentscheidungen ist es als PO:in sinnvoll, sich von den Vorschlägen der Entwicklungsteams leiten zu lassen, denn: Wenn wir einmal geschafft haben, das „Code Monkey“ Syndrom zu überwinden, leisten die Entwickler im Product Backlog Refinement anspruchsvolle Arbeit: Sie zerlegen jeweils eine große Anforderung in kleinere Einträge. Folglich wissen sie dann auch selbst am besten, welche Schritte in welcher Reihenfolge Sinn machen könnten. Gleichzeitig ergeben sich durch das Refinement und die Zerteilung verschiedene Möglichkeiten dafür zu gestalten, wie umfangreich ein Thema umgesetzt werden soll. Wenn die Delegation hier gut funktioniert, konzentriert sich die Arbeit einer PO:in darauf, die Vor- und Nachteile der jeweiligen Umsetzungsoption zu verstehen und letztlich für eine zu entscheiden.

Ein Beispiel:

Angenommen wir betreiben einen Online-Shop und wollen nun eine größere Anforderungen implementieren: Zahlung mit verschiedenen Kreditkarten selbst abwickeln (statt wie zuvor durch Paypal o.ä., um Transaktionskosten einzusparen):

Das Entwicklungsteam könnte dies in folgende Unterpunkte herunterbrechen:

1. Erfolgreiche Zahlung bei Eingabe gültiger Visa-Kreditkartendaten, Adresse Deutschland
2. Fehler bei Eingabe gültiger Visa-Kreditkartendaten, Adresse nicht in Deutschland
3. Fehler bei ungültiger Kreditkartennummer (Visa) nach Prüfung beim Provider
4. Fehler bei ungültiger Kreditkartennummer (Visa) ohne Provideraufruf
5. Fehler bei gesperrter Karte (Visa)
6. Fehler bei Überschreitung des Limits (Visa)
7. Alle (anderen) Fehler bei Zahlung mit Visa nach Prüfung beim Provider
8. Zahlung mit anderen Kreditkarten (Mastercard, AMEX, Diners Club..)

Eine PO:in könnte nun zum Beispiel sagen, dass sie gern die Einträge überwiegend wie vorgeschlagen umsetzen möchte, aber vor der Fehlerbehandlung in 2-6, ersteinmal die 7 umsetzen würde. Das Entwicklungsteam könnte antworten, dass aus technischen oder legalen Gründen der Eintrag 2 notwendig ist, um Zahlungen auch in der einfachsten Form zu ermöglichen. Man würde sich also z.B. auf die Reihenfolge 1,2,7,8 einigen und die anderen Einträge ersteinmal weiter unten im Product Backlog einordnen.

Entscheidungen über die Reihenfolge größerer Themen

Wenn wir beim o.g. Beispiel bleiben: Wie entscheidet eine PO:in, ob sie zuerst Visa oder Mastercard Zahlungen implementieren sollte? Oder sollte vielleicht eher das aktuelle Aussehen der Zahlungsoberfläche vereinfacht werden, damit nicht so viele Nutzer den Zahlungsprozess abbrechen? Oder macht es mehr Sinn einen Newsletter einzuführen, statt die Zahlungen zu verbessern? Oder ist es wichtiger auf die aktuelle Änderung in der Datenschutzgesetzgebung zu reagieren, weil es dort ein Risiko gibt abgemahnt zu werden?

Jedes einzelne dieser Themen ist in der Regel größer (eher Wochen/Monate Arbeit für ein Entwicklungsteam) und hat einen eigenen prinzipiell berechenbaren oder zumindest abschätzbaren Einfluss auf das wirtschaftliche Ergebnis. Sie steigern entweder den Umsatz, verringern die Kosten, reduzieren Risiken oder bereiten die Grundlagen für zukünftige Einnahmen vor. Um die Reihenfolge für die Bearbeitung dieser größeren Themen festzulegen gibt, es das Konzept der “Cost of Delay” oder „Kosten der Verzögerung“. Es ist aus unserer Sicht eines der flexibelsten Konzepte für die Priorisierung. Hier stellen wir das Konzept nur kurz vor, für eine Vertiefung heißen wir sie gern in einem Training zur Product Owner Zertifizierung willkommen.

Zunächst hilft es zu verstehen, dass die Entscheidung für bestimmte Einträge immer bedeutet, dass die anderen Einträge erst später umgesetzt werden. Das heißt, sie werden verzögert geliefert. Deshalb ist es die natürlichste Frage, die man sich stellen kann:

Was kostet es uns, die Bearbeitung eines Themas z.B. um 1 Monat zurückzustellen?

Diese Betrachtungsweise hilft uns alle Product Backlog Einträge mit verschiedenen Nutzungsszenarien auf einer Skala zu bewerten und damit vergleichbar zu machen. Wenn weniger Menschen ihre Zahlung abbrechen, was wird uns das Monat für Monat bringen? Wenn Menschen sich zum Newsletter anmelden, was erhoffen wir uns davon Monat für Monat?

Es ist klar, dass alle unsere Antworten auf diese Fragen letztendlich Spekulationen sein werden. Wir müssen z.B. annehmen, wie viele Nutzer heute abspringen, weil die Zahlungsoberfläche zu kompliziert ist. Oder wie viele unserer Newsletter-Abonnenten zu zahlenden Kunden werden könnten. Dafür gibt es manchmal Vergleichswerte von Wettbewerbern oder aus anderen Quellen. Aber am Ende kann niemand den zukünftigen Nutzen exakt vorhersagen. Das brauchen wir aber auch nicht, denn:

1. Selbst mit grob abgeschätzten Werten finden wir in der Regel heraus, dass sich die Wertigkeit verschiedener Themen im Backlog voneinander um Größenordnungen (Faktor 10, 100 etc.) unterscheidet. Dann wird die Entscheidung leicht, unabhängig von Nachkommastellen …

2. … hilft uns die Frage und der Versuch, den Wert eines Eintrags zu quantifizieren, dabei, eine gemeinsame klare Formulierung unserer Hypothesen zu erreichen. So können wir, nach dem etwas implementiert wurde und wir wissen wie gut es nun wirkt, viel konkreter untersuchen, welche unserer Annahmen zutreffen und welche nicht. Auf diese Weise lernen wir nachhaltig etwas über unsere Kunden und ihre Interaktionen mit unserem Produkt. So können wir mit der Zeit eine bessere Grundlage für zukünftige Entscheidungen erarbeiten.

Welche Position hat ein Product Owner im Organigramm?

Aus der Art der Arbeit, die die Organisation insgesamt leitstet, ergibt sich die jeweils sinnvollste Struktur der Organisation und dadurch auch die Position der PO:in innerhalb dieser Struktur. Wir unterscheiden hier zunächst drei Varianten von Organisations-Designs:

Produktentwicklung – Das Unternehmen entwickelt intern ein Produkt und vermarktet es an Kunden außerhalb. Beispiele für Produkte wären iPhone, Facebook, Xing etc. Hier wäre der beste Product Owner eine Person im Unternehmen, die entweder eine erfahrene Produktmanager:in mit entsprechender Position oder die hierarchische Leiter:in der Einheit für die Produktentwicklung ist. Es ist wichtig zu beachten, dass die Person einen Business-Hintergrund und -Funktion hat.

Interne Produktentwicklung – Hier geht es um die Entwicklung von Produkten, deren Nutzer Mitarbeiter der gleichen Firma sind. Beispiele wären: Makler bei Investmentbanken, die ihre Software zum Handeln nutzen oder Software für Vertriebsmitarbeiter einer Firma, die viel reisen. Ein guter Product Owner für die interne Produktentwicklung ist in der Regel innerhalb der Nutzergruppe, die das System verwenden wird, und ist eng involviert und tief erfahren in der wirklichen Arbeit, die das System leisten wird.

Autragsentwicklung / Projektentwicklung – Hier entwickelt ein Unternehmen im Auftrag einzelner Kunden die gesamte Software. Typische Beispiele sind digitale Agenturen, die für ihre Kunden Apps oder große Webseiten entwickeln. Der entscheidende Punkt hier liegt darin, dass ein Product Owner im besten Fall aus dem Kunden-Unternehmen stammt und wie bei der internen Entwicklung in die praktische Arbeit involviert ist und direkte Verbindung zu den Nutzern hat.

Die folgende Abbildung zeigt den PO in verschiedenen Organisationen:

Zusammenfassung

In diesem Beitrag haben wir die wichtigsten Aufgaben, Fähigkeiten und Eigenschaften einer aus unserer Sicht großartigen PO:in beschrieben. Das Hauptziel dieses Artikels ist, die PO Rolle möglichst verständlich und anfassbar darzustellen. Eine guter Product Owner:in kann mit einem Bruchteil der hier dargestellten Fähigkeiten sehr viel Mehrwert für ihr Unternehmen schaffen. Und sie kann mit Hilfe ihres Scrum Masters vies auch während der Arbeit lernen. Wer nicht schon zu Anfang die nötige Autorität innehat, tut gut daran sich sehr systematisch das Vertrauen seiner Stakeholder zu erarbeiten.

Wir hoffen, dass dieser Artikel für sie hilfreich war. Wir freuen uns ggf. sehr über eine Erwähnung dieses Artikels in Blogs und sozialen Medien.

Hier finden sie unseren gleichermaßen detaillierten Beitrag über die Scrum Master Rolle.

Verwendete Bilder stammen entweder von uns selbst (alle abgelichteten Personen haben ihr Einverständnis erteilt) oder sind zur Nutzung freigegebene Bilder von less.works.

Dieser Wissensbeitrag wurde 2018 von Anton Skornyakov geschrieben und seitdem mehrmals aktualisiert, u.a. am 23.12.2020 und 5.3.2024 von Timon Fiddike.