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 2)

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

Lese­zeit: 9 Minu­ten
product owner socialshare

Die­ser Bei­trag ist der zwei­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: Als häu­fi­ge Ursa­che ist dabei schon immer die Qua­li­tät von Anfor­de­run­gen iden­ti­fi­ziert wor­den. Der Ver­such, das Pro­blem durch immer detail­lier­te­re Spe­zi­fi­ka­tio­nen zu lösen, mach­te Pro­jek­te zuneh­mend lang­wie­ri­ger und star­rer, aber nicht merk­lich erfolg­rei­cher. Als Abhil­fe und Gegen­be­we­gung dafür wur­de um die Jahr­tau­send­wen­de die agi­le Software­entwicklung ein­ge­führt. Unter bestimm­ten Bedin­gun­gen kann die­se Metho­dik wah­re Wun­der bewir­ken; sie hat den rasan­ten Auf­stieg und die geschäft­li­che Agi­li­tät vie­ler Inter­net-Play­er ermög­licht. Doch sie ist kein All­heil­mit­tel und erfor­dert bestimm­te Vor­aus­set­zun­gen: Beson­ders in der „old eco­no­my“ sind vie­le Unter­neh­men von agi­len Pro­jek­ten ernüch­tert und fra­gen sich, was sie falsch machen.

In die­sem Teil beschäf­ti­ge ich mich mit der 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.

Scrum hat gar nichts mit Softwareentwicklung zu tun!

Scrum ist ver­füh­re­risch ein­fach (sie­he Gra­fik). In weni­gen Minu­ten hat man Funk­ti­ons­wei­se und Vor­tei­le die­ses Pro­zes­ses ver­stan­den. Die­ses schnel­le Heils­ver­spre­chen ist sicher auch ein Grund für die wei­te Ver­brei­tung. Aber: Die Ein­füh­rung von Scrum führt nicht auto­ma­tisch zu erfolg­rei­chen Soft­ware-Pro­jek­ten und schon gar nicht zu bril­lan­ter Soft­ware, wie Anwen­der sie im Netz und auf ihren Mobil­ge­rä­ten heu­te erwar­ten (und zwar ganz selbst­ver­ständ­lich, dem Kano-Modell sei Dank). Wer aber die­se Erwar­tungs­hal­tung ent­täuscht, kann auch als eta­blier­tes Unter­neh­men der „old eco­no­my“ sehr schnell am Markt schei­tern, denn ohne (gute) Digi­ta­li­sie­rung funk­tio­niert zukünf­tig kaum noch ein Geschäfts­zweig – zumin­dest bei den „digi­tal nati­ves“, die als Kon­su­men­ten­grup­pe zuneh­men­de Bedeu­tung haben.

scrum macht es sich zu einfach

Das Genia­le, aber auch Gefähr­li­che an Scrum ist, dass es gar kein Soft­ware­ent­wick­lungs-Pro­zess ist, son­dern ledig­lich ein Frame­work, das die agi­le Her­an­ge­hens­wei­se an die Ent­wick­lung eines nicht näher beschrie­be­nen Pro­dukts beschreibt. Des­we­gen ist auch die Nomen­kla­tur so ein­fach wie viel­sei­tig: Nir­gend­wo ist von Soft­ware die Rede; und schon gar nicht von Archi­tek­tu­ren, CI-Ser­vern und ähn­li­chem „Tech­nik­zeug“, was Mana­ger ohne­hin nur unnö­tig ver­schre­cken würde.

Trotz­dem set­zen vie­le Men­schen Scrum mit Software­entwicklung gleich; ganz ein­fach, weil es das gän­gigs­te Ein­satz­ge­biet ist. Wenn man von einem Scrum-Team redet, dann denkt man i.d.R. an eine Grup­pe von meist 6–8 SW-Ent­wick­lern und ggf. Tes­tern, die ganz selbst­ver­ständ­lich den Scrum-Pro­zess mit Leben fül­len, indem sie Metho­di­ken und Tools ver­wen­den, die Umset­zung agi­ler Prin­zi­pi­en sind (TDD, CI, Pair Pro­gramming u.ä.).

Soft­ware-Pro­fis auf der Höhe der Zeit lie­ben aus gutem Grun­de agi­le Ent­wick­lung und haben jede Men­ge die­ses Know-Hows in ihrem Port­fo­lio – inklu­si­ve agi­len Wer­ten wie com­mon code owners­hip; die Zei­ten, da jeder an „sei­nem“ Code geschraubt hat, sind zum Glück längst vor­bei. Des­we­gen ist es – von der Ver­füg­bar­keit abge­se­hen – heu­te in der Regel kein Pro­blem, ein pro­fes­sio­nel­les agi­les Soft­ware-Team zusammenzustellen.

Auch die Rol­le des Scrum Mas­ter ist gut ver­stan­den und eta­bliert. Da er als eine Art Mode­ra­tor dem Team „nur“ hilft, den Pro­zess ein­zu­hal­ten und bestän­dig zu opti­mie­ren, ist es für sei­ne Skills fast uner­heb­lich, ob es sich beim Pro­dukt um Soft­ware oder etwas völ­lig ande­res han­delt, auch wenn gute Scrum Mas­ter natür­lich wis­sen, wel­che Untie­fen in Soft­ware-Pro­jek­ten lauern.

Enter the stage: Product Owner

Aber was genau macht die drit­te Rol­le in Scrum, die noch nicht mal in der offi­zi­el­len Pro­zess­gra­fik dedi­ziert auf­taucht (s.o.)? Hier haben sich die Scrum-Erfin­der Schwa­ber und Suther­land ele­gant aus der Affä­re gezo­gen. Da der Scrum-Pro­zess die ite­ra­ti­ve Erstel­lung eines Pro­dukts in soge­nann­ten Inkre­men­ten vor­sieht, wur­de sinn­vol­ler­wei­se eine Rol­le Pro­duct Owner (PO) ein­ge­führt. In der Theo­rie klingt das ein­fach: Als PO schrei­be ich mei­ne Anfor­de­run­gen in ein Back­log und das Team arbei­tet das so lan­ge ab, bis ich mein fer­ti­ges Pro­dukt in Hän­den hal­ten. Natür­lich will mein Team immer mal mit mir reden (jemand hat mal gesagt, eine User Sto­ry sei vor allem eine Ver­ab­re­dung zum Gespräch), aber dafür muss ich mir ja auch weni­ger Mühe mit den Anfor­de­run­gen machen, oder?

um scrum herum 768x478 1

In der Pra­xis von Soft­ware­pro­jek­ten ist das aber ungleich schwe­rer. Hier trennt sich die Spreu vom Wei­zen. Nur Pro­jek­te mit guten POs haben eine Chan­ce auf lang­fris­ti­gen Erfolg. Denn der Pro­duct Owner muss zumin­dest grob die kon­zep­tio­nel­le Kom­ple­xi­tät eines Soft­ware­sys­tems beherr­schen und die wesent­li­chen Tech­no­lo­gien aus­rei­chend gut ken­nen, um die rich­ti­gen Ent­schei­dun­gen zu tref­fen. Da das Team sich nur von Sprint zu Sprint han­gelt und die Sta­ke­hol­der in aller Regel zu wenig Ver­ständ­nis und Inter­es­se für die kon­kre­te Soft­ware­tech­no­lo­gie mit­brin­gen, ist er eine Art Archi­tekt des Sys­tems, zumin­dest fachlich.

Denn auch wenn es die Rol­le SW-Archi­tekt offi­zi­ell in Scrum nicht gibt: Die Vor­stel­lung, dass sich eine sinn­vol­le Archi­tek­tur „emer­gent“ ergibt, wenn nicht jemand am Anfang zumin­dest eine rela­tiv kla­re Visi­on des End­zu­stan­des und ent­spre­chen­de Rich­tungs­ent­schei­dun­gen for­mu­liert, scheint bei kom­ple­xen Sys­te­men mit einem lan­gen Lebens­zy­klus naiv. Gleich­zei­tig muss der PO aber das beherr­schen, was Requi­re­ments Engi­nee­ring genannt wur­de, als man fest­stell­te, dass das For­mu­lie­ren guter Anforderungen/Spezifikation eigent­lich eine Inge­nieur­s­tä­tig­keit ist. Und er ist eine Art Pro­jekt­lei­ter, da letzt­end­lich er die rele­van­ten Ent­schei­dun­gen tref­fen muss.

Schon eine gro­be Beschrei­bung sei­ner Auf­ga­ben gibt einen Ein­druck, wie anspruchs­voll die Rol­le des Pro­duct Owner ist:

  • Eine Visi­on des fer­ti­gen Pro­dukts ent­wer­fen (inklu­si­ve zu ver­wen­den­der Technologien)
  • Die Anfor­de­run­gen an das Pro­dukt von den Sta­ke­hol­dern ermit­teln und in aus­rei­chend klei­ne Häpp­chen zer­le­gen, die sog. Back­log Items (typi­scher­wei­se in Form von User Stories)
  • Im Pro­duct back­log die Items so prio­ri­sie­ren, dass eine sinn­vol­le Rei­hen­fol­ge ent­steht, in der das Pro­dukt inkre­men­tell ent­ste­hen kann, denn Scrum ist bekannt­lich ein ite­ra­tiv-inkre­men­tel­ler Pro­zess; dabei muss der PO in der Lage sein, zu erwar­ten­de Abhän­gig­kei­ten im Soft­ware­de­sign zu berücksichtigen
  • Die Items so beschrei­ben, dass sie einer­seits dem Team klar­ma­chen, was ver­bind­lich erwar­tet wird (Abnah­me­kri­te­ri­en), ande­rer­seits genug Frei­heit für die kon­kre­te Umset­zung las­sen (der PO soll kein SW-Design machen, nur gute Rah­men­be­din­gun­gen dafür schaffen)
  • Im Sprint Plan­ning die jeweils nächs­ten Items an das Team kom­mu­ni­zie­ren und dafür wer­ben, dass dar­aus ein mög­lichst sinn­vol­les Pro­duktin­kre­ment im nächs­ten Sprint wird; dabei muss er tech­ni­sche Argu­men­te des Teams zumin­dest grob ver­ste­hen und in Ent­schei­dun­gen berück­sich­ti­gen können
  • Wäh­rend des Sprints dem Team für Detail­klä­run­gen zu den Items zur Ver­fü­gung ste­hen, gleich­zei­tig den Kon­takt zu den Sta­ke­hol­dern pfle­gen und das Back­log wei­ter verfeinern
  • Ände­run­gen des Sprint­um­fangs nach­ver­han­deln, wenn das Team das wünscht, weil es sich z.B. ver­schätzt hat oder sich Mach­bar­keits­pro­ble­me abzeichnen
  • Spä­tes­tens im Sprint Review das Inkre­ment anhand der Items und ihrer Abnah­me­kri­te­ri­en abneh­men (das ist nicht not­wen­di­ger­wei­se der User Accep­t­ance Test, aber der Schritt, mit dem der PO dem Team bestä­tigt, dass sie ihn zufrie­den gestellt haben)
  • eine agi­le Release­pla­nung machen, um den Sprint­pro­zess mit über­grei­fen­den, oft­mals nicht agi­len Pro­zes­sen aus­zu­rich­ten, ins­be­son­de­re in Hin­blick auf markt­re­le­van­te Mei­len­stei­ne; hier ist oft noch eine detail­lier­te Beur­tei­lung exter­ner Abhän­gig­kei­ten tech­ni­scher oder orga­ni­sa­to­ri­scher Natur nötig

Die Auf­ga­be des Teams ist es „ledig­lich“, den Inhalt des jewei­li­gen Sprint-Back­logs so zu einem Pro­duktin­kre­ment zu machen, dass die Abnah­me­kri­te­ri­en erfüllt sind und der bis­he­ri­ge Sys­tem­um­fang kei­ne Regres­si­on erlei­det (Test­au­to­ma­ti­sie­rung ist eine abso­lu­te Grund­be­din­gung agi­ler Projekte).

Die Auf­ga­be des Pro­duct Owner ist es aber, den Über­blick über den gesam­ten Weg zu haben und das Team in Rich­tung eines mög­lichst nütz­li­chen Soft­ware-Pro­dukts zu füh­ren, das die Zie­le sei­ner Sta­ke­hol­der erreicht – auch wenn die­se „moving tar­gets“ sind, was ja ein Grund agi­ler Arbeits­wei­se ist.

Mit der Kom­pe­tenz des Pro­duct Owner steht und fällt also der Erfolg eines Scrum-Pro­jekts. Die­se Rol­le kann Motor oder – häu­fi­ger? – Soll­bruch­stel­le sein.

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: