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.