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.