söndag 22 januari 2017

När system krackelerar

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

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

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

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

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

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

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

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

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

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

söndag 15 januari 2017

Satisficing

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

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

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

What does that teach us?

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

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

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

Here the preferences from agile decision making comes handy!

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

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

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

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

Happy decision making!

tisdag 3 januari 2017

Man måste avveckla också

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

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

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

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

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

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

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

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

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

söndag 1 januari 2017

Scaling Agile Capabilities

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

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

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

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

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

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

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

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

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

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

I have found the perspective quite helpful.

fredag 23 december 2016

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.

onsdag 21 december 2016

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.

tisdag 13 december 2016

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.

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.