Bloggrekommendation

Jag har precis upptäckt en annan blogg som skriver om ungefär samma saker som jag, fast med en annan infallsvinkel och ofta i mitt tycke bättre (jag kan bli hemskt trött på mina egna ord).

Monika Wendlebys "Creative Lean".

Läs det här om flödeseffektivitet: "Sjuksköterskans dilemma"

Eller det här om varför New Public Management och lean är två helt olika saker: "Lean är inte lika med New Public Management"

Eller det här om autentiskt ledarskap: "Vad är autentiskt ledarskap?"

Kloka ord. Mycket nöje!

Värde är mänskliga behov

Jag skrev om digitaliseringen och myndigheterna i inlägget "Samtiden och framtiden", om lite förändringar som krävs för att man ska få det att funka. En punkt jag tog upp var behovet av att riva murarna mellan "verksamhet" och "IT". Det är en konstlad och lite obegriplig uppdelning som kostar enorma belopp genom att det inför hinder för effektivt samarbete.

Jag har skrivit om det förut. Här i "Vi bygger broar" om hur projekttänkande och tron att trög IT utveckling beror på trög IT-avdelning döljer att det är fråga om ett gemensamt flöde. Här i "Ett anspråkslöst förslag" om några konkreta sätt för att eliminera beställar/utförartänkandet och samarbeta ihop.

Jag har börjat använda den här definitionen när jag ombeds berätta om kärnan i smidiga arbetsmetoder: "Svärmning runt gemensamma synliggjorda värdeflöden". Vad ett värdeflöde är berättade jag om inlägget "Värdeflödesperspektivet".

Flera organisationer jag arbetat i har vittnat om hur arbetet löpt smidigare så snart allvarliga incidenter inträffat. När vi tillsammans analyserat vad som då har hänt ser vi att alla allvarliga incidenter har synliggjort att ett viktigt mänskligt behov är i fara. Plötsligt har alla förstått vad som är viktigt på riktigt och kunnat samarbeta runt det.

Det är precis den mekanism vi vill åt, fast inom trygga ramar. Och nyckeln är att man slår fast precis vilka behoven är. Inte på ett fint och högtravande sätt som ändå inte kan uppfyllas, utan på ett metodiskt och realistiskt sätt. Som inbegriper att när vi säger vilka behov som är viktiga så har vi också berättat om vilka behov som är mindre viktiga. Att kunna göra saker är att kunna välja bort allt som inte ska göras.

Om vi inte har bestämt oss för vilka behov vi tänker möta så vet vi inte hur vi ska skapa värde. Då kan vi inte synliggöra något gemensamt värdeflöde. Då blir vi fast på varsin sida om muren. Med en stor osäkerhet på om det vi gör skapar värde överhuvudtaget.

Och glöm inte bort att alla människor i hela värdeflödet också har mänskliga behov. Om inte de behoven möts kan inte de människorna samarbeta för att möta mänskliga behov hos dem som ska ta emot det skapade värdet.

Det är här som digitaliseringen börjar. Inte i blicken på vilka verktyg och internetuppkopplade saker som finns. Utan i blicken för vilka mänskliga behov vi tänker möta och vilka vi inte tänker möta. Utan förståelse för mänskliga behov har vi ingen förståelse för värdeskapande, och då kan vi inte heller samarbeta, särskilt inte om något så komplext som digital teknik i människans tjänst.

Oplanerbara projekt?

Igår skrev jag att digitaliseringen kräver att vi slutar upp med att arbeta i projekt när det gäller vår digitala närvaro. Det här är en tanke som är lite ny för en del så jag behöver nog förklara lite djupare.

När man talar om "projekt" kan man använda ordet lite slarvigt om allt möjlig som görs i en verksamhet. Man har till och med talat om agila metoder som "projektmetoder". Men man kan också vara mer precis, eftersom verksamheter ofta har regelverk som definierar vad ett projekt är och därmed styr hur man alls kan arbeta inom organisationen.

Så gott som samtliga projektmetoder som är implementerade i verksamheter idag, (PEJL, PROPS, PRINCE2, PPS med flera) bygger på att du kan arbeta mot ett på förhand fastslaget mål, och att vägen dit kan planeras i detalj. Själva ordet "projekt" kommer från begreppet "förarbete". Projektstyrning handlar om hur man styr utefter den på förhand upprättade planen: korrigerar avvikelser och följer upp på att alla utför precis de aktiviteter som man långt tidigare bestämt ska utföras.

Att utveckla tjänster, och särskilt komplexa tjänster som IT, är en verksamhet med två egenheter. För det första ger små avvikelser i förutsättningarna stora förändringar i utfallet. En liten insikt om att systemet behöver hantera ytterligare en liten sak kan leda till att hela informationsmodellen behöver tänkas om. För det andra så upptäcker vi nya förutsättningar hela tiden, på ett sätt som inte är förutsägbart.

På senare tid har ägarna bakom olika projektmetoder försökt justera dem för att inkorporera den här nya flugan agila metoder. Ofta har man sagt att det går alldeles utmärkt att bedriva "utförandefasen" på ett "agilt sätt" (folk arbetar i team och flyttar lappar på en tavla varje morgon). Men så länge som projektet styrs utifrån den på förhand upprättade planen (resultatet av "förstudiefasen") är modellen inte kompatibel med de agila metodernas hjärtpunkt: ständig omplanering i takt med att man får nya insikter om hur behov ska mötas. Att folk träffas varje morgon och flyttar lappar på en tavla har inget med saken att göra.

Projektstyrning kan hantera små förändringar. Man gör mindre justeringar i planen och i resursallokeringar och hoppas på så sätt få tillbaks projektet "på banan". Vad man däremot inte kan hantera är om banan visar sig leda helt fel. Projektmodellerna föreskriver faktiskt att projektet ska nödstoppas när de grundläggande antagandena inte längre gäller. Problemet är att detta innebär en prestigeförlust, och att folk helt felaktigt tar hänsyn till de pengar man redan plöjt ner i projektet.

Alla inser dessutom att själva behovet inte försvinner bara för att projektet dör. Och om projekt är den enda arbetsform som verksamheten tillåter när det gäller att möta behov genom tjänsteutveckling blir man så illa tvungen att fortsätta och ta hand om de nya insikterna på ett improviserat sätt, inte sällan till mycket höga kostnader.

Agila metoder är inga projektstyrningsmetoder. De är alternativ till projektstyrningsmetoder. Projekt kan hantera komplicerade verksamheter, men inte komplexa. Agila metoder är tekniker för att på ett välstrukturerat sätt hantera komplexitet, att hantera budgetar och planer i ljuset av varians och oförutsägbarhet, och kunna nå både långsiktiga och kortsiktiga mål om dessa är möjliga att nå.

För en chef i en verksamhet som står inför digitaliseringens utmaningar krävs det att man tar tag i problemet med ekonomisk styrning kopplad till projekt, och byter ut den gamla styrningen mot de ekonomiska styrverktygen som de agila metoderna erbjuder. Det kräver att man gör slut med en del av sina tidigare beteenden och mätpunkter, för annars kommer de gamla projektmetoderna att fortsätta vara grus i maskineriet.

Det finns även andra problem med tjänsteutveckling i projektform, men den ekonomiska styrningen baserad på ohållbar planering är det mest grundläggande hindret. Därför tar jag upp det först.

Samtiden och framtiden

Ny regering där IT-frågorna delats upp på det som rör infrastrukturen och det som rör e-samhället (bra), folk inom fler och fler områden som får upp ögonen för smidigare arbetssätt (inte minst i ljuset av sjuktalen och att arbetsgivarens ansvar för den psykiska hälsan har förtydligats), fler som börjar förstå vad digitalisering faktiskt innebär, och Almedalen med tonvikt på framtidsfrågor inträffar om en månad.

Att IT i framtiden skulle sluta ses som en separat del för sig har vi vetat länge. Nu är den framtiden här. Att det händer samtidigt som de smidiga arbetsmetoderna börjar vinna terräng utanför IT-avdelningarna är nog ingen tillfällighet. Vi står i början av en transformation på stor skala av stora delar av samhällslivet, och vi som genom åren sett den transformationen äga rum i det lilla på flera ställen har lite tankar att bidra med tänker jag.

Här följer några tanketrådar:

Om myndigheter tänker sig vara närvarande i medborgarnas liv primärt över digitala kanaler så krävs det att de inrättar sig för att faktiskt kunna sköta digitala kanaler. Muren mellan "verksamhet" och "IT" måste rivas. Det finns nämligen enbart verksamhet. Det finns inte heller någon skillnad mellan att komma på hur tjänsten ska vara och koda den. Kod är bara ett sätt att beskriva insikter på, och insikter måste tas fram löpande.

Projekt är en arbetsform som passar för tillfälligt arbete när mål, tidplaner och budgetar ligger fast. Att arbeta med sin digitala närvaro är istället ett ständigt pågående arbete emot ett mål som ständigt flyttar på sig. Att arbeta med digital närvaro är med andra ord inget för projektarbeten.

Man kan tänka så här (tack Carl för dialogen): Tänk inte "projekt", tänk produkt. En produkt utvecklas konstant över sin livscykel. Eller ett steg till: tänk inte "produkt", tänk tjänst. En tjänst är ständigt närvarande i brukarens liv och kräver att man ständigt sköter om den. Eller ytterligare ett steg: tänk inte "tjänst", tänk på att alltid möta mänskliga behov.

För att lyckas med e-förvaltning behöver en myndighet alltså ständigt arbeta med att pejla av medborgarnas behov, ständigt hitta sätt att förbättra tjänsten, och genomföra och driftsätta förändringarna löpande. Inte klumpvis.

Som tur är finns metoder i den smidiga verktygslådan för att göra detta: obyråkratiska förvaltningsramverk, kravfångningstekniker som utgår från mänskliga behov, ständig omprioritering, vidareutveckling och driftsättning. Den agilitet i organisationen som krävs uppnår man med självstyrande tvärfunktionella team som samarbetar tätt.

Men det kommer inte att lyckas om man inte inkluderar hela värdekedjan. Det är det jag menar med att riva murarna mellan "verksamhet" och "IT", och för den delen även mellan systemutveckling och drift av IT-baserade tjänster.

Idag hindras vi av tre saker. Dels okunskap förstås om hur man kan samarbeta tätt över rivna murar. Det hindret är vi många som i dagsläget är igång och river, inte minst inne på myndigheter. Men även konkreta strukturer ligger i vägen. Beställare/utföraremodeller kan vara institutionaliserade så att man inte ens kan ta ett gemensamt ansvar för tjänsterna. Det kan finnas regler om att IT-utveckling alltid måste bedrivas i projektform. Att man inte får genomföra plattformsförändringar om man inte samtidigt implementerar de funktioner som plattformsförändringen ska ge, vilket leder till stora projekt som då alltid misslyckas eftersom de är för stora. Att man följs upp på hur mycket man belägger sina resurser vilket gör flödet långsamt. Kostnadsfokus istället för att se till totalekonomin. Årsbudgetar som bygger på årsplanering som omöjliggör nya insikter.

Och det finns dessutom en omänsklig ledarskaps- och arbetsplatskultur på många myndigheter. Agilitet kräver transparens. Men kulturen är inte sällan straffande vilket alltid blockerar transparensen. Den som lyfter ett problem blir nedtryckt. Jag har sett hur höga chefer gått flera våningar ner till enskilda systemutvecklare och skällt ut dem för att de misslyckas när de lyft insikter om strukturella problem. Probleminsikt får nämligen chefer i de högre skikten att framstå som sämre i sina likars ögon, för i det högre skikten gäller det att framstå som bäst i klassen oavsett hur verkligheten ser ut.

Det jag är rädd för är att de ansvariga för e-samhället inte är beredda på att de ska behöva hantera den här typen av frågor. Att myndigheterna får direktiv om att röra sig i en viss riktning men inte mandat att undanröja de hinder som ligger i vägen. En del av de här strukturella hindren kan man spåra ända till [ÄNDRING: här beskyllde jag tidigare Statskontoret, det var fel] myndigheternas finaniseringsdirektiv för IT-projekt och hur Riksrevisionens följer upp, det vill säga sådant som inte ens en generaldirektör får besluta om. E-samhället kräver agilitet, och på den här nivån kräver agilitet alltså att självaste regeringen agerar.

Lean och agilitet är ledarskapsfilosofier baserat på systemsyn. I den smidiga verktygslådan finns gott om verktyg för att skapa en mänsklig ledarskaps- och arbetsplatskultur. De finns, de fungerar, och vi vet hur man inför dem. Det enda som krävs är ett beslut att göra det.

I den smidiga verktygslådan finns även ekonomiska ramverk som passar kontinuerlig behovsdriven tjänsteutveckling. Ramverk som ersätter stora budgetar med årsvis uppföljning. Ramverk som ger bättre kontroll över investeringar och effekthemtagning än vad dagens ramverk ger. Även här är vi bara ett beslut bort från att börja använda dem. Vi behöver inte uppfinna något helt nytt, metoderna är redan framtagna (även om kontinuerlig anpassning förstås krävs).

Det jag hoppas på är att berörda parter så snart som möjligt förstår vad som krävs för att förverkliga de drömmar de har om e-samhället och digitala myndigheter. Förstår, och även tar mod till sig och börjar agera därefter.

De agila metodernas historia

[Detta är ett kapitel ur en liten skrift om vad organisationsagilitet är, riktad till folk i arbetslivet men utanför IT. Jag är nyfiken på vad en människa som inte kan IT tycker om den här texten. Är den begriplig, eller har jag råkat få med något IT-specifikt? Kommentera gärna]

När datorerna inte var så kraftfulla var det enkelt att skriva datorprogram. De första programmen var enkla beräkningar av missilbanor eller löner. På natten innan den 23:e i varje månad kördes ett enkelt löneprogram på ett magnetband där alla anställda fanns, och dagen därpå fraktades bandet till en bank som gjorde själva löneöverföringen. Det dyra och komplicerade var själva datorn, stor som ett skåp, som stod i källaren. Programmet var inte det krångliga.

Under 1980-talet blev datorerna mindre och fler och tog sig in på kontoren och kopplades samman med varandra och med de gamla stordatorsystemen som hade hand om lönekörningarna (fast numera utrustade med hårddiskar så att man kunde hantera all data parallellt och inte i sekvens som på magnetbandstiden). Man såg enorma nya möjligheter med den nya tekniken och gav sig i kast med att tänka ut nya system. Men mycket snart märkte man att det fanns stora problem. Flera små sammankopplade datorer gav många möjligheter. men också stor komplexitet. Ju fler möjligheter desto svårare att realisera dem. Matematiskt intresserade personer insåg att komplexiteten ökade exponetiellt med möjligheterna. I mitten-slutet på 80-talet hade man insett att om man inte kom på ett sätt att hantera komplexiteten så skulle man aldrig kunna förverkliga alla fina nya möjligheter. Varje ny funktion man ville ha ökade både tiden, kostnaden och risken oproportionerligt mycket. Något måste göras.

Försök med projekt

Ett försök att hantera komplexiteten var att försöka planera bättre. Man resonerade så här: Byggindustrin har kunnat hantera komplicerade och stora byggen i över 150 år. När man reste Eiffeltornet var det ett paradexempel på logistik (järnleveranser från Sundsvall till Seine) och precis tillverkning (balkarna tillverkades till exakt storlek enligt den mycket noggranna ritningen och skickades upp i tornet för att sättas på plats). Kunde man inte först göra en noggrann design där man, precis som på en byggnadsritning, ritade in hela lösningen för att sedan tidsätta varje moment som krävs för att implementera den? Och sedan bara se till att rätt mängd personal fanns på plats som gjorde rätt saker? I enlighet med en plan som följs upp noggrannt? Alltså utveckla IT i form av projekt?

Man försökte börja tillämpa detta inom IT-utveckling. Det svenska företaget Ericsson utvecklade under åren 1987-1989 projektmodellen PROPS, och flera andra organisationer skapade sina varianter. Alla modellerna byggde på tanken att man i en förstudie kunde skapa den rätta ritningen och utifrån den göra en plan som höll både vad gällde tidpunkter, tidsåtgång och kostnader. Man utgick från att det svåra var att göra planen och att se till att alla följde den utan att avvika.

Även om projektmodellerna hjälpte till att skapa ordning och reda så innebar det inte att de löste problemen. Systemutvecklingsprojekt havererade i en aldrig sinande takt. När internet slog igenom i mitten på 90-talet ökade dessutom både komplexiteten, antal ställen i samhället där systemutveckling ägde rum, och antal personer som ägnade sig åt att både beställa och utveckla system. Vad var det som hände? Varför fungerade det inte? Det som man skriver när man utvecklar system, själva koden, är ett mycket exakt designdokument. Utifrån det dokumentet kan en dator bygga själva systemet och även tillhandahålla det för en användare som en tjänst. Alla andra designdokument som beskriver lösningen är översiktliga och inte detaljerade. De går inte att skapa en plan utifrån. För att göra en riktigt bra lösning i en förstudie behöver man alltså egentligen skriva hela koden.

Men problemen med att använda projektmetoder i utvecklingsarbete stannar inte där. Hur vet man att man är på rätt väg, att den lösning man tar fram verkligen möter människors behov, om man inte får stämma av under resans gång eftersom den lösning man ritat inte får ändras? Och om man stämmer av löpande, kanske genom att ge folk prototyper och delar av systemet att prova, hur gör man då med den återkoppling man får? Hur hanterar man informationen att den tänkta användargruppen inte alls kan använda systemet som det är tänkt, att det krävs omtag på kravställningen?

Med systemutveckling är det så att även små förändringar i kravbilden och förutsättningarna kan påverka ganska stora delar av systemet. Och med projekt är det så att förändringar i det man planerar att göra kan kasta omkull hela planen eftersom de olika arbetsmomenten ofta är så beroende av varandra.

Ska man hålla fast vid en plan som inte längre är meningsfull? Ska man ignorera den nya information man fått fram på vägen om hur människors behov kan mötas? Ska man blint hålla fast vid att de antaganden man gjorde under ett tidigt skede stämmer, trots att man under tiden upptäcker hur fel man hade? Eller finns det andra sätt att bedriva utveckling på?

Iterativa arbetssätt

Att utveckla nya saker innebär ett utforskande. Det fanns de som tidigt såg hur projektmodeller inte stödjer ett utforskande arbetssätt, utan tittade på om man inte kunde hämta inspiration från andra ställen än byggindustrin och andra verksamheter som byggde på planering på förhand. Ett sätt att försöka hantera komplexitetsproblem är att bryta ner problemet i mindre bitar. Redan under femtiotalet hade raketindustrin och den amerikanska försvarsmakten experimenterat med att bryta ner komplexa utvecklingsprojekt i mindre delar och låta olika grupper utveckla sina delar parallellt. Med jämna mellanrum, ungefär var åttonde vecka, berättade man för varandra vad man hade kommit fram till och så gjorde man en omplanering utifrån den senaste kunskapen.

Inom systemutveckling finns det en uppsättning tekniker för att bryta ner stora och komplexa datasystem i mindre bitar, dessa tekniker kallas med ett samlingsnamn för objektorientering. För att lösa komplexitetsproblemet inom systemutvecklingen beslöt sig många att satsa på detta. Men några av dem som arbetade med objektorientering gjorde iakttagelsen att det inte räcker med att bryta ner lösningen i mindre delar. För att få till ett utforskande arbetssätt behöver man även kopiera rymd- och försvarsindustrins tanke om att arbeta i korta etapper och ständigt omplanera. Det som också kallas att arbeta iterativt.

Dessa personer testade under 90-talet iterativa arbetssätt, kompletterade med idéer om värdeflöden hämtade från Toyota och idéer om gemensamt beslutsfattande ifrån alternativ­rörelsen. På årliga konferenser träffade de varandra och presenterade vad de hade funnit och med tiden publicerade man sina arbetssätt som olika metoder: Scrum, XP, DSDM med flera.

Det agila manifestet

När man hade hållit på några år funderade man på vad det var man hade kommit fram till egentligen. Man lånade idéer av varandra så ramverken började likna varandra mer och mer.

Vilka var de underliggande tankegångarna man delade med varandra? Frågan ställdes på en konferens år 2000, och man samlades i en särskild konferens år 2001 för att fundera kring detta. Det verkade som om man allesammans hade nått vissa gemensamma insikter om vad som var mer viktigt än annat:

Man hade funnit att det var förmågan för gruppen att kommunicera och samspela som var viktig, inte att följa en viss process eller att använda vissa verktyg.

Man hade kommit på att det var viktigt att fokusera på den värdefulla leveransen, till exempel mjukvara som fungerar. Det är viktigare än att uppfylla alla projektmodellens formkrav.

Man hade sett behovet av att samverka med kunden så att man prövar sig fram till en bra lösning tillsammans, hellre än att låsa både kund och leverantör i ett detaljavtal på tidigt stadium.

Och allt detta gör att förmågan att hantera förändring blir mycket viktigare än att följa upprättade planer slaviskt. Dessa fyra insikter samlades i en liten text som kallas Det agila manifestet. Det, tillsammans med tolv bakomliggande principer, har fått definiera vad som är agilt och inte.

Agilitet idag

Agila metoder har blivit det normala sättet att arbeta inom systemutvecklingen, i alla fall nere “på golvet”. Fortfarande kämpar många IT-utvecklingsorganisationer med att få även finansierings-, kravfångnings- och säljprocesserna lite mer lättrörliga. Och trenden är att fler och fler människor även inom andra verksamheter än systemutveckling provar agila arbetssätt: omsorg, försäljning, marknadsföring, produktutveckling, tjänsteutveckling med flera ställen. Många upplever ett behov av att jobba smidigare, och många tycker att det både är effektivt och befriande med det stora mått av delegering och självbestämmande som många agila tekniker bygger på. Därför kommer resten av skriften helt sakna IT-fokus.

Infografik: Agil förändringsledning

Infografiken kan laddas ner HÄR

Detta är en liten minnestavla för att minnas hur man kan bedriva förändringsledning på ett agilt sätt. Jag tycker att detta arbetssätt fungerar som en bra teknik vid införande av lean och agila arbetssätt, eller för att bättra processen som efter ett retrospektiv eller annat förbättringsmöte, eller för att införa andra förändringar,

Man utgår från effektmålen man vill uppnå.

För att uppnå effektmålen hittar man på konkreta förändringar i arbetssätten. Hypotesen är att de konkreta förändringarna leder till effektmålen, men det är bara en hypotes. För att veta behöver vi mäta och följa upp.

En förändring som tar upp till ett kvartal att genomföra behöver brytas ner till några delmål som vart och ett kan utföras inom som högst en månad. Varje månadsärende behöver brytas ner till några delmål som vart och ett kan utföras inom högst en vecka.

För att uppnå en förändring hittar man på experiment, det vill säga konkreta förändringar i arbetssätten att testa och som man hoppas kunna ge mer information om och hur de ska permanentas.

Mindre arbetsgrupper hittar på och utför och följer upp experimenten, på vanligt retrospektiv/PDCA/kaizen-sätt.

En synkmästare följer upp och hjälper arbetsgrupperna att göra sitt jobb.

Förändringsägare prioriterar mellan de föreslagna åtgärderna, baserat på uppföljningen.

Ha allt synligt på en tavla, och tillämpa regelbundna förbättringsmöten så att även själva förbättringsprocessen förbättras.

Infografiken kan laddas ner HÄR

Teknik: Agil PO

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.