När system krackelerar

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

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

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

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

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

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

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

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

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

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

Satisficing

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

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

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

What does that teach us?

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

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

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

Here the preferences from agile decision making comes handy!

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

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

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

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

Happy decision making!

Man måste avveckla också

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

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

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

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

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

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

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

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

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

Scaling Agile Capabilities

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

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

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

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

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

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

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

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

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

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

I have found the perspective quite helpful.