Im drit­ten und letz­ten Teil unse­rer Serie 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.

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. 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.

Bei Soft­ware-Pro­jek­ten zählt am Ende nur das Pro­dukt: Es soll eine hohe Benut­zer­ak­zep­tanz mit einer lan­gen Lebens­dau­er ver­ei­nen – und das natür­lich bei ite­ra­ti­ver Wei­ter­ent­wick­lung, gutem ROI und kur­zer „time-to-mar­ket“. Um das unter einen Hut zu krie­gen, set­zen vie­le Unter­neh­men zu Recht auf agi­le Ent­wick­lung, meis­tens mit Scrum. Die­se führt ein neu­es, meist über­se­he­nes Risi­ko ein: Einen Fla­schen­hals namens Pro­duct Owner. In sei­nem Blog­bei­trag beschreibt unser Prin­ci­pal Con­sul­tant Micha­el „Pul“ Paul­sen, wel­che Skills ein Pro­duct Owner haben soll­te – und was eigent­lich sei­ne Auf­ga­ben sind.