Das Anti-Pattern der Kunden-Lieferanten-Beziehung

Einer der vier Haupt­sät­ze des Mani­fests für agi­le Soft­ware­ent­wick­lung lau­tet „Zusam­men­ar­beit mit dem Kun­den mehr als Ver­trags­ver­hand­lung.“ Und in den Prin­zi­pen hin­ter dem Mani­fest heißt es wei­ter „Unse­re höchs­te Prio­ri­tät ist es, den Kun­den durch frü­he und kon­ti­nu­ier­li­che Aus­lie­fe­rung wert­vol­ler Soft­ware zufrie­den zu stel­len.“ Die­ser Begriff des Kun­den führt lei­der bis heu­te oft­mals du dem was Jeff Pat­ton als Kun­den-Lie­fe­ran­ten-Anti-Pat­tern bezeich­net. Gera­de in gro­ßen Orga­ni­sa­tio­nen mit eige­nen IT-Abtei­lun­gen tritt die­ses Mus­ter auf, wenn der Pro­duct-Owner sei­ne Rol­le als Ver­tre­ter der inter­nen Kun­den begreift und Anfor­de­run­gen an das Deve­lo­p­ment-Team zur Umset­zung gibt. Die Kun­den und ihre Nöte und Bedürf­nis­se zu ver­ste­hen ist wich­tig, ist aber nur ein Aspekt, um ein Pro­dukt erfolg­reich zu machen und genau das ist die Auf­ga­be des Pro­duct-Owners. Um alle Aspek­te abzu­de­cken, darf der Pro­duct-Owner nicht genia­ler und ein­sa­mer Ent­schei­der sein und sich nicht ein­sei­tig dem Busi­ness zuge­hö­rig füh­len, son­dern mehr Anfüh­rer eines Exper­ten­teams, das gemein­sam die Ver­ant­wor­tung für die nach­hal­ti­ge Ent­wick­lung des Pro­dukt­er­folgs übernimmt.

In sei­nem Vor­trag bei MTP Enga­ge 2018 in Ham­burg erklärt Jeff Pat­ton (wie immer geni­al durch sei­ne Live-Zei­chun­gen illus­triert und mit Geschich­ten aus sei­ner lang­jäh­ri­gen Erfah­rung gar­niert) das Kun­den-Lie­fe­ran­ten-Anti-Pat­tern. Im Kern kenn­zeich­net die­ses Mus­ter eine Tren­nung zwi­schen dem Kun­den, der etwas will und dem Lie­fe­ran­ten der es inner­halb der ver­ein­bar­ten Para­me­ter Auf­wand, Zeit und Qua­li­tät lie­fern soll. Die­ses Mus­ter führt dazu, dass viel Ener­gie in die Ver­ein­ba­rung und Ver­hand­lung und bei Pro­ble­men in die Suche nach dem Schul­di­gen fließt. Anstatt gemein­sam Ver­ant­wor­tung für die best­mög­li­chen nächs­ten Schrit­te in Rich­tung Pro­dukt­er­folg zu über­neh­men, zieht die­ses Mus­ter einen Gra­ben zwi­schen dem Kun­den, der bestimmt was gemacht wer­den soll und dem Lie­fe­ran­ten, der bestimmt wie und womit es umge­setzt wird. 

Jeff Pat­ton betont auch, dass genau die­ses Mus­ter, das sich so in ähn­li­cher Wei­se in vie­len Orga­ni­sa­tio­nen zwi­schen Busi­ness einer­seits und IT ande­rer­seits wie­der­fin­det, zum Mani­fest für agi­le Soft­ware­ent­wick­lung geführt hat. Genau dar­um steht in den Prin­zi­pi­en ja auch, dass Fach­ex­per­ten und Ent­wick­ler täg­lich zusam­men­ar­bei­ten müs­sen. Obwohl aber immer mehr Orga­ni­sa­tio­nen sich agi­len Metho­den und ins­be­son­de­re Scrum zuwen­den besteht die­ses Mus­ter fort. Grund dafür ist die immer noch vor­herr­schen­de orga­ni­sa­to­ri­sche Tren­nung von Busi­ness und IT, die schnell dazu führt, dass der Pro­duct-Owner als Ver­tre­ter der Busi­ness-Sei­te gese­hen wird und die IT dann eben das Deve­lo­p­ment-Team und den Scrum-Mas­ter stellt und wie bestellt und ver­ein­bart lie­fern soll. 

We see our cus­to­mers as invi­ted guests to a par­ty, and we are the hosts. It’s our job every day to make every important aspect of the cus­to­mer expe­ri­ence a litt­le bit better.
Jeff Bezos

Tat­säch­lich ist es aber die Auf­ga­be des Pro­duct-Owners, das Pro­dukt erfolg­reich zu machen. Und erfolg­reich defi­niert Jeff Pat­ton in Anleh­nung an Mar­ty Cagan als die Schnitt­men­ge zwi­schen des Aspek­ten wert­voll, nütz­lich und mach­bar. „Wert­voll“ meint die Ver­bin­dung zur Wert­schöp­fung und Stra­te­gie der umge­ben­den Orga­ni­sa­ti­on, die der Pro­duct-Owner ver­ste­hen muss, um dar­aus die mög­li­chen Wert­bei­trä­ge des Pro­dukts rich­tig zu prio­ri­sie­ren. „Nütz­lich“ bedeu­tet, dass das Pro­dukt für den Benut­zer einen Nut­zen gene­riert. Der Pro­duct-Owner muss also auch und ins­be­son­de­re die Nut­zer und deren Bedürf­nis­se ken­nen. Und „mach­bar“ bedeu­tet schließ­lich für den Pro­duct-Owner, die vie­len tech­ni­schen, orga­ni­sa­to­ri­schen und sons­ti­gen Rah­men­be­din­gun­gen zu ver­ste­hen, die den Lösungs­raum beschrän­ken. Und dazu gehö­ren tech­ni­sche Schul­den, IT-Sicher­heit, Per­for­mance, Ska­lie­rung und vie­le ande­re tech­ni­sche Aspekte. 

A good pro­duct mana­ger is the CEO of the pro­duct. A good pro­duct mana­ger takes full respon­si­bi­li­ty and mea­su­res them­sel­ves in terms of the suc­cess of the pro­duct. They are respon­si­ble for right product/right time and all that ent­ails. Bad pro­duct mana­gers have lots of excuses.
Ben Horo­witz

Um die­se Aspek­te alle abzu­de­cken, muss die­ses Mus­ter der Kun­den-Lie­fe­ran­ten-Bezie­hung auf­ge­bro­chen wer­den. Der Pro­duct-Owner darf sich also nicht mehr als Kun­de (dem die tech­no­lo­gi­schen Rah­men­be­din­gung egal sind und der nur mög­lichst viel mög­lichst früh will) und das Deve­lo­p­ment-Team nicht als Lie­fe­rant (der sich über schlecht spe­zi­fi­zier­te Anfor­de­run­gen und stän­di­ge Ände­run­gen ärgert) füh­len. Statt­des­sen trägt der Pro­duct-Owner Ver­ant­wor­tung für den Erfolg des Pro­dukts in den drei Dimen­sio­nen „wert­voll“, „nütz­lich“ und „mach­bar“. Das ver­langt vom Pro­duct-Owner in ers­ter Linie Fähig­kei­ten zur Kol­la­bo­ra­ti­on und Füh­rung eines Pro­dukt­teams, weil er für alle die­se Dimen­sio­nen Exper­ten brau­chen wird, um gemein­sam Kom­pro­mis­se zu fin­den und Ent­schei­dun­gen zu treffen.

Share This Post

Von Marcus Raitner

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

Hal­lo Marcus, 

ich fin­de mich in mei­ner Rol­le als Pro­duct Owner gut wiedergegeben :-)

Klei­ne Text­kor­rek­tur: Du woll­test hier sicher noch ein ‚als‘ vor ‚Kun­de‘ ein­ge­fügt haben?
„Der Pro­duct-Owner darf sich also nicht mehr Kunde …“

VG Mar­tin

Schreibe einen Kommentar