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

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

Lese­zeit: 5 Minu­ten
product owner socialshare

Bei Soft­ware-Pro­jek­ten zählt am Ende nur das Pro­dukt, das eine hohe Benut­zer­ak­zep­tanz mit einer lan­gen Lebens­dau­er ver­ei­nen soll – und das natür­lich bei ite­ra­ti­ver Wei­ter­ent­wick­lung, gutem ROI und kur­zer „time-to-mar­ket“. Die­ser Bei­trag legt dar, war­um die rich­ti­ge Beset­zung des Pro­duct Owners für agi­le Soft­ware-Pro­jek­te über­ra­gend wich­tig ist.

Durch­schnitt­lich schei­tern ca. 70% aller SW-Pro­jek­te. Die­se Quo­te ist seit Mit­te der 80er Jah­re bis heu­te sta­bil, wenn man dem bekann­ten „Cha­os-Report“ glau­ben darf. Unter den Top-Ursa­chen ran­giert dabei immer wie­der die Anfor­de­rungs­qua­li­tät: unklar, unvoll­stän­dig, wider­sprüch­lich, nicht detail­liert genug, zu detail­liert, nicht test­bar, nicht nor­men­ge­recht – das sind typi­sche Attri­bu­te, die vor allem von Ent­wick­lern und Tes­tern ange­führt wer­den, wenn Anfor­de­run­gen Pro­jek­te behin­dern oder gar schei­tern lassen.

Man­che frus­trier­te Soft­wer­ker ver­wen­den für die­ses ver­brei­te­te Sym­ptom ach­sel­zu­ckend sogar eine eige­ne Abkür­zung: GIGO – gar­ba­ge in, gar­ba­ge out!

Gute Spezifikationen zu schreiben ist Ingenieursarbeit

Die­se Pro­ble­ma­tik führ­te zur Ein­füh­ren der Dis­zi­plin Requi­re­ments Engi­nee­ring: Ein­schlä­gi­ge Exper­ten (heut­zu­ta­ge oft als CPRE zer­ti­fi­ziert) sind in der Lage, Anfor­de­run­gen der sog. Sta­ke­hol­der (eng­lisch: Inter­es­sen­ver­tre­ter) sys­te­ma­tisch zu erhe­ben und in die nöti­ge Struk­tur und Qua­li­tät zu brin­gen, die die Ent­wick­lungs-Pha­sen eines Pro­jekts (im „Was­ser­fall“ sind das: Design, Imple­men­tie­rung, Inte­gra­ti­on und Test) benö­ti­gen – ver­gleich­bar Inge­nieu­ren in ande­ren Dis­zi­pli­nen: man stel­le sich einen Maschi­nen­bau-Inge­nieur vor, der statt Kon­struk­ti­ons­zeich­nun­gen und Stück­lis­ten nur eine vage tex­tu­el­le Beschrei­bung der Maschi­ne abgibt.

Soweit die Theo­rie. In der Pra­xis hat sich gezeigt, dass auch die bes­ten REs nicht feh­ler­los sind – wie übri­gens auch die bes­ten Soft­ware-Ent­wick­ler. Der Grund der erschre­ckend hohen Feh­ler­quo­te ist nicht etwa man­geln­de Pro­fes­sio­na­li­tät, son­dern die rasend schnel­le Wei­ter­ent­wick­lung der IT: Soft­ware­sys­te­me wer­den in einer der­ar­ti­gen Geschwin­dig­keit kom­ple­xer und ändern ihre tech­ni­schen Grund­la­gen, dass sich kein trag­fä­hi­ger, gar „indus­tri­el­ler“ Pro­zess ent­wi­ckeln und dau­er­haft hal­ten kann. Beson­ders deut­lich wur­de das im sog. „Metho­den­krieg“ der 90er Jah­re: Man ver­such­te ver­geb­lich, durch immer for­ma­le­re Spe­zi­fi­ka­ti­on (ich habe schon Sum­men­be­rech­nun­gen in UML model­lie­ren müs­sen) das Durch­schlüp­fen von feh­ler­haf­ten Anfor­de­run­gen zu ver­hin­dern. Denn früh gemach­te, aber spät ent­deck­te Feh­ler füh­ren bekannt­lich zu hohen Fol­ge­kos­ten bzw. Pro­jekt­ver­zö­ge­run­gen. Das sehen Betriebs­wir­te eben­so ungern wie übri­gens auch teu­re Inves­ti­tio­nen in Halb­fer­tig­be­stän­de – und nichts ande­res ist es, wenn Soft­ware-Pro­jek­te über Mona­te oder Jah­re Bud­get ver­bra­ten, bevor sie Nut­zen erzeu­gen – oder als geschei­tert abge­schrie­ben werden.

„Fail fast, deliver quick and often“: Agil macht alles besser – oder?

All­mäh­lich muss­te jedem klar sein, dass mit stei­gen­der Kom­ple­xi­tät die Ver­mei­dung von Feh­lern immer unmög­li­cher wird – das ist übri­gens auch ein Pro­blem der Abde­ckung bei der Qua­li­täts­si­che­rung, die aber nicht The­ma die­ses Bei­trags ist. Wenn man aber Feh­ler nicht ver­mei­den kann, soll­te man sie so früh wie mög­lich erken­nen und kor­ri­gie­ren, ggf. sogar für die Zukunft dar­aus lernen.

Nach­dem zumin­dest für bestimm­te Kate­go­rien von Soft­ware alle schwer­ge­wich­ti­gen, for­ma­len und doku­men­ta­ti­ons­las­ti­gen Pro­zes­se sich als ten­den­zi­ell kon­tra­pro­duk­tiv erwie­sen hat­ten, pos­tu­lier­te eine Grup­pe von Soft­ware-Pio­nie­ren eine revo­lu­tio­nä­ren Idee: Man könn­te ja zur Abwechs­lung mal mit­ein­an­der reden. Man könn­te direkt Soft­ware schrei­ben statt lan­ge Doku­men­te. Man könn­te Din­ge in defi­niert kur­zer Zeit aus­pro­bie­ren und not­falls weg­schmei­ßen, statt sie sich über aus­ufernd lan­ge Zeit theo­re­tisch (und dann doch nicht funk­ti­ons­fä­hig) zu über­le­gen und sich for­mal gegen ihr spä­te­res Schei­tern abzusichern.

Die­se und ähn­li­che Ideen wur­den bekannt­lich als agi­les Mani­fest for­mu­liert, nach­zu­le­sen unter agilemanifesto.org. Damit trat eine Metho­dik ihren Sie­ges­zug an, der bis heu­te unge­bro­chen anhält: Die agi­le Software-Entwicklung.

Was Google kann, können wir auch, oder?

Software­entwicklung ist heu­te kaum mehr ohne agi­le Metho­dik vor­stell­bar. Wäh­rend frü­her höchs­tens alle paar Mona­te eine neue Soft­ware­ver­si­on unter erheb­li­chen Geburts­schmer­zen auf den Markt kam, brin­gen heu­te vie­le Unter­neh­men teil­wei­se zig Ver­sio­nen pro Tag „in Pro­duk­ti­on“ oder zumin­dest auf Inte­gra­ti­ons- und Test­sys­te­me – und das meist in deut­lich bes­se­rer Qua­li­tät. Das ist neben der Auto­ma­ti­sie­rungs­quo­te auch dadurch zu erklä­ren, dass klei­ne Ver­än­de­run­gen ein­fa­cher zu kon­trol­lie­ren als gro­ße – von der gefürch­te­ten „big-bang“-Integration frü­he­rer Jahr­zehn­te ganz zu schweigen.

Beson­ders Start-Ups pro­fi­tie­ren von kur­zer „time-to-mar­ket“ und exzel­len­tem ROI ihrer Soft­ware­inves­ti­tio­nen. Wie sehr, wird anhand der Tat­sa­che deut­lich, dass Goog­le, Ama­zon und ähn­li­che Inter­net-Gigan­ten vor nicht all­zu lan­ger Zeit sel­ber Start-Ups waren! Im Zuge der agi­len Ent­wick­lung die­ser Unter­neh­men ent­stan­den vie­le Metho­den und Tech­no­lo­gien, die nun auch ande­ren zur Ver­fü­gung – zum größ­ten Teil sogar open-source.

Sol­che Soft­ware­er­folgs­ge­schich­ten rufen natür­lich auch eta­blier­te Unter­neh­men ande­rer Bran­chen auf den Plan. Wer heu­te etwas auf sich hält, „macht Scrum“. Dabei wird oft über­se­hen: Eines unter­schei­det die „big play­er“ des Inter­nets erheb­lich von durch­schnitt­li­chen Fir­men aus ande­ren Bran­chen: Ihr urei­gens­tes Busi­ness baut auf Soft­ware auf. Sie waren nie etwas ande­res als Inter­net-Unter­neh­men und haben das Netz erheb­lich mit geprägt. Oft gehö­ren die Fir­men­grün­der zum Core-Ent­wick­lungs­team, zumin­dest aber haben sie sehr kla­re Visio­nen, was ihre Soft­ware leis­ten soll; weil sie wis­sen, was tech­nisch mög­lich ist und wie das Inter­net funk­tio­niert. Bei die­sen Fir­men gehen agi­le Soft­ware-Ent­wick­lung und „busi­ness agi­li­ty“ Hand in Hand bzw. sind zwei Sei­ten einer Medaille.

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: