söndag 4 december 2016

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.

fredag 2 december 2016

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.

söndag 27 november 2016

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?"

lördag 26 november 2016

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, 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.

onsdag 23 november 2016

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.

lördag 19 november 2016

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.

söndag 13 november 2016

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.