Agilität

Das Anti-Pattern der Kunden-Lieferanten-Beziehung

Einer der vier Hauptsätze des Manifests für agile Softwareentwicklung lautet „Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung.“ Und in den Prinzipen hinter dem Manifest heißt es weiter „Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.“ Dieser Begriff des Kunden führt leider bis heute oftmals du dem was Jeff Patton als Kunden-Lieferanten-Anti-Pattern bezeichnet. Gerade in großen Organisationen mit eigenen IT-Abteilungen tritt dieses Muster auf, wenn der Product-Owner seine Rolle als Vertreter der internen Kunden begreift und Anforderungen an das Development-Team zur Umsetzung gibt. Die Kunden und ihre Nöte und Bedürfnisse zu verstehen ist wichtig, ist aber nur ein Aspekt, um ein Produkt erfolgreich zu machen und genau das ist die Aufgabe des Product-Owners. Um alle Aspekte abzudecken, darf der Product-Owner nicht genialer und einsamer Entscheider sein und sich nicht einseitig dem Business zugehörig fühlen, sondern mehr Anführer eines Expertenteams, das gemeinsam die Verantwortung für die nachhaltige Entwicklung des Produkterfolgs übernimmt.

In seinem Vortrag bei MTP Engage 2018 in Hamburg erklärt Jeff Patton (wie immer genial durch seine Live-Zeichungen illustriert und mit Geschichten aus seiner langjährigen Erfahrung garniert) das Kunden-Lieferanten-Anti-Pattern. Im Kern kennzeichnet dieses Muster eine Trennung zwischen dem Kunden, der etwas will und dem Lieferanten der es innerhalb der vereinbarten Parameter Aufwand, Zeit und Qualität liefern soll. Dieses Muster führt dazu, dass viel Energie in die Vereinbarung und Verhandlung und bei Problemen in die Suche nach dem Schuldigen fließt. Anstatt gemeinsam Verantwortung für die bestmöglichen nächsten Schritte in Richtung Produkterfolg zu übernehmen, zieht dieses Muster einen Graben zwischen dem Kunden, der bestimmt was gemacht werden soll und dem Lieferanten, der bestimmt wie und womit es umgesetzt wird.

Jeff Patton betont auch, dass genau dieses Muster, das sich so in ähnlicher Weise in vielen Organisationen zwischen Business einerseits und IT andererseits wiederfindet, zum Manifest für agile Softwareentwicklung geführt hat. Genau darum steht in den Prinzipien ja auch, dass Fachexperten und Entwickler täglich zusammenarbeiten müssen. Obwohl aber immer mehr Organisationen sich agilen Methoden und insbesondere Scrum zuwenden besteht dieses Muster fort. Grund dafür ist die immer noch vorherrschende organisatorische Trennung von Business und IT, die schnell dazu führt, dass der Product-Owner als Vertreter der Business-Seite gesehen wird und die IT dann eben das Development-Team und den Scrum-Master stellt und wie bestellt und vereinbart liefern soll.

We see our customers as invited guests to a party, and we are the hosts. It’s our job every day to make every important aspect of the customer experience a little bit better.
Jeff Bezos

Tatsächlich ist es aber die Aufgabe des Product-Owners, das Produkt erfolgreich zu machen. Und erfolgreich definiert Jeff Patton in Anlehnung an Marty Cagan als die Schnittmenge zwischen des Aspekten wertvoll, nützlich und machbar. „Wertvoll“ meint die Verbindung zur Wertschöpfung und Strategie der umgebenden Organisation, die der Product-Owner verstehen muss, um daraus die möglichen Wertbeiträge des Produkts richtig zu priorisieren. „Nützlich“ bedeutet, dass das Produkt für den Benutzer einen Nutzen generiert. Der Product-Owner muss also auch und insbesondere die Nutzer und deren Bedürfnisse kennen. Und „machbar“ bedeutet schließlich für den Product-Owner, die vielen technischen, organisatorischen und sonstigen Rahmenbedingungen zu verstehen, die den Lösungsraum beschränken. Und dazu gehören technische Schulden, IT-Sicherheit, Performance, Skalierung und viele andere technische Aspekte.

A good product manager is the CEO of the product. A good product manager takes full responsibility and measures themselves in terms of the success of the product. They are responsible for right product/right time and all that entails. Bad product managers have lots of excuses.
Ben Horowitz

Um diese Aspekte alle abzudecken, muss dieses Muster der Kunden-Lieferanten-Beziehung aufgebrochen werden. Der Product-Owner darf sich also nicht mehr als Kunde (dem die technologischen Rahmenbedingung egal sind und der nur möglichst viel möglichst früh will) und das Development-Team nicht als Lieferant (der sich über schlecht spezifizierte Anforderungen und ständige Änderungen ärgert) fühlen. Stattdessen trägt der Product-Owner Verantwortung für den Erfolg des Produkts in den drei Dimensionen „wertvoll“, „nützlich“ und „machbar“. Das verlangt vom Product-Owner in erster Linie Fähigkeiten zur Kollaboration und Führung eines Produktteams, weil er für alle diese Dimensionen Experten brauchen wird, um gemeinsam Kompromisse zu finden und Entscheidungen zu treffen.

Hi, ich bin Marcus. Ich bin der festen Überzeugung, dass Elefanten tanzen können. Daher begleite ich Organisationen auf ihrem Weg zu mehr Agilität. Über die Themen Führung, Digitalisierung, Neue Arbeit, Agilität und vieles mehr schreibe ich seit 2010 in diesem Blog. Mehr über mich.

2 Kommentare Neues Kommentar hinzufügen

  1. Hallo Marcus,

    ich finde mich in meiner Rolle als Product Owner gut wiedergegeben :-)

    Kleine Textkorrektur: Du wolltest hier sicher noch ein ‚als‘ vor ‚Kunde‘ eingefügt haben?
    „Der Product-Owner darf sich also nicht mehr Kunde …“

    VG Martin

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.