En annan teknik är den agila "PO":n. PO-rollen har fått sitt namn efter begreppet "Product owner" som är lite problematiskt. Det finns nämligen redan en massa "produktägare" i olika verksamheter som uttryckligen inte gör det som en agil PO ska göra, om man till exempel tittar på beskrivningarna av "Scrum Product Owner" i Scrumguiden.
En agil PO tar ansvar för att alla förändringar i ett förvaltningsobjekt är ekonomiskt optimala över hela objektets livscykel. När objekten är tekniska, till exempel mjukvara och IT-tjänster, så handlar det om att väga de marknadsmässiga och verksamhetsstödjande aspekterna av objektet mot tekniska hänsyn. En agil PO har ansvar för alla aspekter: ekonomin, tekniken, marknadsmässigheten, och att objektet är verkligen stödjer de mänskliga aktiviteter som det ska stödja.
I många verksamheter är det istället så att "produktägaren" bara tar några av dessa hänsyn, ofta några av de verksamhetsmässiga. Det tekniska antas antingen sköta sig själv eller så är verksamheten så okunnig om tekniska realiteter att man helt enkelt inte förstår att sätta upp rutiner för att hantera det. Det är helt sant att för ett litet objekt är det rimligt för en PO att lämna över handhavandet för alla tekniska aspekter av objektet till ett arbetslag av tekniskt kunniga. Men eftersom PO:n är den som bestämmer vad som ska göras med ett objekt, så förblir PO:n i slutändan ansvarig även för tekniken. När verksamheten vill ha en sorts förändring av objektet och teknikerna en helt annan så måste någon välja väg och ta ansvar för det valet.
För att lösa problemet med att ingen tar helhetsansvar för ett objekt föreslår Ken Schwaber och Jeff Sutherland i sitt metodramverk "Scrum" att det ska finnas en PO så att prioriteringsordningen alltid är klar: för detta objekt vet vi alltid vad som är det mest nödvändiga att göra just nu. Det kan vara så att den ni idag kallar "produktägare" är rätt person att även axla rollen som agil PO. Men det är inte säkert.
Men det finns ett problem till som PO:n löser. Det handlar inte bara om att optimera det ekonomiska värdet av ett objekt genom att prioritera mellan de förändringar man vill göra i objektet. Det handlar även om att optimera det ekonomiska värdet av ett arbetslag.
Antag att vi har tre objekt, t ex tre tekniska system, och ett arbetslag om fem personer. Arbetslaget kostar fem miljoner kronor om året. Det blir viktigt hur vi prioriterar arbetslagets arbete.
Om vi nu tillsätter en PO per objekt blir det arbetslagets uppgift att prioritera mellan objekten. Prioriterar de objekt A under en månad kommer förändringarna i B och C att få vänta. Hur vet vi att väntekostnaden (cost of delay) för A, B och C är sådana att detta är det mest optimala? Prioriterar de att försöka hjälpa A, B, och C kommer alla tre att få vänta eftersom kalendertiden för att en förändring ska bli klar blir åtminstone tre gånger så lång för var och en, förutom att de alla tre får dela på merkostnaden för uppgiftsväxling mellan tre initiativ (som lätt kan uppgå till 50% av kostnaden utan uppgiftsväxling).
Man kan förstås utrusta arbetslaget med verktyg (förmåga och mandat) att rätt prioritera mellan A, B, och C. Men en agil PO, så som Scrum beskriver den, är också en lösning. Samla förändringarna för alla objekt i en och samma lista, och gör löpande en optimal prioritering mellan dem. Det är därför som Scrum föreskriver att det är PO:ns ansvar att ekonomiskt optimera utvecklingslagets arbete, för det kommer i slutändan att vara optimalt även för varje enskilt objekt ("produkt").
En kursdeltagare föreslog en gång att man borde kalla den agila PO:n för "prioriteringsombudsman" ("Prioritization Ombudsman") för det är vad det ytterst handlar om, snarare än ett produktägarskap.
Inga kommentarer:
Skicka en kommentar