En liten julhälsning

Nu loggar jag ut inför helgen, med denna lilla julhälsning:

Vi kämpar oss till toppositioner, visar oss på styva linan, visar framfötterna, tar för oss, låter vårt ljus skina klart. Vem av oss har sett mest, läst mest, kan mest, bör anförtros uppgiften att leda och bestämma? Vem ska höjas till skyarna?

Jag med mina trettio års yrkeserfarenhet har mindre erfarenhet än en grupp om sju där var och en har jobbat i fem år. Gruppen har läst fler böcker och varit på fler kurser än jag någonsin kommer att hinna med under mitt liv. Jag kan komma på mängder med snillrika idéer, men inte så många och varierade som gruppen kan komma på under en enda bra genomförd workshop. Och gruppen har något som inte jag har: förmågan att snabbt genomföra mängder med experiment för att se om någon av ideerna är bärkraftiga.

Jag känner många människor, från många olika håll. Men gruppens sammanlagda nätverk kommer alltid att vara exponentiellt mycket större än mitt. Den kunskap som gruppen behöver i varje given stund kommer alltid att vara mer lättillgänglig än den jag som individ kan spotta fram. Gruppens avstånd till andra människor är kortare än individens. Många mot en är orättvist eftersom de många alltid är bättre. Att samarbeta är inte orättvist utan smart.

Människan är savannens klenaste varelse. Pälslös, långsam, klen, svag luktsinne, oskarp syn, och utan huggtänder. Dessutom föder vi värdelösa ungar som inte kan ta hand om sig själva på flera år. Men människoflocken är savannens dödligaste rovdjur. En femtedel av jordens däggdjursmassa består av människa. Tillsammans är vi, på gott och ont, oslagbara.

Den gåva vi kan ge varandra i form av stöttning, växande, korsvisa insikter, återförsäkring, det är en gåva som bara fortsätter. Den förmerar sig ju mer vi delar med oss av den. Samarbetet är julklappen som aldrig slutar ge. Samarbetet är julfesten som aldrig tar slut. Det är förmågan att se alla vinklar av granen, av tillvaron, samtidigt, när alla dansar runt den tillsammans, har ögonen öppna och delar med oss av vad de ser.

Detta är kärnan i de agila metoderna, och skälet till att jag inte tröttnar på att lära ut dem. Det är en njutning att med egna ögon få se den kraft som uppstår när samarbetet förlöses och folk börjar tänka "vi" och inte "jag", när de tänker "tillsammans" och inte "vi mot dem", när de tänker på makt som något som vi har ihop, inte som något vi har över varandra.

Med detta sagt vill jag önska alla en god jul och en önskan om ett gott nytt år tillsammans mot gemensamma goda mål.

Agile is no joke

Agile methods are sometimes perceived as something less serious than the alternatives. Especially by those who have very little experience in using them. A vague understanding of early texts on agile methods such as "The Agile Manifesto" leads people to think that it is all about ditching methods, tools, documentations, contracts, and plans, and nothing more. An unstructured dream for the immature, a nightmare for the rest of us.

But it couldn't be further from the truth.

Emphasis on using structured tools that support changing circumstances comes from hard evidence showing us that it is impossible to create strict plans for product development and expect them to hold. Predictability is not an option, regardless of the method used. Therefore we use methods for planning and forecasting that takes variability into account. Inherent variability doesn't go away by pretending that it doesn't exist. Instead: ignoring it exposes you to a tremendous risk, as available data on expensive IT failures show us.

Building the capability to handle variation in plans caused by unforeseen events gives us the benefit of being able to handle actual changing requirements continuously, even late in the process. While changing requirements could be a side-effect of an organization that doesn't understand what they need, it is more often caused by the growing body of facts about the problem and its possible solutions.

We all know that our body of knowledge about the situation is small early in the process and larger as time goes on. All decisions should be made in the last responsible moment if we want them grounded in facts rather than guesses. By using methods for continuous risk management and prioritization based on optimizing for options, this discovery process becomes more painless than being forced to stick to misguided decisions made way too early.

With a method that can incorporate newly found insights on the needs of the users and the market, we increase the chance that what we build will be effective. Agility isn't about efficiently creating everything that random people in the organization ask for, but being precise in meeting the actual needs of the most valuable users. It is about quickly investigating large sections of the solution space and focus on the most beneficial ones, both cost and value wise. The number of changing requirements is not a negative KPI but a metric of increased knowledge.

In order to achieve this, we can never be in debt. Our product must be ready to meet the current reality. No waiting for tests, for more documentation, for productivity enhancing refactoring, or for improved usability. When we are done with a small increment (which we should be regularly) and have deployed it into production, we are done. Our product is usable. Ready to generate value. Our quality assurance strategy are therefore way better than in the older methods, or else we couldn't have this. Modern proven testing strategies and a lot of automation is at the core.

The way we make these things a reality is by extensive amounts of teamwork where organizational borders are crossed (or crushed) and lots of delegated mandates where the teams has a growing amount of decision making power. Delegation is not about letting things go, but about building capability for self-leadership and responsibility in the collaborations of the organizations.

All this isn't possible if we don't choose to use management principles grounded in modern psychological and mathematical science. The foundations for making these things work have been known since at least the 40s-50s, and today our knowledge in both psychology and systems thinking is way better. It is therefore no joke or hippie dogma when we ask management to update its principles on how value is measured or on how governance and leadership is supposed to be done in an organization.

Agile is no joke. It is for real, it is grounded in solid principles and hard evidence, and if you want it you need to really consider what it requires from you and your organization.

Projektmǻl och effektmål

Ett effektmål är något du vill ska vara annorlunda när du genomfört något. "Hur ska folk bete sig tre år efter att du har lanserat det här?" är en coachande fråga man kan använda för att undersöka vilka effektmål som kan vara aktuella.

Ett projektmål kallar man det som ett projekt ska leverera. Om det är en tjänst eller en produkt kan det handla om produktens eller tjänstens funktioner.

I teorin ska en förstudie ha tagit fram projektmål som kommer att leda till att effektmålen uppfylls. Att man går vidare i projektet beror på att man tror på den gissningen.

MEN...

Det finns inga garantier för att projektmålen uppfyller effektmålen. Efter bara en liten tid under projektet kan det bli uppenbart hur de tidiga antagandena som nu hela projektplanen bygger på är felaktiga. Antagandena var trots allt bara gissningar gjorda på ett tidigt stadium, dvs när vi hade tillgång till väldigt lite information.

Vad göra när insikten kommer? Ett par alternativ:

• Avblåsa projektet? En hel del projektmodeller föreskriver faktiskt detta. Men det görs sällan. Prestigeförlust, det felaktiga antagandet att redan förbrukade pengar bör påverka beslutet om nedläggning, och det faktum att projektet måste göras, kanske på grund av en lagändring, förhindrar nedläggning. Den som beslutar om nödstopp kommer att granskas mycket kritiskt. Om man inte beslutar något alls slipper man kanske kritik, så projektet bara fortsätter.
• Förändra projektmålet? Man borde inkorporera de nya insikterna om hur effektmålen uppnås i nya projektmål. Men så som många projekt drivs är det väldigt svårt. Man har inga processer på plats för att förändra målen. Man kan till och med ha mängder med processer på plats för att förhindra förändring av målen.

Resultatet blir att förändringen inte sker. Projektet pågår, långt efter att man insett att det som projektet ska leverera inte är aktuellt. Så länge som strukturerna finns på plats som förhindrar förändring är det svårt att ändra tanke om vad som bör levereras.

Man kan inte styra mot vissa projektmål och mot vissa effektmål samtidigt. När som helst kan vi drabbas av insikten att något av dem måste förändras för att det andra ska vara oförändrat.

Agila metoder bygger på att kunna ta hand om den insikten. Tanken är att eftersom det är effektmålen som skapar värde så ska vi försöka styra mot dem, medan hypotesen om vad vi bör leverera förvandlas med tiden.

Vi försöker vara effektstyrda. Det är nyttan med det vi gör som är det viktiga.

Don't Solve The Problems You See

Collaboration tools that are used to make the collaborations more agile, they will probably subtly teach you systems thinking. The collaboration techniques (synchronizing your work together standing in front of a value stream board on a daily basis, having clear definitions for when work is ready for the next step etc) seldom solve anything, but they point out the systemic causes to low agility so that you will be aware of them and find out solutions and workarounds.

It has happened numerous times that participants on my courses has returned to work with a much clearer view of what the problems are and how one can fix them, and then they have started to solve them.

Don't do that. Or: if you want to do it you must be prepared for what's coming next.

What almost always happens is that your peers, who haven't been on the same course and never had a chance of developing the same way of looking at things that you have now, they won't understand what you are trying to do and why.

Change in itself triggers fears, and change without seeing the need or understanding what the intentions are and how the change will affect them will trigger a sense of losing control. That normally brings people into an anxious defensive mode and they will do anything they can to block what you are trying to do. If they somehow have authority over you, like if they are your boss or something, the defensive actions they take may hurt you.

It is very frustrating seeing what needs to be done and then being blocked by others. That will probably bring you into an anxious defensive mode, which can manifest itself as anger or frustration with your fellow human beings, and sad things may follow.

Instead: realize that your sense of urgency and your new hypotheses of what's to be done are coming from new insight. Try to bring the insights to the common table. See what happens.

Show people that you are a safe person who won't start with turning everything upside down just because of a stupid course that they couldn't attend. Show people that you care. Listen to what they are saying. Help them to visualize how they all see the situation, creating a rich picture where everybody can recognize their own view of the problem while at the same time exploring other's. Insert your own view in that picture as one piece of the jigsaw puzzle together with all the rest.

Invite people to explore the situation together with you. State that everything are hypotheses, that you want to investigate, validate the ideas, and that you aren't about to do things, but to try things.

Help everybody to feel competent and valuable. State the common higher purpose you all share, and make sure everybody feel safe and listened to. Visualize and express things clearly. Take the time that the group needs, and seek mutual understanding first and results later.

This will probably feel as if it takes a slightly longer time. But since you increase the chance of making the change actually stick and change the culture permanently, the effects will actually come sooner than if the change is constantly shot down by the collective fears.

And you will also gain peers who are on the same board as you, and the ideas and insights you generate together will probably be far better than those you come up with after just one course with an agile teacher like me who don't know your situation as good as you all do.

Tjänsteperspektivet: Är IT värdefullt?

Som jag konstaterade förut tror jag alltså att dessa tre perspektiv är oerhört viktiga för digitaliseringen av det offentliga Sverige: ett tjänsteperspektiv (vilka mänskliga behov är vi satta att möta oavsett om det sker via en skärm eller ej), ett livscykelperspektiv (hur säkerställer vi nyttohemtagningen kontinuerligt under hela den tid då behovet ska mötas av tjänsten), och ett integrerat synsätt (hur kan vi samverka på bästa sätt löpande för att möta alla dessa behov antingen vi är databasutvecklare, myndighetschefer, kundtjänstmedarbetare, verksjurister, apputvecklare, handläggare, eller webbprogrammerare).

Tjänsteperspektivet innebär att man tar ett samlat grepp om hur man möter en kategori mänskliga behov hos en grupp människor. Det kan vara behovet av snabb bygglovshantering, att all relevant vårdpersonal har omedelbar tillgång till den viktigaste informationen om min vårdhistorik när jag ska bli vårdad, exakt och enkel avrapportering av polisärenden som hjälper utredarna hela vägen fram till antingen lagföring eller avskrivning, krångelfri handläggning av min sjukskrivning eller någonting annat.

Det handlar inte om journalsystem, polisutredningsstödssystem eller ärendehanteringssystem som isolerade företeelser, utan om en hel kedja av händelser och vägval och informationsbehov som innefattar människor och datorer i en salig röra. Och värdet av tjänsten kan inte isoleras till de länkar i kedjan som råkar bestå av mjukvara, utan värdet uppstår i samspelet mellan alla ingående människor och maskiner.

När Ekonomistyrningsverket påpekar att myndigheterna är lite för dåliga på att analysera nyttohemtagningen med sina IT-system tänker jag att det kanske inte är så konstigt. För om värde skapas av samspelet inom en helhet är det ju svårt att mäta värdet av helhetens enskilda delar.

När en företeelse har ett otydligt värde är risken stor att man istället koncentrerar sig på kostnaden. Kan vi göra något åt de stora IT-kostnaderna? Det finns någon uppfattning hos civilministern om att offentlig IT kostar 45 miljarder kronor per år. Och man har gett Ekonomistyrningsverket i uppgift att kartlägga kostnaderna.

Problemet är att utan en uppfattning om värde kan man inte ha någon uppfattning om vad kostnaderna innebär. Och kostnader är omöjliga att styra på isolerat. Du ser inte hur värde skapas i en enskild del (t ex i ett IT-system), dock tror du att du kan se vad delen kostade. Men utan att förstå värdeströmmen kan du inte se vad som händer med värdeskapandet och kostnaderna i hela flödet om du försöker minska kostnaderna för denna del. Försvinner kostnaden eller skyfflas den till någon annan plats i flödet där den kanske förstärks?

De senaste tio åren har det förekommit ett par spektakulära misslyckanden när myndigheter velat ta fram nytt IT-stöd. I samtliga dessa fall har kostnadsfokus varit en bidragande orsak till misslyckandet. Man har sålt in projekten med att de ska bli billigare att förvalta (vilket ofta betyder svårare att vidareutveckla löpande så att de passar de skiftande behoven kontinuerligt), med att de bygger på "standardsystem" (vilket innebär starka inlåsningseffekter och bundenhet till en viss leverantör), och med att själva programmerarna är billiga eftersom de bor i lågkostnadsländer (vilket innebär svårigheter i informationsutbytet och därmed hinder för den kontinuerliga kunskapsframtagningen all systemutveckling består av).

Men även de IT-satsningar med utmaningar som aldrig blir skandaler i pressen lider av det ensidiga kostnadsfokuset. Det handlar om underdimensionerade driftavdelningar som inte förmår att snabbt möta de ändringsbehov som projekten har vilket skapar stora och dyra förseningar, det handlar om att inte tillräckligt många personer från verksamheten ges möjlighet att komma med viktig information för att besvara de frågeställningar som precis uppkommit vilket leder till att systemet antingen blir försenat eller felaktigt eller bägge.

Det handlar också om synen på systemutveckling som en sällanaktivitet, något som är ett undantag i tjänstens livscykeln, något som kan få kosta pengar under ett års tid och sedan skrivas av på fem år. Och under de fem åren menar man sig inte ha råd att arbeta med förändring och möta de behov som börjar uppkomma direkt då det nya systemet har satts i drift.

Med ett tjänsteperspektiv utgår man istället från behoven hos vissa grupper. Man tittar på vilka tjänster man kan skapa som möter behoven, och så designar man tjänsten som ett flöde och ser på vad för slags funktioner som krävs. Vissa av dessa funktioner kan automatiseras, och då börjar man göra det, steg för steg, medan andra behöver utföras av människor, åtminstone så långt vi ser nu. Ändringsbehov fångas kontinuerligt och prioriteras mot varandra, och de ändringar som har störst värde införs i tjänsten.

Oavsett om ändringen innebär att en maskin ska ändra beteende eller att en människa ska göra det. Det finns inget skäl att göra någon grundläggande åtskillnad mellan systemutveckling och annan tjänsteutveckling. Målet är att möta en människas behov.

Jag tror att särskiljandet av IT har historiska skäl. Digitaliseringen betyder att IT tillåts genomsyra allt, och då blir skillnaden skadlig. Istället för att fokusera på kostnaden för vissa verktyg behöver vi fokusera på värdet som vi alla skapar tillsammans, och då erbjuder tjänsteperspektivet en lins att titta igenom.

The Appreciation of a System

It is not the parts you should look at, but their interactions. Observing the parts will not reveal the pattern they create together and can cause you to make faulty assumptions about the performance of the whole. You may also be tempted to influence the parts in ways that isn't helpful when you don't consider the total effect of your influence.

Observing and trying to understand the elements as isolated units is suboptimal if you want to manage the system that they are a part of.

The understanding of what it means to be a system is one of the four pillars of William Deming's System of profound knowledge, a set of insights regarding management in complex environments that even though being more than 30 years old has become increasingly important in the age of digitalization, disruptive innovation, and organizational agility.

Deming made a point by addressing top management and trying to get them to understand the importance of systems thinking. He realized that if the top management didn't get it, they would never be able to create an environment where the performance of the whole was improved. Everyone would be stuck in their compartments making sub optimizations to the detriment of all. And while it is still true that a top management who lacks understanding of system behavior will ruin it, organizational agility also demands that that every person in the collaboration share these insights.

It seems like the human mind has some difficulty grasping aspects of systems behavior. We tend to believe that the outcome directly reflects the behavior of the parts, or the intentions of the people acting in the system. Instead it is perfectly possible and actually quite common that smart and kind people cooperate in ways that makes the system become like it was run by an evil super genius or an infinitely stupid autocrat. We assume that low performance of the system is a function of low performance of its parts and fail to understand why the system actually performs worse when we force the people in it to work harder.

I believe that it is of utmost importance that we all improve in our systems thinking ability, especially if we are in a position where we design performance metrics or tries to govern system behavior. In my work helping organizations to increase their agility I have found that all four parts of doctor Deming's system of profound knowledge are essential for everyone, and that systems thinking is one of the hardest things to teach and learn.

As of now I am creating a course module that will cover the basics. The thing that I find being the most difficult is dividing the insights in easily digestible chunks. It kind of goes with the subject that understanding the parts of it doesn't necessarily help when understanding the whole!

I am really interested in what you think about this. What questions regarding systems thinking would you be interested in? What is it that you feel is the most difficult things to understand about the subject? I would very much appreciate if you would take the time to reflect a bit about that and maybe share some of your thoughts with me.

Vad är en IT-kostnad?

Jag fortsätter funderingarna runt Ekonomistyrningsverkets (ESV) rapport Fördjupat it-kostnadsuppdrag – Delrapport 2: Kartläggning av it-kostnader. ESV tolkar lyckligtvis sitt uppdrag inte som att blott försöka kartlägga "IT-kostnaderna" (en notoriskt svår klassificering) utan "att bidra till en effektiv statsförvaltning genom effektivare användande och tillhandahållande av it." (sid 10) Men som alla läsare av bloggen vet så är det inte genom att titta på kostnader som vi får kontroll över effektiviteten, utan man behöver se på kostnad per nytta i varje enskilt värdeflöde. Här krävs ett bredare tankesätt.

Att det är svårt att isolera IT-kostnader konstaterar rapporten. Det görs inte på ett enhetligt sätt vilket gör att verket inte kan jämföra myndigheterna med varandra. Men frågan är om det alls går att jämföra vad som är en "IT-kostnad" i två olika verksamheter. ESV betraktar som IT-kostnad allt som kan härledas till IT (sid 14). Där beskriver man också hur gränsdragningen kan gå till: utrustning som kommunicerar automatiskt kan räknas som IT, medan kostnaden för en äldre version av samma ting som inte är uppkopplad inte kan bokföras på IT-kontot.

Med den gränsdragningen blir måttet "IT-kostnad" snarare ett mått på hurpass mycket myndigheten berörts av digitaliseringen. I vad mån det berott på egen styrning och i vad mån det berott på att tillverkaren försett de artefakter ens verksamhet använder med en IP-adress framgår inte. IT-kostnaderna springer iväg för den myndigheten, men är det bra eller dåligt? I förhållande till vad springer kostnaden iväg? Vilken blir skillnaden mot förra året och vad kan vi förvänta oss nästa år? Och är min myndighet bättre än din?

Alla vettiga nyckeltal ska man kunna agera effektivt på. Bra coachande frågor för den som funderar på nyckeltal är: "Vad händer om nyckeltalet faller med 50 %? Vad händer om det ökar med 35 %? Hur möjliggör nyckeltalet ett rationellt agerande?" Om svaret är att man inte vet, så är det förmodligen inget nyckeltal värt att lägga tiden på. En ökad IT-kostnad som i den ena myndigheten beror på att de tvingas till dyr refaktorering av koden i misskötta äldre IT-system (hög teknisk skuld som nu måste amorteras) och i den andra myndigheten på att tillverkarna av stödutrustning integrerat sina system så att större delar av dem kan anses vara digitala och i den tredje myndigheten för att man skapat ett effektiv värdeflöde med hög grad av digitalisering, en sådan siffra på kostnaden säger ganska lite. Data är som vanligt i första hand något kvalitativt, inte kvantitativt.

Rapporten konstaterar även detta och är betydligt mer ödmjuk i sina slutsatser runt nyckeltal. Riksrevisionen har enligt rapporten tidigare påstått att ett enhetligt sätt att beräkna IT-kostnader på gör myndigheternas arbete med IT-kostnader effektivare, fast jag misstänker att det framförallt förenklar för Riksrevisionen som då inte behöver sätta sig in i varje myndighets unika situation när de ska granska. Rapportens författare är noga med att påtala att det här arbetet med att förstå IT-kostnader är en process som kräver dialog och att nyckeltalen som föreslås i rapporten inte utan vidare kan användas för jämförelser (sid 32). De formulerar det på ett underbart sätt som jag önskar hade funnits på skärmsläckarna hos varje politiker och myndighetschef:

Nyckeltalen måste dock hanteras ansvarsfullt, och tolkningen och analysen kräver ofta djup verksamhetskunskap och måste utgå från verksamhetens förutsättningar.

Det citatet är en av de få eviga sanningarna här i världen och jag har skrivit en hel del tidigare om nyckeltalens fallgropar.

Frågan om IT-kostnader är helt enkelt en hårig frågeställning. Vad beror det på och hur kan vi göra det mindre hårigt?

Jag tror att svaret är delvis historiskt. "Det där med data" har alltid varit en främmande fågel. Sedan Gustav Vasa och Axel Oxenstierna via Max Weber har förvaltningarna haft en särskild sorts informationslogik som bara bit för bit försökt använda informationsteknik för att replikera denna fast på ett mer "effektivt" sätt. Men informationstekniken har sin egen logik. Webers förvaltningsidéer må bygga på stringenta definitioner av processer, men det är ju ingenting emot datorernas krav på omutlig exakthet i allt. I jämförelse med en dator är den torraste och mest korrekta tjänsteperson ett svamlande hav av känslosamt godtycke. Förvaltningen vill kunna hantera information men datorerna kan bara hantera data, det vill säga information helt berövad varje uns av tolkning och kontextualisering. Datorer kan skyffla runt symboler, och ingenting annat.

Så vi har en särskild sorts logik som kräver en annan sorts kompetenser att bemästra och en annan sorts anläggningsinvesteringar och en annan sorts driftskostnader än vad förvaltningen hade haft utan datorer. Denna nya sorts förutsättningar kontrasterar emot de gamla. Det har gjort det naturligt att dela upp tillvaron i "verksamhet" respektive "IT", där "IT" är "Den Andre" för att tala med Hegel och Husserl. Och hur mycket kostar inte oss "Den Andre"? Hur dyrt blir det med "Den Andres" alla knepiga krav? Bör vi inte hålla koll på det? Särredovisa "det där med data"?

Vad som händer i och med digitaliseringen är att datoriseringens logik blir norm. Det handlar inte längre om körningar som sker mitt i natten en gång i månaden, inläsning eller inknappning av innehållet i ett pappersdokument, eller samtal med en handläggare som tittar i sin terminal för att muntligen kunna återge vad som står där i ett personligt möte med en medborgare. Det handlar om att människor har tillgång till terminalerna dygnet runt i byxfickan, att de förväntar sig smidighet och korrekthet i allt och att fysiska begränsningar ska upplevas som helt borttrollade så länge som det gäller sådant som kan representeras digitalt.

"Transportation is waste" konstaterade Taiichi Ohno på femtiotalet, och pappersblanketter, kontanter, att behöva få tag i en handläggare för att fixa ett rutinärende, väntan på ett beslut om det är en algoritm som fattar beslutet, väntan på beskedet och väntan på en utbetalning: all sådan informationsförflyttning kan ses som onödig efterfrågan, fördyrande tillägg, och en konstlat försvårande process i ljuset av att det ju går att skapa detta sömlöst med hjälp av lättillgängliga digitala hjälpmedel.

Datorerna ska inte komma in från vänster för att effektivisera små bitar av ett förvaltningsflöde som slagits fast på förhand. Informationshantering behöver ses som i första hand digital om vi alls ska få någon god effekt av datorerna. Vi behöver utforma våra värdeflöden utifrån den smidigaste vägen givet dagens verktyg, och inte använda dagens verktyg för att imitera en karikatyr av gårdagens möjligheter.

I ljuset av det blir hela uppdelningen mellan "verksamhet" och "IT", mellan "beställare" och "uförare" skadlig. Det kräver ett omtag. En ny gemensam förståelse av vad syftet med IT-stöd är.

Som tur är finns det beprövade sätt att riva muren, sätt som används redan idag och som har använts i årtionden med goda resultat. Hela familjen av lean och agila metoder och smidig tjänsteförvaltning ger ett strukturerat sätt att åstadkomma precis detta. När vi leder systemutveckling på ett smidigt sätt fokuserar vi på syften, nyttor och effekter istället för på verktyg och att effektivisera det existerande (och ni som var med på digitaliseringsworkshopen i Almedalen 2016 fick höra mig prata om detta).

Vi arbetar med effektkartläggning och med små mätbara experiment i form av förändringar av befintliga tjänster och en fördjupad förståelse av behov och beteenden hos dem som vi försöker betjäna. Det handlar om att ha ett tjänsteperspektiv (vilka mänskliga behov är vi satta att möta oavsett om det sker via en skärm eller ej), ett livscykelperspektiv (hur säkerställer vi nyttohemtagningen kontinuerligt under hela den tid då behovet ska mötas av tjänsten), och ett integrerat synsätt (hur kan vi samverka på bästa sätt löpande för att möta alla dessa behov antingen vi är databasutvecklare, myndighetschefer, kundtjänstmedarbetare, verksjurister, apputvecklare, handläggare, webbprogrammerare).

Att i ljuset av det perspektivet försöka isolera IT-kostnader som en särskild post är förstås lite svårt men absolut inte omöjligt. Dock: är det hjälpsamt? Vad ska vi ha datat till? Det känns litegrann som att försöka särredovisa användningen av skiljetecken i myndighetens skriftliga kommunikation jämfört med användningen av siffror och bokstäver, istället för att titta på effekten av kommunikationen.

(Och en gång i tiden var skiljetecken en ny och konstig innovation som inte alls var integrerad i normalt skrivande.)

Ekonomiskt sett är det förstås nyttohemtagningen per tidsenhet och tusenlapp som är det intressanta nyckeltalet. Det är också den som rapporten från ESV i synnerhet önskar få se mer av. Men då är det också hela värdeflödet som ska mätas. När de effektivaste värdeflödena levereras av djupt integrerade grupper med en mix av kompetenser och verktyg är det verkligen frågan om fokus ska ligga på att försöka särskilja en viss sorts kostnader och försöka sig på att jämföra olika myndigheter med varandra utifrån den aspekten.

Man kan fråga sig: "Vad är en IT-kostnad?". Men kanske är en bättre fråga: "Vad ska jag med den informationen till?"

En reflektion om nyttohemtagning inom IT

"Effekthemtagning", eller som det också kallas: "nyttohemtagning", är ett begrepp som handlar om hur mycket goda effekter man får av en förändring i en verksamhet, till exempel av en tjänst. Man vill ju inte att en tjänst ska finnas till bara för sin egen skull, man vill ju att den ska leda till något man värdesätter.

Inom tjänsteutvecklingen, och i synnerhet inom systemutveckling, har frågan om nyttohemtagning blivit viktigare med åren. Det kostar mycket att genomföra förändringar i tjänster, inte minst i form av ledtider. Får vi rätt effekt av förändringen?

Jag är mycket angelägen om att myndigheter i Sverige ska fungera smidigt. De är bland de viktigaste verksamheterna vi har, och till skillnad från företag kan vi inte bara byta ut dem om de tappar stinget. Myndigheter hanterar ju dessutom ofta ärenden som är särskilt känsliga: ser till att brottslingar grips och vi får leva i trygghet, försvarar vårt oberoende, ger oss sjukersättning, utbildning och annat viktigt. Därför måste vi alla hjälpas åt så att våra myndigheter verkligen fungerar.

När jag har arbetat åt myndigheter med att hjälpa till med att införa agila metoder inom IT-utveckling har jag flera gånger stött på strukturella hinder för att få till smidighet. När jag grävt i det har jag hittat regler och direktiv som på olika sätt försvårar smidighet, fördyrar förändringarna, och minskar chansen att lyckas. Naturligtvis inte med avsikt men systemeffekter av regleringar tar ju inte hänsyn till regelmakarnas goda vilja.

Ekonomistyrningsverket (ESV) granskar och följer upp hur myndigheternas investerinar i IT-stöd genomförs. Det finns inom Myndighetssverige en stark önskan om större smidighet och att man använder digitaliseringens möjligheter bättre, så man är villig att satsa på IT. Men man kan konstatera att effekten av satsningarna inte alltid blir vad man har tänkt sig. Varför? Det är en av de saker som Ekonomistyrningsverket ska ta reda på.

Jag har börjat läsa igenom verkets rapporter nu, och det som slår mig är att det som rapporterna önskar delvis motverkas av precis det som rapporterna föreslår. Inte minst för att det man föreslår förutsätter IT-utveckling som bygger på projektarbete och på uppdelning mellan beställare och utförare. Det kan vara svårt att förklara vad som är problematiskt med andra människors förslag om dessa bygger på en tankemodell som på avgörande punkter helt skiljer sig från den man själv har. Men jag kan ju försöka.

Vi tar ett exempel. I rapporten Fördjupat it-kostnadsuppdrag – Delrapport 2: Kartläggning av it-kostnader finns ett resonemang runt just nyttohemtagning. Man har kartlagt hur stor andel av ett antal myndigheter som har en modell för nyttohemtagning och konstaterar att myndigheter generellt är svaga på detta. Men sedan fortsätter man

ESV anser att det inför projektstart är självklart att göra en kalkyl som även omfattar effekter av eller nyttan med projektet. Det är också självklart att man efter genomfört (it-)projekt säkerställer att den tilltänkta nyttan tas hem. En modell för nyttohemtagning som tillämpas konsekvent i alla projekt säkerställer att de effekter som projektet syftar till faktiskt fokuseras och realiseras.

Ett av skälen till att agila metoder alls finns är att vi i början av något antingen kan bestämma oss för vilka nyttor vi ska sträva emot, eller så bestämmer vi oss för vilken lösning vi ska ha, men vi kan aldrig garantera bägge. Det beror på att vi saknar kunskapen.i början. Vi står inte helt handfallna utan oftast brukar vi kunna skapa mer eller mindre välgrundade hypoteser. Men så bra kunskap att vi kan prognosticera vilken effekt en viss lösning kommer att få, det har vi inte. Inte ens efter en förstudie. Särskilt inte om det finns organisationspolitiska skäl att genomföra projektet,då kommer tillräckligt många att helt enkelt anta goda effekter. Kalkyler är väldigt enkla att utföra när man saknar data. Och prognoserna kan bara verifieras i efterhand.

Så vi kan bestämma oss för vilka effektmål vi vill uppnå, och vi kan utforma den initiala idén om lösningen i den riktningen, men vi kan inte se in i framtiden.

Den andra meningen får mig också att fundera: "Det är också självklart att man efter genomfört (it-)projekt säkerställer att den tilltänkta nyttan tas hem." Men efter ett genomfört projekt kan man inte säkerställa någonting alls. Då sitter man med det man fick i knäet. Förhoppningsvis kan det vara till nytta för någon, men det går liksom inte att göra om alla de vägval som gjorts under resans gång.

Om man läser den tredje meningen så att den syftar på att arbetet ska bedrivas på ett sådant sätt att vi löpande siktar mot effektmålen under hela utvecklingen, då går det att genomföra. Det är under resans gång man når insikt om vad som faktiskt hjälper oss att uppnå målen. Inte innan, och efteråt är det för sent.

Men för att förverkliga det behöver å andra sidan myndigheterna ge upp projekten (som flera myndigheter lyckligtvis är inne på att göra). Samtliga projektmodeller jag sett som faktiskt används bygger på idén att lösningen ska vara detaljerad på ett mycket tidigt stadium, och sedan styr man mot den fastslagna lösningen i enlighet med den på förhand utlagda planen. I många beställar/utförarmodeller försöker man dessutom aktivt förhindra nya insikter genom att strypa kommunikationen mellan beställare och utförare så att inte den ursprungliga idén (som togs fram när kunskapsnivån var som lägst) hotas.

Agila arbetssätt bygger istället på löpande omplanering och omdesign. Vi vet vilka effektmål vi ska styra på, och utifrån det kan vi designa en minimal lösning som vi förmodar leder till dessa. Den hypotesen prövas och kunskaperna vi får fram matas in i nästa iteration och så vidare. Planerings- och budgeteringstekniker anpassade för arbetssättet ser till att effekten per krona blir optimal i varje stund. Löpande effektkartläggning och andra tekniker ser till att vi filtrerar fram de bästa hypoteserna att bygga vidare på.

Mjukvara är kodifierad kunskap. Kunskap tas fram successivt i samspel mellan de som har pusselbitarna (verksamhet, IT, medborgarna). All erfarenhet av systemutveckling sedan 60-talet har pekat på att tätt samarbete mellan beställare och utförare där man tar fram lösningar löpande är det som snabbast och billigast tar en till målet. Det är det som måste vara vår mentala modell för hur systemutveckling ska bedrivas om vi verkligen vill säkerställa nyttohemtagning.

Do-be-do-be-do: Do and become!

"Agile" are so many things. From an outsider's perspective it is what some organizations and other collaborations are: They respond quickly as the society changes, they are fast to sense people's needs and invent a way of meeting them, and they seem to learn and evolve continuously. Together. Like a super-competent individual with a thousand arms and legs and eyes and ears and mouths.

So agile is definitely something you, as a group of people, can be together.

You get curious. You wonder what magic that lies behind all this. So you walk closer and tries to find things that you can imitate and copy. And you really see a lot of things.

People working in groups. Moving stickers on a wall. Organizing their decision making in a certain way. Handling budgets and projects in ways that you may be unaccustomed to, even removing them altogether and still maintain control. And you read descriptions of collections of things that you can do in your organization: SAFe, Scrum, XP, LeSS, DaD...

It seems like agile is something you can do.

So you tell people that this is what they should do. Do like this. Use this template. Standardize on this agile method. And you track them to see if they are doing as they are told.

But you notice that not all groups in the organization get the same result out of the things they do. Some seem to "get" it, and some don't. And among the groups that don't get it you see groups where they have deviated from the things you told them. So you correct them. No wonder you don't get the right results if people don't do as they are told!

But among the groups that seem to get it there are also groups that deviate from the method as it has been presented to them. They can even present even better result than groups that follow the method. So it seems like the magic doesn't reside within the methods, even if the methods play a crucial role for enabling agility.

The answer is that agile also is something that you think, feel and value. It is a mindset and a set of values. When we apply the methods, we uncover hidden things in our collaboration that blocks agility. The wisdom lies in seeing this when it happens and selecting the right tool from the toolboxes to handle it with.

That wisdom comes from an agile mindset and agile values. The groups that eventually develops agility from experimenting with agile methods all share a set of foundational values. The others typically don't.

As Simon Powers points out: the mindset is not easily seen, but it is definitely the factor that brings the most effect to your path to agility. It has the least visibility but the largest power.

So you can definitely become agile by doing agile, but it will not happen unless you also nurture the values so you start to think agile. That will bring understanding to the practice, and wisdom for people to select those agile tools that will benefit the whole.

When "doing agile": focus on effect!

So, we have an organization that works somewhat agile in places, maybe having a pretty decent level of agility in certain teams. We have a wish for more agility for the whole. Someone or something has led us to look at frameworks of methods that seem to be designed for creating agility in collaborations involving many persons, such as SAFe. Should we blindly progress and implement the collaboration techniques from the framework?

I suggest that we don't. While the techniques from SAFe or any other of the more known frameworks are all tested and tried ways of working that can do wonders, they are often presented as prescriptions with a general applicability, making silent assumptions about preconditions that might not hold true in our particular situation.

Each collaboration technique has a purpose. You want to see an organizational effect when doing things like a two days collaborative planning of 8-12 weeks of work for a group of teams (called "PI planning" in SAFe), or enforcing forecasting based on relative-size estimation with "ideal days" as the common unit, or any other technique. The thing is that it is the effect that in the end will give you more or less agility, not the behavior.

Think about it: is it possible for a group of people to behave in a certain way without achieving the effect? Absolutely. There may be situational factors that makes the behavior lead to other effects than what is anticipated.

Is it possible to attain the effect in more ways than through a certain behavior? Absolutely. And for certain situations, the current behavior may be a better way to achieve the effect than any other proposed alternative.

So it is possible to destroy something that works by enforcing a new behavior? Yes, and if the effect is already present it is unnecessary. We want organizational agility, not compliance.

So what I very much would like to see from any writer of material that tries to collect agile collaboration methods (myself included) is a lot more focus on what organizational effects you would like to see, what the preconditions are for the techniques to work as intended, how to assess the current situation, and how to apply the techniques in a safe way that don't break what is already working.

Basically, this is what we agile coaches do. And when talking to the people behind the frameworks you often notice that they have a very sensible approach to their own frameworks, both in terms of limitations and preconditions.

But that attitude isn't helpful when the specific wording of the framework is commanding and unconditional. The creator of the framework has the knowledge and expertise. People in organizations that need improvement in their collaborations are on the other hand insecure. There will be a bias towards doing exactly as it is written, and pointing out that there might be reasons to be careful with a certain technique in a certain situation will be met with suspicion. "The framework clearly states that it is necessary that we..."

The book Extreme Programming Explained is the star here. Kent Beck reasons about how and when the different techniques work, and gives a lot of examples on how to apply them in order to achieve the desired effect.

I believe that we would gain more from all frameworks and techniques if they presented themselves using that approach.

Flow is the general concept

One thing I often hear when I talk about creating effective service delivery or development and mentions its root in the Toyota Production System is that it would be a bad thing to use insights from manufacturing in other domains. There seems to be a fear that using ways of thinking from a production system automatically will make one treat everything and everyone as things to produce or cogs in a machinery. Seldom that criticism comes from people who has knowledge of what the thinking from Toyota actually says, though.

While it is true that some of the techniques that Toyota invented in the 50s and the 60s are only applicable in a manufacturing context, most of them are about general human concepts such as leadership, human collaboration, improvement of quality, and last but not least: flow.

Value is about meeting human needs. A value stream is what we call the organisation around the sum of all things that is done to capture and understand that need, and to finally meet it with a delivery of some sort. A smooth and fast slow is what we aim for since that would increase the value output per time unit.

Henry Ford optimized for flow when he designed the Highland Park factory that opened in 1912. Frederick Winslow Taylor optimized for flow when he wrote The Principles of Scientific Management in 1911. But even if the methods these persons enforced to increase flow such as predefined work divided into repetitive moments isn't suitable in any context outside of manufacturing (and maybe not even there), the aim for a steady output of value was not wrong but something that increased the income so much that they could pay the workers way more than the workers in other factories.

Flow has always been a core factor in successful service delivery: how do we handle a huge variation in demand and still provide adequate value to recipients? And what is true for service delivery tends to be true for product and service development as well. The Wright brothers solved the problems of creating a propelled heavier-than-air flying machine by a steady series of many experiments, and so has effective development work been conducted ever since, including within Toyota.

Lean thinking has from the beginning been about general concepts such as mathematical facts about collaboration systems in general and psychological facts about the human nature. The two pillars of lean is the continuous improvement of the flow, and respect for the fact that we people are as we are. William Deming's system of profound knowledge is based on the same two fundaments: flow (understanding systems and variation), and psychology (understanding knowledge and the human mind and behaviour).

If you are interested in general lean concepts I recommend This Is Lean, The Machine That Changed The World, Gemba Walks, Lean Thinking, and Toyota Kata. If you are interested in lean service delivery I recommend that you look at Vanguard by John Seddon. And if you want to implement lean thinking in knowledge work, I recommend that you check out Lean Software Development by Mary and Tom Poppendieck. For a thorough walkthrough of several economic principles that apply to product development using lean thinking, I recommend Flow by Don Reinertsen.

It s all about flow, not about factories and manufacturing.

How long should I have to wait?

After being asked to explain why I and others don't believe that a project is the best way to organize development of services that involves digital assets, I thought that I should try to do that. But I am not interested in bashing projects, but explain what requirements digital service development has on its control structure.

What would a reasonable control structure for development of digital services, a "project method" if you want to call it that, look like?

Services are about meeting human needs, and the question we have is how we can organize a collaboration, a system of people, to be able to meet those needs. As anyone who has had a need knows, one of the most important metric in service delivery from a recipient point of view is the "cycle time": How long should I have to wait from the moment someone has discovered my need until it is either met or rejected?

There are other metrics that are important as well, but the cycle time is special since it both has a strong economic impact and is an indicator of many other things in the system. The value of a delivered service can be translated into a cost of not having it delivered, a cost of delay, so it is fair to say that a suitable project method need to make it possible to optimize for short cycle times.

There are luckily a lot of ways discovered how to reduce cycle time, many that have been discovered by japanese industries in the 50s and 60s. One of the most important ways is to reduce the batch size of everything. Small work packages will flow faster through the system, while large batches increase the variation within the system and cause the system to underperform. So the project method should be able to handle several small batches of changes to the service in parallel rather than focusing on larger change.

The value is created when we meet human needs. It is not created when we spend time on activities. Activities are costs, while meeting needs is valuable. What activities that in the end will lead to value creation is something that unfolds during development of a service. It is impossible to say in a complex environment that we now know what sequence of activities that will lead to value creation in the end. We can guess, and at some point in time create a plan out of our guesswork, but the risk is high that the sequence of activities in our plan needs to be modified as more information unfolds during execution.

So what we need is a project method that allows for continuous replanning of the needed activities. The method needs to keep track how far we are from the goal of value creation, allow for continuous discovery of the best path to the goal, and helping the particiants in doing constant evaluation, discovery of needs and paths, and creation of new plans and forecasts, in a coordinated way.

Good coordination between people is hard to achieve. It takes time. Luckily, while the different changes we want to implement in our service really are separate pieces of work, the very domain where the value creation takes place stays the same. So it is possible to form stable collaborations of people who knows the domain both in a business sense and in a technical sense, and help them making their joint work effective. So the project method needs to support stable organizations and avoid temporary ones.

The discovery of needs within a domain often has a pretty stable rate. Especially when you are going digital. Most services need continuous development in order to stay fit for purpose and be competitive, so there is really no end state here. We will probably always find new needs to meet and will always need to find new ways of meeting them. So the project method should be able to go on forever. Managing constant funding and value generation.

Now, constant work in a constant organization doing continuous small batches of changes in order to meet a need in an exploratory fashion isn't what most project methods are designed for. There is in fact already a name for what I have described here: service life cycle management around value streams. That is a model for development that suits digitalization pretty well and gives the business the agility to experiment with fast feedback loops.

I don't suggest that we abandon projects, but that we realize that they are best suited for large changes that requires a temporary organization and where we actually can create those detailed project plans (often broken down into who should do what activities and exactly when) that the project methods prescribe. For going digital, I instead suggest what I have mentioned above.

First Draft of Module: Psychological Needs

I finally finished the first version of the module on psychological needs. This is a module that has grown out of the segment on group development in the Scrum Master course and when I coach agile coaches. I have turned more and more into describing the individual psychological factors that affects us when we try to grow together as a group.

This module explores some basic facts about the human need to feel safe, free, and good (doing good and being good at it); both alone and within a group. It presents a couple of simple models that helps us navigate our understanding of how we work on the inside. No infographics yet, but I am sure that I will create some in time.

What do you think? Read it here: documentation-psychological-needs.pdf

Kostnads-"paradoxen"

Den amerikanske leanpionjären, kvalitetsgurun och ledningstänkaren William Deming formulerade sig gång på gång ungefär så här:

Om du fokuserar på kostnadssänkningar så kommer kostnaderna att öka. Om du fokuserar på kvalitetsförbättringar så kommer kostnaderna att sjunka.

Det här kan upplevas som kontraintuitivt och paradoxalt av dem som lärt sig att låg kostnad och kvalitet är två kommunicerande kärl. Tron är ofta att ju mer man satsar på kvalitet desto dyrare blir produkten, och vice versa.

Men det är inte Demings ord som är paradoxala. Det är folks intuition runt kostnad och kvalitet som ofta är fel.

När folk försöker styra verksamheter på toppnivå med hjälp av numeriska utfall är risken oerhört stor att de misslyckas. Det är för att den verkliga relationen mellan siffrorna i flera fall är okänd. Och om man har låg förståelse för den egna strukturen, hur den egna organisationen faktiskt fungerar och skapar värde, så kan man inte använda siffrorna på något produktivt sätt i sitt beslutsfattande. Man saknar förmåga att agera bra på dem.

Det är därför som grunden i metodiskt kvalitetsarbete, som Deming lärde ut till japanska bolag efter Andra världskriget och som blev ett fundament för det vi idag kallar "lean", handlar om att få en strukturell förståelse för det egna systemet. Innan vi förstår hur värde skapas så är alla frågor om hur mycket? värdelösa.

Det finns i princip två sätt att minska kostnaden per skapad värdefullhet (produkt eller tjänstetillfälle eller vad det nu är för ett värde ni skapar):

1. Försök skapa lika många värdefullheter till en mindre totalkostnad.
2. Försök skapa fler värdefullheter till samma totalkostnad.

I alldeles för många kalkylark framställs dessa två alternativ som likvärdiga: priset per värdefullhet sjunker. Men medan det är svårt och riskabelt att försöka sig på det första alternativet (sänka kostnader) så är den ökade produktiviteten ofta enklare att åstadkomma snabbare. Kostnads"paradoxen" igen! Vad kommer det sig att jag inte fritt kan välja strategi 1) eller strategi 2)?

Svaret ligger i hur värde faktiskt skapas, strukturellt. Om värde skapas på ett enkelt sätt, kanske av enstaka individer som kräver få interaktioner med varandra eller med maskiner för att kunna möta ett mänskligt behov, då är förhållandet mellan kostnad och värde lättöverskådligt. Slutar folk sjunker både kostnad och produktionsvolym.

Men få värdeskapanden är linjära. Värde skapas ofta i komplexa samspel, och ju mer kostnadseffektivisering vi utsatt dem för desto komplexare är de. Inte sällan även mycket känsliga för variation.

Om ett samspel inte utsätts för mer variation än det kan hantera så kommer samspelet att nå ett naturligt optimum där det skapar värde i en stabil och uthållig takt. Om systemet inte är hundraprocentigt utjämnat så kommer man att se bubblor av "överkapacitet" på sina ställen. Det kan vara en vilopaus, ett extra lager med grejer, en administratör som gör enkla administrativa sysslor och så vidare. För den som saknar förståelse för systemet ser dessa bubblor ut som effektiviseringsmöjligheter. Och det är här problemen börjar.

Ibland är det verkligen effektiviseringsmöjligheter. Men ofta så är det det inte fråga om någon egentlig överkapacitet utan en vital del i systemet som hanterar svängningar och gör att utflödet kan ligga stabilt. Bara om man följer den felaktiga intutionen att systemets effektivitet är summan av effektiviteten i dess delar så är man säker på att lokal överkapacitet alltid är del i den globala överkapaciteten och kan tas bort. Det inledande kapitlet i "Detta är lean" förklarar det här utmärkt, eller så googlar ni efter "Niklas Modig effektivitetsparadoxen".

Men oavsett om den observerade överkapaciteten verkligen är en överkapacitet eller inte, så kommer själva reduktionen, själva akten att ta bort den, att påverka samspelet negativt. Det blir ett avbrott. Samspelet måste omorientera sig. Vi får ett produktivitetstapp. Kanske återhämtar vi oss, men det är inte säkert.

De varianser som "överkapaciteten" buffrade för kommer att dyka upp på andra ställen, ofta förstärkta om vi inte observerat dem och planerat hantera dem. Och då orsakar de extra oförutsedda kostnader, förutom att de kan minska produktiviteten genom att blockera värdeskapandet, och därmed öka kostnaden per enhet kraftigt. Den här effekten förstärks ofta av att samma oförstånd som dragit igång "besparingen" i det här läget drabbas av panik när det inte gått som man tänkt sig och därför börjar göra mer av samma slags destruktiva åtgärder.

Det är sådana scenarion som inspirerat till talesättet: fokusera på kostadssänkningar och din kostnad kommer att öka. Kostnadssänkningar tar i sig inte hänsyn till systemet. De är ofta lokala, men systemet har ju en global effektivitet som kommer att påverkas.

Strategi 2) fungerar bättre på grund av den förbättringsprocess man behöver införa för att genomdriva den. Ska man inom en befintlig struktur med kända ramar hitta mer effektivt värdeskapande behöver man se vari värdeskapandet består så att man kan rensa bort allt onödigt. En av onödigheterna är defekter som beror på "bristande kvalitet" (eller som vi säger: okontrollerad variation). Det är så som metodisk strävan efter bättre kvalitet inom givna kostnadsramar driver den systemiska förbättringen av produktiviteten som Deming pratar om.

Och sanningen är att den som väljer strategi 1) - införa resursminskning på flera ställen i samspelet, också måste ta till strategi 2) - produktivitetsökning inom givna ramar, för att lyckas. Besparingsåtgärden åsamkar skada på den befintliga strukturen. För att kunna komma igen krävs att man hittar tillbaks till värdeskapandet och sedan också förbättrar.

Det är här som många tar miste. De tror att strategi 1) och 2) är likvärdiga, och förstår inte att det är strategi 2) som åstadkommer själva förbättringen. Strategi 1) är ingen strategi, det är bara att bestämma sig för inom vilken ram förbättringen ska ske. Förbättringen som sådan måste komma till, annars går det inte.

Så alla måste till sist välja strategi 2) ändå. Och då gör många nästa misstag: att man inte förstår att i ett komplext samspel är det personerna som befinner sig på golvet närmast värdeskapandet som har bäst förmåga att förbättra det, om de ges verktygen och förutsättningarna. Att ge "golvet makten" fungerar inte, men att ge golvet verktygen och makten, det fungerar. Mycket bra till och med. Där finns hela verktygslådan från lean och agila metoder att ta till.

Men ofta krävs det att alla i ledande ställning först och främst förstår att den här kostnads-"paradoxen" inte är någon paradox, utan att deras fokus bör vara att ständigt förbättra värdeskapandet inom organisationen, så snart man har bestämt sig för vilken kostnadskostym som verkar vara rimlig att agera inom.

ASLA - The Domain and The Stewards

In order to support flow and effectiveness, people in the different functions need to have a common understanding of what the collaboration do and why it does it. No matter if you are operating the service or designing changes in it, you need to see things in about the same way.

This can be done by looking at the domain.

The domain is the arena where all of the services that your collaboration provides play out. It is like a stage in a play. There are characters (user and providers of the service) that have needs and wants and direction, and there are certain limits that everybody relates to.

In practice, the collaboration can and should form a group, a Steward Function, consisting of people that can represent all relevant aspects of the collaboration's services: market needs, business needs, technical needs et cetera. The Steward Function takes full responsibility for

• The full life cycle
• of all of the collaboration's services

Therefore, it is the responsibility of the Steward Function to maintain the domain: decide what facts about it that should be considered canonical and continuously incorporate new insights about the needs and how the collaboration should try to meet.

The domain can be maintained in a number of ways, but a common form is for the Steward Function to be the owner of a set of documents that tries to describe the domain in a clear and relevant way. The documents may vary but often includes:

• A persona gallery that describes key user groups and stakeholders. Also anti-personas: the groups we are NOT designing the service for.
• An information model with a domain dictionary that models the key terms and definitions together with their relationships, cardinalities, and main attributes.
• A list of important business rules that affects the behaviour in the domain.
• Descriptions of the main ways for the personas to create value: important flows and journeys.

New ways of modeling domains are being invented all the time and the Steward Function explores what they feel should be the best way for them to maintain it.

ALMA - Sponsorship

We have an intuitive notion about leadership and dominance that affects how organizations traditionally have been governed. While coordination is necessary when many people want to be productive together, relying on our primitive intuitions are in many cases not the most effective way. The issue of governance and management need to be addressed in a more thoughtful manner.

In ALMA we regard governance and management just as a bunch of Capabilities (realized by Processes). Since the Capabilities needed for good governance have a special impact when it comes to the design and the performance of the organization, we consider them with extra care and group them under the overarching theme of sponsorship.

Under the umbrella of sponsorship we group all Capabilities (and Processes) that provides

Direction — Saying that we should meet the needs of people is a no-brainer. Saying what needs to meet is something that requires a thoughtful decision. Pointing out the purpose of the collaboration and in what direction everyone should go is part of the sponsorship.

Prioritization — If you are experiencing conflicting priorities, for instance if you have encountered a bottleneck in the organization's ability to deliver, you need clear direction on how to prioritize. Either directly where you bring up the issue to a board or an individual, or indirectly via rules - general or more specific - that you can rely on.

Approval — If you aren't sure that an agreement is within the line of what the organization needs, or if you feel that an agreement between parties isn't being upheld, you need to escalate this to someone who can take a look at the whole and decide what to do, from a holistic point of view.

Resource allocation — In order to do something you need tools, time, and friends. In an organization, these three have a cost (at least the cost of not being used elsewhere), so there is a need for a mechanism that can make these kind of allocation decisions in a fruitful way.

The responsibility of the Functions that provides sponsorship Capabilities is to guarantee that what they do is in line with the purpose and limits of the whole organization. Functions that provides sponsorship Capabilities should be aware that when they are needed, they are needed quickly because something that no one else can solve is currently blocking the value creation. This is why many lean and agile organizations tries to distribute the sponsorship Capabilities to many Functions by extensive delegation. It is also why many of them also have instituted rules that states that no issue can be lying unsolved more than 24-48 hours before it is escalated to the next higher hierarchical level.

A common way of organizing this in effective operations that handle life-and-death situations (like in the military or at hospitals) is to always have an appointed person in charge of sponsorship decisions at all times, and make sure that this person has the necessary backup when needed.

Remember that no matter if you are a private or public company, or if you are a governmental or non-governmental non-profit, there is always an underlying power structure! Things and time are owned by people, as individuals or in a collaboration, and law-makers have connected certain responsibilities and rights to this ownership. ALMA opens up for delegation, collective decision making, and other forms of distributed responsibility. Note that this is done in order to create effective power structures, not to ignore the issue of power!

A "manager" in a more traditional sense would be a Function consisting of a single individual who are responsible of providing all these sponsorship Capabilities. It is an observation that in a complex environment the burden of all the sponsorship responsibilities is too heavy for a single individual to carry. The processes need expertise knowledge in many areas. By regarding them as Capabilities that can be provided by many Functions, where each Function is made uf of many individuals, ALMA opens up for the possibility to create a more effective leadership that won't burn out people.

There are reasons to abandon the concept of "managers", but management will always be needed!

ALMA - Services, Functions, Processes and Capabilities

The distinction between services, functions, capabilities and processes is borrowed into ALMA from other service management frameworks, but with an agile and lean twist. The insight that capabilities of the different collaborations in the organization are central are borrowed from the emergent practices of capability mapping and agile enterprise architecture.

A Service is something that a person would happily use if we were to offer it on its own. "Fork Delivery" could be a Service on its own, but in the context of a lunch restaurant people wouldn't be happy if they didn't also get the plate, the food, spoons and knives and chop sticks when needed, and so on. "Fork Delivery" is therefore more likely a part of the Service "Lunch Delivery", and not something valuable on its own. A Service meets a human need all the way from the notion of the need to delivery.

A Process is the actual way of providing the part of a Service. When we perform our Processes and measure them and design improvements for them, it is important that we consider the whole Service and the human need it is supposed to meet. Else we run into a huge risk for sub-optimization which breaks the principle of flow.

A Capability is what a part of an organization needs to have in order to provide their part of the Service. It is distinct from Processes in that a Process defines exactly how a part of a Service should be done. But defining a Service in terms of exactly how it is delivered will be against the root principle of improvement. We need to be able to investigate different ways of providing a Service, and as long as we provide the needed Capability, we should be free to experiment how to do it.

"Fork Delivery" would be a Capability needed to provide the Service "Lunch Delivery", and we can experiment how to optimize the fork delivery in numerous ways. The larger investigation whether we actually need forks at all must also be possible to do in the name of improvement, but that would require that many more people would be involved in the experiment. In the small, within the limits of a Capability, people should be free to experiment without having to ask.

A Function is an organizational entity: a group of people who work together performing one or more Processes. An individual can be a part of several Functions but be aware that this can lead to priority conflicts within the individual, unevenness in their work, and overburden. People need to have a home. It is better for one person to belong to a single Function.

A Function can be represented in another Function. People from one Function then participates in the other Function's work. This is great for Sponsorship Functions (management and governance) where limited resources have to be distributed and priorities be made. By forming the governance Function by asking the Functions that are closer to the gemba for representatives, we ensure that the decisions made by the Sponsorship function is more in line with reality (the principle of empiricism at work).

By handling governance in this way we also combat the misconception of the organization as a hierarchy and lower the risk that it will be misused as an arena for persons to play games of political power. There is a power structure in place that should be recognized and designed in an effective way, but the presence of a power structure doesn't mean that forming hierarchies is a good way of governing it.

A Function may handle one or many Processes. A Service may be delivered by using only one Capacity, performing only one Process. But it is more common that the Service will require many Capablities, and therefore potentially many Functions in collaboration. They really must cooperate well in both designing and operating the Service, defining the Capabilities and their interaction.

It is often efficient when a Service is delivered by Capabilities and Processes that all can be performed within one Function. The Function can then experiment with improving the whole Service. It is resilient if many Functions can deliver the same Service in parallel so that more needs can be met faster. It is seldom efficient but brittle if a Function consists of only one person. Dependency on single individuals make the organization vulnerable. People need to have peers.

ALMA -The Core Principles

The core principles of ALMA are

Sustainability. As long as a service is useful it should sustain. That means that everybody involved in the service needs to continuously improve its sustainability. This includes being sustainable environmentally, mechanically, economically, and humane in respecting the limits of people. This combats the disease of overburden (muri), which is a source of much waste but often disguised as value ("Come on, of course you can push it a little harder!").

Flow. Smooth out unevenness, batches, variations, waiting, where it can be done without breaking the first principle. Unnecessary variation that can be removed without making the service less valuable should be removed by clever inventions. Variation that is caused by the inherent variability in the human nature shouldn't be removed but handled, by clever inventions. This combats the disease of unevenness (mura).

Effectiveness. Do the right thing. Don't do the wrong thing or the useless thing. Don't try to make more of what is not the right thing. What is good enough for now and safe enough to try? Do that and proceed. This combats the disease of wasteful actions (muda). Remove waste, but not so that you introduce unnecessary unevenness or overburden.

These three principles will result in a truly efficient flow, but efficiency is not a core principle of ASLA. This is because when you aim for efficiency, you often fall in the trap of suboptimization by trying to maximize resource utilization in all parts of the flow. This causes overburden on people and tools, work waiting in queues which is a terrible waste, overproduction in parts of the flow which makes other parts of the flow instable, and in numerous other ways worsening the output while increasing the cost per item.

In order to sustain an effective flow, you need to build upon the foundation of the gemba, the floor, the place where value is created and waste is discovered and removed. The foundation is created as we saw in the section about the gemba from two other principles:

Transparency. Overburden, unevenness, and waste always hides. By making things visible, we enable action built upon empiricism (real data and true understanding), and so supports

Empowerment. It is the people who are doing the work that should decide on how the work is done. This means that they need to be enabled, not only by transparency, but also by given the tools and abilities to act in a fruitful way, and given the permission to do so.

So: try to improve the flow in a sustainable way by looking at the whole, work together with who you are and what you have got, stop doing what is not valuable, and respect the principle of the gemba: make everything transparent and empower people to act for the better upon what they see.

ALMA - Gemba World View

The Agile Lifecycle Management Anatomy borrows an important concept from the thinking behind effective management in Japan: The primary point of view should be the view from the gemba. "Gemba" is a Japanese word that means something along the lines of "the place where the action is". A TV reporter from a crime scene would say: "I am standing here right at the gemba...", and when Toyota's Taiichi Ohno went down to the factory floor to see for himself what was actually happening, he would say: "Let's go to the gemba!"

The "gemba" is the place where the value is created. Everything important in the organization depends on what happens on the gemba. This world view has some implications:

Transparency - Everyone needs to see reality as it is. This trumps people's wish for controlling information in their part of the organization (unless secrecy is motivated by the work where it must be clearly stated and regulated by transparent principles). Transparency is the nervous system of the organization, and must be supported by the tools and the ways of working. This enables all decisions being made based on empiricism: data and validated hypotheses.

Empowerment - If the value is created on the gemba it is important that the people working closest to the value creation are empowered to also control it. Like in all collaborations, the control is always bounded: the direction you as an organization is heading must be agreed upon, and you must know the limits for what you can do without asking anybody else.

You need mandate in order to be empowered. But you also need the resources: time, tools, and abilities (which can be provided to you by friends). Without the resources it is not possible to do anything useful of your mandate. Everybody in the organization needs to be embedded in a governance structure that can provide guidance on direction and limits, as well as the time and the tools and the other resources. This governance structure can be flat or hierarchical, based on individuals or on teams, and delegate much or little decision power.

Experience has shown that hierarchies based on individuals that perform top-down management is superior to having no management, but that flat team-based organizations where people have a lot of decision power is superior to top-down hierarchical management when there is competence to act in that environment.

An agile environment often falls somewhere in between while aiming to continuously become more team based, flat and empowered.

ALMA - Core Processes

Borrowing from a popular framework for managing IT services, ALMA defines three core processes:

Operation, which is when we deliver the service.

Design, which is when we think about how the service should evolve in order to meet human needs better.

Transition, which is when we make the new design become the new normal.

Each of these processes has their own focuses:

Operation is about consistency within the limits the service is designed for. Manufacturing operation often try to minimize variation in order to produce consistent products. Personal assistants often try to maximize the ability to handle variation in order to meet different needs. Most operations are somewhere in between. We try to optimize the allowed variation. The thing is that everyone involved in a service should know what they provide and under what conditions, and what to do when the the conditions doesn't apply such as when the limits of acceptable variation are violated.

Design is about being sensitive about needs not currently met properly by the service, and inventive about possibilities to meet those needs. This is an ongoing process that involves everyone. The collection of ideas and the possibility to try them out should be built into the daily operations process.

Transition is about being gentle when changing. We avoid scary big bang changes and instead aim for continuous evolution. Services are constructed by different kinds of parts: humans in functions, digital components, infrastructure, facilities, other assets etc, and each part requires a certain kind of care when changing.

There are other processes as well, but these three are the main ones and many of the tools and techniques in ALMA are meant to be used within one of them.

ALMA - The Service Perspective

ALMA is not centered around projects. Not even around products. In ALMA the focus is around services. What is a service? A famous IT service model defines a service as:

a means of delivering value to customers
by facilitating outcomes customers want to achieve
without the ownership of specific costs and risks

A core assumption in ALMA is that anything worth doing in organizations can be seen as either providing a service or making an existing service better. This is in line with this definition of what a service is. Let's have a look at some central themes:

Delivering value. If we are not generating value, the effort is worthless. Value is about meeting human needs. The human can be a paying customer, or otherwise in the position of receiving the great things we provide. The service perspective is equally valid whether we work in a private enterprise or are parts of a non-profit or an organization within the public sector or the government.

Facilitating outcomes. In order to be valuable you need to make a difference. Being just a hand in the middle is waste. We contribute by facilitating outcomes, that is making a certain outcome more probable than otherwise. We matter!

Without the ownership. We own the service. The receiver of our delivery may or may not own the result of our service. But even if we are creating and delivering physical products, what we provide (product development, manufacturing, and shipment) are services to the customer who doesn't have to take the risk of development and manufacturing themselves. They may own the result, but our organization owns the process.

This service perspective, focused on meeting human needs, is crucial for making ALMA work. Everybody needs to lift their eyes and focus on the purpose of why we collaborate. This little meditation may help:

Instead of work, think project. It is not about the effort but about the outcome.

Instead of project, think product. Projects are temporary, we need to focus on continuity.

Instead of product, think service. Products are just, at best, containers of value.

Instead of service, think needs. Our service may shift, but meeting needs is the eternal purpose.

ALMA - Agile Lifecycle Management Anatomy

So, I will try to collect and present what has been written by me here on the blog and elsewhere on how to achieve organizational agility by practicing agile life-cycle management of services and products. An agile organization is like a fit body, and here is a description of its anatomy.

The anatomy points at a structure. There are certain functions you need to have in place in order to make the body move, and it might be that your current organization need to adjust a bit in order to make it work, but it is not an organizational chart per se. You can make it work in a lot of different organizational structures.

The anatomy is founded on a certain set of lean and agile values and principles. Body structure is one thing, it is how you decide to move the body that will make it fit. And decisions on action comes from what you, as a group, value and what guiding principles you are used to.

Organizational agility has during history been improved in lots of environments, using many different techniques. Some of the techniques are very domain specific, such as extreme reducing of variation in a manufacturing environment, while others, such as self organized teams, can be applied almost anywhere. Agile life-cycle management is therefore not one single set of techniques, but rather a toolbox, used within a context of agile thinking around value, service, and product. The anatomy and the values and principles gives the people guidance on when and where one should use a particular tool.

I would like to describe how to make this work, and I hope that you can find guidance on how to transform a bit of your world into becoming more agile.

En svensk agil pionjär ur tiden

De agila metoderna som växte fram under nittiotalet kom inte med något nytt, utan var i mångt och mycket destillat av goda idéer från förr. Att iterativ utveckling var det rätta för datorsystem visste man redan 1968 och vikten av medarbetardriven ständig förbättring lärde man sig av Toyotas 50- och 60-tal. Från denna tid härstammar också insikten om att i många yrken, och särskilt då i serviceyrken, är det viktigt för kvaliteten att den som är närmast golvet också har stor frihet i arbetets utformning. Att låsa fast servicepersonal i trånga riktlinjer och förbud att improvisera gör bara att jag som kund får ett sämre bemötande.

I Sverige har vi haft två företagsledare som blivit världsberömda på att delegera mycket makt ner till golven. Naturligtvis Jan Carlzon på SAS vars bok "Riv pyramiderna!" från 80-talet fortfarande används som lärobok i chefsutbildningar världen över, men också Handelsbankens förre VD Jan Wallander som nu i början av september gick ur tiden 96 år gammal. När Handelsbanken i slutet av 60-talet upplevede en kris, i mångt och mycket orsakad av toppstyre och av en ledning som förlorat markkontakten, och sökte efter en ny VD så anmälde Wallander sig på villkor att han fick lov att vända upp och ner på hierarkierna, ungefär som han hade gjort på Sundsvallsbanken tidigare.

Det visade sig vara lönsamt med delegering. Om folket på golvet, nära kunden, får lov att fatta beslut så blir besluten mer verklighetsförankrade. En organisation med makten i fingerspetsarna är känslig för folks behov och har förmågan att lättrörligt anpassa sig efter en föränderlig marknad. Men det krävs även en annan sak för att uppnå organisationsagilitet, och det är frånvaron av blockerande övergripande strukturer. Här gjorde Wallander något som fick många att lyfta på ögonbrynen: han avskaffade årsbudgetarna.

Många associerar en avskaffad budget med avskaffad kontroll, men det är det inte fråga om. Däremot att man inte tror sig kunna styra över hela år i taget, utan att man är beredd att skifta fokus löpande. Kontroll på kostnader och uppföljning av vart pengarna går har man fortfarande. Wallander blev därmed en pionjär för det som idag kallas för "beyond budgeting" vilket är ett agilt sätt att hantera intäkts- och utgiftsströmmar på. När Bjarte Bogsnes ("Beyond Budgeting") och Jurgen Appelo ("Management 3.0") talar om organisationer som gått före på resan mot större agilitet så nämner de därför Handelsbanken med aktning.

Nu är det upp till oss som fortfarande lever att fortsätta förvandla organisationerna i mer rimlig riktning. Tack, Jan Wallander, för ditt bidrag!

Tio steg till organisationsagilitet

Organisationsagilitet har beskrivits som den tredje vågen inom lättrörlighet och smidighet. Den första vågen var när man började skapa små agila bubblor i annars väldigt trögrörliga och stela organisationer, och mycket av råden till agilister från den tiden handlade om hur man skulle skydda teamen och möjliggöra agilitet trots att verksamheten ville annorlunda. Den andra vågen handlade om hur man kunde synkronisera flera team att samarbeta på ett mer lättrörligt sätt, och idag är detta ett i huvudsak löst problem med väl beprövade ramverk och tricks. Den organisation som vill få storskalig agilitet att fungera kan få det på mella sex och tolv månader om de bara är villiga att göra som expertisen inom området säger.

Men både första och andra vågen handlade bara om en sak: hur man utvecklar tjänster, i synnerhet IT-baserade tjänster. Men utveckling är bara en liten del av en tjänsts livscykel, och tjänsteperspektivet är långt mer vittgående än IT. Det börjar gå upp för fler och fler organisationer att hela deras värde i nuet består i förmågan att möta människors olika behov, men deras värde över tid består i förmågan att kontinuerligt vidareutveckla tjänsteförmågan. Folks behov skiftar.

Och det är här organisationerna har utmaningen idag. För att kunna lyckas med att skapa en tjänsteinnovationsfabrik behövs organisationsagilitet och det är något som på många håll kräver ganska vittgående förändringar.

Det första som måste ryka är projekten. De har aldrig tjänat oss väl, och för kontinuerlig tjänsteutveckling är de rent destruktiva. Projekt betyder välplanerade tillfälliga arbeten i tillfälliga organisationer, och kontinuerlig tjänsteutveckling är tvärtom: ständig förbättring i den fasta organisationen på ett sätt som inte kan planeras på förhand. Istället för projekt behöver vi bygga in tjänstutvecklingskapaciteten i själva linjeorganisationen.

Det andra som måste ryka är årsbudgetar där man på förhand har beslutat om till vad man ska allokera hundra procent av sin förändringsförmåga under ett kalenderår. Den som har begått det misstaget får vänta till minst årsskiftet för att få igenom en förändring när de ser en möjlighet uppenbara sig. Istället behöver man allokera medel löpande inom de ramar man satt. Kostnadsmassan i organisationen är ganska stabil, det är vad organisationen ska lägga sin energi på som behöver kunna vara rörligt.

Det tredje som måste ryka är tron att man med en omorganisation kan anpassa linjeorganisationen efter värdeströmmen. Det går inte. Värdeströmmarna i tjänsteorganisationer (utom de allra enklaste) är komplexa och korsar organisatoriska gränser. Istället bör man låta organisationen så långt det går vara ifred så att den kan bygga kapacitet att hantera strömmarna på tvärs genom avdelningsgränserna. Omorganisation kan behövas för att slå sönder hinder men den bygger aldrig upp. För att bygga upp kapacitet i en organisation behöver organisationen tvärtom stabilitet.

Det fjärde som måste ryka är målstyrning på utfallsmått (management by objectives). Det felaktiga bakom denna styrfilosofi har varit känd sedan femtiotalet: utfallet är beroende både av faktorer som kan kontrolleras av de som arbetar och faktorer som inte kan kontrolleras. Om man arbetar metodiskt med förbättring kommer utfallet att bli bättre, men att styra på utfallsmått som i sig innehåller varians ökar variansen. Ersätt management by objectives med ledarskap.

Det femte som måste ryka är tron att viktiga nyckeltal också är styrtal. I samma stund som ett relevant nyckeltal behandlas som ett styrtal så upphör det att vara ett relevant nyckeltal (Goodharts lag).

Det sjätte som måste ryka är resursoptimering, tron att organisationen presterar mest värde när resurserna är maximalt utnyttjade. Det är en intuition som är matematiskt felaktig. Optimering på flöde betyder en viss överkapacitet i varje del av värdeströmmen vilket kan kännas lite dyrt, men eftersom flödet är bättre hinner fler värdeenheter levereras per tidsenhet vilket gör att kostnaden per värdeenhet går ner. Flödesoptimering är ett exempel på systemtänkande. Det finns fler.

Det sjunde som måste ryka är idén att chefer leder och fördelar arbetet. De som förstår arbetet bäst är de som befinner sig allra närmast värdeskapandet. De ser värdet, och de ser spillet uppstå, särskilt om de tränas i förmågan att se spill. Det kan hända att cheferna är bättre på att planera arbetet än vad folket närmast arbetet är. Då löser man det genom att lära dem planera och följa upp sitt eget arbete. Chefer ska ge förutsättningarna (mål, ramar, verktyg) för självorganisation om organisationen ska ha en chans att bli lättrörlig.

Det åttonde som måste ryka är idén att förbättringsarbetet är chefernas ansvar. Även den ständiga förbättringen behöver utföras av dem som är närmast värdeskapandet. Och den ska vara metodisk vilket kräver utbildning och coachning, regelbunden vilket kräver avsatt tid, och baserad på empiri vilket kräver stor transparens i organisationen.

Det nionde som måste ryka är tanken att narcissism är en god ledaregenskap. När vi rekryterar ledare på magkänsla tenderar vi att gynna stora egon. Dessa kommer att blockera sund grupputveckling, som ju är ett måste för att få breda och välfungerande arbetsgrupper, vilket är ett måste för att få organisationsagilitet. En organisation designar sitt ledarskap genom att besätta positioner på ett medvetet sätt.

Det tionde som måste ryka är den falska bilden av människan som en varelse utan psykologiska behov. Behov finns, och behöver tas hänsyn till, annars fungerar inte människan optimalt och organisationen fungerar dåligt. Den agila organisationen vet vad människor behöver och aagerar med hänsyn till dessa.

Vi som varit inblandade i första och andra vågens agilitet kan berätta att dessa tio saker måste städas bort från organisationerna om vi ska få smidighet i dem. Vi kan också berätta om hur man gör för att styra, leda, planera och följa upp på ett sätt som gör organisationen agil. Men orkar organisationen lyssna till budskapet?

Jag är på plats under hela Almedalsveckan 2017 och deltar gärna i flera samtal runt de här frågorna.

Allt hänger ihop

Det jag hoppas kunna visa med Smidigt!-programmet är hur allt hänger ihop. Ett av våra problem är att vi delat upp verksamheternas aspekter i en massa småavdelningar med stängda dörrar emellan sig. Ledningar vimsar i den här miljön runt och försöker att med olika omorganisationer kunna skapa smartare indelning av avdelningarna som bättre följer värdeströmmarna, men det fungerar inte.

Har man lite komplexitet i verksamheten kommer alltid värdeskapandet att korsa avdelningsgränserna. Det är själva indelandet som är problemet, medan samarbetsformer som öppnar dörrarna på ett ordnat sätt är en del av lösningen.

Om allt hänger ihop är det naturligtvis svårt med överblicken, och det är precis det som Smidigt!-programmet är: en överblick över just en massa samarbetsformer som syftar till att koppla ihop alla olika avdelningar och perspektiv till en helhet. När jag håller kurs brukar jag likna Smidigt!-programmet vid en karta där de olika modulerna i programmet är platser vi kan utforska, och den app jag skriver på just nu kallar jag för "Smidgt! Atlas". Ett verktyg som ska ge överblick. De smidiga samarbetsformerna handlar ju om allt från budgetstyrning till omsorg om människor och maskiner till ledarskap och gruppsykologi. Det är ett integrerat synsätt som spänner över många fält, och sådana kan vara väldigt svåra att överblicka om man inte har en bra kartbok.

Här på bloggen finns redan en massa inlägg som handlar om gränsöverskridandet:

Att riva gränserna mellan "IT" och "verksamhet" (en indelning som vi lyckligtvis snart kommer att lägga på skräphögen) handlar dessa inlägg om: Vi bygger broar om att vi måste samsas om samma värdeström, Beställare och utförare om att beställar/utförar-perspektivet gör att det ser ut som att alla problem finns innanför "utförarnas" dörrar, men att det i själva verket handlar om bristande djup kommunikation dem emellan. Ett anspråkslöst förslag handlar om ett konkret verktyg: att "beställningar" läggs som en väldigt tunn idébeskrivning av vad man vill uppnå, och så kan "beställare" och "utförare" tillsammans utforska de bakomliggande behoven oxh möjliga lösningarna.

För att öppna dörrarna, eller hellre riva väggarna, och sätta sig vid samma bord behöver man en gemensam bild av vad som händer. Ett klassiskt sätt ifrån lean och Toyota är att gemensamt titta på värdeflödesperspektivet. Om detta har jag skrivit en hel serie inlägg som länkas till ifrån Den livsviktiga flödessynen. Hur blir folk glada? Vilka behov möter vi? För att se det kan man ha en workshop för att Leta värden tillsammans. För värde är mänskliga behov.

Ett tidigt försök att överbrygga avdelningsgränser var projekt. Nu har projekt enorma svårigheter av lite olika skäl. Ett skäl är att ett projekt per definition är tillfälliga arbeten i tillfälliga organisationer till en fast tid, kostnad och kvalitet. Det är ju inte tillfällighet vi behöver utan ett konstant värdeskapande. Och problemet med värdeskapande är att det bygger på utforskande, vilket gör det i princip oplanerbart (på det sätt som projekt definierar planerbarhet): Oplanerbara projekt? Istället utgår smidiga samarbetsmetoder från ett tjänsteperspektiv: värde levereras i form av tjänster, och tjänster måste betraktas utifrån hela sin livscykel. Där är utvecklingen bara en liten del. Här finns även början till det som blivit ALMA: The Agile Lifecycle Management Anatomy.

Det här helhetsperspektivet tror jag är viktig för både myndigheter och företag i ljuset av digitaliseringen. Jag sammanfattar i Samtiden och framtiden vad jag tror kommer att krävas. Dels att en massa strukturer rivs upp som i dagsläget mäter fel saker och på fel sätt. Just mätetal har jag bloggat en hel serie om. Särskilt skriver jag om Mätetal som kan vara relevanta i smidiga samarbeten.

Alla måste uppvisa ledarskap i smidiga samarbeten. Det ligger i själva det sätt som vi betraktar organisationer på. Så för den som har ett särskilt ansvar för ledarskapet är det extra viktigt att tänka över sitt ledarskap. Särskilt gäller det att förstå att ens roll i digitaliseringen handlar om att leda för förändring, inte för stillastående. Till din hjälp finns dock ett antal väl beprövade principer.

Om allt detta handlar Smidigt!-programmet. En massa moduler med kunskaper och gruppfärdighetsträningar som ska hjälpa samarbeten att bli mer smidiga. Det bygger på en massa erfarenhet, men också på en massa teoretisk kunskap från olika fält. Bland annat från dessa böcker. Fast det som jag försökt göra är att lägga ihop allt så att det blir både begripligt och möjligt att agera på. Kunskap i sig förändrar ingenting. Förändring förändrar, och att få bidra till förändring som gör jobb trygga och meningsfulla och produktiva är litegrann mitt livsmål. Jag hoppas så innerligt att du kan hitta något du har användning för genom det jag försöker göra.