Lyssna bara på nejsägarna

Att säga att något ska prioriteras är enkelt. Att hävda att det ena eller andra är viktigt, det låter sig göras utan problem. Och görs hela tiden. Vi lider inte brist på målbilder.

Ändå märker många att det saknas prioriteringar i våra verksamheter. Hur kommer det sig?

Det är för att den som aldrig säger vad som är oviktigt, vilket mål vi inte ska uppnå, vad som ska prioriteras ner; i själva verket inte har sagt något alls.

Att styra, att leda, är att bestämma sig för vart vi inte ska. En ledning som inte säger nej är en ledning som inte tar ansvar, utan låter resurskonflikter lösas i det tysta av folket på golvet.

De smidiga motdragen är framförallt två:

Synliggör arbetet! Ärendena ska synas, undanträngningseffekterna när vi prioriterar det ena framför det andra ska vara uppenbara, och vår arbetsgång ska vara dokumenterad.

Lyssna bara på den som säger nej! Alla som inte säger nej och vågar prioritera ner är inga riktiga ledare. Kräv besked och gör det synligt vad konsekvensen blir om nedprioriteringar inte görs.

Men hur ska man då göra?

Finns det några konkreta tips för hur man kommer igång med att göra jobbet lite smidigare? Utan att behöva vänta på att någon annan fattar beslutet? Ja, det finns det.

Inom IT har vi Scrum som är en utmärkt startpunktsmetod. Det är ett tiotal lean-tekniker sammansatta för att driva förändringen mot smidighet. I andra verksamheter finns det kanske inte en lika uttalad metod, men det går att göra till exempel så här:

Självstyrande tvärfunktionellt lag

Gruppera er, ni som har ett delat ansvar för en verksamhet. Att ni inte har samma kompetens eller uppgifter är bara bra, för nu ska ni försöka hitta ett smidigare sätt att arbeta på. Då krävs att ni jämnar till flödet mellan de olika aktiviteter ni gör.

Från och med nu är det ni som tilldelar er själva arbetsuppgifter. Att leda och fördela arbetet gör ni förmodligen bäst själva. Ni är själva experter på hur man arbetar, däremot måste ni veta vad ni ska göra. Vad är viktigast? Vilka mål ska ni uppnå? Det bestämmer organisationen runt er, liksom om det finns några begränsningar vad gäller hur ni får arbeta.

Förbättringsmöte

För att kunna ta ansvar för en arbetsgång så att den kontinuerligt förbättras behöver ni regelbundet se över och justera den. Avsätt ca 45 minuter per vecka, och bestäm med vilket intervall ni behöver ha det. Två veckors mellanrum (dvs ett möte på max 90 minuter) har många funnit vara ett bra intervall.

Arbeta strukturerat. Boken "Agile Retrospectives" ger en bra grund att stå på. Tänk på att ett bra förbättringsmöte ofta fungerar enligt den sk Demingcykeln: meningen är inte att ni ska gnälla över allt som är dumt, utan:

• Angrip ett av era irriterande problem.
• Hitta på konkreta motåtgärder. Se gärna på hur man jobbar med A3-tänkande.
• Under tiden fram till nästa möte: pröva motåtgärden. Tanken är ju att ni ska utvärdera den det första ni gör på nästa förbättringsmöte.

Synliggör värdeflödet

Synliggör era ärenden. Ha ärendet i centrum, och visa hur det svischar genom ert värdeflöde och slutligen landar hos en mottagare (kund/beställare/brukare) som tack vare ert jobb nu blir glad.

Många använder en kanbantavla för att synliggöra sitt flöde.

Kom ihåg att det ultimata är när ett ärende flyter utan avbrott jämnt genom flödet och landar i mottagarens knä. Optimera inte på att alla hos er ska vara fullt upptagna hela tiden. Då blir inte flödet jämnt. Optimera på att leverera snabbt och säkert istället. Sluta påbörja saker, börja slutför dem.

Se era planeringshorisonter

Vilka planeringshorisonter är viktiga för er? Vecka, två veckor, en månad? Se hur balansen mellan händelsestyrt arbete och planerat arbete är hos er. Synliggör hur oplanerade aktiviteter faktiskt stör de planerade. Gör en realistisk bedöming av hur mycket värde ni förmår leverera inom en horisont, och följ sedan upp hur det faktiskt gick. Låt den erfarenheten styra när ni tar på er arbete för nästa period.

I Scrum har vi en horisont på några veckor som kallas sprint. I början av en sprint gör vi en sprintplan, och i slutet gör vi en sprintgranskning

Skriv ner hur ni jobbar och dra igång

Fundera inte så mycket utan kör igång. Skriv ner hur ni jobbar på ett liggande A4 och sätt upp på väggen. Justera och bygg på i takt med att ni på förbättringsmötena kommer på fler saker. Mät nuläget innan ni drar igång (hur mycket värde levererar vi per vecka?) och stäm av när ni kört ett tag.

Kom ihåg att hemligheten med de smidiga arbetssätten inte är att de är smidiga, för de är de inte. Hemligheten är att de gör det så tydligt vari osmidigheterna består idag, så att man kan göra någonting åt det. Det blir inte bra när man börjar, men det blir bra med tiden när man fått tillfälle att göra det bra.

De små stegen är värdefulla

(Det här är ett omtag på en bloggpost som av outgrundlig anledning försvann.) Nyss hemkommen från en serie utbildningsuppdrag hos olika svenska myndigheter runtomkring landet har jag huvudet fullt med tankar och behöver blogga av mig lite.

Efter att ha kört utbildningar i smidiga arbetssätt ett tag nu, oftast med IT-anknytning, har jag kommit att känna igen ett mönster:

När jag först berättar om tankarna bakom och hur jag med egna ögon sett smidiga metoder förvandla verksamheter till det bättre blir deltagarna nyfikna. När jag sedan går igenom teknikerna och folk förstår hur de hänger ihop blir de entusiastiska.

Men sedan, när pusselbitarna blivit en fullständig bild i hjärnan, börjar de jämföra bilden med nuläget. Då ser de plötsligt alla de strukturella hindren i organisationen, och de blir missmodiga.

Var inte det.

Det här fungerar nog bra, men det krävs att hela organisationen är med på det! är en vanlig kommentar. Men sanningen är att hela organisationen aldrig kommer att vara med på det här lika mycket och på samma sätt. Insikterna och förändringarna kommer att ske i olika takt.

Organisationer är nämligen inte stora supertankers som en kapten, givet tillräckligt med tid, förmår vända. Organisationer är snarare organismer, mer eller mindre smidiga. Det som utmärker en osmidig organisation är att samarbetena mellan delarna går så trögt. En osmidig organisation lider av en bristsjukdom, brist på snabb och precis återkoppling mellan dess olika delar.

Det är därför som de små stegen, ute på golvet bland vanligt folk, är så viktiga. Ingen kapten förmår vända en oformlig koloss. Men vanligt folk kan gå samman i självstyrande lag, börja undersöka sin värdeström, se hur man kan snabba upp återkopplingen. Då väcks kolossen till liv, och alla - inklusive ledningen - får en klarare blick för vad som faktiskt behöver göras för att få till den där stressfria kreativiteten och produktiviteten som är så härlig att jobba i.

Vi avslutar alltid utbildningarna och coachningarna med att ta fram en konkret handlingsplan med saker som var och en faktiskt kan pröva. När man börjar betrakta situationen på ett strukturerat sätt, genom att använda väl beprövade metoder, så ser man faktiskt att man kan göra väldigt mycket - även inom sitt eget mandat, med start direkt eller i morgon eller i värsta fall i nästa vecka.

Efter en sådan genomgång brukar folk bli hoppfulla.

Arbete är kunskapsarbete

De verksamheter jag arbetar i kallas ofta för kunskapsarbeten. Produkten i processen är ett stycke raffinerad och kodifierad kunskap, som t ex ett datasystem, ett stycke dokumentation, eller konkret hjälp i ett supportärende. Dessutom består inflödet, råvarorna, av (väldigt oraffinerad) kunskap, och hela processen styrs genom att människor utbyter kunskaper med varandra.

Om man jämför med andra verksamheter kan man se att allt, även ren industriproduktion handlar om kunskap. Även om inte produkten och råvarorna alltid kan kallas kunskap, så styrs processen av att människor utbyter information med varandra. En insikt från lean är att om ett materialflöde går åt ett håll: till mottagaren, så finns det en motsvarande informationsrörelse åt andra hållet: till utförarna från mottagaren. Dessutom omsätts en massa information mellan människor i själva processen.

Den här insikten är grundläggande för smidiga arbetssätt. I en fabrik kan man tydligt se hur störningar i materialflödena skapar osmidighet. Men störningar i kunskapsflödet är inte lika lätta att se, även om vi upplever effekten av dem väldigt starkt. Det är faktiskt så att om man upplever störningar på jobbet, och inte riktigt kan sätta fingret på vari de består, så är det väldigt troligt att det är störningar i kunskapsflöden man erfar.

Principen lyder: "Bygg en lärande organisation". Kunskap är trögrörlig där den flyttas från hjärna till hjärna via bilder, prat, gemensamma erfarenheter, och inte minst tid. Kunskap kan bara bäras av informationsbitar som uppvisar en hög grad av ordning. Men termodynamiken avskyr ordning, så ditt kunskapsarbete kommer hela tiden att slås sönder av själva universum. För att motverka detta: bygg in lärandet i varje steg och underlätta alltid informationsspridning överallt.

Synliggör informationsbehovet för varje process. Vem behöver veta vad? Varför och när? Den som behöver informationen ska signallera sitt behov (dragande system, folk agerar självständigt), och verksamheten ska vara beredd att precis då leverera informationen, korrekt information, i lagom mängd och takt, i rättan tid. Som vanligt är det synlighet och jämnhet som skapar smidigheten.

Bilden kommer från Khalid Albaih.

Anything beyond the savannah is a loss

(I got some great feedback on this posting in Swedish: Allt bortom savannen är en förlust so I decided to translate it into English so that my friends outside of the country can comment on it too.)

Me and my partner-in-crime Jeff is writing a book that is to be used as course-material in the courses that we offer in cooperation with Informator (introduction to agile, agile leadership, product owners, scrum teams, kanban teams, scrum mastery/coaching, scaling agile).

As we don't sit in each others' laps when we write, we have to write different parts of the book. Right now, while Jeff is fiddling with a chapter on different agile practises, I have started to write the chapter on teams. It will be a chapter focusing rather heavily on group dynamics and neuro psychology, because those theories are needed if you want to think correctly about teams. But it occurred to me that the fundamental perspective is rather simple. It is a perspective I always use in my courses and coaching when it comes to the part about teams:

Anything beyond the savannah is a loss.

You can talk a lot about how a person finds their role within a team, how the team grows into self organization, how cognitive stress affects our ability to do creative work, how much information we lose when we use different forms of communication etc. etc. Science and studies are occupied with this, as we speak. And it is important that we - if we want our ways of working to remain smooth - make sure that they are synchronized with what science knows about human beings. But as a rule-of-thumb, this will take us a long way:

Anything beyond the savannah is a loss.

We are created to act in small, self-organizing teams of hunters/gatherers who work tightly together. We see each other face-to-face when we speak about our common goal and how to get there. We won't let our minds be occupied with more than a handful of things. The challenges and our goal ahead are specific. We stick together and support each other. We are standing next to the (cave) wall and draws what we want to achieve, so that everything becomes focused and crystal-clear. We trust each other, because the savannah is full of stuff that can't be trusted.

But this The Office parody we live in, a parody of abstract goals, messy documentation in large binders, no clear goals stated on the walls, large organizations with people you don't really know, collaboration with units on other continents where you don't even know what the people's names are or if they have kids or what they want from life, mistrust and passive aggressive language; all such things are taking us further away from what we really are: a group of hunters/gatherers on the savannah in north east Africa.

The sixth lean principle goes: Respect people! That includes more than just being polite. It is about understanding and conform to the fact that we are human beings, with cognitive abilities designed for another reality than destructive corporate culture. The smooth ways of working, let them be called lean or agile, are in a way a mission to bring us back to a way of work and be in accordance of what we really are designed for!

Allt bortom savannen är en förlust

Jag och min partner-in-crime Jeff håller på och skriver en bok som ska tjäna som grundbok i det kursutbud jag och han erbjuder via Informator (intro till agilt, agilt ledarskap, produktägare, scrumteam, kanbanteam, scrummastery/coachning, skalbarhet).

Eftersom vi ju inte sitter i knäet på varandra och skriver blir det ju så att vi skriver olika delar. Just nu, medan Jeff knåpar på ett kapitel om olika agila praktiker, så har jag börjat skriva på kapitlet om arbetslag. Det blir ett rätt gruppdynamiskt och neurointensivt kapitel, för det behövs om man ska tänka rätt om arbetslag. Men det slog mig att infallsvinkeln är rätt enkel. Det är en infallsvinkel som jag alltid använder i kurser och coachningar när vi ska börja på det som handlar om teamen:

Allt bortom savannen är en förlust.

Man kan säga mycket om hur människan finner sin roll inom ett lag, hur laget växer till självstyre, hur kognitiv stress påverkar vår förmåga att arbeta kreativt, hur mycket information som tappas när vi använder olika former för kommunikation osv osv. Allt detta är föremål för forskning, och det är viktigt att vi - om vi vill att våra arbetssätt ska förbli smidiga - ser till att de är i synk med vad forskningen vet om oss. Men som tumregel duger detta väldigt långt:

Allt bortom savannen är en förlust.

Vi är skapade att agera i små självstyrande grupper av samlare/jägare som jobbar tätt ihop. Vi ser varandra ansikte mot ansikte när vi pratar oss samman om vårt gemensamma mål och hur vi ska nå dit. Vi har inte mer i bakhuvudet än en fyra-fem olika saker. Våra utmaningar och vårt mål är konkreta. Vi håller ihop och stöttar varandra. Vi står vid (grott)väggen och ritar målet med vår strävan, för att allt ska bli fokuserat och glasklart. Vi litar på varandra, för savannen är full av sådant man inte kan lita på.

Men The Office-parodin av abstrakta mål, rörig dokumentation i pärmar, inga tydliga målbilder på väggarna, stora organisationer med folk du inte riktigt känner, samarbete med enheter på andra kontinenter när du inte ens vet vad människorna där heter eller om de har barn eller vad de uppskattar i livet, misstro och passivt aggressivt språk; allt sådant fjärmar oss från de vi egentligen är: en grupp samlare/jägare på savannen i nordöstra Afrika.

Den sjätte lean-principen lyder: Respektera människan! Det är mer än att bara vara artig. Det är att förstå och böja sig för det faktum att vi är människor, med kognitiva förmågor designade för en annan verklighet än den destruktiva corporate-kulturen. De smidiga arbetssätten, må de kallas lean eller agile, är på något sätt en strävan att ta oss tillbaks till ett arbetssätt vi faktiskt är designade för!

Olika sorters lag

Det självstyrande laget är en kärnkomponent i de flesta smidiga arbetsmetoder. Men det kan vara svårt att sätta samman bra lag, eller att stötta lagen på rätt sätt när de möter svårigheter. Jag har märkt att vilka strategier som fungerar bäst bland annat beror på hurpass väl lagens medlemmar har samma målsättning och i vad mån de måste arbeta reaktivt (händelsestyrt) respektive proaktivt (planerat).

Samma mål

Egentligen finns det inga lag där medlemmarna har olika mål. Att ha samma mål är vad som skiljer ett lag från vilken annan grupp människor som helst. Däremot kan en grupp människor vara tänkta att fungera som ett lag, men där man inte riktigt har tänkt på att de faktiskt har rätt olika mål. Kanske tillochmed målkonflikter inom sig.

En sådan grupp behöver sätta sig tillsammans och fundera på vilka deras mål faktiskt är. De olika medlemmarna måste synliggöra vad de har på sina privata agendor, och så får gruppen försöka ta ett samlat grepp om dem. Antingen skapa ett gemensamt mål, eller tvingas inse att man inte är ett lag utan bara en grupp disparata individer som inte kommer att tjäna på att arbeta ihop.

Reaktivt

Ett lag vars uppgifter i första hand är reaktiva är troligen en trång sektor (de jobbar så hårt de kan och har alltid en fylld inkö), eller så har de (mindre troligt) nedtid i väntan på saker att ta tag i. Så länge man inte stressas av kravet att balansera proaktivt och reaktivt arbete (se längre ner för den konflikten) kan ett reaktivt arbetssätt vara rätt behagligt, så länge alla har realistiska förväntningar knutna till dem.

Det det reaktiva arbetslaget behöver är att se vilka de faktiska omständigheterna är. Till att börja med kommer de alltid att vara en flaskhals. Det kommer att upplevas som en ständig resursbrist, men att öka resurserna kommer inte att lösa de problem som laget kan ha. Att vara en flaskhals synliggör istället vilka bristerna i flödet faktiskt är, så att man kan göra något åt dem.

Laget ska ägna sig åt att mäta sina handläggningstider, se vilka ärenden som tenderar att fastna, analysera varför, och göra något åt problemen. Det viktigaste är att skapa jämnhet och en uthållig arbetsbelastning, och att synliggöra sin verkliga kapacitet. Till detta kan ett dragande flöde i t ex ett kanbansystem fungera bra.

Ett lag som är får vänta på ärenden är mycket ovanligt, eftersom det betyder ett resursutnyttjande lägre än 100%. Styrmodellerna i dagens organisationer är ofta så omogna att de bara förmår se till nyttjandegrad istället för ett optimum mellan nyttjandegrad och flödeshastighet på ärendena. Flödeshastigheter är ju kopplade till värdeskapande, medan nyttjandegrad har med kostnadskontroll att göra. Eftersom värdeskapandet är svårare att mäta än kostnader syns inte alltid vilka ekonomiska möjligheter det finns i att optimera på flöde, men det är ett ämne för flera andra poster.

Proaktivt

Ett lag vars primära uppgift det är att följa en plan har det enkelt på pappret. Projektmodeller brukar t ex bygga på ett avlägset mål, och sedan en utförlig plan i form av tidssatta aktiviteter som förväntas kunna löpa i varandra. I projektplanen syns aldrig de saker som man är tvungen att hantera när de plötsligt uppkommer. I synnerhet syns inte det man är tvungen att hantera som följd av att det uppkommit ny kunskap.

Ett sådant lag behöver två saker: först en försäkran om att andra finns som kan ta hand om de händelser som kräver ett reaktivt arbetssätt. Sedan krävs processer och verktyg för snabba och gärna regelbundna omplaneringar. En metod som Scrum och ett verktyg för ständig omplanering (en backlog) har visat sig fungera väldigt bra i dessa situationer.

Konflikten mellan proaktivt och reaktivt

Ett lag med en blandning av reaktiva och proaktiva ärenden har förmodligen svårt att utföra planerade aktiviteter som spänner över lite längre tid. Händelser de reagerar på är förmodligen ganska viktiga, så de planerade uppgifterna blir ständigt nedprioriterade. Negativ stress är vanligt i sådana sammanhang. Man kan inte följa planen (vilket kullkastar alla projektplaner), men man gör inte heller ett optimalt jobb i hanterandet av händelser. Man är varken eller, och även om man lade 100% av sina resurser på att hantera enbart händelser skulle man fortfarande vara flaskhals (se stycket om reaktiva lag ovan).

Det laget behöver se sin konfliktfyllda arbetssiuation. Rotorsaken är dels att laget har en målkonflikt mellan att följa planen och att klara av sina övriga åtaganden, dels att man inte kan vara i reaktivt läge och proaktivt läge samtidigt, och naturligtvis att ingen riktigt förstår att förväntningarna förmodligen är lite fel ställda.

Här är synliggörandet livsviktigt. Alla behandlade ärenden, planerade som oplanerade, måste synliggöras så att den verkliga arbetsbelastningen och förmågan syns. Det måste finnas ett tydligt mandat kring hur man prioriterar de olika ärendena i förhållande till varandra, och alla projektplaner som är beroende av hur laget förmår leverera enligt plan måste stå under ständig revision beroende på hur det faktiskt går.

Först när detta är på plats kan man börja förbättra situationen och aktivt bestämma hur mycket av resurserna som ska läggas på planerat respektive på händelsestyrt, och skapa strategier för att optimera förmågan att arbeta både reaktivt och proaktivt samtidigt. Men det är också ämnet för många poster. Att lära ut knepen runt detta upptar en hel del tid på mina utbildningar.

Var är ni?

Ett lag bör fundera på var man befinner sig utmed dessa två axlar, och i vilken grad man lider av konflikterna som beskrivits ovan. I koordinatsystemet har jag ritat ut tre lag som tillhör olika extremer på skalorna. I verkligheten har de flesta lag en mer komplex situation, mittenåt i koordinatsystemet.

Lag Röd är ett typiskt Scrumteam. Alla händelsestyrda aktiviteter tas om hand av andra team och personer i verksamheten, och teamet har samma mål vilket gör det möjligt att planera vettiga sprintar att samarbeta kring. Observera att detta är det slags team där Scrum fungerar utan modifikationer! Så snart du inte har denna situation måste du börja anpassa Scrum på olika smarta sätt om du ändå vill använda sprintar som verktyg.

Lag Grön är ett typiskt serviceteam. De har ett gemensamt förvaltningsansvar för en uppsättning förvaltningsobjekt och kan samarbeta om inkommande ärenden som rör dessa. Bekymret gäller förvaltningsobjektens långsiktiga skötsel. Om inte detta lag har ansvar för den, vem har det då? Och varför ligger inte det ansvaret på lag Grön, det är väl ändå där kompetensen finns?

Lag Blå är ofta en produkt av en organisation där ledningsfolk har hört talas om lean-agilt-eller-nåt-sånt och trott att en massa saker ordnar sig bara man grupperar människor i självstyrandegrupper. Denna uppsättning kommer antingen att leda till besvikelse över oinfriade förväntningar, eller så gör man något åt situationen. Först och främst ser över om inte dessa människor egentligen har eller kan få ett gemensamt ansvar över en funktion, så att de kan få ett gemensamt mål. Annars är de inget lag, och inget av det goda ett självstyrande lag kan föra med sig i smidiga arbetssätt kommer att hända.

Grejer mellan stolarna

Här är lite kommentarer från en grej jag jobbar med just nu:

Tanken med att dela in sig självstyrande lag är att man gör sig av med formella överlämningar och sådant spill när nånting måste fixas av flera personer. Inom laget kan vi optimera vårt samarbete och göra färdigt i ett enda svep.

Problemet är att då behöver laget enas om en gemensam inkorg där alla grejer som ska göras samlas. Det blir en kö helt enkelt: bra för att jämna ut ett flöde, dålig eftersom den skapar väntan. Väntan kanske är nödvändigt, laget är nog en trång resurs jämfört med allt man vill att de ska göra. Men vad händer med väntetiderna när ärenden måste passera flera lag?

Om ett ärende först ligger och väntar hos Lag Gul, sedan fixas lite med, och därefter skickas vidare till Lag Röd, så vill vi inte att det ska behöva ligga och vänta i Lag Röds inkorg. För då blir den totala väntan onödigt lång.

Det vi vill är istället att Gul och Röd ska kunna fixa ett ärende som vore de ett gemensamt lag. Inga dyra överlämningar, inget liggande mellan stolarna, från och med den stund då Gul tagit tag i ärendet ska det göras färdigt, som alltid i ett enda svep.

Lag som ingår i sådana samarbeten måste först komma överens om att ge varandra direktingångar för redan påbörjade ärenden. Detta känns till att börja med obehagligt, eftersom det känns som om man överger sin lyckade idé om att ha en gemensam inkorg per lag. Men om vi är överens om att det är dåligt att hålla på med flera saker samtidigt inom ett lag kan vi kanske vara överens om att det är dåligt att hålla på med onödigt många saker samtidigt även inom en organisation?

Ärendet som Gul och Röd samsas kring är påbörjat i den stund Gul tagit tag i det. Om Gul måste lägga det i Röds inkorg kommer Röd att påbörja ännu fler ärenden innan Guls ärende tas om hand. Vi får på så sätt många påbörjade saker i organisationen. Om Röd istället prioriterar de redan påbörjade ärendena, genom att man får signal från Gul om att sådana redan finns (kanske i en särskild inkorg för redan påbörjade ärenden lagen emellan), så samarbetar Gul och Röd om att hålla nere antalet samtidiga ärenden, och bägges arbete blir mer smidigt.

Konceptet kan drivas vidare med att man centraliserar hela organisationens inkorg i ett servicedesktänkande osv, men detta kräver faktiskt att fungerande samarbetskanaler mellan lagen redan finns på plats, så det skadar inte att börja i det lilla. En enkel överenskommelse mellan två självstyrande lag om hur ärenden dem emellan ska kommuniceras och prioriteras tar oss faktiskt väldigt långt.

Tidshorisonter

Nä, det blev inte så bra att blogga på engelska. Jag gör mig visserligen förstådd på engelska, men jag känner att det ju är svenska förhållanden min erfarenhet sträcker sig till, tokigheter begånga i svenska organisationer. Därför, trots att agilism är i högsta grad ett engelskspråkligt fenomen, blir nog svenska bäst. Därför byter jag också namn på blogghärket, från ¡Agilistas! till Smidigt!.

En smidighetens fiende är som bekant ojämnheten, till exempel i form av ryckighet. Plötsligt tog pengarna i budgeten slut och allt lades på is, plötsligt fattades igångsättningsbeslut och alla måste genast rusa iväg på det nya projektet (och släppa allt annat utan att samla ihop och etablera värdet i det man skapat). Att ojämnhet är en av de största rotorsakerna till spill har vi vetat länge.

Det blir gärna ryckigt när man har för kort planeringshorisont. Tyvärr glömmer vi ibland bort att titta framåt i tiden. När vi sätter oss för att planera arbetsuppgifterna nästkommande veckor kan det vara första gången vi ens funderar på vilka uppgifterna är. Organisationen gör sig på det sättet väldigt närsynt. I Scrum säger vi att vi "glömde groomingen", alltså glömde bort det moment när vi tittar ett par perioder längre fram.

För att minska ryckigheten kan man dela in Högen (med saker vi vill göra) i olika fack, ett för varje tidshorisont. Eftersom vi sedan gammalt har ett tänkande runt tiden där vi delat in den i grövre delar kan man utgå från den indelningen när man gör sina horisonter: Ett fack för den närmaste veckan, ett för den närmaste månaden, det närmaste kvartalet, och ett för halvåret. Kanske vissa verksamheter behöver komplettera med ett fack för dagens arbete, eller ett för det närmaste året.

De olika facken har olika krav på detaljrikedom i beskrivningarna av vad som behöver göras. För stor detaljrikedom i något som ligger längre fram bryter mot principen bestäm utifrån vad du vet. Man riskerar att låsa fast sig i lösningar baserade på ogrundade antagande. Rättan-tid-planering bygger istället på att man planerar med så stor detaljrikedom som krävs just nu, avpassat för varje tidshorisont. Både att planera för mycket och för lite i förhållande till tiden leder till ojämnhet.

När den nya veckan närmar sig behöver man ur månadsfacket ha prioriterat de mål som är viktigast, och brutit ner dem lagom mycket så att de passar för en veckas arbete. När den nya veckan börjar kan högen med veckomålen vara färdig, så att man får en jämn övergång. På samma sätt färdigställer man gradvis nästa månads månadsfack ur kvartalshögen, nästa kvartal ur halvårshögen osv. In från vänster kommer också alla de ärenden man vill lyfta in i respektive tidshorisont direkt.

Samma tänkande fungerar när man arbetar med andra planeringshorisonter. Systemutvecklingsorganisationer som arbetar med Scrum använder ofta 2- eller 3-veckors perioder (som kallas sprintar). Dessa kan synkas mot månads-, kvartals, och halvårshorisonterna på samma sätt: sitt med utvecklingslaget och förbered nästa sprint gradvis så att den är i princip färdigplanerad när den börjar. I Scrum kallas förarbetet för "grooming" och den sista planeringsvändan för "sprintplanering", men man tjänar på att inte göra så stort väsen av skillnaden dem emellan.

Det finns många fler trick man kan göra med gradvis planering i tidshorisonter, som t ex mäta hastigheter och på så sätt få uppdaterade projektbudgetar som stämmer, eller mäta kostnaden för störningar i planeringen. Men det spar jag till en annan gång.