Sie befin­den sich hier:Start­sei­te/Blog/Pro­duct Owner: Motor oder Soll­bruch­stel­le agi­ler SW-Pro­jek­te? (Teil 3)

Product Owner: Motor oder Sollbruchstelle agiler SW-Projekte? (Teil 3)

Lese­zeit: 7 Minu­ten
product owner socialshare

Die­ser Bei­trag ist der drit­te und letz­te Teil unse­rer Serie „Pro­duct Owner: Motor oder Soll­bruch­stel­le agi­ler SW-Pro­jek­te?“ In Teil 1 habe ich beschrie­ben, war­um Soft­ware­pro­jek­te oft (ca. 70%!) schei­tern. In Teil 2 ging es um die Fra­ge, war­um die imma­nen­ten Pro­ble­me kom­ple­xer Soft­ware­pro­jek­te nicht auto­ma­tisch ver­schwin­den, wenn man z.B. auf Scrum setzt.

Im letz­ten Teil sehen wir uns an, was der Pro­duct Owner alles ken­nen und leis­ten muss. Und schließ­lich geht es um die für die Beset­zung die­ser kri­ti­schen Rol­le ent­schei­den­den Fra­ge, wel­che Skills erfor­der­lich sind und wie wahr­schein­lich es ist, dass sie in einer Per­son ver­eint sind.

Mit welchen Artefakten sollte sich der Product Owner beschäftigen?

Selbst die bes­ten Pro­duct Owner ver­lie­ren leicht den Über­blick zwi­schen den stra­te­gi­schen, kon­zep­tio­nel­len Aspek­ten eines Soft­ware­pro­dukts und den Tau­sen­den Details, die bei sei­ner Umset­zung rele­vant sind. Selbst wenn ein PO alles im Kopf behal­ten kann, wird er es schwer haben, die­ses Wis­sen nur münd­lich an ande­re zu ver­mit­teln. Auch das Pro­duct back­log allei­ne taugt dafür nicht. Des­halb soll­te ein PO nach mei­ner Erfah­rung mit fol­gen­den Arte­fak­ten ver­schie­de­ner Gra­nu­la­ri­tät arbeiten:

  • Pro­duct state­ment / Pro­ject char­ter: Beschreibt kurz und prä­gnant das Nut­zen­ver­spre­chen des Pro­dukts, also was es war­um kann sowie rele­van­te Rah­men­be­din­gun­gen, z.B. finan­zi­el­ler, orga­ni­sa­to­ri­scher und/oder regu­la­to­ri­scher Natur. In der Regel wird der PO die­ses Arte­fakt vom Busi­ness Owner / Spon­sor erhal­ten / ein­for­dern oder es mit ihm zusam­men entwickeln
  • Pro­duct visi­on: Beschreibt die Visi­on des fer­ti­gen Pro­dukts (bzw. rele­van­ter Aus­bau­stu­fen). Das soll­te typi­scher­wei­se aus der Sicht der Anwen­der gesche­hen. Pro­fi­tip: Eine buch­stäb­lich greif­ba­re Visi­on kann z.B. ein fik­ti­ver Ver­kaufs­kar­ton sein, auf dem Nut­zen, High­lights und Fea­tures des Pro­dukts bewor­ben wer­den. Plat­zie­ren Sie die­sen dort, wo sich das Team beson­ders häu­fig auf­hält (neben der Kaf­fee­ma­schi­ne!), um immer wie­der vor Augen zu füh­ren, wor­um es geht
  • Sto­ry map: Ein Hilfs­mit­tel für die agi­le Release­pla­nung und das Befül­len des Pro­duct back­logs. Typi­scher­wei­se eine Matrix, bei der hori­zon­tal die gro­ßen Anwen­dungs­fäl­le auf­ge­lis­tet sind, die ver­ti­kal immer mehr ver­fei­nert wer­den. In einer sol­chen Matrix (am bes­ten als phy­si­ka­li­sche Tafel mit Post-Its o.ä.) kann am bes­ten der Über­blick über das Sys­tem gewon­nen und mit Sta­ke­hol­dern, die ggf. Ziel­kon­flik­te haben, dis­ku­tiert werden
  • Design statement(s): Beschreibt den fach­li­chen und tech­ni­schen Ent­wurf des Pro­dukts. Der PO ist gut bera­ten, die­se Ent­wür­fe mit erfah­re­nen Ent­wick­lern / Archi­tek­ten zu erstel­len, denen die­se State­ments spä­ter als Leit­plan­ken für die Imple­men­tie­rung die­nen. Neben dem fach­li­chen Ent­wurf, für den sich z.B. die Metho­dik Domain-Dri­ven Design anbie­tet (die übri­gens her­vor­ra­gend par­al­lel zur Erstel­lung der Sto­ry map mit Sta­ke­hol­dern ange­wen­det wer­den kann), gehö­ren hier auch sol­che Ent­wurfs­ent­schei­dun­gen rein, die IT-stra­te­gi­scher Natur sind, z.B. die Vor­ga­be, dass statt einer „klas­si­schen“ 3‑tier-Archi­tek­tur eine bes­ser beherrsch- und erwei­ter­ba­re Zwie­bel­ar­chi­tek­tur zu ver­wen­den ist
  • Pro­duct back­log: Erst dann kom­men wir zum zen­tra­len Arte­fakt des PO, das eigent­lich eine Samm­lung von Arte­fak­ten ist, den soge­nann­ten Back­log items. Die­se sind in der Rei­hen­fol­ge ihrer Umset­zungs­prio­ri­tät sor­tiert und in der Regel (aber nicht not­wen­di­ger­wei­se) in der Form von User Sto­ries for­mu­liert. Im Rah­men des regel­mä­ßi­gen back­log refi­ne­ments ver­fei­nert der PO das Back­log, so dass immer aus­rei­chend Items an der Spit­ze des Back­logs ste­hen, die for­mal umset­zungs­reif sind. Vie­le Pro­jek­te for­mu­lie­ren dafür eine Check­lis­te namens DoR (Defi­ni­ti­on of rea­dy), die ana­log zur DoD (defi­ni­ti­on of done) dem PO Ori­en­tie­rung gibt, ob ein Item umset­zungs­reif ist (die eigent­li­che Ent­schei­dung über die Annah­me trifft das Team im Sprint Planning)

Die Gra­fik zeigt das gan­ze im Überblick:

um scrum herum 768x478 1

Ab dem Pro­duct back­log setzt dann wie­der der eta­blier­te Scrum-Pro­zess ein. Aber eben erst dann. Es ging ja hier um die anfangs auf­ge­wor­fe­ne Fra­ge, wie eigent­lich das Back­log ent­steht bzw. was der PO alles zu tun hat.

Welche Skills sollte der Product Owner besitzen?

Aus der bis hier erfolg­ten Kon­kre­ti­sie­rung der Rol­le Pro­duct Owner und ihrer Auf­ga­ben, soll­te schon deut­lich gewor­den sein, dass sie eine Men­ge Skills in sich ver­ei­nen muss:

  • Bera­ter­s­kills: Der PO ist Bera­ter ver­schie­de­ner Grup­pen mit unter­schied­li­chen Inter­es­sen und Anla­gen und muss sie in Rich­tung des Pro­jekt­er­folgs füh­ren. Neben ent­spre­chen­der Erfah­rung sind hier­für vor allem diplo­ma­ti­sches Geschick und kom­mu­ni­ka­ti­ve Stär­ken nötig
  • Manage­ments­kills: Bei einem agi­len Pro­jekt sind unend­lich vie­le Ent­schei­dun­gen zu tref­fen, vor allem was jetzt (noch) nicht gemacht wird. Wenn die Rah­men­be­din­gun­gen vom Spon­sor ein­mal gesetzt sind, ist der PO der Haupt-Ent­schei­dungs­trä­ger. Ins­be­son­de­re muss er auch gute Wün­sche und Ideen der Sta­ke­hol­der, der Ent­wick­ler und (das ist am schwie­ri­ges­ten) sei­ner selbst zurück­stel­len, wenn sie kei­nen aus­rei­chen­den ROI bringen
  • Visio­när: Es muss nicht gleich ein Ste­ve Jobs sein, aber der PO ist der­je­ni­ge, der die Visi­on des Pro­dukts haben und ver­fol­gen muss
  • Tech­no­lo­gi­sches Know-How: Der PO muss aus­rei­chend Know-How haben, um sol­che Ent­wurfs­ent­schei­dun­gen zu tref­fen und mit dem Team dis­ku­tie­ren zu kön­nen, die für die IT-stra­te­gi­sche Aus­rich­tung des Pro­dukts rele­vant sind. Im Umfeld von Web­an­wen­dun­gen gehört dazu, die im Inter­net gän­gi­gen Archi­tek­tur­mus­ter zu ken­nen (Hin­weis: Das geht weit über mono­li­thi­sche 3‑Tier-Archi­tek­tu­ren hin­aus), denn wer soll stra­te­gi­sche Pro­dukt­ent­schei­dun­gen tref­fen, wenn nicht der PO?
  • Her­aus­ra­gen­de Auf­fas­sungs- und Kon­zep­ti­ons­ga­be: Die Ana­ly­se- und Ent­wurfs­fä­hig­kei­ten müs­sen bei einem PO stär­ker als bei einem Requi­re­ments Engi­neer, da er sowohl hin­sicht­lich des Pro­zes­ses als auch der Inhal­te einen deut­lich höhe­ren Bereich abdeckt
  • Empa­thie: Die­se Eigen­schaft mag über­ra­schen, aber neben dem Ver­ständ­nis der Ansprech­part­ner im Pro­jekt muss der PO vor allem Ein­füh­lungs­be­dürf­nis für die Anwen­der des Pro­dukts haben, um es zu einem vom Benut­zer als hilf­reich emp­fun­de­nen machen zu kön­nen. Ein erfah­re­ner PO wird aus die­sem Grun­de auch immer zu User Cen­te­red Design nei­gen, schon in der Pro­dukt­vi­si­on, aber auch bei der Aus­ar­bei­tung der ein­zel­nen User Stories

In den sel­tens­ten Fäl­len wird eine Per­son alle die­se Skills in sich in aus­rei­chen­dem Maße ver­ei­nen. Und wenn man kei­ne sol­che fin­det? Zwar sieht Scrum aus gutem Grund nur einen PO vor. Bevor das Pro­jekt aber wegen feh­len­der Skills einer ansons­ten geeig­ne­ten Per­son Schiff­bruch erlei­det, soll­te geprüft wer­den, den PO zu unter­stüt­zen, z.B. durch Coa­ching oder einen ent­spre­chen­den Spar­rings­part­ner (so wie ja die SW-Ent­wick­lung auch sehr gute Erfah­rung mit dem Pair Pro­gramming gemacht hat).
Eini­ge Pro­jek­te haben auch gute Erfah­run­gen mit PO-Team­s/­Paa­ren gemacht, indem z.B. jeweils ein Fach­mann und ein IT-Mann an einem Pro­dukt gemein­sam als PO arbei­ten. In die­sen Fäl­len muss aber unbe­dingt dafür gesorgt wer­den, dass das Paar nach außen immer eine kon­sis­ten­te Mei­nung ver­tritt (wie Eltern ggü. ihren Kindern).
Auf jeden Fall soll­te man die man­geln­de Kom­pe­tenz (oder auch den Aus­fall) des PO als ein zen­tra­les Risi­ko im Risi­ko­ma­nage­ment des Pro­jekts behan­deln (ich gehe davon aus, dass jeder Leser die Bedeu­tung von Risi­ko­ma­nage­ment für Pro­jek­te kennt).

Fazit

Wer für die Ent­wick­lung von Soft­ware­pro­duk­ten agi­le Pro­zes­se wie Scrum prak­ti­ziert, darf nicht auto­ma­tisch von so gro­ßem Erfolg sei­ner Soft­ware wie Goog­le & Co. aus­ge­hen, zumal wenn Soft­ware nicht sei­ne eigent­li­che Unter­neh­mens­mis­si­on ist.

Zwar gilt – nicht zuletzt dank den digi­ta­len Vor­rei­tern: Agi­le Software­entwicklung, also das ite­ra­ti­ve Fort­schrei­ben einer Soft­ware bei gleich­blei­bend hoher Qua­li­tät, ist heu­te kein Hexen­werk mehr. Metho­den und Tools sind aus­rei­chend eta­bliert bzw. kön­nen Team­mit­glie­dern schnell ver­mit­telt wer­den. Ger­ne unter­stüt­zen wir auch hier­bei, z.B. bei der Ein­füh­rung von Beha­vi­or Dri­ven Design, das wir für eine per­fek­te Ergän­zung agi­ler Metho­dik hal­ten (es kann übri­gens auch mas­siv zur Ent­las­tung des POs führen).

Ein sinn­vol­les und markt­wirk­sa­mes SW-Pro­dukt zu kon­zi­pie­ren und ite­ra­tiv zu ent­wi­ckeln ist ungleich schwe­rer, wenn es eine nicht-tri­via­le kon­zep­tio­nel­le Kom­ple­xi­tät besitzt. Die Ver­ant­wor­tung hier­für liegt in Scrum beim Pro­duct Owner. Dies ist in der Regel eine ein­zel­ne Per­son, die einen gro­ßen Umfang an Skills und Fer­tig­kei­ten braucht. Eine Fehl­be­set­zung die­ser Rol­le stellt ein sehr hohes Risi­ko für das Pro­jekt dar.

Soll­ten Sie im Umfeld Ihrer Pro­jek­te dies­be­züg­lich Beden­ken oder Pro­ble­me haben, spre­chen Sie uns bit­te an. Wir unter­stüt­zen Sie ger­ne mit unse­rer Exper­ti­se, z.B. in Form von Trai­nings, Work­shops, Coa­ching oder Ent­las­tung Ihres Pro­duct Owners.

Weitere Teile der Artikelserie

Kommentare und Feedback gerne via Social Media:

Blei­ben Sie auf dem Lau­fen­den – mit dem monat­li­chen sepp.med Newsletter: