ESV:s rapport: Den bortglömda frågan om ledarskapet

Vad ESV:s rapport inte tar upp är en av de viktigaste faktorerna för lyckad digitalisering: ett passande ledarskap. I en bilaga till rapporten lyfter man fram Transportstyrelsens modell för att följa upp digitalisering. Den modellen tittar även på ledarskapet men ESV:s arbete har inte gått ut på att mäta eller på annat sätt synliggöra de offentliga aktörernas mognad och omognad vad gäller det ledarskap som krävs för lyckad digitalisering.

Och det är min stora oro och invändning. Framgångsrika digitala värdeströmmar byggs i små etapper och utvecklas kontinuerligt. Man styr löpande mot nyttohemtagning genom att arbeta utforskande med ständig omplanering. Ansatsen brukar kallas agil och den både kräver en annan syn på utvecklingskostnader och löpande finansiering och en riven skiljemur mellan IT och verksamhet. Och förutom att dessa två förändringar förutsätter en annan modell för finansiering av värdeströmmarna än vad som används idag, så krävs också ett slags ledarskap som tyvärr inte är så vanligt på myndigheterna.

Andra skriver mycket om det agila ledarskapet och digitaliseringen, så därför brukar jag avstå när jag bloggar och istället inrikta mig mer på strukturer och pengafrågor så att det också kommer med i debatten. Men i stort sett alla vi som arbetar dagligen med de här frågorna är rörande överens: ledarskapet är centralt.

Det krävs ett ledarskap som aktivt förespråkar radikal transparens i organisationen, till exempel genom att inte bestraffa den gruppering där systemisk varians, variation i utfalll som snarare beror på systemfaktorer än på individerna, råkar dyka upp. Det krävs tillitsbaserad styrning och de strukturer i form av tydliga delegeringar och explicita frihetsgrader som det bygger på. Det handlar om ett coachande och tjänande ledarskap som sätter golvet närmast värdeskapandet i högsätet och tydligt fokuserar på kundnytta mer än att behaga personerna över en i hiearkin.

Eller: nedanför en i den omvända hierarkin som lean och agilt tillämpar på. Är jag chef är jag tjänare åt värdeströmmens frontsoldater, och min chef betjänar i sin tur mig med förutsättningar och tydliga beslut. Och alla chefer förväntas se och förstå vad som händer på golvet, mitt i värdeströmmen.

I nästan alla artiklar om forskning och erfarenheter som gjorts rörande ledarskap och digitalisering lyfts dessa och liknande drag i ledarskapet fram som nödvändiga: frihetsgrader i arbetet, resultatorienterat, inga alltför förutbestämda roller, bort med informationsmonopolen, alla är ledare, fokus på samarbetet och folks relationer, organisationellt lärande, empati med kunden under kundresorna, kultur runt att synliggöra alla problem och att arbeta med ständig förbättring, beslutsmässighet, förändringsbenägenhet hos ledarskapet för att skydda golvet mot för mycket disruption, mod att prova, ständigt prototypande.

Eller med andra ord: det vi brukar kalla för agil kultur. Jag vågar påstå att detta inte är det rådande ledarskapsparadigmet idag på myndigheter och offentlig sektor. De ledare som smittats av glädjen i detta sätt att leda och arbeta kämpar ofta i motvind och flera manövreras bort av organisationsproffsen som skaffat sig positioner inom det befintliga systemet. Jag har i mitt arbete på myndgheterna mött flera som farit mycket illa i den processen.

Agil kultur slår sönder småpåvedömen, och småpåvarna rustar sig alltid för krig vid agila införanden. Myndigheter bestämmer på ledningsnivå att de nu ska arbeta mer agilt, men de gör inget åt de befintliga ledarskapsstrukturerna som i dagsläget förhindrar det agila arbetet. Varje ansats som vill lyckas med digitalisering måste ta tag i ledarskapsfrågan, och om ESV vill ha mätbar digitaliseringsmognad så är det just dessa faktorer man bör sikta in sig på.

Här finns en faktor som kan avgöra om digitaliseringen av Svensk offentlighet blir lyckad eller inte. Den här frågan måste man titta på om man vill lyckas. Hur myndigheterna på ett strukturerat sätt planerar att odla det ledarskap i verksamheten som digitaliseringen kräver är en mycket viktigare framgångsfaktor än hur de har tänkt om sin IT-kompetensförsörjning!

Och därmed har jag läst färdigt ESV:s huvudrapport. Jag är glad över att så många bra tankar om nyttofokus och annat finns däri. Och rapporten ledde mig även till att köpa boken om TBM, det ramverk för att mäta nyttor och kostnader inom IT på ett strukturerat sätt som ESV vill titta närmare på. Tack för den! Det var en ny och bra bekantskap.

Detta var sista inlägget i en serie om flera. Om ni är intresserade av att höra mer om relationen digitalisering, agilitet och ledarskap kan ni bjuda in mig. Till exempel kommer jag att vara i Visby under Almedalsveckan, och delta i en del samtal om dessa frågor. Vill ni ha påhälsning där, säg bara till!

ESV:s rapport: Myndigheternas styrmodeller vs digital mognad

Huvudrapporten sid 32-33: Myndigheterna självskattar sin mognad vad gäller projektstyrningsmodeller, förvaltningsmodeller och projektportföljmodeller, till hyfsad högt. Myndigheterna har stora ambitioner att bli ännu bättre.

Mina iakttagelser är att myndigheterna visserligen har förvaltningsmodeller på plats på pappret, men att de inte följs. En förvaltningsmodell kan till exempel innehålla kontrollpunkter för att säkerställa driftsäkerhet. När resultatet från stora försenade prestigeprojekt ska driftsättas är det dock inte ovanligt att projektet inte upplevt sig ha haft tid eller råd att möta kraven från driften, och så som maktförhållandena är riggade (projekten går först) så kör man över förvaltningsmodellen.

Projektstyrningsmodellerna ställer till ganska mycket. För livscykelhantering av digitaliserade värdeströmmar är det förvaltning med av ständig nyutveckling som bör vara i centrum. I myndigheterna är det istället inte ovanligt att projekten förfogar över merparten av pengarna och förvaltningen svälts ut. Det leder till att den tekniska skulden ökar, vilket inte är hållbart för digitala värdeflöden. Förvaltningsmodellerna och projektstyrningsmodellerna är inte kompatibla.

Varje projekt måste enligt dagens modeller vara finansierat i sig själv vilket gör att nödvändigt plattformsarbete inte blir av eftersom modellerna som används inte kan hantera att den ekonomiska nyttan av digital infrastruktur uppstår i flera senare projekt och att kostnaden därför måste amorteras i dessa. Detta drabbas ESV själva av, på sid 40 känner de sig tvungna att inför läsaren av rapporten motivera varför man inte kan räkna hem till exempel en landsomfattande digital identifieringslösning i ett enda projekt. För en statsförvaltning som äger och förvaltar flera digitala värdeströmmar borde det sättet att räkna på vara en självklarhet och inte något som en utredare måste påtala.

Projektmodellerna är dessutom som jag skrivit tidigare inte anpassade för att ta vara på möjligheter löpande, utan för stora omvandlingar som löper under perioder av år och som antas kunna planeras till hög grad. De beslutas om utifrån osäkra planer, ledningen av projekten följs upp utifrån huruvida de förmår få projektet att följa planen snarare än uppnå effektmålen, och förändringar i planer och budgetar ses inte som ett tecken på att man är duktig på att kontinuerligt styra efter föränderliga omständigheter utan som ett tecken på svag styrning. Förändrade krav mäts som ett negativt KPI medan kravstabilitet ses som något gott.

Så när myndigheterna skattar sig själva som hyftsade på förvaltning, projekt och portföljstyrning menar jag att det säkert är sant utifrån hur frågan ställts, men att frågan inte på något sätt mäter mognad för digitalisering. Frågorna på den här nivån bör istället röra förmågan att snabbt omsätta nya insikter om behov till funktion i den digitala värdeströmmen, förmågan att optimera resurserna löpande, förmågan att styra plattformsutvecklingen strategiskt, taktiskt och operativ och så vidare.

Och när myndigheterna har ambitionen att förstärka sin förmåga i de befintliga projekt- och förvaltningsmodellerna (på något annat sätt kan jag inte tolka svaren) så blir jag rädd. Mer av det som idag förhindrar digitalisering är inte vad som kommer att hjälpa. Mer av samma som inte lett till så goda resultat hitills är inte vad vi behöver.

Rapporten handlar bland annat om centralisering och decentralisering i digitaliseringen. Här är en sak jag önskar att ESV ska titta närmare på centralt: hur förvaltningsmodellerna och projektmodellerna påverkar möjligheterna att livscykelhantera digitala värdeströmmar, genom vad modellerna föreskriver och inte. Inte huruvida myndigheterna använder dem. För naturligtvis svarar en lydig myndighet att de faktiskt har styrmodeller och att de avser att använda dem mer. Myndigheten ser nog det inte som sitt uppdrag att ifrågasätta nyttan av modellerna, åtminstone inte offentligt.

ESV:s rapport: om kostnader och nyttor

Läser mer i: ESV:s rapport:

Huvudrapporten sid 21-24: ESV har sammanställt it-kostnader som andel av verksamhetskostnad, it-investeringar som andel av verksamhetskostnad, inhyrd it-personal som andel av total it-personal, it-kostnader per användare, kostnad för utkontrakterad it-verksamhet som andel av it-kostnad, kostnad per it-arbetsplats, kostnad för telefoni per användare, utgifternas fördelning mellan att säkerställa, förbättra, nyutveckla, samt kostnader för lagring.

Här är jag inte ense med ESV. Det är möjligt att det finns värden jag inte ser i denna inhämtning, men jag har svårt att se hur dessa tal på något sätt kan sporra till handling när det gäller digitaliseringen. Och alla nyckeltal ska sporra till handling, annars är de meningslösa.

Till att börja med är det som jag skrivit tidigare tveksamt att kunna isolera IT-kostnader på ett vettigt sätt. Och så olika och konstigt som de myndigheter jag sett valt att skilja mellan IT-kostnader och IT-investeringar undrar jag vilken nytta den indelningen gör. Det är mängder med investeringar (permanenta och nyttiga förbättringar i IT-stödet) som bokförs som kostnad och mängder med kostnader (till exempel slöserier inom projekt) som bokförs som investeringar. På samma sätt är skillnaden mellan säkerställning, förbättring och nyutveckling extremt svår att göra när det gäller systemutveckling, och gränsdragningarna sker ofta arbiträrt beroende på humöret hos revisorerna och verksamhetens preferens och förmåga att presentera saker som det ena eller andra.

Och att särskilja telefonikostnaden från IT-arbetsplatsen? Är mobil surf en del av det ena eller det andra? Är Skype telefoni eller IT? Hur kommer de framtida AR-glasögonen att bokföras? Trams a la 1900-talet. I år är vi en sjättedel in på 2000-talet.

Jag ser framför mig att Shekarabi och andra tänkt "Vad dyrt det är med IT! Tag reda på varför!" och att detta helt enkelt är verkets försök att svara på frågan. Men både i tidigare rapporter och i denna så påtalar de svårigheten att mäta den typen av kostnad utan att ha så djup kvalitativ förståelse av vad kostnaden innebär. Man säger på sidan 22 uttryckligen att sifforna bäst kan användas inom en myndighet (inte för jämförelser) och då för att bli medveten om kostnadera och öka lärandet om den egna verksamheten. Man kan inte dra några slutsater om lämpliga åtgärder från dem. Mätvärdena kan inte sporra till handling.

Huvudrapporten sid 26-30: De strategiska IT-projekten har svag målgruppsfokus. Verktygen för att följa upp nyttohemtagningen tillräckligt bra finns inte på plats. Planeringen och budgeten för strategiska IT-projekt revideras i stor utsträckning vilket kan bero på dåliga mål, ineffektiva arbetssätt eller bristfällig styrning och ledning.

Här är ett exempel på en kluvenhet jag märkt tidigare hos ESV vad gäller definitionen av vad som kännetecknar god IT-utveckling. Så här ligger det till: JA, offentlighetens IT-projekt har svagt målgrupps- och nyttofokus. Men det beror som sagt på att man i sina metoder, metoder som inte sällan är beslutade om på hög nivå, väljer att inte följa upp på det lika starkt som man följer upp på de konkreta produktmålen, leverablerna. För du kan ju som sagt inte följa upp på både på effektmål och produktmål. Under resans gång kommer det att visa sig att de initiala ideerna om produktmål inte var så bra som man först trodde.

Och NEJ, detta behöver inte innebära problem. Projektplaner och budgetar revideras. Är det något dåligt? Det beror väl på om de revideras för att man kommer till insikt om att den inslagna vägen leder fel medan den reviderade vägen är bättre? Om man bestraffar eller på annat sätt försvårar förändring kommer man skapa en kraft som in i det längsta hindrar insikten om att det finns en mycket bättre väg att sprida sig och påverka projektet. Den blir då en fördyrande och fördummande kraft. Och med dagens sätt att följa upp projekt på så är den kraften i full gång. Idén att det finns ett egenvärde i att hålla fast vid den plan som spikades vid en tidpunkt då man visste betydligt mindre om verkligheten än idag, den idén är farlig. Den blockerar innovation. Den skapar projekt som fortsätter fast de borde ha ändrat riktning för länge sedan.

Bakom tanken att revideringar är något dåligt ligger tanken att de hade kunnat undvikas om bara folk varit duktigare på att se in i framtiden. Och medan det i teorin är sant, så begränsas vi av vår faktiska förmåga att planera. Här spökar både "hindsight bias" (att vi dömer tidigare insikter baserat på kunskap vi har idag och inte på kunskap man hade då), samt oförmågan att erkänna att komplexa verksamheter (och dit hör tjänsteutveckling) är svåra att förutse.

Rapporten skriver: "Att budget och tidsplaner revideras skulle kunna bero på dåligt uppsatta mål, ineffektiva arbetssätt eller bristfällig styrning och ledning." Är ett bra mål ett som alltid kommer att stå sig oförändrat? Är värdet av förutsägbarhet alltid högre än andra värden? Traditionen bjuder så, och i en straffande organisation (som myndigheter ofta är) finns det ett starkt tryck att inte utsätta någon i högre ställning för överraskningar. Chefen vill inte göra generaldirektören besviken och generaldirektören vill inte få skäll av ansvarig minister. Att inte kunna förutse allt associeras med att inte ha kontroll över sin verksamhet.

Det är en helt igenom tokig idé. Tjänsteutveckling har en ganska hög grad av varians, särskilt när systemutveckling är inblandat. Det kan bero på dålig ledning att den variansen blir högre än nödvändigt, men den riktigt dåliga ledningen är den som kräver noll varians i en verksamhet som har en yttre varians man inte kan göra sig av med. Agila metoder för tjänsteutveckling, som arbetar med att löpande styra på effektmål, bygger på att man kontinuerligt reviderar planer och mål. Och det är inte något ineffektivt arbetssätt som bygger på bristfällig styrning. Tvärtom är styrningen väldigt hård när alla inblandade utövar ett starkt målstyrt ledarskap, och utforskandetekniken med ständiga små förändringar som löpande utvärderas är ett väldigt effektivt sätt att hitta bra vägar för att nå effektmålen.

Så här behöver ESV fundera lite: under vilka omständigheter är det ett problem att budgetar behöver revideras? Särskilt när man dessutom citerar eGovernment Benchmark att målet för styrningen inte kan vara att kunna förutse vad som komma skall utan kunna att hantera förändringen när den väl sker. Jag anar att två motstridiga tankar finns hos ESV här: den om att hålla fast vid planer och den om att hantera förändring, och jag tänker att ESV borde landa i rekommendationen att det effektivaste är att fokusera på nyttohemtagningen och effektiva sätt att styra mot den, även om de effektiva sätten innefattar reviderade planer.

Det finns en ansats till det i att man inte uppmanar till att försöka planera bättre utan i att myndigheterna bör problematisera varför projekten blir så stora att de tar lång tid (och därmed blir känsliga för förändring). Och det är precis den ansats som de agila metoderna tar: vi styr ekonomin i osäkerhet inte genom att försöka förutse allt (eftersom det inte går) utan genom att arbeta i små korta steg där varje steg innebär ett mätbart kliv framåt.

Och som svaret på frågan om varför myndigheternas projekt blir så stora vill jag be ESV att titta på befintliga destruktiva finansieringsmodeller som kräver att varje projekt i sig ska ha ett business case och vara lönsamt. Det finns många behov av stora plattformsarbeten i myndigheternas IT-plattformar för att kunna möjliggöra många framtida smarta effektiva tjänster. Men de möjliggjorda framtida tjänsterna får de inte ta med i beräkningen. Följden blir att de inte får pengar till plattformsarbeten om de inte kan realisera flera av dessa framtida tjänster inom samma projekt. Och då blir allt stort och klumpigt.

Det finns andra sätt att arbeta på, med en arkitekturell plan och en tjänsteutvecklingsplan som löper parallellt där arkitekturarbetet hela tiden föregår tjänsteutvecklingen något. Man kan i en sådan modell särskilja investeringar från ren R&D även utan att behöva gå omvägen via stora projekt, och man kan löpande styra om vad man arbetar med för att alltid arbeta på det som är mest lönsamt. Kostnaden för IT-utveckling är nämligen ganska konstant. Det kostar en viss summa pengar att få igång ett visst antal människor att kunna arbeta inom en viss domän i en viss teknisk miljö. Dessa människor kostar en klump pengar varje månad, oavsett vad du väljer att använda dem till. Fokuset och uppföljningen bör ligga på vad de arbetar med. Arbetar de med det som är mest användbart just nu?

ESV:s rapport: Digitaliseringen av det offentliga Sverige

I dagarna släppte Ekonomistyrningsverket ytterligare rapporter från sitt uppdrag att beskriva digitaliseringen av det offentliga Sverige. Jag kommenterar:

Huvudrapporten sid 7: Man behöver ha kontroll på kostnaderna för att väga kostnad mot nytta. Man behöver ha processer och modeller på plats för att styra och leda arbetet. Endast ett fåtal följer upp sina utvecklingsinitiativ, och väldigt sällan utifrån nyttohemtagning.

Jag håller helt med! Men jag vill göra ett par anmärkningar jag tycker är viktiga. För det första: man ska inte försöka behandla kostnader för digitalisering som IT-kostnader. För som jag skrivit tidigare: Vad är en IT-kostnad? De digitala verktygen möjliggör nya sätt att bedriva verksamheten på. Det handlar alltså om att personer med verksamhetskunskap och personer med IT-kunskap samarbetar tätt för att se hur de kan stöpa om värdeflödena för de personer som vill nyttja ens tjänster.

Det går inte att isolera på samma sätt som förr i tiden. Då tittade man på ett besvärligt verksamhetssteg som skulle kunna förbättras med hjälp av IT-stöd, och man uppdrog till en separat IT-enhet att ta fram detta stöd. Verksamheten var i grunden likadan fast flera av de manuella stegen, som att skicka ut blanketter och läsa in blanketter, kunde automatiseras. Nu är vi i ett läge där vi ska fråga oss om blanketter alls är relevant, handlar det inte i grunden om att få in validerad information från olika källor i rättan tid, oavsett om det sker via blanketter eller på annat sätt? Flödena måste definieras om helt utifrån dagens informationsekosystem.

Processer och modeller finns på plats. Men de är definierade utifrån det äldre behovet vilket ger oss fokus på stora projekt istället för på löpande förfining och en beställare-utförarmodell som i onödan separerar verksamhet och IT. Projekt som styrmodell för utveckling av digitala tjänster är visserligen bättre än ingen styrmodell alls, men med sina fokus på förplanering (ofta i detalj) utifrån ogrundade antaganden samt tröghet till att omdefiniera projektmålen när man får nya insikter, så lämpar sig projektmodellerna inte jättebra när det gäller den typen av ständig utforskning som byggandet av digitala värdeströmmar innebär.

Projektmodellerna styr IT-projekten mot på förhand fastslagna produktmål, och följer även upp på huruvida de ursprungliga produktmålen nåddes. Moderna agila styrmodeller styr istället utvecklingen mot effektmålen, nyttorna, och justerar produktmålen i takt med att man får nya insikter om hur effektmålen bättre kan uppnås. Så länge som de offentliga aktörerna styr och följer upp på fastslagna produktmål och inte löpande följer upp mot nyttor, så får vi inte det nyttofokus som Ekonomistyrningsverket vill se.

Jag tänker särskilt på ett stort projekt där förstudie och uppföljning bedrevs med gammal projektmetod, medan genomförandet bedrevs agilt. Väldigt snart i genomförandet såg projektet hur flera av de ursprungliga antagandena i förstudien var felaktiga, men man kunde snabbt arbeta om kraven så att de nyttor som projektet motiverades med bättre kunde realiseras. Vid revisionen senare fick projektet dock kritik eftersom man arbetat om kraven så många gånger under resans gång. Uppföljningen mätte kravstabilitet, såg förändringar och anpassningar till verkligheten som något negativt, och ignorerade nyttohemtagningen.

Den typen av mekanismer är rotorsaken till mycket utebliven nyttohemtagning i det offentliga. När Ekonomistyrningsverket (ESV) skriver "Det är också viktigt att man har processer och modeller på plats för att leda och styra arbetet" vill jag lägga till "...löpande mot nyttohemtagning". På sidan 9 i huvudrapporten skriver ESV: "ESV anser att frågan om ett bredare införande av nyttorealisering är central för att öka takten i digitaliseringen." Jag håller med, och säger: se till att den offentliga sektorn använder de metoder som redan idag finns, metoder som faktiskt styr på nytta.

Huvudrapporten sid 9-10: Med "digitalisering" menar ESV både att information blir digital, att nya verktyg därigenom kan användas för att effektivisera samhällstjänster samt möjliggöra nya, och att detta troligen kommer att transformera samhället i grunden. Med "effektivisera" menar ESV både att öka "inre effektivitet" (att processerna i de befintliga verksamheterna blir effektivare) och "yttre effektivitet" (att nyttan för den enskilde medborgaren ökar).

Jag tycker att det är bra att man lanserar begreppet "yttre effektivitet" för att få folk att tänka på något större än att bara snabba upp befintliga verksamheter eller att göra dem billigare. På engelska brukar man skilja mellan "efficiency", att saker går snabbt och utan spill, och "effectiveness", att saker är verksamma och precis vad vi behöver. När vi arbetar med tjänsteutveckling brukar vi använda workshoptekniker som understryker att värdet först och främst ligger i att tjänsten har hög "effectiveness". Är tjänsten halvkass blir ingen glad av att vi utför den billigare idag än igår, om vi istället kunde gjort den mer i linje med vad folk faktiskt behövde. Att leverera det som inte behövs, att missa målet litegrann, är spill och slöseri. "Effectiveness" är ett centralt begrepp för att kunna styra på nytta. Det känns som om ESV vill använda "yttre effektivitet" på samma sätt.

Huvudrapporten sid 12: I EU:s handlingsplan för e-förvaltning 2016-2020 finns bland annat några principer för bra digitala tjänster: de är byggda för interoperabilitet (och därmed gränslöshet) och de ska vara säkra och tillgängliga.

Det här rör något som vi inom systemutvecklingen har propagerat för länge, och som nu äntligen börjar tas hänsyn till även utanför IT-avdelningarna. Ett självklart sätt att dela upp ett system på är mellan ett bakomliggande system (som tar hand om att lagra och bearbeta datat) och dess gränssnitt (som möjliggör in- och utmatningen av samma data). Ett gränssnitt kan vara avsett för andra system, eller så kan det vara avsett för människor. Det går (med mycket möda) att få ett annat system att använda ett gränssnitt avsett för människor. Det är däremot mycket enkelt att få ett gränsnitt avsett för människor att använda ett gränssnitt avsett för andra system (så länge de utgår från ungefär samma mentala modeller av saker och ting). Om du läser den här texten på webben är det precis så det går till: din webbläsare eller app är byggd för att visa texten (utifrån en mental modell av att texten har en rubrik, stycken, meningar och ord) på ett mänskligt sätt, men den pratar med själva systemet på betydligt mer standardiserat maskinellt sätt (exakt vilken text identifieras av en precis adress, rubriker och stycken och bokstäver har speciella sifferkoder).

Flera av dessa hopplösa system som den offentliga sektorn idag har köpt på sig och tvingar sina anställda att använda fungerar inte så: där är det bakomliggande systemet och dess gränssnitt sammanvävda. Det är som om du hade varit tvungen att installera en särskild webbläsare för just mina texter, och en annan webbläsare för andra människors texter, och så vidare. Om ett system, till exempel ett journalsystem eller ett bibliotekssystem, istället tar på sig ansvaret att hantera och bearbeta datat på ett säkert sätt, med ett gränssnitt avsett för andra system, så kan man ha olika gränsnitt för olika människor lagda ovanpå. Det är mycket enklare och billigare att genomföra förändringar på gränssnittsnivå när större delen av komplexiteten göms under ett maskingränsnsitt, och vi kan få till snabbare uppdatering av gränssnitten och samverkan mellan system utan att hela systemet behöver uppgraderas.

Alla problem är därmed inte lösta. Vi behöver fortfarande tänka till runt hur vi identifierar oss när vi använder de olika systemen, men att få inköpare och leverantörer att förstå vinsterna med att kräva maskingränssnitt (även kallat "API:er") på allt är centralt för att få till sömlösa digitala värdeströmmar.

Det här var första inlägget i en serie om flera.

ESV:s rapport: Varför går digitaliseringen så trögt?

Jag fortsätter lusläsa ESV:s rapporter:

Huvudrapporten sid 13: Som skäl för digitaliseringens tröghet i Sverige anförs de befintliga finansieringsmodellerna, styrmodellerna, avsaknad av standarder, legala hinder, ledarskap och kompetens, samt kultur och arbetssätt.

När det gäller styrmodellerna och finansieringsmodellerna (dessa är sammanvävda) så tror jag att de är viktigare än vad ESV säger i rapporten. ESV har rätt i att det går att göra mer inom de befintliga ramarna, men det är att arbeta i motvind. Budget- och styrprocesser är som jag skrev ovan uppbyggda för projektarbete mot precisa produktmål. Och detta är i linje med det befintliga ledarskapet, kulturen och arbetssätten. Myndigheter är vad jag har sett generellt dåliga på ledarskap som mynnar ut i kundfokus och innovation. Och det är inte en enskild faktor som är orsaken, utan ett myller.

Cheferna är ofta tillsatta för att bevara processerna sådana de är, de belönas för sin förmåga att få folk att agera förutsägbart och för sin förmåga att optimera sin lilla del av verksamheten, och de har ofta ett inre fokus på den egna ställningen i processen och hierarkin. Och detta är förstås en systemeffekt av den övergripande synen på organisation och förvaltning som inte sällan består av myter: toppstyrning ger god kontroll över utfallet, optimera alla delar så blir helheten optimerad, den som ser bra ut i en högre chefs ögon är därmed en bra chef, och så vidare.

Kontrastera det mot den ledarskapskultur som krävs för att utveckla bra tjänster, den kultur som krävs för att få lean, agilt och design thinking att fungera: delegera mandat, i synnerhet mandatet att utforska olika sätt att göra saker och ting på, ha ett kundfokus, titta på din plats i de värdeströmmar du ingår i och arbeta förtroendefullt tillsammans med närliggande delar för att ge kunden en så bra upplevelse som möjligt, mät helheter (inte nedbrutna KPI:er) och arbeta med rotorsaksanalys för att få reda på vilka faktorer som faktiskt påverkar utfallet, arbeta metodiskt tillsammans med andra för att påverka de faktorerna till det bättre, synliggör allt, ju "högre" chef desto mer stöttande måste du vara, möt varandra med psykologisk insikt i avsikt att bygga upp och stärka och så vidare och så vidare.

Rapporten pekar på Statskontorets rapport "Utvecklad styrning - om sammanhållning och tillit i förvaltningen" och i både den och i det arbete som bedrivs i Tillitsdelegationen berörs dessa kulturella hinder. Man kan även se till de internationella studier som genomförs där man ser hur toppstyrning och inre organisationsfokus minskar graden av innovation. Där finns en rotorsak till att vi inte har kommit längre, och varför varje digitaliseringssatsning inom det offentliga slukar så mycket resurser utan att leverera ett fullgott resultat.

Huvudrapporten sid 16-20: Mätt med EU:s eGovernment Benchmark är Sverige i kategorin "hyfsade" men vi borde höja oss till att vara åtminstone i kategorin "bra".

Det är inte mycket att säga om resultatet eller slutsatsen. Våra myndigheter har hög tillgänglighet på nätet men är bara halvanvändbara. I mina ögon säger det mig två saker: myndigheterna finns på nätet eftersom medborgarna finns på nätet. Självklart kommer inte ett land där färre personer är uppkopplade att satsa på nätnärvaro. Men huruvida vi är bra på nätet bestäms av något annat: hur vi väljer att arbeta med användbarhet och att ta fram digitala tjänster och gränssnitt som ger nätnärvaron mening. Det är våra låga poäng vad gäller användbarhet som är det intressanta, inte våra höga poäng på nätnärvaro.

Dessa mätvärden är släpande mått (sådant du ser i efterhand, när det redan är försent) som visar på underliggande strukturella brister. Användbarhet bestäms istället av förmågan att arbeta utforskande med ständig tjänsteförfining. De satsningar inom myndighetsvärlden som särskilt vunnit pris för sin användbarhet eller nominerats till tävlingar för att de är särskilt bra på användbarhet, till exempel Försäkringskassans digitala kanaler och Polisens Polismobilititet (effektiva appar för poliser på fältet), arbetar på precis det sättet: utforskande med ständig tjänsteförfining. De satsningar inom myndighetsvärlden som snarare massivt försvårat för användarna samt kostat en enormt massa pengar till liten nytta: Polisens PUST Siebel, Försvarets PRIO (åtminstone i de första vändorna) m fl, har istället byggt på stora projekt, långa ledtider, försök att spara pengar som lätt till fördyrande dålig användarnytta, teknik som blivit omodern redan innan resultatet av projektet kunnat visas upp och så vidare.

Men det är inte huruvida resultatet (t ex PUST Siebel vs Polismobilitet) blev bra eller ej som är intressant! Det intressanta är frågan: vilket av angreppssätten kommer att fungera snabbast och bäst den dag det plötsligt dyker upp en ny teknik som möjliggör ett nytt sätt för folk att interagera med eller inom myndigheten på?

På bara några år blev en uppkopplad mobiltelefon med appar normen för hur vi använder digitala tjänster. Tänk om det plötsligt kommer bra integrerade och uppkopplade AR-glasögon som var och varannan människa bär! Vilken organisation kommer snabbast att kunna integrera det i sin tjänsteleverans och därmed öka effektiviteten (inre och yttre)? Projektet bakom PUST Siebel eller gruppen som utvecklar Polismobilitet? Försäkringskassans experter på avdelningen för digitala kanaler eller något av (de försenade) mastodontprojekten på FK som syftade till att öka den inre effektiviteten avseende blanketthanteringen?

Förmågan att kunna leverera fungerande mjukvara, dvs digitala tjänster som är verksamma och nyttiga och skänker glädje i folks vardag, är som det agila manifestet påminner om framförallt beroende av de inblandade individernas, inklusive kundens, samspel med varandra samt av förmågan att kontinuerligt hantera de nya insikter som kommer ur det samspelet. Rapporten påminner om att det inte alls är säkert att morgondagens styre och förvaltning liknar dagens, särskilt inte i ljuset av tekniska landvinningar, och citerar därför eGovernment Benchmark (min emfas):

No one can actually predict what government could look like in ten years. The only thing that is certain is that it will be very different from how it looks now. Technology is changing the game quickly and will continue to do so. The biggest challenge is therefore not so much in anticipating what comes next, but ensuring governments are able to deal with change.

Eller som agila manifestet uttrycker det: förmågan att hantera förändring är viktigare än förmågan att följa en plan.

Gå till golvet och se!

När folk kom till Taichi Ohno (legendarisk fabrikschef och sedermera chefsingenjör på Toyota) med dokument fulla med siffror om hur det stod till i fabriken så tittade han otåligt lite grann på första sidan men slängde sedan undan pappren, reste sig, och sa: "Låt oss gå och se efter själva!".

Taichi Ohno var kolerisk, intensiv, kedjerökande, lynnig i humöret, och väldigt intelligent. Man ska inte försöka sig på att diagnosticera historiska personer, särskilt inte som amatör, men hans personlighet (och hans egna beskrivningar av uppväxten och erfarenheterna av skolan) pekar på bekymmer att i lugn och ro rikta uppmärksamheten på siffror och dokument. Däremot verkar han ha haft en fenomenal förmåga att ta in alla intryck på en gång från en bullrig och rörig fabriksmiljö och se hur saker och ting rörde sig. Och inte rörde sig.

Det Taichi Ohno genom egen erfarenhet visste var att siffrorna i rapporten hade en begränsad förmåga att beskriva verkligheten. Siffror pratar om vissa utfall (som man bemödat sig om att kvantifiera och mäta) men väldigt lite om hur utfallen uppkommer. De ledande indikatorerna, själva anledningarna till att produktionen eller kvaliteten eller de andra siffrorna blev si eller så, de kanske lös med sin frånvaro. De kanske inte ens var identifierade så att de kunde mätas.

Den något lugnare men inte mindre intelligenta William Deming förstod detta i högsta grad. "The most important things cannot be measured" sa han. Det han menade var att de kvalitativa förutsättningarna påverkar utfallen på ett såpass oförutsägbart sätt att de inte kan räknas på. Hur mäter man effekten av att folk på olika avdelningar inom en organisation har ett stort förtroende för varandra? Hur mäter man effekten av att de lunchar ihop och trivs i varandras sällskap? Hur mäter man trivseln och hur mäter man på vilket sätt trivseln bidrar till att den organisationen presterar tio gånger så högt värde som dess konkurrent?

Taichi Ohno var motståndare till att styra verksamheter på numeriska data utan att ha markkontakt och förstå vad som hände på golvet, vad som var viktigt för värdeskapandet. Hans idéer ledde till att Toyota blev en av de mest framgångsrika industriföretagen någonsin. William Deming förstod att det viktigaste inte gick att mäta (vilket ledde till att han kraftigt satte sig emot Druckers idéer om "Management by objectives", grundplåtar i NPM). Hans ideer lade grunden till Total Quality Management och Six Sigma.

Det är precis här det blir tokigt med NPM. Tanken är att ett kvalitativt mål ("Gymnasieskolan ska bli jättebra!") kan och ska brytas ner till kvantitativa preciserade mål ("Svensklärarna ska öka mängden undervisning i kasusanalys med 15%!"). Detta utan att vara säker på om det är just detta som möter elevernas behov av undervisning bäst.

Eller när en polischef ser att hens poliser verkligen behövs i ett område där kriminaliteten blossat upp, men tvingas skicka sin personal på att göra nykterhetskontroller på vägarna eftersom det mätbara målet var satt till att utföra ett visst antal "blås" per månad. Detta är en sann historia: patrullerna löste chefens problem genom att ställa sig vid parkeringsplatsen på ett stort varuhus en söndag eftermiddag där alla var garanterat nyktra, genomförde de reglementsenligt avtalade antalet kontroller, och så var de fria att ägna sig åt mer akut brottsbekämpning igen.

Cheferna högre upp i organisationen är varken dumma eller elaka. Hade någon av dem varit närvarande i klassrummet eller i polisbilen hade de sett hur de kvantitativa målen de satt var en alldeles för tidigt etablerad hypotes om bra lärar- eller polisarbete. De hade säkert inte misstyckt om läraren och polisen justerade prioriteringarna något utifrån vad verkligheten krävde av dem. Det är när systemet tvingar chefer att tappa markkontakten, att inte vara närvarande på golvet, när förhindras att leda utifrån den förståelse man får av att gå och se efter själv utan istället tvingas att styra på siffror på ett papper, det är då systemet börjar bli djupt dysfunktionellt.

Dysfunktionellt på det sätt som New Public Management har gjort det till.

Varians och NPM

Det här inlägget är en reflektion och kommentar till det här inlägget från Tankesmedjan Balans om varför NPM inte fungerar. Jag är som bekant väldigt negativ till New Public Management, både så som tankefiguren kommit att bedrivas, men också mot tankefiguren som sådan. Min ingång är alltså i stort densamma som Tankesmedjan Balans: NPM är en destruktiv styrmodell. Däremot är det vissa saker i inlägget jag inte håller med om, och vissa saker jag känner behöver förtydligas.

Först: skälet till att man prövade NPM var att det befintliga alternativet, budgetfinansiering med svag uppföljning, inte fungerade. Kvaliteten på de offentliga tjänsterna var lägre än de hade kunnat vara, vilket inte minst blir tydligt av alla lyckade exempel av kvalitetsökning när man så småningom släppte in fler utförare. Utan drivkraft att kontinuerligt förbättra strukturerna kommer man att få en alltmer dysfunktionell verksamhet, och konkurrensutsättning är bevisligen en sådan drivkraft.

Det är dock inte den enda tänkbara drivkraften, och framförallt räcker det inte med en drivkraft för att faktiskt förbättra något. Man måste även ha en verksam metod, och den metoden skiljer sig något åt beroende på vilken verksamhet det rör sig om. Konkurrensutsättning kan ge dig viljan att bygga något bra, men du måste förutom vilja även ha tillgång till bra verktyg och förmågan att använda dem. Så min ingång är att utförarmonopol ofta är destruktiva, att vi inte ska gå tillbaka till en blind anslagsfinanisering av offentlig verksamhet, men även att NPM inte är rätt verktyg.

Det andra jag vill påminna om att NPM inte handlar om att styra offentlig sektor som det privata näringslivet styrs, även om det lånat vissa verktyg som används inom vissa delar av näringslivet. Jag vill även påminna om att styrverktygen som används inom NPM inte alltid varit så framgångsrika inom näringslivet heller.

I teorin handlar NPM om målstyrning på mätbara utfallsmått ("management by objectives"), och det är också dess största brist. Alla problem med management by objectives ("MBO"), alla olönsamma beteenden som MBO driver, återfinns i NPM. Och teorin är mycket fin. Den handlar om att ingen ska detaljreglera hur du beter dig så länge du löser din uppgift, och uppgiften är vagt definierad vad gäller hur du ska utföra den men mycket precist formulerad vad gäller de mätbara och numeriska mål du ska uppnå.

Peter Drucker som på 50-talet formulerade MBO, han var vän av delegering och verksamheter som inte behöver detaljregleras. Utförarna av en verksamhet ska ha frihet att utifrån sin professionalitet bestämma hur, medan beställarna ska vara duktiga på att formulera vad de vill ha och hur mycket. Om bara beställarna vet precis vad de vill ha och utförarna precis vad de kan leverera och till vilket pris så fungerar modellen utmärkt.

Men redan här finns minst två problem inbyggda. Hur professionell jag än är kommer jag i många verksamheter ha svårt att på förhand slå fast hur jag ska bära mig åt, vilken kapacitet jag kommer att ha, och hur mycket kalaset kommer att kosta. Det finns helt enkelt såpass mycket yttre varians (variationer jag inte har kontroll över) att verksamheten blir en chanstagning. Om jag ska komma med mitt erbjudande tidigt i en process, till exempel i ett bindande anbudsförfarande, tvingas jag att göra en massa omöjliga övervägningar och hoppas att jag genom prispåslag som täcker upp risken ändå kan få kostnadstäckning för vad jag levererar.

Det andra problemet är exakt detsamma fast på beställarsidan: hur professionell jag än är kommer jag i många verksamheter ha svårt att på förhand slå fast exakt vad jag vill ha och hur mycket. Jag kan sällan på förhand förutse de systemiska konskekvenserna av min beställning och av mitt sätt att beräkna ersättningen till utförarna.

Det handlar inte om oduglighet hos beställare och utförare, utan om att den teoretiskt möjliga planerbarheten för olika slags verksamheter varierar. Det har inte heller något med privat/offentligt att göra, eller med att det offentliga ofta har med människoomsorg att göra, utan mellan skillanden mellan masstillverkning och tjänsteleverans.

Nyckelordet är varians. Det finns yttre varians (varians jag inte kan påverka), och inre varians (varians jag kan påverka). När variansen är låg ökar min förmåga att förutse både kvalitet, tid, mängd och kostnad. Inom tillverkningsindustrin ser man till att variansen framförallt beror på inre faktorer, och man arbetar hårt med att få den så låg som möjligt. Den varians som trots allt finns jämnar man ut genom att man tillverkar många identiska föremål, så om man råkar leverera en defekt sak kan man kompensera med pengarna tillbaks eller ett nytt exemplar. Kvalitet i tillverkningsindustrin handlar om att reducera variansen.

När det gäller tjänsteleverans handlar det istället om att hantera variansen. Folk har varierande krav, och värdet i en tjänst handlar om att tillmötesgå lagom många av dessa. Vad lagom många krav är, och vilka, och vem som får lov att värdera kvaliteten, det är oerhört svårt att precisera. Här finns alltså en massa varians vi behöver hantera på ett bra sätt, och vad som är ett bra sätt och hur mycket det kommer att kosta är inte lätt att förutse.

När det gäller tjänster där en privatmarknad redan existerar, där folk för egna pengar köper tjänsterna och gör dessa små subjektiva bedömningar av vad lagom bra kvalitet är, där finns det en standard att utgå från. Det är till exempel mycket lättare att definiera vad som är tillräckligt bra och prisvärda städ- och hantverkstjänster, eller matleverans och transporter. Man jämför med vad folk köper för sina egna pengar på den privata marknaden och så får man en uppfattning om vad som är rimlig användning av skattemedel. Varken utförare eller beställare blir missnöjda eller skinnade på pengar.

Men även här kan det bli svårt att bestämma precis vad man vill ha. Vad är en rimlig nivå på städningen i en skola? Och framförallt: vad är den minsta godtagbara nivån? Kan vi få ett specialpris? Både beställare och utförare pressar sina marginaler, och risken är stor att alla inblandade parter blir missnöjda. Observera att detta problem inte beror på offentligt eller privat eller mötet dem emellan, utan på behovet att på förhand bestämma både kostnad och kvalitet. För det är det man bestämmer på förhand man sedan följer upp på. Och alternativet är inte att strunta i kvalitet, pris och uppföljning.

I teorin är detta mycket enkelt. Om man bara kan hitta rätt mätetal är inte management by objectives så svårt. Problemet är att det inte alls är en trivial uppgift, i synnerhet inte i ljuset av varians. Att hitta "rätt" mätetal och förutse vad som är lagom och hur mycket det kommer att kosta, det kan bokstavligen talat vara omöjligt. Och det blev inte plötsligt omöjligt bara för att verksamheterna konkurrensutsätts. Det är precis lika omöjligt även i en anslagsfinaniserad monopolsituation.

Att förutse saker som pris och kvalitet är alltså svårt eller omöjligt i närvaro av hög yttre varians, och kännetecknande för verksamheter där NPM fungerar dåligt är just hög yttre varians. Fler problem finns, och en annan styrmodell krävs som jag skrev häromdagen, men det får jag vidareutveckla i senare inlägg.

Tillitsbaserad styrning

Det är enkelt att vara sur på "New Public Management" eftersom denna modell för styrning av offentlig sektor bygger på att man försöker styra på utfallsmått utan att ha koll på yttre varians och andra saker som påverkar utfallet. Därför driver den styrmodellen fel beteenden, som alltid när det handlar om en variant av Management by Objectives. Vilket nog de flesta som arbetat inom offentlig sektor kan vittna om.

Men vad ska vi ha istället?

Sedan femtiotalet har William Deming och Toyota lanserat ett alternativ till både taylorismens toppstyrning och Druckers målstyrning och balanserade styrkort. Det bygger på att man tydliggör förväntningarna på varandras beteende utan att snöa in på just specifika numeriska målresultat, och på att man ständigt vidareutvecklar samarbetet kvalitativt. Har transparens mellan varandra och arbetar med ständig förbättring.

Nu har denna insikt nått även regeringen. Jag är inte den nuvarande regeringens (2017) bästa vän, men här tycker jag de har fått till det bra. De har nämligen bestämt sig för att utforska alternativ till NPM/MBO och kallar alternativen för tillitsbaserad styrning.

Vad är det? Styrning baserad på att jag helt enkelt litar på att du gör din grej? Som ger dig fria tyglar? Som inte är någon styrning alls utan bara låt-gå-mentalitet?

Nä. Det handlar visserligen på att jag litar på att du gör din grej, fast på grund av att vissa kontrollmekansimer är på plats.

Först att du och jag tydligt har definierat vad som faktiskt är grejen vi ska uppnå. Vilket är målet? Och då menar jag kvalitativt.

Sedan att det finns vissa gränser vi lovar att inte korsa. Vi preciserar inte målet i exakta termer, för i en verksamhet som innehåller varians kan man inte precisera vad utfallet ska komma att bli så tydligt och exakt. Men vi kan komma överens om vilka utfall som är off-limits. Vilka utfall som vi absolut bör titta närmare på tillsammans.

Detta kallar förvaltningsforskaren Cajsa Niemann för Villkorat förtroende i sin doktorsavhandling. Man är trygg med varandra inom vissa väldefinierade ramar. Och det är en av ledtrådarna i hur regeringen tänker sig att man kanske kan styra hela statsapparaten.

För oss som pysslat med lean och agila metoder är detta inget nytt. Tokigheterna med MBO har varit kända sedan 50-talet, och att ett agilt angreppssätt dramatiskt ökar förmågan att träffa rätt, förmågan att nå effektmålen, är inte heller något nytt. Inte heller att de agila arbetssätten bygger på tillit, och att tilliten vilar bland annat på att våra policies är explicita.

Tilliten som psykologisk mekanism ÄR alltid villkorad. Den uppstår inte av sig själv utan kräver att vissa rädslor hos folk är omintetgjorda. Knepet är att synliggöra dessa villkor, göra dem glasklara, och vidareutveckla dem tillsammans under resans gång. Jag vet att detta är ett väldigt fruktbart sätt att styra på, för jag har själv varit med om att införa det. Jag tror att det kan revolutionera statsförvaltningen och offentlig sektor. Till det bättre.

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.

Teknik: tvärfunktionellt arbetslag

En agil teknik är det tvärfunktionella arbetslaget. Vilket problem vill man lösa genom att ha tvärfunktionella arbetslag?

Att ett arbetslag är tvärfunktionellt innebär att det innehåller en blandning av kompetenser som krävs för att skapa ett visst värde. Motsatsen, ett enfunktionellt arbetslag, består av specialister på en del av arbetet. Som till exempel vid vissa systemutvecklingsmetoder: en grupp lösningsarkitekter som utifrån en beskrivning av verksamhetslogiken och informationsmodellen skapar en övergripande teknisk lösningsskiss som de skickar vidare till de som arbetar mer kodnära.

De enfunktionella arbetslagen uppstod ur en idé om specialisering och enkelriktade arbetsflöden: inom tillverkningsindustrin är det rationellt med specialiserade arbetsstationer och så låter man arbetspaketet flöda genom systemet från den ena stationen till den andra. Problemet var att utvecklingsarbete handlar om att tillsammans förfina information om både problem och möjliga lösningar. Att generera beskrivningar av verksamhetslogik, av lösningsarkitekturer, och av kod är bara utflödet av denna informationsförfining.

Enkelriktade flöden mellan specialiserade grupper är bara ekonomiskt effektiva om transaktionskostnaden mellan grupperna är låg och inget värdeutbyte sker mellan grupperna. I utvecklingsarbete är det värdeskapande med ett kontinuerligt utbyte (inte ett enkelriktat flöde) mellan olika kompetenser så att man kan skapa en gemensam bild (inte olika sorters dokument som ägs av helt olika personer). Utvecklingsarbete måste därför optimera informationsutbytet och kunskapsförfiningen.

Detta kan göras om personer med olika kompetenser arbetar tillsammans i ett litet samkört arbetslag med att förfina och till slut kodifiera samma kunskapsmängd och på så sätt skapa en gemensam leverabel. Ett tvärfunktionellt arbetslag.

I grunden är det ett leanverktyg från tillverkningsindustrin: gruppera människorna runt samma arbetspaket så att de kan blir experter på att samarbeta om att skapa en leverabel så fort de får en förfrågan. I lean kallas det en "cell", till skillnad från en station vid ett löpande band.

Om du nu inte har tvärfunktionella arbetslag, hur anpassar du metoden då? Du behöver titta på det bakomliggande syftet med det tvärfunktionella arbetslaget, nämligen kommunikation och kunskapsförfining, och se hur man kan åstadkomma detta även när nyckelkompetenser befinner sig på olika platser i organisationen. Kan de dela möten med varandra? Kan deras respektive grupper samplanera? Kan de olika enfunktionella grupperna arbeta runt samma flödestavla där de har arbetspaketens hela flöde i centrum, och inte bara den egna lilla delen av processen?

Det är nyckeln i all anpassning av agila metoder när du inte kan anpassa dig till att använda en viss teknik: se till teknikens bakomliggande syfte och försök uppfinna en egen teknik som uppfyller syftet. Pröva lite olika varianter, mät för att se vilka tekniker som innebär bäst förbättring hos er, och besluta er runt dem.

Vad ni inte ska göra är att behålla arbetssätten oförändrade jämfört med så som de beskrivs i de agila ramverken, när förutsättningarna hos er faktiskt inte är uppfyllda. Har ni inte tvärfunktionella arbetslag ska ni inte låta era enfunktionella arbetslag imitera hur de tvärfunktionella brukar arbeta. Ni kommer inte att få några bra resultat då. Det blir bara en rituell imitation av agila arbetssätt och ingenting som kommer att leda till större agilitet.

Vad vill metoden lösa?

När man inför agila metoder i olika samarbeten dyker man alltid på spänningsfältet mellan de som vill följa metoderna till punkt och pricka och de som vill anpassa dem. Och bland dem som vill slaviskt följa efter finns det de som vill följa av rätt anledningar och de som vill göra det av fel anledningar. Precis som hos de anpassliga: vissa vill anpassa utifrån ett verkligt behov av anpassning, medan andra vill anpassa för att undvika någon av de förändringar som metoden kan komma med.

Så hur vet man hur man ska förhålla sig till anpassningar av agila metoder då? Hur vet vi om vi ska följa slaviskt eller om vi ska ändra i metoden? Genom att man förstår hur metoderna fungerar.

Metoderna är påsar med tekniker i. Även om det står olika namn på påsarna innehåller de påfallande ofta samma tekniker, och det är teknikerna som påverkar samarbetet till att bli mer agilt om man tillämpar teknikerna rätt.

Varje teknik finns där för att lösa ett specifikt problem. Folk har erfarit strukturella hinder mot större agilitet, och så har de experimenterat fram en teknik som hjälpt deras samarbete att ta sig över det specifika hindret. Metoderna är inte magiska och teknikerna är inga ritualer som fungerar oavsett förutsättningarna. Om du inte har den situation som tekniken är tänkt att hantera, så ska du inte använda dig av just den tekniken.

Så står ni med en frågeställning rörande ett visst arbetssätt så börja med att undersöka om ni verkligen förstått hur det nuvarande arbetssättet påverkar den aktuella situationen, och vilka alternativa arbetssätt som skulle kunna påverka på ett annat vis. Sedan bör ni experimentera med arbetssätten för att validera de här hypoteserna, utvärdera på empirisk grund, och bestämma er för förhållningssätt därefter.

Det viktiga med införandet av agila metoder är att ni hela tiden är öppna för det här prövande förhållningssättet. Det kräver att ni aldrig standardiserar runt en viss metod eller teknik utan optimerar organisationen för förändring. Agilitet är ett lärande.

Kravkurs GBG den 30 mars!

Jag håller, tillsammans med Informator, en kurs i agil kravhantering i Göteborg den 30 mars 2016.

I kursen provar vi på olika tekniker hämtade från det verksamhetsfält som kallas för Lean UX: Personas och Impact Mapping / effektkartläggning, samt typiska agila kravtekniker som CCC-kompletta User Stories och Story Mapping.

Det hela synkas ihop med backloggarbete i en tredelad backlogg som är kompatibel både med SAFe (portfölj-, program-, och teambackloggarna) och med vår kurs i agilt produktägarskap.

Är du beställare, kravfångare, eller produktägare i en agil organisation så kommer du att ha nytta av den här kursen!

Oförutsägbara framtid

Den amerikanska ekonomiprofessorn Don Reinertsen har helt rätt i att produktledningsbeslut, till exempel om en systemförändring i en IT-tjänst eller IT-produkt, måste följa ett ekonomiskt ramverk. Hans förslag är att man kvantifierar väntekostnaden, vad det kostar att inte ha något på plats, för de olika alternativen och prioriterar utifrån det. Det blir då ganska uppenbart att man för systemförändringar som är ungefär likvärdiga ska man prioritera den förändring som man snabbast får ut i produktion så att det kan börja hämta hem värde. "Prioritize the Weighted Shortest Job First (WSJF)".

Man kan ganska enkelt göra spel och simuleringar som visar nyttan av detta.

Men man får samtidigt inte glömma bort att värdet av en systemförändring framförallt är kvalitativ. En IT-tjänst ingår i flera värdeströmmar. Varje förändring i tjänsten förändrar samtidigt flödet på ibland oförutsägbara sätt. Ny utformning av verktygen kommer att påverka hur själva arbetet går till. Ny utformning av tidsfördriven förändrar hur vi fördriver vår tid. Kanske till och med förändrar IT-tjänsternas utformning hur vi definierar både arbete och fritid.

Eftersom effekterna på hela flödena är oförutsägbara kan man ofta inte kvantifiera någon väntekostnad. Men hur ska vi då veta om vi ska försöka oss på den snabbaste förändringen först? Om vi inte vet om förändringarna är likvärdiga?

Svaret är att vi ska bli ännu mer angelägna om att prioritera utifrån snabbhet. Med snabb förändring får man snabbt svar på vad förändringen innebär i en komplex och oförutsägbar verklighet. En snabb förändring är en billig förändring så även förändringar som visade sig vara dåliga bör vara snabba att få ut i produktion.

I komplexa och adaptiva system, vilket nästan alla värdeströmmar är (om man tar hänsyn till människors beteende vilket man måste), är det förmågan att få snabb återkoppling på en prövande rörelse som är den avgörande, inte förmågan att förutse. Det ekonomiska ramverket vi beslutar utifrån måste därför vara inriktat på att minska risk och omfattning, och på att snabbt mäta utfall av olika förändringar. Inte vara inriktat på förutsägbarhet om förutsägbarhet ändå inte finns.

Don Reinertsen tar upp även denna aspekt i sin bok om produktutvecklingsekonomi, Flow och Eric Ries bygger hela tankegången i Lean Startup på principen om prövande förändring till låg risk och snabb återkoppling. Tyvärr har inte Dean Leffingwell i SAFe betonat värdet av utforskning tillräckligt hårt, utan lyfter framförallt principen om Weighted Shortest Job First, en princip som bygger på att man faktiskt kan vikta värdet av förändringarna på förhand (och korrekt estimera deras längd/kostnad). Man riskerar att gå miste om potentiellt väldigt höga värden bara för att man inte vågar utforska det okända.

Återigen alltså en risk med SAFe när det tillämpas utan en ifrågasättande självständig tanke. Det är alldeles för frestande för många, gärna i stora organisationer, att försöka optmimera för förutsägbarhet. Det logiska felslutet att påstådd förutsägbarhet är verklig förutsägbarhet, eller att förutsägbarhet alltid innebär låg risk, eller att låg risk alltid innebär god ekonomi, ligger nära oss, i synnerhet i organisationer som har lätt för att straffa.

Det är viktigt att snabbt få ut förändringar i produktion, men inte baserat på en falsk känsla av förutsägbarhet och kontroll utan baserat på vårt behov av att testa oss fram i en oförutsägbar verklighet.

Kaos in, kaos ut

Var på ett industriföretag igår och pratade agil systemutveckling (produktägarkurs), om hur kraven måste flöda. Drog följande lilla mentala ordbild:

"Om inköp och logistik inte gör sitt jobb, om det inte kommer några inleveranser till fabriken, eller om de kommer i fel ordning, eller är ofärdiga och fulla med fel, eller inte är förpackade på ett hanterbart sätt, inte 17 går cheferna då runt och skäller på arbetarna för att inget produceras. Nej, i ett sådant läge skulle cheferna styra upp inflödet direkt, och se till att inleveranserna sköttes i god ordning.

Detsamma måste folk börja göra inom IT-utveckling. Sluta gräla på systemutvecklare och testare och drift när utleveranserna dröjer, om inleveranserna, de uttryckta behoven, kraven och önskemålen och informationen om hur allt funkar, bara är ett stort kaos."

De organisationer som har koll på kravflödena och där produktägarskapet sker i god ordning, där verksamhet och IT samverkar, där har man ett stort och jämnt utflöde av nytta.

Beställare och utförare

Det finns i synnerhet en form av bristande markkontakt som förstör bra och effektiv utveckling av IT-system: abstraktionen i beställare och utförare, att någon beställer IT-utveckling av någon annan på ungefär samma sätt som man beställer tillverkning.

Det är en abstraktion som kan fungera när man är i avtalssituationer, till exempel när man måste teckna ett avtal som fördelar tänkt ansvar mellan två entiteter eller när något har gått snett och vi måste utföra den där ansvarsfördelningen i verkligheten. Men den fungerar inte när man utvecklar. Inte ens om man faktiskt är två olika juridiska entiteter som ska samarbeta om utvecklingen.

För det är samarbete som krävs. Som det agila manifestet formulerar det: We value Customer collaboration over contract negotiation.

Mjukvara är kodifierad kunskap och förståelse. Det behövs såpass mycket förståelse av både problemdomänen och vilka tänkbara lösningar som finns i lösningsdomänen att man till slut kan kodifiera denna kunskap så att också en dum dator förstår. Det är en kunskap man skaffar sig tillsammans: både de som ska använda det färdiga resultatet av utvecklingen och de som är bra på att fånga kunskap och förfina den till kodifierat skick.

Det finns inget sätt att göra en tydlig ansvarsfördelning i en process vars framgång bygger på mycket tät och rik kommunikation. "Beställare" och "utförare" sitter bokstavligen i varandras knä. Om de inblandad är duktiga på det de håller på med så kan de minska riskerna för att den här kommunikationen går fel, men de är i lika mån ansvariga för slutresultatet.

När man, som vi på Squeed, arbetar i en renodlad utförarorganisation som säljer oss som länkar i utvecklingskedjan behöver man ta ut en ekonomisk riskpremie av varje kund. Ibland går det fel i kommunikationen och då behöver man kunna ha lite kapital för att kompensera för denna varians.

Men situationen är långt värre för de som arbetar med IT-utveckling internt i organisationer där de som ska använda resultatet betraktar sig själva som beställare som kan flytta en stor del av ansvaret över på utvecklingsorganisationen, men utan att dessa får lov att ta ut någon riskpremie. I ett flöde kommer problem att uppstå överallt, men de kommer att manifesteras långt ner i kedjan nära leveransen. Det är som ett stopp i avloppet i källaren: problemet har inte uppstått där utan beror på det som kommer längre upp ifrån.

Så oavsett var kommunikationen och kunskapsförfiningen brister är det "utförarna" som kommer att framstå som de skyldiga, om man saknar förmåga att se kommunikationsbristen i samma ögonblick som den uppstod. Det "beställarna" måste förstå är att om de tar ansvar för sin beställning så har de samtidigt ansvar för utförandet.

En ännu mer bisarr avart av detta är organisationer där den delen av utförarorganisationen som beslutar om utvecklingen på strategisk och taktisk nivå betraktar sig själva som beställare i förhållande till de som befinner sig på operativ nivå nära koden. Där har man verkligen lyckats att ge sig själva stora mandat och samtidigt undvika ansvar.

Det må vara en god ordning för de som placerat sig i den positionen, men vad jag inte kan förstå är hur ledningen för sådana organisationer tillåter det att ske. Dessa organisationer brukar ju ha en lång historia av misslyckad IT-utveckling, och med tanke på hur systemet är riggat kan man bara dra slutsatsen att dessa misslyckanden är avsiktliga.

Nytt kursmaterial färdigt

Så är äntligen uppdateringen för min kurs "Product Ownership" färdig. Vi talar om vad en produktägare är i Scrum och i SAFe, hur man budgeterar och styr en IT-produkt på strategisk, taktisk, och operativ nivå, och litegrann om mjukvaruekonomi (hur man styr systemutveckling på ett ekonomiskt rimligt sätt och hur man följer upp).

Vill du gå den? Hör av dig!

Medarbetarundersökningen vartannat år

Läste i dagens Göteborgs-Posten om att kommunen nu utfört sin medarbetarundersökning och då sett vilka kommunala organisationer som hade högst respektive lägst personalnöjdhet.

Det är i vanlig ordning lite si och så med ledarskapet, kanske särskilt i kultursektorn, och det är ju ett problem i sig. Min erfarenhet av ledarskap är att det är inte supersvårt att skapa en organisation med något sundare ledarskapsstrukturer. Ofta gör man organisationen markant bättre genom att bara bättra på en handfull ledarskapsbeteenden.

Men det som jag studsade över var det här: "När den förra medarbetarundersökningen gjordes för två år sedan..."

Två år.

Det är visserligen bra att mäta. Men om man inte kan agera på mätetalet så är mätetalet istället en farlig fiende. Mätetalet behöver ingå i en uppföljningscykel: man agerar, man mäter, man justerar, man mäter, man justerar och så vidare. Det är beteendet som är det intressanta, utfallsmåttet ska bara berätta för oss att vi behöver ändra kursen.

Ett utfallsmått som tas en gång vartannat år kan visserligen berätta för oss att vi behöver ändra oss, MEN ger oss ingen vägledning hur. Den längsta justeringscykeln som alls är rimlig att ha är väl i storleksorningen ett kvartal. Gärna kortare, om ni vill gå snabbare fram.

Det kan hända att man på lokal nivå arbetar med tätare uppföljningscykler. Men jag tror inte det, för då hade inte situationen hunnit bli såpass bedrövlig på de ställen där det är dåligt. Då hade utfallsmåttet triggat en uppryckning, som man följt upp betydligt tätare.

I mina ögon ser det ut som tvåårscyklerna är ännu ett bevis på att Göteborgs kommun har stora svårigheter med sin styrning och ledning. Jag tycker att utfallet i de kommunala verksamheterna också tyder på detta, så det kommer jag nog tro tills dess att jag har blivit överbevisad om motsatsen.

Markkontakt och flöde

De agila värdena och principerna är en sak. De storskaliga ramverken gör så gott de kan. Men det finns ett par andra viktiga principer som många glömmer av när de ska implementera agila arbetssätt hos sig. Det gäller kanske framförallt när de ska införa agilt i de större sammanhangen, och det beror inte på vilket ramverk man väljer, utan hur man väljer att tillämpa det.

Det är principerna om markkontakt ("gemba") och flöde ("flow").

Vissa agila ramverk, t ex lean software development och SAFe, är tydliga med vad de lånat från Toyota. Men alla ramverken har lånat från Toyota, och i synnerhet dessa två principer.

Hela skälet till att vi investerar i att bli mer lättrörliga (agila) är för att vi vill uppnå ett bättre flöde även i en komplex och oplanerbar miljö. Vi vill bli bättre på att möta behov, även när vi inte riktigt vet hur. Då behöver vi investera i flödesskapande arbetssätt så att vi kan leverera mindre paket men göra det snabbare och bli duktigare på att snabbt fånga upp återkoppling.

Att optimera på flöde är att rensa bort allt onödigt arbete och all onödig väntan. Det är att först och främst se till att informationen flödar fritt och effektivt, för informationsflödet påverkar alla andra flöden. Det är att se till att ingen del i systemet (till exempel en människa) är överlastad. Optimerar man på flöde kan man inte optimera på ett högt resursutnyttjande, men genom att få ner varianser i arbetsbelastningen så kan man förbättra bägge.

Alla agila ramverk är flödesoptimerande i någon mån. Just förmågan att flödesoptimera blir testad när man vill bli agil i större organisationer och värdeflöden. Det är här som lättviktiga ramverk får problem om de inte kompletteras med verktyg för att hantera det större flödet. En hel del av verktygen i SAFe försöker lösa precis detta.

Men det man ofta misslyckas med när man försöker bli storskalig och agil är att behålla markkontakten. Principen om gemba, att vara verklighetsnära i allt man gör, är central för alla smidiga arbetsmetoder.

Det började i verkstadsföretaget Toyota som en idé att den som ska leda ett arbete själv måste veta vad arbetet innebär. Chefen måste ha jobbat på golvet. Det fortsatte med en tanke att beslut inte ska fattas på tyckande utan på fakta. När man gick mer mot massproduktion innebar detta att chefer inte skulle fatta beslut på aggregerade nyckeltal utan istället gå ut i fabriken för att på plats se hur det faktiskt fungerar. Detta ledde sedan fram till insikten att det är folket på golvet som själva bör få mandat och förmåga att också fatta beslut.

När det gäller att utveckla produkter och affärer har principen om markkontakt lett till insikten att gemban ("golvet") inte i första hand är fabriken eller utvecklingsavdelningen eller styrelserummet, utan är den verklighet där produkten används.

Jag har sett storskaliga agila ansatser inom mjukvaruutveckling som aktivt motverkat principen om markkontakt på alla nivåer. De som sätts att leda produktens utveckling på strategisk och taktisk nivå (till exempel i portföljstyrningen eller i programledningar) saknar erfarenhet av att utveckla system. Man fattar beslut baserade på planer och tyckande istället för på faktiska kapaciteter och relevanta mätetal. Ingen av de som styr tar sig någonsin dit där de kan observera det faktiska arbetet äga rum. Man hindrar folket på golvet att själva ta kontrollen över sina arbetsformer, istället standardiserar man i onödan runt praktiker som i det enskilda fallet minskar möjligheten att nå i mål. Och man undviker i det längsta att införa kravfångstmetoder som bygger på att observera verkliga användare och låta nya insikter om deras behov få påverka de redan fastslagna planerna.

Det behöver väl knappast nämnas att resultatet i alla dessa fall blir sämre än det var tidigare?

Jag är beredd att ge ramverken halva skulden för att det är på det här viset. SAFe-införande löper, förmodligen på grund av sitt språkbruk, en notoriskt hög risk att överstandardisera när ledande personer beslutar om att likrikta utan att riktigt förstå varför man vill likrikta eller vilka de skadliga konsekvenserna kan bli.

Men ett ramverk kan aldrig göras ansvarig. Ansvaret vilar på dem som fattar besluten. Om de fattar beslutet att följa ett halvbra ramverk till punkt och pricka på grund av att de själva saknar kunskap att hantera verktyget rätt, så bör de överväga att lämna över en del av beslutsmakten till de som har bättre insikt.

I synnerhet då insikter i principen om flöde och principen om markkontakt.

Det är skalan och inte ramverken

Kritik mot storskaliga agila ramverk bygger ibland på att de bryter mot några av de fyra agila värdena eller de tolv bakomliggande principerna. Och det stämmer i viss mån. Men jag vill ändå försvara de storskaliga ramverken med att brotten mot till exempel de fyra värdena snarare är en produkt av storskaligheten än en produkt av ramverken.

Individer och deras samspel framför processer och verktyg? Ja, men om vi ska synka samspelet mellan hundra individer behöver vi ha något strukturerat sätt att samspela på. Kanske är en tvådagars produktinkrementsplanering med alla i rummet ett bättre verktyg för detta än många alternativ?

Fungerande mjukvara ofta? Ja, men i vissa tekniska plattformar innebär "ofta" var tionde vecka istället för varannan. Trögheten behöver inte ha med processen att göra, utan med övriga strukturer (tekniska och organisationella).

Kundsamverkan framför avtal och friskrivningar? Ja, men där är ramverken, både lättviktiga (som Scrum) och tyngre som (SAFe), helt i händerna på säljprocesser och avtalsjuridik. Det bästa vi kan göra är att försöka övertyga kunder och säljare och ledning om behovet av andra angreppsätt, men då behöver vi presentera ekonomiska modeller och andra kringstrukturer. Lättviktighet som innebär att vi inte svarar på vissa frågor från omgivningen hjälper oss inte i den kampen.

Omplanering framför att följa planerna? Japp. Men på rätt nivå. Om vi använder de agila verktygen för löpande omplanering till att vimsa omkring så tar vi oss ingenstans.

Agilitet har inget egenvärde. Värdet ligger i om ökad agilitet gör oss bättre på att uppfylla människors behov. Vi kan använda vår agilitet för att kunna söka oss fram, men den övergripande riktningen behöver vara fastslagen så att vi vet vilka behov som är viktigare än andra. Särskilt om vi är många som ska springa mot samma mål.

Mer lättviktiga metodramverk som Scrum döljer den här problematiken.  Man antar att det finns en person, PO, som helt enkelt vet hur man värderar och prioriterar. Men den PO som läser Scrumguiden får liten eller ingen vägledning för sitt arbete. "Organisationen ska veta vad som är viktigt och ställa sig bakom PO:ns prioriteringar!" Men hur organisationen kommer fram till detta besvaras inte.

Man kan ha synpunkter på hur SAFe föreslår att en produkt- och portföljledningsstruktur ska se ut. Det finns fler bra sätt att lägga upp arbetet på än vad SAFe beskriver. Men man är farligt naiv om man påstår att en sådan struktur inte behöver finnas utan bara är ett sänke för agiliteten. Scrum implicerar att den finns där. På något sätt behöver PO:n ta reda på vad som är viktigt inför sprintplaneringen.

Däremot lider flera storskaliga agila implementationer av problem. Men dessa menar jag snarare uppstår när man frångår två viktiga leanprinciper: den om "gemba" och den om "flow". Man behöver markkontakt och flöde. Men det får bli ämnet för ett annat inlägg.

De storskaliga ramverkens grundantagande

De tre mest kända ramverken för storskalig agil utveckling: SAFe, Nexus och LeSS utgår från samma grundantagande: utmaningen för storskalig agil utveckling är hur man ska koordinera flera team runt en produkt.

SAFe kallar för ett "Agile Release Train". Nexus kallar det för ett "Nexus". LeSS kallar det inte för något särskilt, bara "det här är Scrum fast för flera team". Men det handlar om en samling av team som samplanerar sin utveckling av en och samma produkt från en och samma behovslista.

I grund och botten är ramverken väldigt lika. Nexus och Less beskriver inte behovslistan på något annat sätt än Scrum (det finns färdignedbrutna saker och ofärdiga) förutsätter värdeskapande varje sprint och tillför få (Nexus) eller inga (LeSS) nya roller. SAFe går lite längre och tar höjd för att varje värdeskapande kan ta några sprintar (ett sk "produktinkrement") och arbetar därför med en tredelad behovslista med vissa specifika artefakter i samt några nya roller för att koordinera detta.

Men inget av ramverken tar höjd för den situation där ett utvecklingsteam behöver stötta flera parallella utvecklingsansatser (projekt eller produkter). Inget av ramverken kan rakt av lösa frågan om hur man koordinerar värdeskapande som sker kors och tvärs och inte sällan i konflikt med varandra. SAFe har åtminstone i och med beskrivningen av värdeströms- och portföljnivån ett förslag på hur det ska lösas, men om ingen finns som kan prioritera på portföljnivå så fungerar det inte.

Problemet är vanligt, det kan lösas och det är inte jättesvårt att lösa även om det ofta inbegriper att man behöver se över beslutsmandat, projektfinansieringsmodeller och uppföljingsmodeller. Men det måste bli mer känt att inget av de existerande ramverken i sig löser den situationen.

Skalningsramverken försöker lösa koordineringsproblemet när flera team ska samsas om en backlogg. Det är en sorts skalproblem. Organisationer vill istället alldeles för ofta använda dem för att få ett eller flera team att samsas om flera skilda backloggar. Det går inte. Det är en helt annan sorts skalproblem.

Det spelar då ingen roll att ramverket har förmågan att hantera flera team. Det man behöver är ett sätt att hantera flera olika beställare med vitt skilda prioriteringar.

(...och apropå storskalighet, som vanligt säger Jurgen Appelo som det är!)