Har du ERFARENHET av stor skala?

Detta är ett viktigt meddelande som på grund av orsak samt förekommen anledning går ut till alla agila coacher som med erfarenhet som Scrummaster i bagaget glatt ger sig i kast med en organisation av lite storlek och tror att det bara är att köra på med diktaten i Scrumboken: Hur vet du det?

Agilitet är inte samma sak som Scrum. Scrum är en liten smart samling med lean-tekniker som fungerar även i stor skala under förutsättning att vissa omständigheter råder. Kruxet är att under vissa villkor fungerar inte Scrum. Det som skiljer en agil vägvisare från valfri scrummaster är kunskapen om dessa villkor, samt kännedom om hur man trots detta kan hjälpa den lite större organisationen mot större agilitet (vilket ju är målet).

Ta t ex idén om feature-team. Det är en lysande idé: att ett och samma team tar sig an och implementerar en funktion från ax till limpa, utan att vara bunden till att bara göra förändringar i vissa komponenter. Så i princip har du rätt när du säger att så bör det gå till. Men vad gör du när lösningens komplexitet kräver kompetens i nitton komponenter? Gör ett jättestort team (och bryter mot principen om att hålla storleken till under nio personer)? Svänger ihop team med rätt kompetensmix för varje feature, team som du sedan upplöser och därmed bryter mot principen om stabila team?

Eller ta idén om att varje kadens (som heter "sprint" om vi ska prata Scrum) måste resultera i en körbarhet. Alltså, vad boken säger (och det är en mycket bra idé) är att varje sprint ska resultera i ett potentiellt släppbart inkrement SÅ LÅNGT DET BEROR PÅ TEAMET. Det som teamet släpper ifrån sig ska vara färdigtestat. Nå, hur hanterar du integrationstester när det som flera team släpper ska integreras? Kräver du att även integrationstestet ska vara gjort när teamet släpper ifrån sig, eller accepterar du som en frukt av komplexiteten att integrationen är något som följer efter det att teamen har släppt, trots att det innebär en långsammare takt, totalt sett?

Eller ta distribuerade team i andra tidszoner. Överlämingar är spill, skriftlig dokumentation är jämfört med att arbeta tillsammans i en dialog, spill. Men vad är det mindre spillet: att öka graden byråkrati och dokumentation, eller att acceptera att information går förlorad eftersom folk av fysiska skäl inte kan sitta ihop och konversera och jobba vid samma tidpunkter.

I vildmarken handlar inte vägvisarjobbet om att ta den enligt boken rätta vägen. Det handlar om att välja mellan flera onda ting och rekommendera vilken väg som är minst olämplig för att nå målet, precis nu. Man måste väga samman flera faktorer, ha målet om ökad agilitet för hela organisationen i sikte (inte drömmen om bättre punktvis efterföljelse av Scrumguiden), och veta vilka strider som är värda att ta och vilka som kan vänta. Vilken idiot som helst kan ladda ner ett papper och läsa innantill, när verkligheten utmanar med vägval som är långt ifrån optimala krävs det lite större eftertänksamhet än så. Gärna lite erfarenhet också.

Där ni står

Under en utbildning idag, hos en avdelning som jag hjälpt införa olika smidiga tekniker för en tid sedan, ställde jag frågan vad som hade förändrats i och med de nya arbetssätten.

- "Entusiasmen, viljan att lösa problem, glädjen i att hjälpa och förbättra", blev svaret.

Det gjorde mig väldigt glad, men faktiskt inte så förvånad. Det är lyckligtvis en rätt vanlig erfarenhet, som bygger på en välkänd mekanism.

Många som stöter på de smidiga teknikerna första gången brukar häpna över den radikala delegeringen. Det till myteriet gränsande (nåja) självstyret. Under förbättringsmötena tar folk ansvar för saker som i en organisationskarta ligger långt utanför den egna avdelningens ansvarsområde. Hur kommer detta sig?

Svaret är att vi människor vill hjälpa till, vill göra ett bra jobb, vill vara med och skapa något stort och bra. Men när man inte ser hur det skulle kunna gå till blir man handfallen, och då också demotiverad.

 

Genom de smidiga teknikerna lär sig alla att fokusera på värdeflödet. Man bryr sig om det som gör mottagaren glad. Det medför att man automatiskt bryr sig mindre om avdelningsgränser och formella mandat. Alla ser ju hur en överlämning mellan två avdelningar fungerar osmidigt. Att försöka påtala denna osmidighet för chefer långt upp i hierarkin känns osmidigt i sig självt. Dessutom: vad vet chefen långt ifrån golvet om det här?

Istället tar man kontakt med varandra och anordnar ett snabbt (<45 minuter) förbättringsmöte för att reda ut hur samverkan ska lösas. Man dokumenterar ett processteg, testkör under två veckor, och bestämmer sig sedan för om man ska permanenta det nya arbetssättet. Arbetssättet skrivs ner på en liten plansch och sätts upp på väggen. Att ändra arbetssätt blir odramatiskt när man hela tiden testkör i det lilla.

En tredje faktor som ökar frimodigheten och därmed motivationen är synliggörandet (rätt info i rätt tid). Vi VET om den förändring vi testar är till det bättre eller ej, för vi får information om utfallet omedelbart. Osäkerhet om det man gör är till det bättre eller ej skapar handlingsförlamning, och är ett tecken på att egentligen ingen i organisationen kan besluta något på goda grunder. Med rätt info i rätt tid kan istället alla fatta vettiga beslut med låg risk.

Så det är inte underligt om smidiga tekniker ökar viljan att ta större ansvar. Plötsligt finns ju förutsättningarna.

Syfte, steg, samspel

Det här är ett försök att beskriva tanken bakom ramsan Purpose, Process, People; alltså i vilken ordning man bör angripa saker och ting som man känner inte riktigt funkar i arbetssättet.

När vi tänker arbetsdelning har vi en tendens att genast tänka på vem som gör vad. Det är inte så konstigt, för i grund och botten är och förblir vi jägare och samlare från savannen. I den lilla gruppen som ska göra något är det överblickbart. Vem som gör vad är rent naturligt arbetsledningens första fråga.

Men när vi ska göra något i lite större skala, då blir vem som gör vad en tokig fråga. För den blir i våra huvuden till stordriftsfrågan vilka gör vad, och då börjar vi genast tänka i termer av avdelningar. Då sätter vi alla flintknackarna i ena hörnet av grottan, alla som skrapar skinn i det andra hörnet, alla som flår djuren i det tredje; osv.

Genast åker vi på bök. Djurkropparna måste plötsligt släpas mellan de olika avdelningarna, och transporter är ju i grund och botten slöseri. Det må vara hänt i en grotta där fyrtio personer samarbetar om något i grunden enkelt och konkret, men hur är det i en storskalig verksamhet? En där det vi gör inte alltid är så påtagligt?

Vår impuls att översätta den småskaliga arbetsdelningen mellan människor ("People") till en storskalig indelning i avdelningar av folk som gör likartade arbetsuppgifter, den skapar slöseri. Värdet består ju i att olika människor gör olika saker för samma produkt, eller tar hand om olika delar i samma tjänsteflöde. Det blir en massa konstiga och osmidiga överlämningar mellan avdelningarna och svårt att samarbeta när avdelningarna blir stora.

Därför ska man börja från början, med att slå fast själva syftet ("Purpose"). Vari består värdet? Vem blir glad? "Vi blir glada när djurkroppen är uppdelad i rena skinn och snygga köttbitar". Aha! Då ska vi inrikta oss på det! Vilka processteg behövs då för att nå dit? Knacka kniv, flå, skrapa, stycka? Ja! Vi har hittat en process för att uppnå värdet!

Först när vi vet vilket syfte vi ska uppnå, och vilka steg som ska ta oss dit, först då är det dags för oss att fundera över hur samspelet bör se ut. Vi börjar alldeles för ofta med att fundera över våra organisationer, när vi egentligen först borde fundera över vilket värde vi ska åstadkomma och vad som då behöver göras.

Alla dessa obegripliga omorganisationer är ett symptom på en oklar värdekedja. När man har anammat tankesättet syfte-steg-samspel ("purpose, process, people") gör man inga omorganisationer förrän värdekedjan är förstådd. Sedan kan det bli justeringar i organisationen i takt med att man förstår mer och mer av vilket värde man kan leverera, men dessa justeringar blir sällan dramatiska, och framförallt blir de inte obegripliga.

Vi har ju ett tydligt syfte.

Exakt samma fast på ny plattform!

Nu ska ni få en liten historia ur verkligheten, men det hjälper inte om ni frågar var någonstans detta har utspelats för dels vill jag skydda mina uppdragsgivare, och dels har jag faktiskt sett precis nedanstående ske på fyra helt olika platser under tolv års tid. Jag gissar att det händer igen och igen och igen...

Det var en gång en verksamhet som behövde ett system. Eftersom organisationen hade beslutat om en viss teknik (en generell applikationsteknik som byggde på en generell relationsdatabas och ett generellt språk för mellanlager och användargränssnitt), så beslöt man sig för att bygga systemet i precis denna teknik.

Organisationen berömde sig av sina noggranna förstudier och sin rigorösa beslutsprocess, och därför tog man god tid på sig för att inhämta kraven från användarna. Alla processer kartlades, och man såg till att ingen detalj glömdes bort. Man gjorde det så noga så att det tog så lång tid, att när informationsarkitekterna tog över för att modellera objektrymd och databas, så hade kravfångarna och verksamhetsmodellerarna ingen budget kvar. De lämnade över kravdokumentet och började jobba på andra projekt. De som var konsulter gick vidare till andra uppdrag i helt andra verksamheter.

Informationsarkitekterna och programmerarna ville jobba agilt och gjorde sitt bästa för att samarbeta runt de överlämnade kravdokumenten, men när de sprang på frågor fanns det inga kravfångare kvar att fråga; och verksamheten tänkte minsann inte lägga en minut till på att förklara sina verksamhetsprocesser och behov en gång till.

Nå, till slut lyckades utvecklarna leverera ett system, inte på budget och inte så att verksamheten blev helt nöjd, men åtminstone så att det kunde anses färdigt enligt de högst luddiga och oklara acceptanskriterierna. Nja, kriterierna var egentligen inte luddiga, språkligt/syntaktiskt sett, men det hade visat sig under resans gång att de innehöll självmotsägelser och det är ju innehållsligt/semantiskt sett samma sak som oklarhet.

Verksamheten och IT-utvecklingen (varför ses aldrig IT som en del av verksamheten när informationsflöden utgör själva verksamhetens blod?) bråkade en stund om vems felet var (rätt svar: ingens, förstås, eftersom det inte existerar någon metod att på förhand ta reda på om krav är självmotsägande med mindre än att du försöker skapa en lösning som uppfyller dem); men verksamheten - som behövde systemet - accepterade och tog det i drift.

Det fungerade. Inte bra, men det fungerade. Åtminstone delvis.

Ganska snart insåg man att det faktiskt var viktigt att systemet både fungerade bra och till alla delar. Systemet skulle ju stödja verksamhetens absolut viktigaste process. Pengar behövde skakas fram för att lyfta systemet ytterligare ett steg.

Men nu tänkte någon till. Var inte grundproblemet egentligen att man valt en generell plattform för att göra systemet? Var det inte så att verksamhetens behov bättre matchades av en mer specifik plattform, ett sk affärssystem, som hade moduler för att stödja den här typen av verksamhet? Naturligtvis skulle det komma att krävas specialanpassningar, men i det stora hela var det en bättre match mellan plattform och verksamhet. På sikt måste ett plattformsbyte vara bättre!

Eftersom denna någon besatt ett rätt så omfattande mandat fattades beslutet utan några förstudier (personer på höga mandat besitter ju magiska egenskaper att se verkligheten sådan den är och behöver inte se några förstudier gjorda av folk med mindre mandat): plattformen skulle bytas ut, innan man gick vidare med att rätta bristerna i det befintliga systemet!

Något ytterligare kravarbete skulle inte behövas, resonerade man, eftersom det befintliga systemet tjänade som facit. Första delprojektet skulle ju bara replikera det befintliga. "Exakt samma, fast på ny plattform!", löd ordern.

Men vem skulle göra arbetet? De befintliga utvecklarna kunde ju funktionskraven bäst, och var därför bäst skickade att göra det! Sedan kunde man kasta in konsulter som kände till plattformen, alltså det nya affärssystemet.

Utvecklarna kliade sig i huvudet. De visste hur databasmodellen såg ut som stöttade de befintliga funktionerna. De visste att affärssystemet i botten var en relationsdatabas. "Exakt samma fast på ny plattform!" löd ordern. Alltså tog man det befintliga schemat och tryckte in i affärssystemets databas, och sedan gav man sig i kast med att anpassa de gränssnittsmoduler som mest liknade den befintliga funktionaliteten.

Det gick trögt. De befintliga utvecklarna kände ju inte till affärssystemets finesser, det gamla systemets databasmodell stöttade inte dessa finesser; så en enorm mängd specialtricks, skript, fulhack osv krävdes. När sedan experterna på affärssystemet skulle komma in och stötta visade det sig att dessa inte alls var så värst mycket till experter. I synnerhet begrep de sig inte på den röra som de befintliga utvecklarna lämnat efter sig. Lämnat efter sig? Ja, det ingick ju inte i någon budget att dessa bägge utvecklargrupper skulle arbeta parallellt.

Nu började någon-med-det-stora-mandatet bli nervös. Version 1 av systemet hade kostat mycket mer än prognosen. Version 2 riskerade att bli ännu dyrare och ta ännu längre tid och vara ännu sämre. Det utlovade leveransdatumet närmade sig och de tilldelade pengapåsarna var tomma. Bäst att agera! Bäst att kommendera fram en leverans!

Och så blev det. Systemet som varken var en skräddarsydd lösning byggd på en generell plattform; eller en smart anpassning av ett standardsystem; och vars funktionalitet (när det över huvudtaget fungerar) var en karikatyr av det som några kravfångare och verksamhetsspecialister drömt fram för länge sedan; det togs i bruk. Och kostade snabbt (i frustration, i fel, i utebliven verksamhetsnytta, i folk som tvingas lägga eoner av tid i handhavandet) betydligt mer än hela den sammantagna utvecklingskostnaden av version 1 och version 2.

Detta är så onödigt, och ändå händer det igen och igen och igen. Några enkla tips på vägen för att inte sätta sig i detta klister:

• Förstudier är galet. Studier är det rätta. Dessa ska bedrivas samtidigt som systemutvecklingen så att man hela tiden vet att man är på rätt spår. Se Scrum för en enkel och handfast metod som löser detta, till en låg kostnad.
• Det finns ingen metod som validerar krav innan de är implementerade. Krav kan vara självmotsägande. Vi kan vissa tricks för att minska risken att vi fångar krav som sen blir tokiga, men säkra kan vi (av matematiska skäl) inte vara. Det går därför inte att minska risken genom att vara rigorös. Det enda sättet att på allvar minska risken i systemutvecklingen är att minska omfattningen. Bryt ner i delmål och delprojekt, så vet ni att ni är på banan.
• Krav kan inte överlämnas i kravdokument. Dokument är viktiga som gemensamma sätt att fästa sin samsyn på papper, men det går inte att skriva ner alla aspekter och vara säker på att dessa tas om hand längre fram. Kravfångare och utvecklare ska campera ihop och jobba tätt. Överlämningar är en känd spillkälla.
• När Gartner Group sammanfattar statistik över lyckade och misslyckade IT-projekt försöker de hitta skälen till att projekt lyckas. Den viktigaste faktorn har varit närvaro av användare. Värdeflödet (tänk lean) är när en användare får ett verktyg som stödjer användarens värdeskapande processer. Man måste ha med dem för att uppnå det!
• Att ha mandat betyder inte att ha förmåga. Och ska du ha reell makt över utfallet behöver du mandat och förmåga på rätt nivå. Folk i höga positioner ska inte göra känslomässiga val av teknik. Inte utan en analys som visar att deras antaganden är rätt. Förbättringar ska vara ett empiriskt experiment. Inte magkänsla hos någon med hög månadslön.
• Om man vill använda färdiggjorda system ska man vara helt på det klara med att dessa verkligen stöttar ens verksamhet (eller så får man göra om sin verksamhet så att den passar systemet), och man måste känna till den verkliga kostnaden av att anpassa. Tänk på att konsulter för ett specifikt system är mycket dyrare och mer sällsynta än konsulter för standardtekniker.
• Att säga: "Exakt samma fast på ny plattform" är inte en kravspec. Plattformar ser väldigt olika ut. Annars hade det inte funnits plats för dem bägge på marknaden: de har olika uppbyggnad och fokus. Säger man "Exakt samma" så menar man ofta "Likadan fasad". Problemet är att de olika plattformarna är radikalt olika hustyper. Att limma på en fasad från en sorts hus utanpå en helt annan sorts hus, brukar inte bli så bra.
• Kostnaden i utvecklingen är inte programmeringen. Kostnaden är att ta fram informationen om exakt hur systemet ska fungera. Fokus ska ligga på att förbättra den informationsframtagningen. Och när vi säger exakt så menar vi exakt. Datorer är exakta.
• Systemkostnaden är till väldigt liten del programmeringen. Livscykelkostnaden är lätt tio gånger högre. Räknar vi med kostnaden av utebliven verksamhetsnytta pga dåliga system blir den mycket högre än så!
• Det går inte att kommendera fram en annan verklighet än den vi lever i. Nej, på riktigt: det går inte.

Scaling agile

I've had some conversations regarding "scaling agile" recently, with people from other countries than Sweden. I promised them to put together blog posts on how I teach and coach agility in an organization that spans many departments, many teams, and many components. For their sake I try to do it English which is my second language, so bear with me.

Scaling

The descriptions of the agile methods such as Scrum often focus on the convenient small scale: the whole client organization may be represented by a single Product Owner, the whole IT-department by the cross-functional team (max 9 persons) that actually has the competence to create a full feature end-to-end in the few objects that they need to manage, etc.

As soon as the reality is more complex than this (many objects, many teams, many departments, complex platform, different technologies etc) you will need to scale. Scaling can be done in many dimensions, depending on where you actually have the increased complexity; and when we do, we must be sure that we keep our focus on maintaining our agility

Agility

First: remember what it is we want to achieve when we use "agile" methods. Remember that the "agile" methods aren't agile at all, but that they help us - if the methods are properly applied - to become more agile in our collaborations. There is this constant need for any organization that develops new software and IT-based services to change direction quickly, since development is all about discovering new things:

Aha, the reference user group didn't understand the proposed user interface! Let's change it! Ooops, we found hidden complexity in the organization's view on what actually constitutes a customer! Integration to System Gizmo is problematic since it shows that Gizmo cannot handle UTF-8 data as it said it could!

The inherent inability to plan ahead development calls for a more flexible way of controlling the value creation in a collaborations focused on developing things, than what project models that rely on extensive planning can do. Hence the rise of the "agile" methods, and a manifesto that says that it is more important to be able to respond to changes, than be able to follow a plan.

Inspect & Adapt

The thing that actually makes us agile, our ability to change quickly in respond to new circumstances, comes from an increased ability for all of us to actually see the current situation as it is; and an increased ability to change accordingly. In agile circles this is called "inspect & adapt", and it is an observation that the frequency of our inspect & adapt-events will determine our agility. Faster feed-back loops means better steering ability.

All the practises that make up the different agile methods (a method is basically a bunch of practises thrown together in a bag), aims at increasing either the ability to inspect, or the ability to adapt, or both. In particular, they aim to increase the transparency of our work (you cannot inspect if things aren't visible), and they want to increase the power (=ability to steer) on all levels by shifting mandate around and make sure the ability to govern follows the right to govern.

This can be seen in such practises like the self-organized team (increased ability to adapt by delegating mandate to the level where the expertise is), a visible backlog showing the status of both all items and their actual prioritization (increased ability to inspect by letting everyone see what is going on and what limited organizational resources we actually compete for).

No matter what practise: it will affect either the ability to inspect or the ability to adapt or both, and you can tell if you applied correctly if this actually had that effect in your collaboration.

Transparency

So when we scale agile, we must understand that it is the ability to inspect and adapt we actually try to scale. And since the ability to adapt actually comes from our ability to inspect (a blind driver is a bad driver) we must understand that the primary focus must be to increase the ability to inspect. In a big organization it is important to increase the transparency even more. Here are some tricks we've used in different organizations:

Use a single backlog! Put all items for all project and all teams in a single backlog. In all lean implementations (and doing agile is a lean implementation) one of the top priorities is to visualize the value-chain; and in a development organization the backlog is the value-chain. I will explain the extended backlog in a later post, since this is a crucial tool.

All teams on the same wall! If you can: put the teams (with images of the team members) on the same wall. Maybe their boards as well, but at least a team presentation poster (of the individuals and of the team's responsibilities) together with the team's goals for this and the coming sprints (or what you call your planning horizons).

Big visible calendar! One tricky part of scaling is the synchronization issue. You see your team mates, but seldom put that in the larger context; or here the drum beat / see the conductor. But actually the whole organization share common goals, and those goals will be realized through specific events. In order to increase the visibility and synchronize between teams: have a common visible calendar with all the releases, all sprint demos, and all other events that are important to them all.

These are just some of the simple tricks that you can use to increase transparency among many teams. There are more to scaling than this and I will cover them in more blog posts, but now it is sunny weather and I need to prepare for my son's birthday reception.

Aspektledarskap

Jag har blivit bjuden på fika hos företaget Green Bullet, konsulter som jobbar med att hjälpa organisationer att införa smidiga arbetssätt i personalhanteringsprocesserna.

Fikat var bra och samtalet ännu bättre, och en sak vi pratade om var ledarskapets roll i de smidiga teknikerna. Ibland talar man om situationellt ledarskap: att en ledare ska tillämpa olika sorters ledarskap beroende på situation.

Med smidiga tekniker går vi ofta ett steg längre: att ledarskapet för olika aspekter av arbetet fördelas mellan olika funktioner, som alltså utövar detta ledarskap samtidigt.

Det viktigaste ledarskapet är målstyrningen. Där bestäms det åt vilket håll laget ska arbeta:vilka konkreta mål och delmål som objekten ska uppnå. I Scrum och många andra metoder motsvaras detta av en produktägarfunktion, och målen visualiseras i en ordnad behovslista. Detta är verksamhetens värdeskapande: VAD som ska uppnås.

Det näst viktigaste ledarskapet är självstyret i arbetslaget. Här bestämmer man HUR man uppnår målet, och man hur man följer upp att målen nås. Detta ledarskap är emergent: beroende på vad laget ställs inför kommer olika personer att träda fram och ta ledande roller.

Detta samspel mellan mål och utförare äger rum i en miljö. Denna miljö måste skapas av en ledning som förstår att skapa ett stödjande ledarskap som kan hantera individuella problem, som ansvarar för rekrytering, lönesättning, och som har allas välmåga för ögonen. Det är framför allt här processerna runt personalen behövs, och där företag som Green Bullet kan hjälpa till, med sin blick för det de kallar "agil HR".

Sedan kommer processtyrningen. För att samspelen ska fungera krävs det att någon smyger runt och tar ansvar för dem. Vi kan kalla det för en processchef eller scrummaster, någon måste få igång samspelen och coacha fram både självstyre och en jämn nedbrytning i delmål och vara den som ser till att alla relationer är positiva och produktiva.

I en mer primitiv organisation har man Chefen på alla dessa positioner. Det skapar både bräcklighet och toppstyre. Smidiga arbetssätt bygger istället på självstyre och resiliens.

Smidighet?

Ja, vad menar vi med smidiga arbetsmetoder?

För det första att smidighet (liksom lean och agile) beskriver en egenskap hos ett samarbete. Smidigheten är resultatet av en process, men processen i sig är inte nödvändigtvis särskilt smidig. Det är inte våra metoder som är smidiga, men våra metoder gör oss - alltså vårt samarbete - smidiga. Vi vill få organisationer att bli som smidiga organismer, genom att tillämpa metoderna.

Tänk på smidigheten hos en som dansar balett. Träningsmetoderna är inte så smidiga och följsamma alla gånger, men kroppen blir det, som ett resultat av att man uthålligt utövar sin konst. Den smidighet vi vill uppnå gäller alltså samarbetena, de mellanmänskliga relationerna i värdeskapandet. Dansaren tillämpar sina tekniker på sig själv, individuellt; vi tillämpar våra tekniker på oss som grupp.

Smidigheten vill jag sedan påstå kommer av fyra andra egenskaper man ska försöka öka i sitt samarbete: lättrörlighet, slankhet, styrka och uthållighet.

Lättrörlig (agile)

Att vara lättrörlig är att snabbt kunna byta riktning utan större kostnad. Det är en viktig egenskap för alla som arbetar för att tillfredsställa en efterfrågan som snabbt växlar. Den är också viktig för alla som arbetar med att utveckla nya saker och utforska nya områden: de nya insikterna som hela tiden skapas gör att man behöver tänka om.

Det är inte underligt att termen föddes inom systemutvecklingen, och att de metoder som kallas agila kommer därifrån. Att utveckla system är verkligen att jaga ett mål som hela tiden rör sig i takt med att nya insikter görs. Men lättrörlighet är en viktig egenskap för många samarbeten.

De tekniker som skapar lättrörlighet syftar till att skapa snabba återkopplingar i samarbetet, så att processen styrs empiriskt mot det rörliga målet. Man arbetar som en målsökande missil: inspektera nuläget genom att fråga sig var man är och var målet är; och anpassa kursen därefter. Ju snabbare och oftare man kan inspektera och anpassa, desto lättrörligare är man.

Teknikerna syftar till att öka transparensen (annars kan man inte inspektera) och makten (annars kan man inte anpassa någonting).

Slank (lean)

Slankhet, det som på engelska heter lean, innebär att man städar bort allt från processen som faktiskt inte bidrar till värdet. Att man minskar slöseriet. Är man inte slank, dvs om man gör en massa onödigheter i sitt arbete, så kommer det bli mycket dyrt att försöka bli lättrörlig: tänk hur svårt det är att anpassa kursen för en alldeles för tung raket.

Det här tänkandet föddes inom japansk efterkrigsindustri, och det är inte underligt eftersom man var tvungen att försöka bedriva verksamhet med mycket knappa resurser. Slöserier märks ju inte lika lätt i en överflödsekonomi. På sikt innebar knappheten därför en fördel, eftersom man var tvungna att tidigare och hårdare än konkurrenterna göra sig av med slöseri och spill.

Nu, i en tid då både råvaror och uppmärksamhet är knappa resurser måste alla samarbeten bli slankare.

Stark (fit for purpose)

Med styrka menar jag samarbetets förmåga att leverera. Vad hjälper det oss om vi är lättrörliga och utan tungroddhet om vi till att börja med inte klarar av att göra det vi ska?

Det finns en mognadsutveckling i samarbetet som leder till ökad styrka. Först är man fokuserad på individerna: är det Fatima som ska göra det ena eller andra, eller är det Pelle? Sedan mognar man och inser att det egentligen handlar om att olika roller ska göra saker. Och därefter börjar man fundera: mer exakt vad ska göras. Man får ett fokus på sina processer. Individerna och rolltagningen är fortfarande superviktig, men viktigast är att ha klart för sig vad som ska göras.

Det är här som olika processramverk, som t ex ITIL och andra förvaltningsmodeller kan bli till nytta. De standardiserar olika aspekter av arbetet och gör samarbetet duktigare på att utan risk, defekter och avbrott skapa det värde man vill skapa.

Uthållig (resilient)

För att få de långtgående goda effekterna av de smidiga arbetssätten får de inte rinna ut i sanden. De måste vara resilienta, så att vi hela tiden väljer att hålla fast vid dem. Därför kommer uthålligheten av samarbetets förmåga att vara bra för människorna som ingår.

Processerna innebär inte en orimlig arbetsbörda. Folk hittar sammanhang som stärker dem och där de känner att de kan påverka. Rädsla och tvång städas bort. Det finns ett ständigt förbättringsarbete som tar bort hinder för det goda arbetet. Här samverkar mängder med små faktorer och konkreta tekniker i processerna, i spilljagandet, och i inspektera-anpassa-looparna, så att smidigheten inte bara blir en nyårslöftesgrej utan vidmakthålls.

Till vår hjälp har vi principer och värden, som t ex att respektera människan. Men viktigast i uthålligheten är ledningens roll som kulturskiftare och kulturbärare. Här finns ett helt fält av nyttiga insikter, och jag rekommenderar var och en som varit igång ett tag i sin smidighetsrevolution att börja titta på t ex Management 3.0 eller det som kallas för Rightshifting. Där får ni goda tips i kulturskapandet som hjälper er att bevara den smidighet ni är på väg att uppnå.