onsdag 12 april 2017

A Capability View on Agility

Agile "methods" (Scrum, SAFe, DSDM etc) are not tools but toolboxes, collections of tools that skilled folks have seen work so they have put them in a toolbox and put a name on it. The "methods", the toolboxes, are very similar when it comes to what tools they contain. Iterations, cross functional teams, daily meetings preferably in front of a kanban board of sorts are often present.

What creates agility in a collaboration however isn't the name of the toolbox, or even the tools, but the new capabilities you can build using the tools. When you focus on the capabilities you need, you will be able to select the correct tool for the job and be able to avoid the not so helpful religious fights about what toolbox one should use.

You don't need the product owner but the capability in the organization to understand and decide what is the most important thing right now given that this product should be healthy during its full life cycle. A product owner is one way of creating that capability.

You don't need sprints but the capabilities to review what you are doing at regular intervals and to plan ahead a bit, synchronized with other efforts. Having sprints is one method, but there are others.

You don't need the scrum master but the capability to have coaching servant leadership working in the organization, where the human factors are understood and regarded.

You don't need the retrospective but some structured way of doing kaizen, continuous improvement.

The toolboxes are often excellent starting points. The particular collection of tools has after all proven to be effective. But by all means, don't look at the tools, look at what you are trying to build.

Focus on the capabilities.

tisdag 11 april 2017

Att verka utan att synas

Arbetet som agil coach går ut på att få andra att glänsa. Man försöker tillämpa systemtänkande på de samspel man ser, försöker få de andra i samspelet att tillägna sig samma sorts tänkande, och att de i grupp kommer igång och löser de underliggande strukturella problemen som hindrar dem från att skapa väldigt mycket värde.

Det är att agera katalysator och inte vara en ingrediens. En igångsättare men inte en nödvändig förutsättning för att arbetet ska fungera i fortsättningen. Om man inte gör sig onödig på den plats där man är så kommer man aldrig vidare till att hjälpa nästa.

Man behöver kunna verka utan att synas. Det är, tycker jag, en av de svåraste sakerna i agil coachning.

För samtidigt behöver man ett visst mått av synlighet för att kunna göra sitt jobb väl.

En grupp har till exempel ett stort behov av direkt ledarskap i början av sin resa. Med tiden ska den bli självgående och ha förmågan att fatta bra beslut tillsammans, men till att börja med behöver de någon som både hjälper dem att formulera det gemensamma syftet och ger dem några konkreta samarbetsverktyg att börja med.

För att få handlingsutrymme, till exempel för att alls få uppdraget, behöver man tydliggöra visionen och möjligheterna. Det innebär att ställa sig i rampljuset en stund. Vara den som erbjuder sig att visa vägen, också för att vara den som organisationen tydligt kan skylla på om det inte går vägen.

Man kan också behöva manövrera ut andra som tar väldigt mycket plats på arenan. Formella och informella ledare som har en annan agenda än den som man kommit överens med ledningen om. Folk som kanske vill ta de synliga ledarpositionerna, inte som ett första steg på resan att lyfta andra, utan som ett sätt att glädja sitt eget ego.

I lean och agilt handlar ledarskapet mycket om att på ett medvetet sätt motverka de intuitioner om ledarskap som vi människor har mer eller mindre medfött, och som också ofta bekräftas av våra mänskliga kulturer.

Vi belönar gärna narcissism hos våra ledare. Vi underordnar oss den som är lite bufflig och hotfull. Och när vi är på en förändringsresa och det börjar skaka lite så tyr vi oss hellre till de som rakt och enkelt berättar för oss vad vi ska göra än till de som krånglar och vill att vi ska fatta egna beslut och våga stå på egna ben.

Det luriga är att man som vägvisare på förändringsresan behöver både kunna ikläda sig rollen som direkt ledargestalt och backa undan för att stärka självledarskapet. Detta hos människor som hellre lyssnar till vem som helst som kan uppvisa direkt ledarskap, och helst i kombination med bufflighet, i synnerhet precis när resan känns som otäckast och det faktiska behovet av både direkt ledarskap narcissism och bufflighet är som lägst.

Det är det svåra tycker jag.

lördag 8 april 2017

The third digitalization insight

The first insight is that something needs to be done.

You can already now see lots of possibilities. Things that you sense could be done better or differently using digital equipment to connect the value stream. Or things that you see that your competitors do that you don't.

The worst reaction to this insight would be if you shout further down in the organization to start do all these things that you see needs to be done: "Start more projects! More digitalization! Why are you so slow?"

Instead you can meditate over the second insight. What you need is the organizational capability to invent. To look at your value streams in a new light. Can design thinking help? Probably. Implementing design sprints? Yes, that is one specific thing you can work with.

Or why not invest in an innovation center? A place where certain people in your organization are allowed to innovate, free of the constraints that reigns in the rest of the organization? Allowing two "modes" of operation in different sections of the organization: one fast where all the cool things are done, and one slow, where all your normal dull and slow and not so innovative people can do all the normal dull things.

While working "bi-modal" (as it is sometimes called) can be a starting point, it is definitely not a solution. What you could (and should) use it for is to let it help you get the third insight.

The second insight was that your lack of digitalization ability isn't caused by a lack of digitalization projects. The third insight is that your lack of digitalization ability isn't caused by the lack of innovative people or innovation centers. It is caused by structural hindrances, systemic factors, that you are responsible for upholding.

Organizations need structures that prevent them from falling apart. Organizations, just like organisms, must possess the capability to prevent too much change to happen at the same time. They must possess what biologists call homeostasis. On the other hand: the biological term for total standstill in the organism is death.

What the third insight inspires people to do is to invest in the organizational capability to move rapidly but with preserved integrity. Innovation centers can be organizational prototypes where those capabilities can be developed, but if the capabilities stay there, the innovations they might come up with will not affect the rest of the organization. Your core value streams will not develop.

That organizational capability is called business agility, and the ways of implementing it are well known and investigated during more than twenty years. They are neither hard or easy to implement, rather medium hard, but they involve a critical look at the present structures, including leadership culture and high level financial KPI:s.

The third insight is that you, as the leader of the organization, must start with yourself and think about what kind of organization you want to lead.

måndag 3 april 2017

Dröjsmålskostnad (cost of delay)

En av Donald Reinertsens stora bidrag till tjänsteutvecklingen är att han trycker på att man bör mäta värdet av en framtida förändring i en tjänst utifrån dess dröjsmålskostnad (cost of delay).

Dröjsmålskostnaden kan uttryckas som svaret på frågan: "Vad förlorar vi varje dag på att inte ha genomfört förändringen än?" Det är en kraftfull fråga som hjälper till att lösa många svårigheter folk har med att prioritera. Exempelvis dessa:

Vilka kvalitetshöjande åtgärder ska vi satsa på först?

Vi har problem med API:et för integrationen med systemet Gnork. Det ger ett visst antal ärenden i supporten. Vi har även problem med våra automattester. Det ger långa driftsättningstider som binder upp folk stora delar av veckan när det är driftsättningsdags.

Genom att räkna på kostnaden för dessa bägge problem under någon representativ tidsrymd (till exempel inräkna både driftsättningsperioder och perioder utan driftsättning) kan vi få en kostnad per tidsenhet som ger oss vägledning i frågan om vad som är viktigast att åtgärda.

Vilka deadlines är viktiga och vilka är det inte?

En deadline kan ses som en kalendertidpunkt då kostnaden för att inte ha en åtgärd på plats (dröjsmålskostnaden, cost of delay) ökar till ohanterliga nivåer. Det kan gälla förändringar i tjänsten motiverade av lagkrav under hot om höga viten, eller att inte ha en produkt i drift den dag man har köpt TV-reklam och vill slå på stora trumman.

Men vad gör man när man köpt TV-reklam, och ett nytt lagkrav träder i kraft, och man inte tagit höjd i sin kalendertidplan för dröjsmål på grund av faktorer man inte kunnat förutse?

Att ha beslutandemakt över en tjänst innefattar att behöva ta tuffa beslut. Genom att räkna på dröjsmålskostnaden kan man ta det minst dåliga beslutet och priortiera även bland sådant som "inte får lov att ske" (vilket man som chef ju är satt att hantera, hade chefandet varit enkelt kunde vi skrivit en javaskriptsnurra som chefade).

Hur ska vi ställa kvalitetshöjande åtgärder mot större strategiska projekt?

Här kommer den stora vinsten med fördröjningskostnad: Det finns ett (otillräckligt) sätt att räkna på tjänsteinvesteringar som går ut på att man tar det nya tjänstebeteendets livscykelintäkt ("Vi snackar miljooooooner här va!") dividerat med livscykelkostnaden ("Måste det kosta så mycket? Kan ni inte göra det lite enklare? Underhåll? Nä, det blir för dyrt! Felärendena får supporten ta hand om! Den ligger i Långbortistan så den blir billig!"). Gissningar om livscykelintäkt (gärna aggregerat på flera år) dividerat med livscykelkostnad (unikt låg), ger en (gravt osäker) uppfattning om satsningens relativa värde.

Jämfört med alla sådana business case där kronorna räknas i miljoner både på intäkts- och kostnadssidan står sig de "mindre" kvalitetshöjande åtgärdena slätt. Det finns på allvar organisationer som inte räknar de mindre förbättringarna som värdetillväxt på sin investering (så kallad capex) utan som rena kostnader (så kallad opex) vilket gör att de stora projekten alltid ges förtur i budgeten trots att deras bidrag till värdetillväxten sett till livscykeln kan vara betydligt mer blygsam än de många men mindre åtgärderna.

Fördröjningskostnaden jämför istället äpplen med äpplen genom att ställa samma fråga till bägge typerna av investering: vad är kostnaden per dag av att göra detta? Vad är kostnaden per dag av att inte göra detta?

Totala business case baserade på livscykel är lögnaktiga eftersom de innefattar så mycket osäkerhet och inte tar hänsyn till att tjänsterna behöver mycket underhåll under livslängden för att fortsätta generera värde. När man aggregerar långa tidsrymder aggregerar man även den risk som varje dag eller varje vecka finns att ROI av skäl man inte kan rå för plötsligt störtdyker och kräver utvecklingsinsatser för att vara uthärdligt.

Kostnaden för en defekt är vad den kostar att kompensera för, varje dag. Det kan gälla manuell handpåläggning eller andra ökade kostnader, eller att man tappar intäktsmöjligheter. Kostnaden för ett icke driftsatt paket av funktioner (till exempel en ny produkt) är den uteblivna intäktsmöjligheten (eller viten kopplade till exempelvis lagkrav), varje dag.

Det är detta "varje dag" som är nyckeln. Genom att bryta ner till jämförbara kalendertidsenheter blir investeringarna möjliga att räkna på. Tack Donald Reinertsen för den tankegången, och tack Dean Leffingwell för att du populariserat det genom SAFe (även om SAFe:s resonemang runt fördröjningskostnad inte är riktigt detsamma som Reinertsens).

torsdag 30 mars 2017

Vi måste prata om portföljhantering

Vi måste prata om portföljhantering. Portfolio management. Det har hänt flera gånger att jag läst rapporter och utredningar som pekat på vikten av portföljhantering för att lyckas med digitalisering, men snabbt sett att de pratat om två radikalt olika saker

När man pratar om portföljhantering inom IT kan man mena dels projektportföljhantering (när man försöker ha koll på alla större förändringsprojekt), och dels IT-portföljhantering (när man försöker ha koll på alla sina mojänger under hela deras livscykel och behandla dem som de investeringar de är).

Ibland pratar man om någon av IT-portföljhanteringens delkomponenter såsom IT-produktportföljhantering, applikationsportföljhantering, eller tjänsteportföljhantering, men det är ungefär samma sak: livscykelhantering med fokus på totalekonomin och den strategiska och taktiska betydelsen av IT-objekt man investerar i.

Projektportföljen är ett försök att centralisera kontrollen över de stora förändringarna som pågår i de olika förvaltningsobjekten (produkterna/applikationerna eller tjänsterna). Det innefattar däremot inte kontroll över löpande förbättringar i objekten och hur dessa åtgärder blandas med åtgärder för vidmakthållande av funktion. Det innefattar inte ekonomiskt ansvar över tjänstens eller applikationens livscykel.

Varför har projekten fått en så framskjuten plats i våra organisationer? Projekt infördes när förvaltningsorganisationen inte förmådde genomföra förändringar på ett adekvat sätt. Projektportföljhantering infördes när projekten blev många och började påverka varandra och man behövde "trafikleda" mellan dem för att se till att de inte störde varandra och att de bidrog till att uppfylla organisationens strategiska mål.

IT-portföljhantering (och i ännu högre grad den modernare tjänsteportföljhanteringen) tittar istället på värdet över en livscykel. Det är ett försök att hantera sin tjänstekatalog på samma sätt som du hanterar andra tillgångar du investerat i (som till exempel fabriksbyggnader). Du tittar på kapabiliteter och kapaciteter, kostnadsstrukturer och bidrag till värdet, och så håller du koll på hur du ska lägga ditt ständigt pågående förbättringsarbete.

Projekt och projektportföljer är nödvändiga när förvaltningsorganisationen inte förmår planera och utföra förändringar på sig själv. Men i digitaliseringen handlar det om ett ständigt förbättringsarbete av digitala värdeströmmen, och då kan vi inte ha förvaltningsorganisationer som inte förmår hantera förändringar.

Insikter om värdefulla förbättringar kommer löpande, kostnaden för att inte ha en förbättring på plats är högre än att arbeta för att införa förbättringen så snabbt som möjligt, så därför riggar den moderna förvaltningsorganisationen sig för att bli experter på just detta. Agila metoder är ett sätt att på enklaste och snabbaste sätt omvandla löpande insikter om behov och värdeskapande till fungerande funktioner i tjänsterna och flödena.

Så när vi pratar om att portföljhantering är nödvändigt för att lyckas med digitaliseringen så är det tjänsteportföljhanteringen, livscykelperspektivet och förmågan till snabb och ständig förbättring, vi pratar om. INTE hur förändringsarbetet ska isoleras i projekt som koordineras av projektportföljhantering.

Detta är för övrigt den ursprungliga betydelsen av portföljhantering inom IT (från början av 70-talet). Och precis som när det gäller andra tillgångsportföljer handlar det om att balansera värdeskapande och kostnader, utveckla nödvändiga funktioner och andra möjliggörare, samt kontinuerligt anpassa sig efter organisationes strategiska mål i en föränderlig värld, under det att man genomför ständiga förbättringar.

Det handlar inte om att koordinera förändringarna som isolerad företeelse. I digitaliseringen är aldrig förändringarna isolerade.

lördag 25 mars 2017

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!

torsdag 23 mars 2017

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.

lördag 18 mars 2017

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.

lördag 11 mars 2017

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.

torsdag 9 mars 2017

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.

söndag 5 mars 2017

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.

lördag 25 februari 2017

The Benefit of Management by Fear

In general, the possibility to avoid threats and pain is a stronger motivator than the possibility to gain something pleasant. This is true for most organisms where you can talk about motivation at all. Responding to threats with fear and avoidance is apparently a good survival tactic.

And like all creatures that are dependent on groups to survive, we are particularly fearful of rejection, that the group will reject us and leave us alone in the wild. Which the group will do if the most influential individual in the group tells it to.

This is why management by fear is such an effective strategy for motivating people to work. If you have the mandate to reject people and make their peers reject them as well, you can make them do anything.

Or, not really. There are a few things that the fearful brain is incapable of doing. So if you are planning to use management by fear there are a couple of things you need to be prepared to handle yourself.

You need to define the tasks for your subordinates since their fearful brains won't be able to come up with the tasks themselves.

The tasks need to be perfectly thought out because your people will perform them even though everyone can see that the result is flawed. A fearful brain doesn't dare to criticize your orders.

You need to increase the checks and controls. If subordinates fears showing you mistakes that has been made you need to find other ways bringing them into the light.

(Extensive checks are also important for linking the necessary punishment to bad behaviour. A small part of uncertainty whether or not you will be punished will strengthen the fear, but uncertainty is a strong demotivator. Most punishment should come as a logical consequence of past outcome.)

The responsibility for planning and follow-up if things are going according to plan or not from now resides with you.

You must handle all the external relations. Fearful brains will focus on pleasing you and not your customers.

From now on you have to do all innovation. A fearful brain is incapable of experimenting.

Given that you are willing to assume these responsibilities, management by fear can be a great tool for your organization. The alternative is to create an organization of customer-focused, innovative responsible adults that can manage their own work according to the goals you set together. That will also require a lot from you as their manager, but it is a different set of tools.

lördag 11 februari 2017

Kvalitet OCH snabbhet

Den falska motsättningen mellan hög kvalitet och snabb leverans är en tankekonstruktion som verkar vara väldigt svår att göra sig av med.

Det kan ha att göra med dessa två kopplingar: slarvig leverans ger låg kvalitet, samtidigt som slarvig leverans utan större ansträning kan snabbas upp.

Så det går att få snabbhet i leveransen genom att slarva, med du kommer då att få låg kvalitet. Men du måste då också vara beredd på fortsättningen: låg kvalitet ger sedan långsam leverans. Defekterna som slarvet orsakade behöver tas om hand. Det du inte säkerställde igår poppar upp idag och rör till allting för er.

Den snabba leveransen sker inte på bekostnad av kvaliteten utan på bekostnad av framtida snabbhet. Snabbt slarv är ett lån från framtiden.

Det finns en mytisk modell inom projektledningen som kallas "projektpyramiden". Den ställer projektets omfång, tid, budget, och kvalitet mot varandra och vill påstå att man genom att vilja ha det ena måste ge avkall på det andra. Den bilden är falsk när den leder folk till att tro att det går att leverera ett visst omfång på en viss tid inom en viss budget om man bara får lov att tumma på kvaliteten. Istället är variablerna bundna vid varandra så att du så snart du sänker kvaliteten får en dramatisk höjning på tid och kostnad för det omfång du bestämt dig för.

Projektpyramiden ger en falsk bild av verkligheten, åtminstone i många producerande och tjänsteutvecklande verksamheter.

Produktivitetsökning kräver ordning och reda. Kräver att det inte finns så mycket okontrollerad varians i systemet. Det är därför som ett fokus på systematiskt kvalitetsarbete i förlängningen ger högre produktivitet (mer, bättre, snabbare och billigare). Men nyckelordet är systematiskt. Det handlar inte om kvalitet genom att individer sliter hårdare eller tar mer tid på sig och dubbel- och trippelkollar allt arbete. Eller genom att man gör väldigt mycket och sedan inspekterar fram den lilla del av produktionen som råkar blir bra. Det handlar om metodik.

Tricket från metodiskt kvalitetsarbete, det som lean och agila metoder använder, är att man gör god kvalitet billigt. Förtydligar kvalitetskraven så att de är otvetydiga och låter de som ska utföra arbetet och de som ska ta emot det utförda arbetet tillsammans avgöra om kravet är tvetydigt eller ej (i Scrum genom redokriteriet och klarkriteriet). Rapporterar blixtsnabbt så snart man ser att en avvikelse från överenskommelserna är på gång att inträffa och får snabba beslut om hur man ska göra. Bokför de avvikelser man av olika skäl inte kan hantera så att man alltid har med dem i beräkningen.

Och det ständigt pågående förbättringsarbetet. Vi dokumenterar hur vi arbetar idag. Vi analyserar vad som hindrar oss från att ta nästa steg mot större kvalitet och snabbare feedbackloopar (där leverans till människor som använder det vi producerar och deras användande är den viktigaste feedbackloopen). Vi experimenterar med vårt arbetssätt. Vi förenklar, arbetar i team, bryter ner i mindre delar, har snabb omplanering, automatiserar så många rutiner som möjligt som har med felsäkring att göra, och så vidare.

Det kräver ganska stora frihetsgrader för arbetsgrupperna för att de ska kunna arbeta med metodiskt kvalitetsarbete. Det kräver å andra sidan av grupperna att de hela tiden arbetar under stor transparens så att alla ser vad som händer, och att de arbetar med ständig riskreducering så att utforskandet av arbetssätten blir säkra och trygga.

När arbetsgrupper börjar använda lean och agila metoder utmanas de befintliga strukturerna. Myter i organisationen, som till exempel projekttriangeln eller tron på planerbarhet i komplexa miljöer, eller tron att effektivitetsförbättring i alla verksamhetens delar innebär effektivitetsförbättring på hela flödet, riskerar att avslöjas när verkliga mätdata synliggörs av de som arbetar nära det direkta värdeskapandet.

Personer som har sin yrkesroll och identitet baserad på att upprätthålla myterna blir hotade av det nya arbetssättet. Detta gäller inte minst många chefer som tillsatts för att bevara och förstärka en struktur som inte längre kan sägas vara hjälpsam. Det gör att förändringsarbete som syftar till att få både kvalitet och snabbhet förhindras av ett uteblivet skifte i tankesätt och kultur.

Samtidigt är det ofta dessa chefer som äger frågan om både kvalitet och snabbhet. De är tillsatta för att få till precis det de själva förhindrar, så länge de inte inser att det krävs ett nytt tankesätt och ett nytt beteende från deras sida. Att arbeta i det spänningsfältet utgör större delen av mitt arbete att stötta organisationen i förändringen. Det är väldigt intressant och väldigt utmanande.

lördag 4 februari 2017

When you can't iNvEsT

In agile development we have a backlog: a list of needs that we want to fulfill in a certain order. We also try to have a cross functional small team that take care of meeting the needs without having to handover stuff that must happen to other people. In certain agile frameworks (such as Scrum) the team shouldn't even have to interact with others when meeting the need so that they are able to independently take responsibility for a couple of weeks worth of work.

That means that each work item that meets a need (is valuable) also has to be small. We also want each item to be independent of the others so that we can give our primary stakeholder (for example the Product Owner role in Scrum) the opportunity to pick and choose any of the items in the backlog to be fulfilled.

In 2003 Bill Wake suggested that these three characteristics (I for "independent", V for "valuable" and S for "small") of a good product backlog item should be combined with the characteristics negotiable (in agile, a requirement is the starting point of a conversation and not the end of a discussion), estimable (just enough so that stakeholders can decide if it is worth it), and testable (if we can't test if a need is fulfilled or not, the need was probably not expressed clearly enough). And thus the acronym INVEST (independent, negotiable, valuable, estimable, small and testable) was born.

Now, while INVEST can be an ideal (since if we manage to make all of our items on the list INVEST compliant it is really easy to increase the agility in our development) many have found it hard, if not impossible, to achieve. So what should we do then? Abandon the whole idea? No. But think a bit. And know how to work with it.

The thing is that three of the letters in the acronym has everything to do with the organization. Why isn't the items negotiable? Why can't you reach a consensus on them? There is almost always a destructive power game present when people doesn't understand why the items on the backlog isn't the last word on how to meet a need or what the need is about.

Why isn't the item estimable? Are there hidden complexities that you haven't explored yet? Don't you have sound practices around refinement so that you know what it would take? And why isn't the item testable? Haven't you had all the required conversations yet? Doesn't people know what they want? Do you let people who know how to test things step up and participate in the item generation?

The N, the E, and the T are typically things that an agile transformation address, and it goes typically very well. It isn't that hard to create an environment where we collaborate on the items, negotiates what we would like to see done, make forecasts, and thinking about their testability. The problem usually resides with the other three.

Things can be cut into small partial targets. But in many environments, they are not valuable. Due to inherited complexity in the technical environment things cannot be small and valuable at the same time. They might be able to, later on, but not now. So we might have to slice down a valuable feature into smaller pieces, starting with a primitive version of the feature and improving it over the course of a few sprints. In the same manner, features may be dependent of each other and implemented and released in a certain order within a releasable package.

It is for circumstances like these a backlog split in three levels, as Dean Leffingwell suggests, is constructed. Closest to the team are the sprintable items that they can plan for and implement. A group such of sprintables is needed to implement a feature (the second level), and packages of related features that are needed together in order to generate business value (Leffingwell calls these packages Business Epics) constitutes the third.

The three tier backlog has its place when the items cannot be small, valuable and independent at the same time. It has been criticized for introducing complexity, but the idea is not to introduce complexity but to mirror the actual complexity we actually have to deal with. Then we can start to manage the complexity and hopefully work in order to reduce it.

Related: The SMIDIGT! module about the three tier backlog: documentation-the-backlog.pdf

söndag 22 januari 2017

När system krackelerar

Just nu (januari 2017) i Sverige är det några viktiga samhällssystem som verkar krackelera. Det finns många politiska reflektioner man kan göra runt det, vilket jag inte tänker ägna mig åt på den här bloggen, men det finns också ett antal reflektioner som definitivt har koppling till lean och andra smidiga samarbetssätt. Särskilt på att man så tydligt kan se sprickorna på systemnivå. Flera sanningar från systemtänkandet blir tydliga.

Störningar uppstår på en plats och syns på en annan. Just nu har akutsjukvården kris. Väntetiderna springer iväg och tangerar livsfarliga nivåer. Frågar man folket på golvet, på gemban, till exempel sjuksköterskorna, om orsakerna så är ett av de stora hindren för effektiv akutsjukvård att det inte går att skicka sjuka vidare till vårdplatser längre bak i sjukhuset. Bristen där slår igenom på akuten. Att fixa akutens problem handlar bland annat om att fixa vårdavdelningarnas problem.

Störningar smetas inte jämnt över flödet utan drabbar det sköraste området. Man hade med sig kanariefåglar ner i gruvor för att känna av problem med farliga gruvgaser. Innan halterna blev farliga för människorna tuppade kanariefågeln av och man kunde utrymma gruvan i god tid. Fåglarna var skörare än människorna och gav tydliga indikationer på en ohållbar situation.

Detta är ju en god lösning så länge som kanariefåglar anses vara mindre viktiga än människor. Problemet uppstår när det sköraste området samtidigt är ett av de viktigaste. Att låta akutavdelningar agera indikatorer på vårdavdelningarnas problem är kanske många kan hålla med om är mindre lämpligt.

Det går fort när det vacklar. Effekten av störningarna är inte linjära mot mängden. Alla system "buffrar", dvs kan härbärgera variation, upp till en viss gräns. Man märker alltså inte alltid när man närmar sig olika kapacitetstak med hög hastighet. När man närmar sig taken blir däremot effekterna ganska stora, och en systeminfarkt (att flödet helt kleggar igen) kommer snabbt.

Orsak och verkan kan vara åtskilt i tiden. En annan effekt av buffringen är att det kan ta tid innan man ser konsekvenserna av en systemhändelse. Och de aggregerade konsekvenserna av beteenden under många år kan drabba flödet under ganska kort tid. En skuld uppbyggd under flera decennier kan behöva amorteras av på ett halvår.

Det är alltid flera orsaker. System uppvisar oftast komplexa beteenden. Du kan nästan aldrig hitta en rak orsakskedja där en sak leder till en annan och så vidare. Det är nästan alltid fråga om flera saker som samverkar på flera sätt, ungefär som vädret.

System är oförutsägbara. Vi kan se att systemet beter sig skakigt, men vi kan inte förutse när i tiden något rasar eller kostnaden för konsekvenserna.

Våra intutioner är på många sätt inte lämpade för systemtänkande. Vi tror att problem uppstår där de syns så vi skjuter budbäraren eller försöker lösa fel problem. Vi fastnar för den första rimliga orsaksförklaringen och går inte vidare för att ta in den större bilden. Vi tror att saker som händer i snabb följd också har orsakssamband. När ett beteende inte omedelbart möter motstånd tror vi att det inte innebär någon fara på längre sikt. När systemet skakar tror vi att den första lösningen måste vara att tillföra mer resurser där det skakar istället för att utjämna varians och se om det är några andra delar som ska förstärkas. Och vi tror att den som pekar ut oförutsägbarheten inte har förstått systemet, vi tror nämligen att saker i princip är förutsägbara och planerbara om man bara försöker tillräckligt hårt och är duktig.

Men intuitionerna kan inte skydda oss från de verkliga systembeteendena. Det vill alltså till att vi allesammans tar fram systemglasögonen och de verktyg som faktiskt finns för att lösa systemiska problem. Allt detta är lösbart, om vi vill.

söndag 15 januari 2017

Satisficing

I am reading up on Satisficing, a decision making strategy that aims at satisfying a need but just sufficiently. It seems like we, when making decisions, often go through a list of options until we see one that we believe meets our needs, given our mental models about needs and how the options will work out. We simply tend pick the first match.

Evaluation of options is hard mental work, and making decisions takes a toll on our psychological motivation. Therefore there will be fewer people who opt for trying to analyze all available options before making a decision (as a believer of rational choice theory would assume they do), and more people who are seeking an easier way out by evaluating as few options as possible (a behavior more in line with what proponents of choice theories of psychological realism believe).

We also have the systemic effect of weeding out those who tries to analyze every option when there is no complete list of options to choose from. They will never be included in the count of decision makers since they are stuck with analyzing. So when we are dependent on other people making a decision, we can expect that they for the most part are using a satisficing strategy.

What does that teach us?

First of all the importance of mental models when understanding your own needs and how they might be met. People will pick the first option that they believe will fix things according to their understanding of the situation. The way we talk about things, frame situations, use illustrations and parables will totally determine what options we pick. Make sure that the mental models reflect the actual situation.

Then that the order of presentation is very important. Any option higher up in the list will have a higher chance of being chosen, regardless of its effectiveness compared to the other options further down. So if we want to increase the chance of picking an effective solution to a problem we have, we should first try to quantify, or at least rank, the effectiveness of them before picking one.

And last but not least: since we use this and other decision making strategies that works against making optional choices, we can assume that our decisions will be bad. We can try to become better at it, but we must realize that we will make the wrong choices from time to time. So we have to employ strategies that reduce the bad consequences of a bad decision.

Here the preferences from agile decision making comes handy!

In agile, we try to make it small before making it big. Everything should be seen as an experiment that we run for a limited time, and then we can make a better decision whether we should continue or not. Is this good enough for now, and is it safe enough to try?

We will also try to optimize for options when we decide. Given two paths, if we chose the one that has many branches ahead we can always change course as we learn more about our goal and how the reality works. Making definitive decisions early on when we have access to very little information may sound cool and you feel like a Powerful Leader when you do it, but it isn't really the most effective thing to do. Maintain your flexibility at all times.

The journey to value creation is a journey of insights. What we grow together is the body of knowledge. When we investigate our options we should look out for the options that gives us the most learning opportunities. If it is impossible to be sure that we have picked the right option, it becomes very important to quickly learn if our chosen path was the wrong one to take. That will increase the chance of making the next step on the journey better.

And when evaluating and learning, remember the words of Deming: "Without data you're just another person with an opinion". But also from the same man: "The most important things cannot be measured", and "The most important figures that one needs for management are unknown or unknowable".

Happy decision making!

tisdag 3 januari 2017

Man måste avveckla också

Vad händer om en ledning tror att IT alltid är något man inför, och lägger all krut på dyra utvecklingsprojekt? Man får ett växande beroende till ett myller av applikationer och tjänster. Till slut kan man inte förändra någonting, och hela ens digitaliseringssatsning riskerar att bli ett haveri. IDG skriver om det idag, och Jonas Söderström har varit inne på det flera gånger.

Man måste avveckla systemen också! Eller rättare: Ta ett livscykelansvar. Införa en tjänst när den behövs, ändra på tjänsten när det behövs, och ta bort tjänsten när den börjar göra mer skada än nytta.

Det finns tusen och ett skäl till att detta inte görs. Det är sällan någon annan än VD:n som äger frågan om helheten, och få VD:ar förstår sig på hur man äger en flora av digitala tjänster. Man kan ha konstiga ekonomiska ramverk på plats som ser funktionstillväxt som värdeskapande och funktionsavveckling som att man förstör värden, trots att det i verkligheten kan vara precis tvärtom: när funktionstillväxten sänker värdet på anläggningen och renodling och avveckling av funktioner ökar det.

Vi har förstås även vår instinktiva rädsla för att välja bort. Fear of missing out, eller loss aversion som är den etablerade termen inom psykologiforskningen. Det är alltid lättare att säga "ja" och lägga till något än att säga "nej" och ta risken att välja bort något mycket värdefullt. Att säga "ja" till en avdelning som ber om mer är också psykologiskt enklare än att säga "nej" till folk.

Ändå är det ofta rätt sak att göra. Men det krävs mod. En av de första sakerna som Steve Jobs gjorde när han kom tillbaks till Apple var att våga slakta en uppsjö av varianter och modeller som var och en var ekonomiskt motiverad och hade sin lilla roll att spela i ett mycket litet ekosystem men som sammantaget bidrog till att skapa en sämre helhet.

Man måste säga nej till även bra affärer, bra digitala tjänster, bra stödsystem, för att orka satsa på de som är bäst: både bra och i linje med ens strategi. Hur kan lean och agila metoder hjälpa?

I en organisationsgemensam behovslista (backlog) ser man hur fokus på färre saker kortar ledtiderna i värdeskapandet. När alla i organisationen känner till spillkällor och har förmåga och mandat att arbeta med ständig förbättring på helheterna så föds insikterna om behovet av avveckling naturligt. Genom att tydliggöra produktägarskapet för helheten, till exempel i form av en uttalad produktägarperson i en liten organisation eller en gruppering i en större. Genom att fokusera på tjänstestrategin och visionen.

Och inte minst genom att ha ett ekonomiskt ramverk för beslut runt tjänstefloran som optimerar på värdeskapande. Till exempel genom att bygga på några av de principer som den amerikanska ekonomiprofessorn Donald Reinertsen listar i sin bok "Flow". Alla beslut kan inte alltid räknas ut, men man kan se till att de beslut man fattar inte är ekonomiskt oförsvarbara.

Om tjänsteperspektivet är det första man behöver tillskansa sig när man vill syssla med digitalisering så är detta, livscykelperspektivet, det andra. Och då använda sig av de verktyg som finns som stöder det.

söndag 1 januari 2017

Scaling Agile Capabilities

It is my experience that people who think about how to achieve more organizational agility benefits from looking at things from a business capability viewpoint before thinking about organization, tools, and what agile frameworks to experiment with.

A business capability is the ability for a part of the organization to meet a need, internally or externally. The capability could be translated into an expectation of what a part of the organization can provide rather than how it is achieved. For instance the capability to create an increment of valuable deliverables at regular intervals, or the capability to provide a clear answer on what the most important thing is right now.

Methods, frameworks, collaboration techniques, particular roles et cetera is on the other hand totally focused on the how. The capability to create a valuable increment at regular intervals has to be performed by a single cross functional team according to some, the capability to answer on the organizational priorities has to be performed by a single person whose name will be "Product Owner", and so on.

The methods holds a promise: follow me and the capability will emerge! And it is true that these tested techniques often delivers. During my last ten years of experimenting with agility I have tried many of the techniques others have used and written about, and we have achieved pretty good results with them.

But it is also true that we have applied the same techniques in other places and seen things become worse. So it is clearly not the techniques themselves that generates the outcome, but the application of them in environments where also other factors contribute to the result. Of course. Collaborations are complex systems. You can never attribute success to only one thing. Every situation is different and small changes in the circumstances have a huge impact on the result.

Controlling the outcome in a complex environment requires tweaking. We need to steer the system empirically: inspecting the situation and the desired outcome, adapt the action, inspect the result of the adaption, and so on. This is the very heartbeat of anything lean and agile.

Focusing on the desired business capabilities gives you a view on the outcome. What is it that you want to achieve? What is the need?

In some environments it takes a couple of specialized teams to create value. It is as of now impossible for a single team to do this in isolation. So you need the capability for teams to plan, execute, and follow up together, just as they do as individual teams. You could use the Nexus collaboration patterns for this, or organize into a release train as SAFe describes, or trying something else, but it is the capability of many teams acting as one that we need.

In some environments it is hard to create value in chunks that are independent, valuable, and small at the same time. In those environments it can be helpful to think about independent business epics, valuable features, and small slices, as three separate things to manage in different levels of the backlog. Because we may need the capability to divide, explore, and prioritize epics, features, and slices in different ways using different cycles (not all information flows at the same rate).

This is a way of thinking and discussing needs and how to meet them. It lifts us above meaningless quarrels on what processes and tools we should use and instead helps us focus on the good interactions between people. Talking about business capabilities, thinking like agile business architects, is a way of dealing with systemic needs and the different ways of meeting them.

I have found the perspective quite helpful.