TTW 4: 14 Principles: An Executive Summary of TPS Culture

Om du kopierar varje Totyotaverktyg som finns (kanban, andon, 5S osv) och kallar in en TPS-expert för att stolt förevisa resultatet kommer hon ändå att skaka på huvudet. Det tunga arbetet ligger framför er: att anamma kulturen bakom TPS. Ständigt förbättra er själva och ert samarbete. Kommunicera, lösa problem, och växa tillsammans. TPS handlar om att göra sig mer beroende av människorna i organisationen, inte mindre.

Det svåraste i samarbetsverktyget 5S (Släng, Systematisera, Städa, Standardisera, Stanna kvar) är "Stanna kvar" (sustain / shitsuke): att vara uthållig. Det kräver en kultur där folk själva vill hålla fast vid verktyget eftersom de själva ser nyttan i det.

I det här kapitlet sammanfattar Liker Toyotas kultur (The Toyota Way) i 14 punkter sorterade i fyra principer: 1) Långsiktig filosofi, 2) Rätt process ger rätt resultat, 3) Öka värdet i organisationen genom att utveckla människorna, samt 4) Lös hela tiden rotproblemen för att få en lärande organisation.

Långsiktig filosofi (Philosophy)

1) Chefsbeslut ska baseras på långsiktighet även om de kortsiktiga finansiella målen inte uppnås. Vet vad det övergripande långsiktiga syftet är och väx organisationen i den riktningen. Skapa värde för kunder, samhälle, och ekonomin. Ta ansvar över ditt eget öde och ditt beteende i varje stund.

Rätt process ger rätt resultat (Process)

2) Skapa kontinuerliga flöden i processen för att blottlägga problemen. Väntetiderna ska ner mot noll. Snabba upp både materialflödena och informationsflödena genom att koppla samman människor med varandra, för att blottlägga problem. Alla måste tänka i termer av flöde.

3) Använd dragande system för att undvika överproduktion. Förse människor längre ner i kedjan med det de behöver, när de behöver det, och precis så mycket som de behöver. Minska mängden pågående arbete genom att inte ha stora lager med halvfärdiga saker. Var responsiv för skiftande efterfrågan istället för att försöka planera.

4) Jämna ut arbetsbelastningen (heijunka). Lunka som en sköldpadda och sprinta inte som en hare. Att ta bort spill (muda) utgör bara en tredjedel av lean. Man måste även ta bort överlast (muri) av människor och maskiner, och jämna ut ojämnheter (mura). Akta er för ryckighet, att starta och stoppa processer, och arbeta inte med stora sjok (batches).

5) Odla en kultur där man stoppar processen för att fixa problem, och får kvaliteten rätt från början. Kvalitet åt kunden är det värde du skapar. Använd alla moderna effektiva kvalitetssäkringsmetoder som finns. Bygg in i verktyg och processer förmågan att stoppa vid problem (jidoka). Visualisera när en process eller maskin behöver hjälp. Organisationen måste ha stödprocesser på plats som snabbt kan lösa problem och vidta åtgärder.

6) Standardiserat arbete är grunden för ständig förbättring och bemyndigande av de anställda. Använd stabila och upprepningsbara metoder överalt för att behålla förutsägbarhet i tid och utflöde. [ OBS att förutsägbarheten med nödvändighet måste vara dramatiskt lägre vid innovation och utveckling, men behovet av fasta rutiner och takter finns där ändå för att få bort onödig oförutsägbarhet (min kommentar). ] Detta är fundamentalt för dragande flöden. Standardisera runt goda praktiker men tillåt folk att experimentera med alternativa sätt att arbeta på för att hitta ännu bättre sätt att standardisera.

7) Använd visuell styrning för att inga problem ska kunna gömma sig. Visa på ett enkelt sätt nuläget så att folk lätt ser om saker är i enlighet med den överenskomna normen eller om situationen avviker. Undvik datorskärmar om de vänder bort folks uppmärksamhet från arbetet. Skapa enkla visuella verktyg direkt på arbetsplatsen för att stödja ett dragande flöde. Koka ner alla rapporter och dokument till en enda sida, även de mest viktiga dokumenten.

8) Använd bara beprövad teknik som du vet stöttar människor och processer. Teknik ska stötta människor, inte ersätta dem. Oftast är det bäst att förbättra den manuella processen först innan man automatiserar. Ny teknik är ofta opålitlig och svår att standardisera runt, och saboterar lätt flödet. Testa under verkliga förhållanden innan ni gör verksamhetsprocesserna beroende av en viss teknik. Använd inte teknik som är i konflikt med er kultur eller som hotar stabilitet och pålitlighet. Men uppmuntra folk att experimentera med ny teknik och att pröva den. Har något visat sig vara bra ska man inte dröja med att införa det.

Öka värdet i organisationen genom att utveckla människorna (People)

9) Odla ledare som förstår arbetet i grunden, som lever enligt filosofin, och som kan lära ut konsten till andra. Odla hellre ledarskapet inom organisationen än hämta folk utifrån. Ledarnas arbete är inte bara att få saker gjorda och att ha god hand med människor, utan de måste vara goda föredömen i filosofin och organisationens affärsmannaskap. En bra ledare måste förstå arbetet i grunden för att kunna lära ut filosofin. [ Liker är fortfarande fast i paradigmet ledare=chef. Om ledarskap är mer spritt är det lättare att få ledare som förstår arbetet i grunden. Cheferna blir då mer av administratörer, koordinatörer och möjliggörare av allas ledarskap. Så fungerar agila organisationer (min kommentar). ]

10) Utveckla enastående människor och arbetslag som följer företagets filosofi. Odla en stabil kultur där värderingarna och föreställningarna delas och levs år efter år. Utbilda folk i att arbeta enligt filosofin för att uppnå enastående resultat. Jobba hårt med att förstärka kulturen. Arbeta i tvärfunktionella arbetslag för att öka kvaliteten och produktiviteten och för att förbättra flödet genom att lösa de svåra tekniska hindren. Bemyndigande (empowerment) sker när folk använder företagets verktyg för att lösa företagets problem. Utbilda ständigt i hur man arbetar i grupp för att nå gemensamma mål. Grupparbete är en inlärd förmåga.

11) Respektera nätverket av partners och leverantörer genom att utmana dem och hjälpa dem att förbättra sig. Respektera partners och leverantörer genom att se dem som en del av din verksamhet. Utmana dem att nå nya nivåer och hjälp dem att nå dem.

Lös hela tiden rotproblemen för att få en lärande organisation (Problem)

12) Se efter själv för att få en grundlig förståelse av situationen (genchi genbutsu). Gå till källan och verifiera data istället för att teoretisera runt det som folk (eller datorskärmen) berättar. Utgå från det personligen verifierade när du talar och tänker. Även chefer på hög nivå måste gå ut i verkligheten och se efter själva för att inte bara få en ytlig förståelse av situationen.

13) Fatta beslut långsamt genom konsensus efter att noga ha övervägt alla alternativ; genomför besluten blixtsnabbt. Följ inte första bästa stig utan överväg alternativen. När du bestämt dig ska du röra dig snabbt men försiktigt. Förankring (nemawashi) kallas det när man diskuterar problemet och lösningarna med de som påverkas av dem för att få deras insikter och acceptans. Denna process tar tid men ger tillgång till fler insikter och alternativ och gör folk beredda på att implementera lösningen snabbt så snart man har bestämt sig.

14) Bli en lärande organisation genom ständig reflektion (hansei) och ständig förbättring (kaizen). Så snart ni har en stabil process använder ni verktyg som angriper rotorsakerna till ineffektivitet. Utforma processerna så att de inte är beroende av lagerhållning och köer. Detta blottlägger grundläggande problem. Låt folk använda kaizen för att ta bort grundprblemen. Skydda organisationens kunskap genom att ha stabil personalstyrka, långsamma karriärvägar, och genomtänkt successionsplanering [ Liker är fast i paradigmet karriär=bli chef. Att göra karriär i en agil organisation handlar mer om att få utökade befogenheter och kompetenser inom den sfär du redan har än att befordras till din inkompetensnivå (min kommentar). ] Standardisera runt de goda arbetssätt ni finner, istället för att uppfinna hjulet på nytt så snart ni startar ett projekt eller byter chef.

Man kan använda en handfull TPS-verktyg och bara följa några principer, men resultatet brukar bli en kortsiktig förbättring som inte är uthållig. Följer man principerna däremot så får man de verktyg som passar på köpet. Vissa av verktygen är avsedda för industriproduktion, men principerna är däremot tillämpliga överallt, även i tjänsteproduktion och utveckling/innovation.

TTW 3: The Heart of the TPS: Eliminating Waste

"Ta bort allt onödigt på vägen mellan beställning och betalning", sade Ohno. Det onödiga, det som inte skapar värde, kallas för spill eller slöseri (waste/muda). Men vad man benämner som spill beror på vad man menar är värdefullt. TPS bygger på att värde ska ses ur ett kundperspektiv. "Vad vill kunden ha ut av den här delen av processen?". En "kund" kan här ses som den yttersta beställaren, eller helt enkelt nästa person i kedjan (inre kund).

Toyota har identifierat sju spillkällor / sorters slöseri:

Överproduktion (Overproduction) - att man producerar sådant som ingen har beställt. Enligt Taiichi Ohno är detta urspillet som leder till alla andra spill.

Väntan (Waiting) - när någon står och glor för att en maskin inte är färdig, eller när ett arbetspaket får vänta eftersom den som ska arbeta med det är fullt upptagen med något annat.

(Här är en lite knepig sak: boken nämner faktiskt bara det första spillet, att en människa väntar på jobb, men de flesta uppräkningar brukar fokusera på det sistnämnda - att ett arbetspaket väntar - och påpeka att det är det dyrare spillet. Att en människa eller maskin får vänta lite gör ofta inget så länge som arbetspaketet har full fart genom flödet och slipper vänta. Ofta blir det anti-lean om man är rädd för att människor och maskiner står och väntar lite.

I boken Workplace Management kapitel 9 varnar Taiichi Ohno själv för rädslan att inte utnyttja all kapacitet. Risken är överhängande att man överproducerar om man vill hålla människor och maskiner sysselsatta med produktion hela tiden. Laga maskinen och förkovra människan istället.

Just här upplever jag en liten motsättning mellan Likers framställning och Ohnos egen framställning.)

Onödiga transporter (Unneccessary transportation) - när saker flyttas fram och tillbaks i onödan.

Onödig processning (Overprocessing inklusive failure demand: att man måste processa något för att kompensera för en defekt någonstans) - alla handgrepp som sker i onödan.

För stora lager (Excess inventory) - all ställen där halvfärdiga leveranser eller material behöver ansamlas för att flödet därefter ska kunna vara jämnt.

Onödig förflyttning (Unneccessary movement) - alla onödiga förflyttningar arbetare tvingas göra, allt letande osv.

Defekter (Defects) - alla fel vi gör: att lägga ner möda på något som ändå inte blir bra.

Liker vill lägga till sin åttonde typ av slöseri: Oanvänd arbetarkreativitet - när ideer och engagemang från de anställda inte tas till vara. Idag skulle vi väl också vilja räkna outnyttjad kreativitet och engagemang hos kunderna som spill.

Det finns en tendens hos den som arbetar med massproduktion att inte alltid förstå allvaret bakom slöserierna. Men de har följdverkningar och Liker ger här exempel på sådana.

Man kan göra en värdeströmskarta över ett arbetspakets väg genom ett flöde på väg att bli en leverans. Då kartlägger man var och när i flödet som värde skapas och när det inte gör det. Ofta hittar man då spill man inte såg förut. Liker beskriver ett uppdrag i en mutterfabrik. Ledningen försäkrade honom om att det inte fanns några produktivitetsvinster att göra i ett såpass enkelt flöde. Men när de gjorde en värdeströmskarta såg de en enormt massa processsteg och mycket väntan. Bland annat var muttrarna tvugna att lämna fabriken i några veckor för att härdas eftersom ledningen fått ett bra pris på härdning hos en underleverantör långt borta. Muttrar som borde kunnat tillverkas på en halv dag tog veckor och månader att tillverka.

Dessutom var ofta maskinerna på fabriken sönder eftersom man outsourcat underhållet av dem. I väntan på att de lagades tillverkade man så mycket som möjligt så långt det gick, vilket byggde upp stora interna lager och köer. När man fick problem med kvaliteten var det därför väldigt svårt att veta vad det berodde på, och man fick svårt att möta kundernas växlande krav.

I den situationen går det inte att processförbättra på klassiskt manér: optimera varje del av flödet och automatisera mer. Istället får man försöka införa lean: se till hela värdeflödet och ta bort allt som inte skapar värde.

I en lean verksamhet försöker man skapa celler där alla människor, verktyg, och material finns sida vid sida för att skapa ett enskilt exemplar av något värdefullt (till exempel en mutter). En cell tar bort det mesta av behovet av lagerhållning, köer och väntan eftersom varje mutter färdigställs i ett enda svep (single piece continuous flow). Det ger dramatiska förbättringar.

Men det gäller att akta sig för att förälska sig i en metod, som till exempel cellen. På mutterfabriken infördes celler för delar av flödet. Även om just dessa delar av flödet blev dramatiskt mycket snabbare så skrattade alla arbetarna åt leantokerierna eftersom alla förstod att denna vinst åts upp av det stora slöseriet: muttrarnas mer än veckolånga resa, i stora lådor, till underleverantören som skulle härda dem.

Toyota klarade sig länge utan någon dokumentation av sitt produktionssystem. Men till slut behövde man hitta ord och bilder som sammanfattade tankegångarna. Ohnos lärling Fuijo Cho skapade "TPS-huset". Denna bild finns i flera varianter men grunderna är desamma: ett tak bestående av målen (lägsta kostnaderna, kortaste ledtiderna, bästa kvaliteten), och ett golv bestående av fundamenten (stabila processer och utjämnade flöden). Taket bärs upp av de två pelarna Just in time och jidoka.

Det är illustrerat som ett hus för att alla ska förstå att allt hänger ihop och stärker vartannat. Även när det är kontraintuitivt: flödet utan köer skapar sårbarhet som i sig gör hela byggnaden instabil. Man behöver tillämpa jidoka och kaizen för att åtgärda det, och resultatet blir ett mer stabilt hus än annars.

Alla husets invånare måste vara delaktiga i husets stabilitet. Alla måste kunna känna igen spill och slöserier och veta hur man åtgärdar dem. Man aktar sig för både överlast och defekter, och detta medför att arbetet blir ganska säkert och tryggt att utföra. Detta är i linje med Toyotas princip om att alltid respektera och omfamna det mänskliga i människan (Respect people).

Liker sörjer att lean alldeles för ofta presenteras som en uppsättning tekniker som ska effektivisera tillverkningsprocesser, när det i själva verket är ett system som ska hänga ihop och som är ett utflöde av ett tänkesätt som sätter människan i centrum.

TTW 2: The Story of the Toyoda Family and TPS

Ledarfilosofin inom Toyota går tillbaks till familjen Toyodas värderingar.

Det börjar med Sakichi Toyoda som under det sena 1800-talet då textilindustrin tar fart i Japan börjar bygga vävstolar. Först var de manuella, men eftersom han ville att hans vävande släktingar inte skulle behöva slita så hårt började han experimentera med att koppla ihop dem med en ångmaskin. Liker lyfter fram detta som ett tidigt exempel på genchi genbutsu, att gå till golvet och se efter själv hur det fungerar.

1926 startade Sakichi firman Toyoda Automatic Loom Works och hans vävstolar blev berömda. En av de viktaste uppfinningarna är en vävstol som stannar direkt när varptråden går av så att inte maskinen fortsätter och orsakar trassel. Detta är ett exempel på jidoka, smart "autonomatisering" som bygger in kvalitet i själva processen.

Sakichi Toyoda var intresserad av förbättringsarbete, och inspirerades av boken Self-Help som beskrev hur uppfinnares och andras uthålliga förbättringsarbete lyfter människor omkring dem. I boken framhålls både att man inte ska ge upp, och att man ska förbättra utifrån fakta och inte gissningar.

Sakichi Toyodas son Kiichiro Toyoda startade bilfabriken. Han var en ingenjörsmässig uppfinnare precis som sin far. Inspirerad av vad han sett i USA, dels hos Ford men framförallt i logistikflödena i daglighandeln, så beslöt han att principen om Just In Time skulle råda.

Den japanska ekonomin efter Andra världskriget var skakig, men istället för att låta arbetarna ta smällen såg Toyota till att ledningen tog ansvar och sänkte sin egen lön. Kiichiro Toyoda ville till varje pris undvika att människor tvingades sluta på jobbet.

Dessa ideal: ta reda på fakta, pröva själv, innovera, bidra till samhället och respektera männniskorna som arbetar hos dig, de präntades in även hos andra familjemedlemmar. Kiichiros yngre kusin Eiji Toyoda blev så småningom högsta chef på Toyota men fick börja med att experimentera med olika verktyg. Man lämnar inte över ledarskapet åt någon som inte själv har fått sina nävar smutsiga av arbetet, eller som inte har tänkt djupt och faktabaserat på ett problem för att sedan komma på en lösning.

Redan på 1930-talet efter en tur till USA och bilfabrikerna där förstod Toyota att man inte kunde låna massproduktionsideerna utan att anpassa dem till japanska förhållanden. 1950 kom Eiji Toyoda tillbaks från ännu en resa i USA och förstod hur man skulle göra. Massproduktionen hade inte förändrats sedan 1930-talet. Den orsakade en massa väntan och lagerhållning när de stora serierna väntade på att flyttas från den ena avdelningen till den andra, de stora serierna gömde en massa defekta produkter som inte upptäcktes förrän långt senare, och man förstod att bonussystemet (som premierade beläggningsgrad) drev varje enskild chef att öka produktionstakten utan att ta hänsyn till jämnheten flödet.

Det var helt enkelt möjligt att konkurrera med de amerikanska jättarna. Eiji Toyoda gav uppdraget att förändra produktionssystemet till Taiichi Ohno. Också Ohno förstod, efter att ha studerat Ford i böcker och på plats, att nyckeln var det jämna flödet. Ford hade genom det löpande bandet börjat tänka i termer av flöde, och han skrev om vikten av flöde i sin bok, men i praktiken lyckades han inte skapa det. Specialisering, toppstyrd arbetsmetod, centralplanering och andra Tayloristiska påfund i Fords produktionssystem ledde till stora trögheter.

Ohno såg att man kunde lyckas med Fords flödesideer om man fokuserade på att snabbt kunna tillverka en sak åt gången och gav mandat och förmåga åt arbetarna själva att förbättra sina arbetssätt. Flöde kräver flexibilitet (=agilitet). Under de nästföljande åren och årtiondena växte Toyotas produktionssystem fram genom praktiskt experimenterande på fabriksgolvet.

En viktig komponent för att få ett jämnt flöde är att flödet är dragande. Om varje station får trycka ifrån sig saker så snart de är klara uppstår köer. Centralplanering av alla produktionsmoment kan lösa problemet men kräver att centralplaneraren alltid har tillgång till uppdaterad information och kapacitet att blixtsnabbt räkna ut och kommunicera optimala produktionstakt i varje steg. Det kan man inte. Istället lånade Toyota en idé från hur man fyller på butikshyllor i stora butiker: låt processerna själva signallera när de är redo att ta emot (när det finns lagom med tomt utrymme på hyllan), inte när de är redo att lämna ifrån sig. Signalen, kanban, gav namn till hela tankesättet.

Kanban och andra knep, till exempel förmågan att tillverka små serier (ibland om en enda enhet, single piece continuous flow eller 1x1 flow) på ett lönsamt sätt, det möjliggjorde Just in time: att rätt mängd av något kommer till rätt ställe i rätt tid. När det blir verklighet i hela flödet får plötsligt företaget förmågan att snabbt kunna anpassa sig till ändrade förutsättningar, till exempel plötsligt ändrad efterfrågan.

Ett av knepen var att ta till sig amerikanen William Demings tankar om kvalitet. Deming påminde om att i ett flöde så var nästa steg i processen din kund. Det är inte nästa steg i processen som ska acceptera den kvalitet (och variation i kvalitet) som du kan leverera, utan det är du som ska anpassa dig efter vad de kan ta emot. Detta är nödvändigt för att få ett dragande flöde att fungera, och leder i förlängningen till att hela organisationen ser varje del av organisationen som sin kund eftersom alla påverkar varandra.

För att kunna anpassa sin kvalitet till vad nästa steg i flödet kan ta emot så behöver folk arbeta lokalt med kvalitet. Deming förespråkade "Shewhartcykeln" (som japanerna kallade "Demingcykeln") PDCA som systematiskt angreppssätt. Detta gifte ihop sig med Ohnos idé om att arbetarna på ett metodiskt sätt ska äga och vidareutveckla sina egna arbetssätt och blev principen om ständig förbättring (continuous improvement eller kaizen). Det är kaizen, metodiskt förbättringsarbete drivet av människorna på golvet, som utvecklar själva TPS och som gör att Toyotas tankesätt inte ebbar ut.

På 1960-talet var TPS i full gång, men det var inte förrän vid oljekrisen 1973 som det började sprida sig. Den japanska industrin drabbades hårt men regeringen såg att Toyota klarade krisen bättre än konkurrenterna. Regeringen började därför jobba för att sprida TPS i hela Japan, men det var svårt. När Liker besökte Japan i början på 80-talet såg han att så snart du rörde dig utanför Toyota var den TPS man praktiserade där väldigt urvattnad, och det skulle dröja mycket länge innan resten av världen började förstå.

Massproduktionen fokuserade på att hålla nere kostnader, ofta på bekostnad av kvalitet. Men i början på 80-talet började industrin även i väst förstå vad kvalitetspionjärer som Deming, Joseph Juran och Kaoru Ishikawa kommit fram till, och som Toyota tagit till sig: att om man satsar på metodiskt kvalitetsarbete så kommer totalkostnaden att sjunka. År 1990 kom till slut, genom ett forskningsprogram på MIT, boken The Machine That Changed The World ut som tar Toyotas produktionssystem (under namnet "lean") ut till alla.

TTW 1: Operational Excellence as a Strategic Weapon

Världen förstod att Toyota var något extra i början på 80-talet, och i början på 90-talet började beskrivningar av de underliggande tankesätten sprida sig. Bilarna var bra, men produktionssystemet (Toyota Production System, TPS) var något alldeles extra: snabb utveckling av nya modeller, mycket innovation, bra design, snabb produktion, hög kvalitet, låga kostnader, bättre löner till arbetarna, samt stigande börsvärde och hög lönsamhet, i årtionde efter årtionde.

Toyotas verktyg är inga hemligheter: mjuka flöden i rättan tid (JIT), en sak åt gången (1x1 flow), ständig förbättring (kaizen), felsäkring och annan inbyggd kvalitet (poka-yoke, jidoka, andon), och produktionsutjämning (heijunka). Men det är de underliggande tankesätten som får det att fungera. I den här boken, The Toyota Way, samlar Jeff Liker tankesätten i 14 principer grupperade i fyra kategorier: Philosophy, Process, People/Partners, samt Problem Solving.

Många försöker införa "lean" (som tänkandet bakom Toyotas produktionssystem ibland kallas) men genom att införa de enskilda verktygen. Liker vill med boken hjälpa folk att införa tänkandet och på så sätt få verktygen att hänga ihop och bilda en "lean" verksamhet. Hur? Boken citerar Jim Womack (ur Lean Thinking):

1. Bestäm vad "kundvärde" betyder för er.
2. Identifiera flödena i din verksamhet som skapar kundvärde.
3. Rensa bort det som hindrar flödet.
4. Se till att det är ett dragande flöde, du ska inte trycka saker igenom det.
5. Förbättra och se till att allt fungerar klockrent.

Detta är i linje med TPS huvudsakliga upphovsperson Taiichi Ohnos utsaga: "Allt vi gör är att se vad som händer från det att kunden ger oss en order tills dess att vi får betalt. Allt onödigt på den vägen tar vi bort."

Lean har sina rötter i Japans ekonomiska situation efter Andra världskriget. Företag i USA kunde specialisera sig och massproducera för den stora och växande världsmarknaden, men i Japan efter kriget var marknaden liten och skiftande. Toyota behövde kunna jobba med små serier och snabbt ställa om produktionen (det vi idag kallar agilitet).

Massproduktionens urtänkare Taylor och Ford var sin tids "lean"-pionjärer, som eliminerade vad de såg som spill i flödena. Men deras spilljakt såg inte till balansen i hela flödet, utan till att att maximera utnyttjandegraden i varje steg. Men det driver beteenden som gör att hela flödet blir sårbart och dyrt, när man till exempel gör allt i stora serier eller överproducerar istället för att låta produktionen i varje stund matcha efterfrågan.

Toyota fokuserar istället på ett effektivt och flexibelt flöde med korta ledtider och snabb lageromsättning. Det innebär beteenden som kan verka ointuitiva för den som är skolad i ett Tayloristiskt tänkande, till exempel att acceptera att inte allt och alla utnyttjas maximalt hela tiden. Men att optimera på flöde istället för på utnyttjandegrad är ekonomiskt mer sunt, och gör att man blir mycket bättre på att snabbt möta skiftande kundkrav. Man står bättre rustad än konkurrenterna idag när alla kräver flexibilitet och anpassningsförmåga av producenterna.

Den drivande tanken är att i varje steg ställa sig frågan: Hur adderar detta steg värde ur kundens perspektiv? Kundperspektivet ger helhetsperspektivet.

Skälet till att så få organisationer lyckas med lean tror Liker beror på att de förälskar sig i några ytliga verktyg utan att ta till sig tankegångarna. Verktygen är sprungna ur förbättringsarbetet som bedrivs på golvet, så ledningens uppgift är att stötta folk att kunna bedriva detta: ge dem kunskap och mandat att förändra. Men även om man hör orden om att ge makt åt människorna på golvet är det få som förstår att det faktiskt är det som Toyota gör.

Resultatet är en mängd ytliga "lean-projekt" som uppvisar marginella förbättringar men som sällan orkar fortgå. Liker exemplifierar med en omvittnat "lean" organisation i USA som lät Toyota Supplier Support Center försöka förbättra en av produktionslinorna. Man ansågs vara ett föredöme i branschen, men när Toyota var färdig nio månader senare stod inte produktionslinan att känna igen. Dramatiska förbättringar av produktivitet, omloppstider, lagerhållning, och minskad övertid genomfördes, och detta på en organisation som av de flesta ansågs redan vara ett föredöme av lean.

Toyotas tänkande går dels djupare än vad många föreställer sig (särskilt i ledarskiktet, TPS är en lednings- och styrfilosofi), och ger dels mer dramatiska förbättringar än vad många kan tro är möjligt.

Nyckeln är lärande. Alla uppmanas att ständigt experimentera med arbetsformerna för att försöka finna nya och bättre sätt, och att sedan se till att dessa beteenden stannar kvar i organisationen. Med boken The Toyota Way hoppas Liker kunna sprida själva tänkandet till fler verksamheter än tillverkningsindustrin.

Sociokratiska principer

Sociokrati (gruppvälde) är en kraftfull organisationsform när det gäller att skapa livskraftiga värdeskapande samarbeten. Syftet är att bli av med toppstyren, men merparten av de sociokratiska principerna fungerar överallt där man arbetar i grupp.

Ansvar

Principen om ansvar (accountability) är den princip som får allt att fungera. Om inte varje individ i samarbetet tar ett personligt ansvar för hela samarbetet kommer vi att få ett dåligt samarbete. Det är den här principen som gör att vi kan lita på att överenskommelserna i systemet hålls och att kunskap om avvikelser sprids.

Empiri och transparens

Om vi ser på samarbetet som en organism så är empiri (empiricism) och transparens (transparency) de två principer som skapar nervtrådarna. Var vi är och vart vi är på väg måste vara synligt för alla. Vi ska inte låta oss styras av godtycke, varken vårt eget eller andras, utan använda empiriska metoder för att utvärdera alla beslut.

Effektivitet och ständig förbättring

Effektivitet (effectiveness, inte efficiency) och ständig förbättring (continuous improvement) är musklerna i samarbetet. Vi lägger bara tid på det som för oss närmare målen, och vi ser till att ständigt förbättra allt för att bli bättre på det.

Likvärdighet och medgivande

Det är dessa två principer som skiljer sociokratin från andra organisationsformer: att man värderar allas ord lika (equality), och att beslut kräver medgivande (consent) vilket ska förstås som "avsaknad av allvarlig invändning".

I en organisation som saknar sociokratiska ambitioner men vill bygga på samverkan i och mellan grupper är det ändå nödvändigt att reflektera över vilken syn på likvärdighet man håller sig med, och synliggöra vilka sorters medgivande som faktiskt krävs för att få igenom beslut. Det är inte ovanligt att även toppstyrda organisationer i praktiken är beroende av medgivande från golvet för att få något att ske.

Själva frågeställningen tydliggör och hjälper organisationen att förflytta sig i riktning mot ökad grad av delegering, vilket är nödvändigt om man vill ha agilitet.

[UPPDATERING: Som twitterkontot @sociokrati påtalar är dessa sju principer hämtade från en specifik implementation av det mer generella begreppet sociokrati, närmare bestämt det som kallas Sociokrati 3.0. Det finns andra implementationer, som t ex holakrati. Här finns lite information om historien. ]

Organisationsagilitet

Det finns en självklar anledning till varför sk "agila metoder" (samlingar av samarbetstekniker som gör samarbeten mer lättrörliga och smidiga) först vann popularitet inom system- och produktutvecklingen: man vet inte hur produkten (eller tjänsten) eller systemet helst ska se ut förrän man designat det, och det kräver ett antal omtag. Insikter uppdagas löpande.

(Och låt oss då påminna oss om att programmering är designarbete och att programkod är en detaljerade ritning av ett system.)

Men behovet av denna lättrörlighet finns även inom andra samarbeten. Marknadsföring innehåller en osäker koppling mellan insats och utfall. Investeringar innehåller en osäker koppling mellan insats och utfall. Ledning av ett bolag innehåller en osäker koppling mellan insats och utfall. I stort sett allt kunskapsarbete har ett behov av att gradvis utforska dessa osäkra kopplingar och vara beredd att byta riktning så snart man märker att det är det rimliga att göra.

Vi som sysslar med att göra samarbeten mer lättrörliga (vilket för närvarande oftast sker inom en teknisk leveransorganisation) ser behovet av att få omgivningen med oss. När vi i ett teknikprojekt på ett tidigt stadium, tack vare de agila metoderna, kan visa att effektmålen inte kommer att uppnås genom den plan och den budget som omgivningen beslutat åt oss, så är det oerhört tragiskt att se hur omgivningen saknar förmåga att byta fot även när vi presenterar data som visar varför det bör göras.

Från ett lättrörligt perspektiv ter sig projektkraschen som en katastrof i slow motion, en som hade kunnat undvikas.

Av detta skäl börjar nu fler och fler organisationer inse att det där med agilitet inte bara hör hemma inom en viss avdelning utan i helheten, och de börjar se sig om efter ramverk och metoder som kan hjälpa.

Om några veckor börjar jag ge en distanskurs i agilitet. Det blir en översiktskurs i 16 lektioner på åtta veckor, med lite inlämningsuppgifter och ett kunskapsprov. Eftersom det är första gången ger jag den gratis. Är ni intresserade kan ni anmäla ert intresse till ola punkt berg snabel-a fundament punkt se.

Den här kursen innehåller inget IT-specifikt alls. Den innehåller en översikt av lean och agila metoder för olika sorters verksamheter, där du lär dig att tänka i termer av flöden, mjuka överlämningar och svärmning runt arbetspaket, parallella takter, balansera långsiktigt och kortsiktigt arbete, arbete i olika cirklar, delegering av beslutsfattande, och uppföljning.

Du kommer också att lära dig om ramverket Synk, som är ett slags Scrum fast för alla slags arbeten.

Tills dess, några glimtar från ett föredrag jag och Piamia gav om det agila ledarskapet, tillsammans med Informator:

Agila projekt

Jag gav några skäl till varför agila metoder inte är speciellt kompatibla med projekt, om vi med projekt menar tillfälligt arbete i en tillfällig organisation, med ett fast mål till en fast kostnad och på fastslagen tid.

Det stora bakomliggande problemet är att tillfälligt arbete i sig är tveksamt, men låt oss anta att vi har ett tillfälligt arbete som kräver en tillfällig organisation. Låt oss också anta att vi har insikten om att målet inte är fast och att vi av det skälet sneglar på agila tekniker. Teknikerna i den agila familjen syftar ju till att få ett samarbete som kan jaga ett mål som flyttar sig.

Är inte det ett läge för ett agilt projekt då, trots motsättningarna mellan begreppen "agilt" och "projekt"? Jo. Men tänk på följande:

Som projektledare företräder du ett beställarperspektiv. Om du sneglar på tekniker från Scrum är det inte rollen som scrummästare du ska ha eftersom en scrummästare inte fokuserar på leveransen utan på samarbetet. Sikta istället på rollen som produktägare, och tänk på att ha produktägarrollen i Scrum inte är detsamma som att äga en produkt utan är en speciell roll som ska prioritera mellan delmål i leveransen.

Du ska inte följa upp på aktiviteter. Du ska följa upp på delmål. Kom överens med utförarna vad de ska ha uppnått inom några veckor och lämna dem i fred. Kom ihåg att påmina dem om att de ska ringa dig så snart de märker att de kommer att avvika från er överenskommelse, men så länge som telefonen är tyst finns inget behov av löpande uppföljning. Ta det när ni träffas nästa gång istället, då du får se resultatet.

En agil behovslista/backlogg spårar alla delmål till större mål, och dessa är i sin tur knutna till effektmål. Effektmålen ska inte vara rörliga, om ni inte uttalat jobbar med innovation och tänker er att ni ska pivotera (omdefiniera själva produkten eller vad ni nu gör). Det normala antagandet är istället att effektmålen ligger fast, men att insikten om vilka konkreta leveranser som behöver göras för att nå dem förändras.

Jobba med kontinuerlig nedbrytning av leveranser till mindre paket och var hela tiden beredd att omdefiniera paketen. Sikta alltid på att göra så lite som möjligt för att ta er närmare effektmålen.

Håll tiden och kostnaden fast, sikta på så stor effekthemtagning som möjligt, och kör på så länge som budgeten räcker. Eftersom leveranserna är små kommer ni alltid ha levererat någon nytta. Ni kunde hursomhelst inte gjort bättre, eftersom leveranserna baseras på den bästa information ni har tillgång till. Kan ni inte skapa nyttiga delleveranser löpande under projektets gång så ska ni inte försöka er på att köra agilt. Det blir bara en dyr besvikelse av alltihop.

Om det inte finns någon annan som kan lära ut självorganisationens svåra konst till utförarna så kanske du som projektledare måste ta scrummästarrollen. Men se då till att du faktiskt är mästare på Scrum så att du inte blandar ihop uppgiften att följa upp arbetet med uppgiften att hjälpa folk till självstyre.

Gemensamt ansvar

Många arbetsprocesser grundar sig i antagandet att en grupp människor inte förmår ta ett gemensamt ansvar för något, till exempel ett dokument eller en grupp arbetsuppgifter. Men det stämmer inte. Hade det stämt hade vi inte kunnat ha arbetslag som tar ett gemensamt ansvar för att leverera en viss mängd arbete under en eller ett par veckor, som vi gör i Scrum.

Att undvika att sprida ett visst ansvar genom att endast tillåta en enda individ att ta ansvaret fullt ut är ett beteende som kommer av den här tron. Det beteendet har stora kostnader i form av risk, rigid arbetsfördelning och att man skapar en flaskhals i flödet. Det hade ju varit bra om man kunnat ta bort den här begränsningen.

Oförmågan att ta ett gemensamt ansvar beror på två saker: ansvarsutspädning och brist på koordination. Bägge dessa faktorer är vanliga och naturliga, men de uppstår bara under vissa specifika förhållanden.

Ansvarsutspädning (diffusion of responsibility) är när en människa tror att någonting är någon annans problem och därför väljer att inte ta ansvar. Det beror bland annat på det som i psykologin kallas åskådareffekten. Om vi ser att andra agerar behöver vi inte själva agera. Om vi ser att andra inte agerar tror vi att de antingen redan har agerat eller att det inte är så allvarligt att någon behöver agera. På grund av denna mekanism har människor blivit överfallna mitt i folksamlingar utan att någon har reagerat.

Denna effekt slår till när vi är många som kan dela på ansvaret, när banden mellan oss är svaga, när det är otydligt hurpass allvarlig en situation är, samt när det är högstatuspersoner och ledarfigurer närvarande, för då tycker vår intution att det är deras problem.

I ett agilt arbetslag är vi däremot få, vi svetsar samman gruppen, alla uppgifter är glasklara, och vi har ingen uttalad chef inuti teamet. Istället har vi vår process som hjälper oss att koordinera arbetet, och vår förbättringsprocess som ständigt utvecklar processen.

Vi har tagit bort de faktorer som hindrar oss från att ta ett gemensamt ansvar. Vi hade kunnat välja att ha dem kvar, men istället väljer vi att ta bort dem.

[ PS: Här är ett par bra filmer om åskådareffekten! ]

Ett anspråkslöst förslag

Att resa en vägg mellan "verksamhet" och "IT" kostar mycket smärta (och pengar!). Av olika skäl har man trott att en beställare-utförare-modell för systemutveckling fungerar smidigare än att organisera sig runt de gemensamma värdeflödena, och nu lever man med att försöka hantera problemen som väggen skapar.

Ett av problemen är att "utföraren" får svårt att se genom väggen vilka "beställarens" behov är. Problemet manifesteras som en känsla av att beställningarna är otillräckliga. "Utföraren" behöver mer information i "beställningen", och i brist på andra vägar vill man öka informationsmängden i beställningsdokumentet.

Här behöver den agila varningsklockan i bakhuvudet slå till. Använd manifestet som tankehjälp: Vårt mål är en fungerande leverans, inte elaborerade dokument (punkt två). Vi gör det genom att skapa bra samspel mellan individer, inte genom att öka byråkratiseringen genom verktyg och processer (punkt ett). Det är tät samverkan mellan beställare och utförare som är framgångsfaktorn, inte att formuleringarna i beställningarna/avtalen är precisa (punkt tre).

Så här kan man göra för att riva väggen:

Gör beställningarna mindre! Det kostar "beställaren" att fylla i dokument, det kostar "utföraren" att läsa och förstå dem. Gör varje initial beställning en A4-sida stor: Det här önskar vi kunna göra, det här är syftet, så här mycket tänker vi oss att det får kosta, och de här riskerna ser vi. Rubrikerna är inte det centrala, det centrala är att beställningen är en A4-sida stor. Förslagen ska helt enkelt bli mer anspråkslösa.

Sätt samman en tvärfunktionell styrgrupp! Samla representanter med verksamhets- och IT-kompetens, dvs från det som förr kallades "beställare" och "utförare". Ge den gruppen mandat att bland de inkomna beställningarna välja ut dem som verkar vara värda att gå vidare med. Tänk på att balansera kostnad och värde, och prioritera de korta jobben framför de långa.

Använd behovsundersökande kravtekniker tillsammans! Det finns tekniker för att vaska fram de underliggande behoven (effektkartläggning och personas till exempel) och som av en händelse har jag utvecklat en kurs i ämnet.

Genom att driva kravflödet med gemensamma krafter river vi muren. I vår verksamhet skapar vi värde tillsammans. Att en del av det värdet skapas med hjälp av informationsteknik är inget skäl för att skapa konstlade väggar mellan människor.

Möten?

Läser denna bok om hur man faciliterar distansmöten och påminns om att aldrig ha ett möte utan att veta syftet.

Utmärkande för smidiga metoder är att vi oftast har väldigt strukturerade möten. Det beror på att varje möte ingår i en process med ett tydligt ingångstillstånd och ett tydligt mål. Inför arbetsplaneringsmöten vet vi prioriteringen bland arbetspaketen och vi vet hur mycket vi kommer att kunna arbeta under den närmaste perioden. Inför arbetsuppföljningen vet vi hur det gick under perioden och mötet handlar om hur vi ska agera på informationen. På ett förbättringsmöte använder vi strukturerade verktyg för att hitta vilka problem vi ska attackera och hur vi ska göra det.

På ett möte diskuterar man ibland saker, alltså belyser en fråga. Då använder vi verktyg som stöttar diskussionen, till exempel skapar ett faktaträd för att slå fast kända sakförhållanden eller visa på att ett sakförhållande är okänt, och så kan vi blottlägga och argumentera för våra värderingar och på det sättet skilja dem åt.

På ett möte innoverar man ibland. Då använder vi verktyg som stöttar innovation, till exempel verktyg som får oss att tänka stort och nytt och verktyg som får oss att smalna av och konkretisera och pröva värdet av de nya idéerna.

På ett möte beslutar man ibland saker. Då använder vi verktyg som stöttar beslutsfattande, på det sätt som vi vill att beslutsfattande ska ske, givet de maktstrukturer vi har och vill använda oss av.

Vad vi helst inte vill göra på ett möte: sitta ner och prata och bestämma sig ad hoc. Ad hoc-processer är alldeles för tyngda av dolda maktspel och oklara tankestrukturer. Dessutom tar de en förfärligt lång tid. Mötesverktyg snabbar upp processen eftersom de aktiverar hjärnorna på rätt sätt.

Det som krävs är tydlig facilitering, alltså att någon tar på sig att leda mötet med hjälp av de överenskomna verktygen utan att för den sakens skull kunna påverka utfallet mer än någon annan. Det är en lite klurig konst, men tack vare verktygen är den inte omöjlig och jag önskade verkligen att fler började använda dem. Alltför många klagar på tyngden av alla möten utan att göra något åt den.

SAFe "Feature" och Jira

I den lilla världen kan ett ensamt team leverera färdiga funktioner med bara några veckors (en sprints) mellanrum. Eftersom en funktion kan beskrivas i en sk "User Story" har man kallat de saker som ett team levererar under en sprint för just en "user story". Flera funktioner som hör ihop brukar kallas för en "epic".

Backloggverktyget Jira låter därför scrumteam hantera krav i ärenden av typen "Jira User Story", och flera sådana hanteras av den samlande ärendetypen "Jira Epic". I ärendetypen "Jira Epic" kan man följa upp hur varje ingående "Jira User Story" färdigställs.

Men om man måste skala upp det här? Om man inte kan leverera en funktion under en sprint utan behöver flera sprintar? Om det är mer än ett team som ska jobba med samma funktion? Alltså om arbetet med samma funktion måste delas upp mellan flera team och/eller delas upp över tid?

I Dean Leffingwells fyrdelade modell för en systemutvecklingsbacklogg (från Agile Software Requirements 2008, som senare blev ramverket SAFe) inför han därför en ärendetyp mellan user story och epic: en sk "feature". Tanken är att man på en övergripande nivå kommer fram till vilka funktioner man vill leverera, fångar var och en i en feature, och sedan bryts varje feature upp i mindre skivor av ett eller flera team och hamnar på deras respektive team-backloggar. På så sätt kan teamen följa upp hur de levererar en hel funktion även om de måste dela upp arbetet i delmål.

De sprintbara delmålen som hamnar på varje utvecklingsteams backlogg heter även i Leffingwells modell "user story". Så förhållandet i Leffingwells modell mellan "SAFe User Story" och "SAFe Feature" är precis densamma som i Jiras modell mellan "Jira User Story" och "Jira Epic". En "Jira Epic" delas upp i flera "Jira User Stories" på samma sätt som en "SAFe Feature" delas upp i flera "SAFe User Stories".

Samtidigt innehåller som sagt Leffingwells modell fortfarande begreppet "epic" ("SAFe Business Epic" samt "SAFe Architectural Epic"), och detta skapar förvirring när folk vill använda Jira för att hantera SAFe:s modell av backloggen. En "epic" i Leffingwells modell består av flera "SAFe Features" som i sin tyr består av flera "SAFe User Stories". En "epic" i Jiras värld består av flera "Jira User Stories" och det är allt.

Hur gör man? Tänker man uppifrån och ner så är det frestande att att beskriva "SAFe Business Epic" och "SAFe Architectural Epic" med hjälp av "Jira Epic". Det blir då på samma sätt frestande att använda en "Jira User Story" för att beskriva en "SAFe Feature". Men då orsakar man en massa svårigheter för alla andra i samarbetet.

En "SAFe Feature" ska inte ligga på ett enskilt utvecklingsteams backlogg utan på en sk "Program Backlog" för att hanteras på en överordnad nivå. En "Jira User Story" ska däremot handhas av ett team.

En "SAFe Feature" ska inte vara bunden till en viss sprint. I Jiras sprintplaneringsverktyg ska "Jira User Stories" bindas till en viss sprint.

En "SAFe Feature" ska kunna delas in (av teamen) i flera "SAFe User Stories", och varje "SAFe User Story" ska kunna estimeras och planeras och utvecklas av ett team för sig. Men om vi använt "Jira User Story" för att beskriva en "SAFe Feature", vad ska teamen använda för att kunna hantera sina "SAFe User Stories"? Hur ska de kunna göra sitt jobb om vi tagit verktyget från dem och använt det till annat?

Dessutom är det så att Jiras styrka är möjligheten att bringa ordning i en mängd arbetspaket och hur de förhåller sig till varandra. Det finns altid många fler "SAFe User Stories" än "SAFe Features", och många fler "SAFe Features" än "SAFe Epics". Det verkar vara dumt att slösa ärendetyper i Jira på att hantera ett fåtal saker som dessutom sällan förändras. Effektmålen och förutsättningarna för varje epic tenderar att vara stabila, det är informationen om hur epicen ska implementeras (vilket fångas i features och user stories) som förändras ofta och kräver verktygsstöd.

Så det rimliga är såvitt jag har sett att använda "Jira User Story" för att fånga en "SAFe User Story", och använda "Jira Epic" för att fånga en "SAFe Feature". Jag har sett konsekvenserna både av att använda Jira Epic för epic och för feature, och det blir oerhört trassligt för teamen att kunna koordinera sitt arbete om de inte får använda Jira User Stories för sina teambackloggar.

Vad ska man använda för att fånga sina "SAFe Epics" då? Man kan använda "Jira Epics" och länka till andra "Jira Epics" som fångar features. Man kan använda ett annat verktyg. Jag har goda erfarenheter av antingen en mapp i ett filarkiv (under versionskontroll), eller en wikisida per epic (kanske i Confluence, Jiras syskon som är en wiki). Låt sedan de "SAFe Features" som tillhör denna epic peka ut länken eller sökvägen dit. Sätt en "label" på din "Jira Epic" (="SAFe Feature") som beskriver vilken epic det rör sig om. Ha ett prefix i namnet på varje "SAFe Feature" som pekar ut vilken epic det rör sig om.

Det enda argumentet som jag tycker håller emot tanken att använda "Jira Epic" för att hantera en "SAFe Feature" är att man tyvärr inte kan ordna sina "Jira Epics" i en sträng ordning. Man kan alltså inte prioritera sina "SAFe Features", sin "Program Backlog", på samma sätt som andra backloggar. Men i praktiken har jag sett att det inte är något problem. På epicnivå handlar det inte så mycket om att prioritera "SAFe Features" löpande, utan om att bestämma vilka som ingår i en viss epic och vilka som inte gör det. Behovet av att dra-och-släpp-sortera sin programbacklogg är långt mindre än behovet av att dra-och-släpp-sortera teambackloggarna. Det är teamen som har det största behovet av "Jira User Stories", så låt dem använda dem till sina "SAFe User Stories".

När man skapar ett smidigt lean/agilt flöde börjar man från flaskhalsarna och arbetar sig bakåt. Eftersom utvecklingsteamen är den trånga sektorn behöver vi uppfylla deras behov av smidigt verktygsstöd först. Fungerar inte golvet smidigt kommer ingenting att fungera smidigt.

Kniberg om storskalighet

Henrik Kniberg gav ett föredrag om storskalig agil utveckling nyligen, och av döma av sammanfattningen på InfoQ (se länken) så var det ett bra föredrag med observationer som är helt i samklang med mina.

Jag gillar särskilt att han trycker på att man måste förstå varför man skalar. Storskalig agil utveckling är inget eftersträvansvärt. Om en liten grupp människor oberoende av omgivningen kontinuerligt kan leverera nyttigheter som möter människors behov så är det att föredra. De storskaliga teknikerna tar vi till när vi måste koordinera fler än en handfull personers arbete och/eller nyttigheterna tar lång tid att leverera.

Det kluriga är alltså hur teamen kan hålla sig i synk med varandra och hålla ordning på beroendena mellan dem. Henrik pratade om tre grundläggande frågeställningar man behöver ha svaren på:

1. Hur man bryter ner det arbete man ska göra ("slicing the elephant").
2. Hur man bör organisera arbetslagen (ta reda på vilka människor som bör göra vad).
3. Vilka återkopplingar ("feedback loops") som behöver finnas för att koordinera arbetet.

Det är en konkret lista som matchar observationen att man först behöver ta reda på vad man ska göra innan man börjar fundera på organisationsformer och samarbetsmetoder (se Jim Womacks 3P).

Kruxet när man hanterar skalning är att det hela tiden är fråga om avvägningar, något som Henrik också trycker på. Om vi organiserar arbetslagen på ett sätt kommer behovet av återkopplingarna bli ett. Om vi organiserar arbetslagen på ett annat sätt kommer behovet av återkoppling bli ett annat.

Henrik påmminer om att det alltså därför inte kan finnas något rätt eller fel, utan varje organisation måste hitta sina avvägningar utifrån sina behov. Man kan inte hitta ritningar som automatiskt passar flera.

Det jag stannar upp inför är den svåra frågan om hur man fördelar ansvar mellan team. Man kan organisera sig utifrån lösningens bakomliggande komponentstruktur, men det betyder att varje levererad nytta (som ju sker i ett samspel mellan lösningens komponenter) kräver stor koordination mellan komponentteamen. Det är min och hela branschens observation att om det är möjligt ska man istället skapa team som inom sig själva kan leverera hela nyttor (sk "feature teams").

Men i organisationer som har en tillräckligt komplex miljö går det inte att sätta samman team som klarar av att leverera hela nyttor. I de enkla fallen, som i Henriks exempel med en trelagersarkitektur (klient, server, databas) är det förstås möjligt. Men om plattformen är krångligare än så? Teamen blir då antingen för stora, eller så blir de inte stabila utan behöver göras om inför varje ny nytta.

Vi kan sikta på att hålla nere antalet team som krävs per nytta, men det kommer ändå att uppstå ett behov av att för varje sak man gör koordinera mellan åtminstone två team, dvs situationen blir precis som den som Henrik varnar för (se bilden med det ledsna ansiktet vid "Coupled teams"). Det är trögt att få till agilitet i den situationen.

Men det går! Man kan använda smidiga synkroniseringstekniker som gör ansiktena betydligt mindre ledsna, och i de organisationer där jag har ramlat på den här situation har vi använt dem med någorlunda framgång. På samma sätt som smidiga tekniker får individer att jobba bra ihop i team kan smidiga tekniker få team att jobba bra ihop i olika och växlande konstellationer.

En del av de teknikerna utgår från det som Henrik visar i bilden om hur team kan synka med varandra. Organiserar man sig utifrån mönstret "Team of small teams" man man skapa stabila samverkansformer mellan teamen som tar bort en del av synkroniseringssmärtorna. Min erfarenhet är att samma tekniker med framgång kan användas om man organiserar sig i "Team of team of small teams" eller "Web of team of small teams". Det som krävs är en synkronisering på övergripande nivå där organisationen kan ge klara besked om syfte och prioriteringar, så att alla teamen vet vad de ska sträva efter.

Agility - ny plansch

I mina kursmaterial finns det översiktsbilder som förklarar olika koncept. Ny har jag börjat bryta ut dessa ur dokumentationen och publicera dem som separata PDF:er.

PDF med grundläggande information om agilitet.

Disciplin

Agila metoder erbjuder lättnad för hårt ansatta arbetslag. Otydlighet försvinner, vi tvingar omvärlden att fatta prioriteringsbeslut, vi hålls inte längre ansvariga för osäkra estimat, ledningen tvingas anpassa sin karta efter den faktiska terrängen, vi får styra över vår tid själva, med mera.

Men för att detta ska fungera krävs disciplin i arbetslaget. I samma sekund vi märker att vi inte kommer att uppfylla förväntningarna på oss måste vi larma intressenterna. Har vi en överenskommelse om klarkriterium för olika arbetspaket och leveranser, så ser vi till att vi håller de överenskommelserna. Eller så rapporterar vi avvikelsen. Vi låter inte strukturella problem kvarstå utan arbetar med rotorsaksanalys och ständigt förbättrade arbetssätt för att ta bort dem

Omgivningen kan lita på ett agilt självorganiserande arbetslag. Laget måste inom sig själva ha den förmågan att hantera sig själv, annars fungerar inte självorganisationen.

De 12 agila principerna bakom det agila manifestet slår fast att ett agilt arbetslag strävar efter excellens i leveransen. Exakt vad det innebär kommer man fram till genom bra samtal med sina intressenter, och det man kommer fram till, det håller man.

Utan denna disciplin och förmåga till självstyre fungerar inte de tekniker vi vanligen använder för att få till mer smidighet.

Resiliens

Beteendeförändring med agila metoder driver som sagt kulturförändring, men det krävs att man inte gör avkall på vissa hygienfaktorer.

När man startar förändringen behöver den grupp som förändringen startar i få ett skydd mot blockerande faktorer. De får inte utsättas för osäkerhet: antingen är deras arbetsuppgifter och omständigheterna för dem kända på förhand, eller så ska det finnas en tydlig process för hur de hanterar plötsliga förändringar i målbilden.

De får inte heller vara osäkra på vilka mandat de har, och de ska ha mandaten i praktiken och inte bara i teorin. Har de rätt att bestämma en viss sak ska inte deras beslut plötsligt överprövas. Var mandatfördelningen ett misstag kan man alltid ta upp det och justera den, men det ska inte ske ad hoc utan i den vanliga strukturerade förbättringsprocessen (för en sådan har ni väl?).

I de fall där jag får lov att vara med och leda själva förändringen följer jag alltid inflödet av arbetsuppgifter (målbilden) långt utanför gruppen. Ju längre "uppströms" jag kommer och fortfarande ha inflytande över flödet, desto stabilare flöde kan jag etablera. I värsta fall är hela omgivningen runt teamet skakig, och man får införa de stabiliserande verktygen i själva teamet. I en mer mogen organisation är omgivningen runt teamet villig att påverka sina egna arbetsrutiner för att inte skapa onödig ryckighet i beställningsflödena.

På samma sätt utforskar jag linjeorganisationen runt teamet: vilka mandat och förmågor har man, och vilka av dem är man villig att delegera till teamet? I värsta fall har man ingetdera, och då får man istället skapa synlighet i hur det dåliga arbetsresultatet beror på avsaknaden av möjligheter.

Det viktiga är att eliminera osäkerheten. Otydligheten.

Osäkerhet på vad man förväntas leverera och osäkerhet på vilka medel man har, det skapar en stress som triggar defensiva beteenden hos alla inblandade. Precis alla beteenden vi önskar i en agil transformation (till exempel lättrörlighet, påhittighet, samarbete, frihet från skuld och skam, synlighet) blockeras av defensiva beteenden.

Många har genom åren blivit förvånade över att jag inte börjar förändringen i teamet utan istället tittar på teamets miljö, men det är alltså för att se om det går att göra något åt miljön. Kan man påverka mijön direkt slipper vi hjälpa teamet att använda tekniker avsedda för att få ett team att förbli någorlunda produktiva i en destruktiv miljö. Att organisationen lägger resurser dels på att skapa en dålig miljö och sedan på att skydda teamen ifrån dem är rent slöseri.

Kultur är konkret

"Agilt är en mental beredskap att hantera förändring!" "Agilt bygger på tillit och engagemang!" "För att få agilt att fungera behöver du en kultur som inte går ut på att skuldbelägga!"

Så kan det låta. Och det är sant. Det krävs ofta ett kulturskifte för att få större organisationsagilitet. Och folk är ganska ofta medvetna om att kulturen behöver ses över. Men jag vet inte hur många gånger jag sett att man försöker sig på resan mot större agilitet utan att samtidigt ge förutsättningar för kulturskiftet.

Man stöter ibland på uppfattningen att kultur är något svårgripbart, men att man automatiskt förändrar den om man bara vet om att den behöver förändras och pratar riktigt mycket om förändringen. Men det stämmer inte.

Om vi tänker på kultur som de grundläggande förväntningar vi har på vårt eget och andras beteende inom ett sammanhang, så förstår vi att vi kan påverka kultur på precis samma sätt som vi kan påverka förväntningar överhuvudtaget. Hur vi talar om saker och ting spelar förstås roll, till exempel om vi ens har begrepp för viktiga saker. Det är svårt att skapa en mer empatisk kultur om inte människorna däri har tillgång till ord som beskriver hur vi känner oss och hur det påverkar.

Men den starkaste kulturbäraren är summan av alla faktiska beteenden. Det är hur vi själva och andra faktiskt agerar som bestämmer våra förväntningar. Det är därför folk har fel som påstår att man inte kan skapa ett kulturellt skifte genom att byta arbetssätt. Det är just genom att byta arbetssätt som det kulturella skiftet sker.

I de fall där ett utbytt arbetssätt inte lyckats förändra någon kultur finns det ofta tre bakomliggande skäl:

Ytlig förändring - Det nya arbetssättet har inte utmanat de befintliga kulturbärande praktikerna. Man kan till exempel ändra vilka som är med på vissa möten, men om man inte ser över själva beslutsmakten också kommer mötesnärvaron inte att göra någon större skillnad. Man kan byta begreppsapparat, men så länge som det inte medför någon förändring i beteendet spelar bytet ingen roll.

Kvarvarande blockeringar - Även när man låter det nya arbetssättet gå på djupet måste man också se till att kvarvarande blockeringar faktiskt upphävs. Man kan till exempel införa en planeringsrutin som optimerar på att ärenden ska handläggas snabbt, men om det finns kvar en uppföljning som optimerar på beläggningsgrad per handläggare är risken stor att beläggningsgraden bedöms vara viktigare än snabbheten, och förändringen får ingen effekt.

Ingen ståndaktighet - Ett skifte i beteende som på allvar utmanar den befintliga kulturen kommer att möta motstånd. Inte nödvändigtvis på grund av att människor vill göra motstånd, utan på grund av tusen små inbyggda skäl i den befintliga organisationen. En förändring i beteendet som är i samklang med den befintliga kulturen, i samklang med vad som uppfattas som naturligt, den sätter sig mycket fort. En förändring som utmanar den befintliga kulturen tar mycket längre tid på sig att sätta sig. Man behöver alltså tvinga sig till det nya sättet att agera på under mycket längre tid, om det nya sättet på allvar driver kulturförändring.

Det är här många tar miste. De erfar motståndet, och så drar de slutsatsen att det inte går att genomföra förändringen om man inte först förändrar kulturen, och lägger ner precis den förändring som hade åstadkommit ett kulturskifte om de bara orkat hänga kvar och hålla i.

Det här betyder inte att motstånd betyder att du är på rätt väg. Den förändring du vill genomföra kanske är till det sämre? Du kanske möter motstånd på goda grunder? All förändring är inte till det bättre. Men antag att det du vill åstadkomma är det? Motstånd är naturligt. Om du vill skapa den förändring i kultur som krävs för att organisationen ska bli mer agil så behöver du hålla fast vid de nya beteenden som speglar den nya kulturen. Och de beteendena kommer att skava, tills den kulturella förändringen har satt sig.

Tre kärnprocesser

Det finns många processer inom förvaltningsramverk. När folk skapar processramverk börjar de med de viktigaste processerna. Sedan lägger de på fler och fler tills de ser att allt som krävs är på plats. Problemet uppstår för folk som sedan ska börja tillämpa ramverken. Hur ska de kunna identifiera kärnprocesserna? Kunna skilja det viktiga från det oviktiga?

Det finns tre processer som är särskilt centrala i tjänsteförvaltningen, eftersom de direkt styr över hur tjänsten ser ut:

1. Förändringshantering (Change Management) - hur vi ska förändra tjänsten.
2. Incidenthantering (Incident Management) - hur vi hanterar avbrott och störningar i tjänsten.
3. Problemhantering (Problem Management) - hur vi hanterar de bakomliggande orsakerna till avbrotten och störningarna.

Dessa tre hänger intimt samman. Det är förändringarna som vi genomfört som ger upphov till incidenterna, och de bakomliggande problemen behöver en förändring för att kunna lösas. Samtidigt är bandbredden i utvecklings- och förvaltningsorganisationen ofta stabil och ändrar sig inte så ofta, så vi måste hela tiden bestämma oss för om vi ska använda tiden till grundligt problemlösningsarbete eller till att täcka över bristerna med snabba fixar under tiden vi försöker fokusera på en större förändring som förhoppningsvis får incidenterna att sluta.

I organisationer där man försöker separera dessa tre processer får man problem. Separationen är ett sätt att dölja den starka kopplingen. Vill man istället behålla förvaltningen agil kan man centralisera besluten till en och samma gruppering som prioriterar det som behöver göras genom att bestömma över behovslistan och vara de som ytterst godkänner det sätt som den operativa personalen hanterar och värderar incidenter på.

[En liten observation från ITIL: Den förändringshanering (Change management) jag pratar om här är större än CM-processen i ITIL. Den innefattar hela förändringens livscykel från förslag till driftsättning. Tänk också på att ITIL på oklara grunder har förlagt Application Development till transitionsfasen istället för att se det som en del av tjänstedesignen. Om vi tänker på transitionen enbart som utrullning av implementerade förändringar och låter designfasen innefatta allt som har att göra med utvecklingen av dem, så blir det mer logiskt givet hur utveckling fungerar (utveckling är design) och mer kompatibelt med de agila arbetssättens prövande iterativa metoder.]

En projektskeptikers bekännelser

Jag har på sistone varit inblandad i en del diskussioner om projekt. Dels i de uppdrag jag har, dels i flera diskussioner på konferenser och på nätet. Jag menar ju att projekt ofta innebär stora hinder för agilitet i organisationer, om vi med projekt menar ett arbete av tillfällig karaktär i en tillfällig organisation, mot ett fast mål till en fast tid och kostnad.

Till att börja med håller jag med att om arbetet verkligen är tillfälligt, som en enstaka förändring inom ett område där verksamheten normalt inte förändrar sig, så är det nog projektarbete som krävs. Ett projekt är som en byggnadsställning av tillfällig organisation, planering, resursförsörjning, och styrning. Vi tar till det när vi gör vår ombyggnad, men annars inte. Men projektet kräver att den ordinarie verksamheten släpper till och underordnar sig projektets plan och behov. Annars får vi förseningar och målkonflikter och andra stora strukturella kostnader.

Hade projekten bara dykt upp i de sammanhangen hade jag inte haft så mycket emot dem. Men jag ser organisation efter organisation som kör flera projekt, både efter varandra och parallellt, och ofta utan att kunna leda och styra dem i förhållande till varandra. Vilket inte är så underligt, jag har ännu inte sett en projektmodell som bygger på konstant anpassning av den egna planen i förhållande till alla andras planer. Tvärtom verkar de projektmodeller som finns vara byggda för att driva den egna agendan främst. De är inte gjorda för att köras parallellt med hänsyn till varandra, utan de inkräktar snarare på varandras resurser och bemanning.

Portföljstyrningsmodellerna jag sett har inte heller varit inriktade på att styra projekten smidigt mot varandra, utan handlar om att starta och följa upp projekten som vore varje projekt oberoende av det andra.

När man sedan ser till innehållet i projekten kan man ifrågasätta hurpass tillfälliga de är. Det är sant att just den här genomgripande förändringen av våra datasystem varken har skett förr eller kommer att se senare. Men nästa kvartal har vi en ny förändring, och kvartalet därefter har vi ännu en förändring. Att förändra datasystemen är helt enkelt en del av vår verksamhet. Ja, att implementera just detta EU-direktiv i förvaltningen är säkert en engångsföreteelse. Men nya EU-direktiv dyker upp regelbundet. Att implementera dem är vårt jobb. Att utveckla nya bilmodeller är vårt jobb. Och så vidare.

Projekt är disruptiva i sin natur, och tanken är att vi ska ta till dem när vi ska vara disruptiva. Men disruption har en oerhört hög kostnad. När vi dessutom släpper lösa flera parallella disruptioner ska vi kanske inte bli förvånade om vårt värdeutflöde i organisationen blir väldigt lågt, eller om projekten börjar lägga krokben för varandra. Naturligtvis oavsiktligt, det här är ett systematiskt problem och inte resultatet av någon människas illvilja eller inkompetens.

En av projektmetodernas styrkor är att man sätter samman en tillfällig organisation som ofta blir mer tvärfunktionell än vad den befintliga linjen är. När en linjeorganisation i sig själv saknar förmåga att agera effektivt tvärfunktionellt så erbjuder projektmetoderna ett sätt att frigöra kraft och planera och leverera. Men då finns det ett alternativ som innehåller fördelarna från projektarbetet men utan flera av dess nackdelar, nämligen att ge linjen den planerings- och leveransförmågan. Istället för att tillfälligt åtgärda linjens brist på kompetens med en tillfällig organisation, så angriper vi rotorsaken och förändrar linjen. Det är här flera av teknikerna i lean och den agila traditionen hjälper. Vi identifierar värdeströmmar, och ger linjen förmågan att svärma runt värdeströmmarna och att förändra sig dynamiskt när värdeströmmarna förändrar sig.

Det tar tid för en organisation att sätta sig och börja leverera. Att betrakta organisationer som tillfälliga strider emot det vi vet om människors behov av stabila sociala sammanhang för att kunna arbeta effektivt i team. Det hade kunnat fungera om deltagarna i projekten fått lov att fokusera på ett och samma projekt. Men i den stund vi låter olika personer ingå i olika tillfälliga projektkonstellationer så får inte längre dessa människor ett gemensamt syfte. Och det som driver den mänskliga grupputvecklingen är just samlingen runt det gemensamma syftet.

När vi inför lean och agila metoder försöker vi i görligaste mån undvika omorganisation och disruptiva ändringar i arbetssätt. Man kommer av och till att behöva disruption, men grundläget är att i den befintliga organisationen börja med ständig förbättring och skapa en linje som har förmåga att förändra sig själv. Organisatonsförändring är i lean inget avslutat utan en ständigt pågående process. Man startar resan, men det finns inget slutdatum. Det gör att även om vägvisarens närvaro är tillfällig, så är inte förändringen ett avslutningsbart projekt. Det börjar, och fortsätter, och fortsätter.

Mitt största argument för att projekt är oagila i sig själva gäller synen på planer och genomförande. Även när arbetet verkligen är tillfälligt så att ett projekt borde vara det bästa, så är det många sorters arbete som inte är förutsägbara. Varken mål, tid, eller kostnad kan slås fast på förhand. Vi vet inte exakt vilka aktiviteter som krävs. Vi vet inte vad som kommer att hända. Här brukar projektvänner protestera och mena att det ju visst går att genomföra projekt utan att veta allt detta. Hela tanken med agila projekt är att användas i dessa lägen, säger de.

Problemet är att jag har ännu inte sett en projektmodell som accepterar förutsättningarna att varken mål, tid, eller kostnad kan slås fast. Finns en sådan modell? Använder folk sådana modeller? Får jag komma och titta på och lära mig mer om agila projekt?

Samtliga projektmodeller jag sett, från de etablerade Props och Pejl till olika sorters hemmabyggen, bygger på att man efter en förstudie har en uppsättning aktiviteter som ska utföras i sekvens, i enlighet med en tidplan man tar fram. Jag förstår att man i teorin kan driva projekt agilt, i betydelsen använda samarbetsteknikerna i den agila traditionen inom en tillfällig organisation, och jag har sett det göras, men då har det skett genom kraftiga avsteg från de regler man normalt har om på förhand fastslagen budget och uppföljning på aktivitetsnivå.

Beställare och styrgrupp har ofta upplevt den situationen som oerhört obehaglig. De har inte kunnat få några leveransplaner eller realistiska kostnadsindikationer eller någonting sådant de behöver för att kunna styra projektet. Men styra behöver de, eftersom det agila arbetssättet kräver en ständig omplanering och omprioritering. Men vilka parametrar ska de styra efter?

I en agil linjeorganisation klarar du av ett agilt arbetssätt, för där finns hela tiden en upparbetad struktur som ger dig indikation om leveranskapaciteter och flödeshastigheter. Lärdomarna och insikterna återförs kontinuerligt, samarbetena är upparbetade och vana, larmvillkoren tydliga, processen för att kontinuerligt bryta ner långsiktiga planer till kortsiktiga delmål är på plats och fungerar, och du vet vilka effektmål du hela tiden ska styra efter.

Utan stödet från en agil linje blir det agila arbetssättet oerhört skört. Jag skulle inte våga tillämpa agila arbetssätt i en projektkontext om inte projektet var såpass stort så att det hann etablera alla dessa strukturer innan det var dags att avsluta det. Och när en organisation har tagit den investeringen i strukturerna, varför ska den egentligen riva upp dem? Kan inte strukturerna finnas kvar och fortsätta leverera värde?

Observera att detta inte är en kritik mot projektledare. Själva koordineringsarbetet som projektledare är duktiga på behövs i hög grad inom en agil organisation. De projektledare som är vana vid att detaljstyra individer på timnivå behöver ta ett par steg tillbaks och börja sätta upp mål för team på veckonivå istället, men förmågan att planera och koordinera är ännu viktigare i en agil linje där vi omplanerar och omformar oss regelbundet. Det är de inbyggda strukturella effekterna av projektarbete jag vänder mig emot (utom i specialfallet jag nämnde inledningsvis), och jag hoppas att fler organisationer inser att det finns alternativ som har förmågan att hantera en föränderlig omvärld över tid istället för tillfälligtvis.

Läs mer om vad jag tänkt om projekt.

Övervakning är slöseri

Att övervaka en process är slöseri.

Övervakning är att flytta information. Information kan bara flyttas från en hjärna till en annan, och även i de bästa informationstransporteringsmetoderna försvinner mängder med information i själva flytten. Även värdefull informationsförflyttning lider av spill, eftersom vår förmåga att rätt förstå varandra är så bräcklig.

Att övervaka en process som fungerar är uppenbart slöseri. Det som sker det sker, och att en eller flera människor tittar på höjer inte värdet. Att övervaka en process som inte fungerar är lika mycket slöseri. Att se saker fallera höjer inte heller värdet.

Övervakning kan vara ett nödvändigt slöseri (necessary waste). Om risken att något förbises är 10 %, så sänks risken till 1 % vid dubbelkontroll. Kostnaden för en defekt kan vara så stor att övervakning (sk framfiltrerad kvalitet) är billigare än alternativen just nu. Men det är likväl ett slöseri, och lösningen är att ta bort själva behovet av övervakningen.

John Seddon lanserade begreppen felbehov (eller falskt behov) och värdebehov ("failure demand" och "value demand"). Ett felbehov är behov av att vi gör något på grund av att något blivit fel. Att behöva torka upp en massa spilld färg för att vi varit oförsiktiga när vi målade om till exempel, eller att behöva gå efter med en pensel för att fylla i allt det vi missade första gången. Det ser ut som värdeskapande eftersom vi sänker värdet om vi inte gör det, men det är i grunden ett onödigt jobb om vi hade kunnat göra det rätt första gången.

Övervakning är failure demand. Vi behöver den bara om vi inte kan lita på en process. Men vad säger att vi kan lita på övervakningen? Om processer behöver övervakas och övervakning är en process, vilka ska då övervaka övervakarna? Och om övervakningen är en mer felfri process än den övervakade processen, hur kom det sig? Kan vi använda samma tekniker för att felsäkra den övervakade processen till att börja med?

Övervakning har alltid en kostnad. Förutom kostnaden för själva övervakningen i tid och material så kostar det i uteblivna möjligheter. Vi kan ju använda tiden till något annat. Men dessutom för övervakningen med sig en massa systemkostnader. Nyckeltal riskerar att missförstås och driva felaktiga beteenden. Vi bygger bort tilliten. Övervakningen ger en falsk känsla av säkerhet.

Den enligt mig värsta systemeffekten är denna: om arbetsprocessen är fastlåst i en överbyggnad som övervakar alla dess delar så blir arbetsprocessen väldigt svår att förändra lokalt på den nivå där man tydligast ser bristerna. Övervakningen gör det alltså svårare att undvika defekter och avvikelser. Gör det väldigt svårt att arbeta med ständig förbättring.

Vad är alternativen till övervakning? Arbeta med inbyggd kvalitet istället för framfiltrerad. Arbeta med att felsäkra processen, alltså att göra det svårt att göra fel. Att istället för generell övervakning låta människor närmast felkällorna hålla ordning på ett fåtal viktiga larmindikationer och ha en överenskommen process för hur man reagerar på avvikelserna. Använd naturliga och smidiga informationsspridare istället för krav på rapportering.

Här vilar ansvaret på er som beslutar om arbetssätt och processer och verktyg. Känner ni till den samlade effekten av kontrollsystemen? Kan ni minimera behovet av informationsförflyttning genom att använda spridare? Har ni en handlingsplan i era ledningssystem för hur ni ska agera på varenda en av datapunkterna? Kan ni delegera ansvar närmare golvet för att göra återkopplingslooparna kortare och slippa agera själva? Det finns metoder för att ta sig ur den här situationen. Övervakning är hursomhelst slöseri och väldigt sällan svaret.

Läs gärna också denna lilla artikel om byråkrati versus professionalism i ideella organisationer. Det mesta i artikeln är tillämplig på alla organisationer.

ALMA: Two levels of governance

Condition

When you want to govern a service, or a group of services, through the life cycle, but you don't want to be overburdened by bureaucracy.

Solution

Put together a central cross functional service management team. This team should be broad enough to have all relevant competences and perspectives to answer all questions about what is the most meaningful to happen with the service.

The service management team doesn't need to have the competence to actually realize it. For that you put together service maintenance teams (for instance service desks, service development teams or service operation teams, or combinations thereof). The maintenance teams should have all needed competences to realize what the management team prioritize. In order to avoid handovers, and to keep a broad and deep knowledge level in the management team, representatives from the maintenance teams must be parts of the service management team.

Description

While the identification of several roles and different groups in life cycle management frameworks such as ITIL or PM3 is important, it is also observed that this can lead to unnecessary organizational complexity.

There are basically four responsibilities when taking care of a service: managing capacity/capabilities and changes thereof, and when things go wrong: managing the incidents and solving the underlying problems. Instead of appointing different managers for these processes you can put together a single management team (of maximum 9-10 persons ideally) that is capable of making all decisions regarding resource allocation, policies, and prioritization. Then let the team sort out how they distribute responsibility among themselves, or if they should delegate some of it to others.

The management team should work closely with the maintenance teams, having representatives present when the maintenance team plans and follow up on their own activity, and having representatives from the maintenance teams in the management team. In order to keep it agile we must minimize handovers, align the mandates with the abilities, and always make our decisions based on empirical evidence and deep understanding of what is happening on the floor, close to the customer. Both the management team and the maintenance teams are regarded as governance teams that collaborate in governing the services.

All common agile principles about transparency and self-organization apply here.

The management team should maintain the vision and the plan. The plan should be continuously updated with correct data about velocities so that forecasts, if you need them, are kept accurate. Experience has shown that this can be accomplished if the management team meets regularily 1-4 times a month.

History

Groups like the management group are prescribed in a lot of frameworks. What we've done in order to keep it agile is basically to merge all these groups into one. The idea of assigning responsibilities and accountability to a group, and then let the group sort out how they distribute the responsibility, is a common organizational pattern in team focused lean and agile. Having mutual representation between two groups is used in sociocracy, a governance system based on self organization. Emphasis on cross-functionality of the teams in order to reduce handovers and improve lead time is a common Scrum construct.

Personligt ansvar och misslyckande

För att lyckas med lean och agilt krävs både disciplin och personligt ansvarstagande. Det ställer krav på våra beteenden, och ytterst är det bara vi själva som kan ta ansvar för vad vi gör.

MEN denna insikt måste tillämpas i ljuset av vad vi vet om vår mänskliga oförmåga att rätt förstå orsak och verkan. Vi människor lider av en benägenhet att tro att det som sker alltid sker med avsikt. Vi har till exempel lätt för att se regelbundna mönster i slumpvisa utfall och vi har lätt för att tro på magi och att universum beter sig meningsfullt, även när inga orsakssamband kan påvisas.

När vi tillämpar de här intuitionerna på människor betyder det att vi får lätt att ge varandra skulden för att saker och ting sker, även när utfallet beror på omständigheter utanför folks kontroll. "Du gjorde det med flit!" säger det lilla barnet. Psykologerna kallar detta varianter på det fundamentala attributionsmisstaget: tron att beteenden mer beror på folks karaktär än på omständigheterna.

Lean och agila metoder bygger på ständig förbättring med empiriska metoder, dvs att vi analyserar de komplexa samband som faktiskt orsakar ett visst utfall, och sedan åtgärdar dem. Ett av de vanligare hindren i införandet av agilt är när ledningssystemen i organisationerna istället tillåter chefer att utifrån sina intuitioner påföra människor skuld och skam. Resultatet blir dels att de verkliga orsakerna inte åtgärdas ("Nu vet vi vems fel det var och därmed behöver vi inte göra mer"), och dels att vi får en skammande kultur som blockerar processutveckling och förhindrar folk att ta ansvar för helheterna ("Om jag gör rätt enligt mina instruktioner så slipper jag kritik, även när det leder till sämre totalresultat.")

För att få agilitet måste man istället införa ett ledningssystem som påbjuder medarbetardriven förbättring på empirisk grund. Chefer måste bli varse både sin egen oförmåga att rätt se samband mellan orsak och verkan, och förstå att deras status i hierarkin gör att deras personliga föreställningar lättare fortplantar sig. En chef i en lean/agil organisation måste vara ett föredöme i att skapa en kultur utan skuld och skam, och kunna lära ut rotorsaksanalys och att felsäkra arbetet. Begår folk farliga misstag är det för att organisationen, dvs ytterst dess ledning, har valt att möjliggöra farliga misstag.

Det är känt från psykologin att påförandet av skam leder till en tro att det är något fel på en själv. Det gör att man i en kultur som påför skam inte vill ta ansvar för sitt agerande. Tror jag att mitt agerande beror på hur jag är (dvs en dålig person) blir alla frågeställningar runt problematiska beteenden väldigt jobbiga att närma sig. I en kultur där man istället ser problemen för vad de är: utfall av komplexa samband där våra ageranden utgör en (väldigt situationsberoende) del, där är det lättare att tillsammans erkänna detta och också hitta konstruktiva lösningar på problemet.

Så tänk er för när ni utformar era ledningssystem. Hur ska cheferna agera för att stödja er transformation mot större agilitet?

Hela verktygslådan

En bieffekt av att agila metoder sprider sig är att antalet personer som har en begränsad uppfattning om verktygen ökar. Det går an när de själva känner sin begränsning, men det blir ett problem när de tittar på till exempel Scrum och tror att denna enda lilla verktygssamling på något sätt representerar helheten.

Agilitet är till att börja med inte ett antal metoder utan ett tillstånd i ett samarbete (lättrörligt och flexibelt). Det är en observation att detta tillstånd lättare uppnås om vi väljer arbetssätt utifrån ett antal principer och värderingar.

Det är visserligen sant att det mesta inom agilt har formulerats inom systemutveckling, men kärnvärdena och principerna är universella: Möt människors behov genom att leverera snabbt, ofta, och med hög kvalitet. Detta kräver smidigt samarbete mellan alla inblandade människor, att vi även blandar i kunden, att folk nära kunden och golvet får bestämma mycket själva, att folk med olika kompetenser samarbetar på djupet, att signaler om ändrade förutsättningar kommuniceras blixtsnabbt till alla, att folk besitter hög grad av engagemang och innovationskraft, att det finns gott om självdisciplin och förmåga att ta ansvar, med mera.

Det fina är att det finns många beprövade verktyg för att uppnå detta. Vi vet hur en grupp kan arbeta empiriskt med ständig förbättring av arbetsprocesserna, både självständigt och tillsammans med andra grupper, hur man leder med respekt och hjälper folk att styra sig själva, hur man kan arbeta systematiskt med sin kvalitet, vad som krävs för att en grupp ska bli ett effektivt team, vad som motiverar och demotiverar oss, hur vi ska maximera innovation, kunna möta människors behov och samtidigt säkerställa på gräsrotsnivå att vi uppnår våra verksamhetsmål.

Vi kan skapa ledningssystem för detta, se till att det som sker i organisationen syns, skapa trygga miljöer där experiment kan ske, förankra vår strategi på djupet och samtidigt ta till vara varje medarbetares kunskap om hur man bäst uppfyller den. Vi kan tillochmed göra allt detta och samtidigt känna stor glädje på jobbet.

Så det är inte att verktygslådan är för liten som är problemet, snarare att kunskapen om hur man använder de olika verktygen är för låg. Här vilar ansvaret på oss som hållit på ett tag: att försöka sammanställa det viktigaste av det vi kan och vet så att andra kan pröva och slippa begå alla de misstag som vi begått på vägen. Förklara hur de olika verktygen fungerar så att folk vet när de bör använda dem. Och hela tiden förankra det i det bakomliggande tänkandet.

Ingen silverkula

Managementkonsulten Bernhard Lovén skrev en bra drapa mot det eskalerande oskicket att på ett ytligt sätt lovorda sk "agila arbetssätt". Det var framförallt tre saker han angrep:

• Påståendet att en organisation utplånas om man inte svänger över och blir mer agila.
• Bristen på konkretion: vad menar man när man säger att man ska bli agil?
• Att agila arbetssätt inte är garantier för motiverade medarbetare.

Mot detta ställer han vikten av att en organisation

• känner sitt syfte,
• vet vad marknaden (kunder eller medborgare) vill ha,
• vad den egna organisationen förmår leverera,
• hur man bör organisera sig för att leverera på bästa sätt,
• och sedan följa upp hur det går.

Medan det stämmer att allt detta är viktigt var det en sak i texten som stod ut för mig: "Vore jag chef..." så skulle jag först göra min hemläxa och besvara dessa frågor. Är det chefens uppgift? Är chefen bäst lämpad till detta?

Bernhard Lovén har precis som jag noterat att människorna i de organisationer vi möter sällan kan formulera vare sig syftet och målen eller hur deras arbetsuppgifter bidrar. Man kan se det som att organisationen (i betydelsen ledningen om det är chefen som ska besvara frågorna) inte gjort sin hemläxa och sedan inte varit tydlig med att kommunicera dessa svar. Folkets okunskap beror på att ingen chef har berättat det för dem.

Men man kan också se det som att okunskapen beror på att de aldrig själva fått formulera svaren. Och det är väl här vi leanfolk och agilister utmärker oss.

Agilitet är förmågan för ett samarbete att vid behov snabbt byta inriktning, till exempel när man fått nya insikter. Vilka konkreta arbetssätt som krävs för att skapa ökad agilitet varierar, men flertalet är stulna från Japan och Toyota. Toyotas behov att med begränsade resurser möta en varierande efterfrågan drev fram tekniker för att öka smidigheten, hastigheten, och innovationskraften; dvs precis det vi behöver i en organinisation för att göra den mer lättrörlig.

En observation är att golvet, gemban, de människor som är närmast kunderna och produkterna, har insikter om både behov och möjligheter som ingen på ledande nivå har. Risken är med andra ord stor att om chefen tar på sig att besvara alla frågorna ovan så blir det ganska verklighetsfrånvända svar. Vilket medarbetarna kan vittna om när de möts av å ena sidan ett syfte och å andra sidan mätetal som de, med sin djupa kunskap om verksamheten, ser driver ett helt motsatt beteende.

Istället bygger styrningen inom lean och agilt på att ledningen äger frågan om syftet och vad man vill se, medan nivåerna nedanför äger frågan om hur det ska uppnås och hur det ska följas upp. Mönstret går igen i Toyotas modell för strategiförankring (hoishin kanri), i dialogen mellan produktägare och utvecklare inom Scrum, och i det medarbetardrivna processförbättringsarbetet (kaizen/retrospektiv).

För att detta ska kunna fungera krävs ett rikt informationsflöde. Från lean har agilisterna stulit idéerna om visuell styrning (flödestavlor och andra informationsspridare), avvikelsehantering på golvet (jidoka och andon), och att centrala aspekter av arbetsgången dokumenteras. Det är informationsflödena som gör att agila organisationer är bra på att fånga upp och sprida nya insikter om både marknadsbehov och den egna leveransförmågan. Många ögon nära golvet ser mer än vad ett fåtal uppe i ledningen gör, och många hjärnor tänker bättre än några få.

Att chefen bör göra hemläxan ovan är rimligt i de fall där chefen är den bäst lämpade att besvara dessa frågor. Men i många organisationer, och kanske speciellt i stora organisationer med både stort avstånd mellan golv och ledning och hög grad av specialisering, är detta sällan fallet. Här är det istället centralt att folk ges autonomi inom trygga ramar så att de inte tvingas agera emot sin professionella kompetens. Förutom att kvaliteten blir lidande och kostnaderna högre när kompetensen åsidosätts är det få saker som är så demotiverande som att tvingas utföra ett arbete fel, eller att följas upp på helt fel saker.

Hemläxan för chefen i en agil organisation blir istället att med hjälp av teknikerna i den lean/agila verktygslådan skapa ledningssystem som delegerar så mycket som möjligt av den taktiska och operativa makten till dem som har bättre koll på verkligheten än vad chefen själv har. Vinsten för ledningen blir att kunna ägna sig mer åt strategiska frågor, och att man får mer kontroll på vad som händer när nervtrådarna, informationsflödena, inom organisationen blir känsligare. En organisation som av sig själv kan hantera en snabbt föränderlig omvärld är helt enkelt en trygg organisation att leda. De obehagliga överraskningarna blir färre.

I förlängningen kan en ledning delegera så mycket av makten att den blir fri att helt ägna sig åt övergripande frågor om sitt syfte. Exemplen är många: regnplagg (Gore-Tex), skor (Zappos), vård och omsorg (Buurtzorg), tomatkonserver (Morning Star), eller industrimaskiner (Semco). De ekonomiska vinsterna av denna totala delegering är uppenbara för den som studerar dessa bolag, men även om man inte är villig att gå så långt som de har gjort, så ser många organisationer sin egen brist på agilitet som ett strategiskt hot. De agila teknikerna är verkligen inga magiska silverkulor, men de kan definitivt lösa några av de problem som dagens stora organisationer brottas med.