Flöde, möda, och nytta

Att inse att all värdefull verksamhet är ett flöde som i slutändan gör minst en människa glad är en beprövad metod att skaffa sig ett tankesätt som driver ut spill och osmidigheter. Leanpionjären Deming beskriver det som ett motgift mot ett par av de "verksamhetens dödliga sjukor" han beskriver i boken Ut ur krisen. Kartläggning av värdeströmmen är ett vanligt sätt att jaga slöserier i till exempel en tillverkningsprocess eller en vårdkedja. En mjukvaruskapande organisation skildrar sitt värdeflöde i en behovslista och en flödestavla.

Ett flöde tar ett ärende (en patient, en kund, ett råvaruämne, en önskad mjukvarufunktion) och omvandlar det - steg för steg - till ett levererat värde (färdigbehandlad patient, nöjd kund, färdig produkt, implementerad och levererad funktion) i händerna på någon (till exempel patienten eller kunden själv).

Vi behöver alltså identifiera vilka steg ärendet tar. I de fall där ett arbetslag arbetar tillsammans nära varandra med ett ärende i taget behöver man oftast inte dela upp värdeskapandet i diskreta steg. Där sker arbetet dynamiskt människorna emellan, och spillen är ofta inte av en sådan art att de synliggörs med t ex en flödestavla utan uppträder mer subtilt. Men när värdet skapas i en sekvens som innefattar att ansvaret för ärendet i någon form överlämnas från ett lag till ett annat, är det bra att visualisera det som om ärendet går från ett steg till ett annat.

Ett vanligt fel när man tänker på sitt värdeflöde är att man skiftar fokus från nyttan till mödan. Vi människor har ingen spontan känsla för värde, däremot har vi en väl utvecklad känsla för om vi arbetar hårt eller inte. Vår möda är för oss mycket mer konkret än resultatet av mödan. Vi blir lätt mödodrivna (efforts driven) snarare än nyttodrivna (results driven). Det är därför som känslan av produktivitet är bland de farligare känslorna vi har.

Varje steg ska alltså inte definieras utifrån vilket arbete som görs, utan utifrån vilka små värdefulla delmål som ärendet uppnår. Patienten fick sitt blodtryck taget och den önskade funktionen blev nedbruten i delfunktioner som kan implementeras och utvärderas på två veckor. Här kan en scrumterm hjälpa: delmålet utgör ärendets klarkriterium (Definition of Done) för detta steg i flödet.

På samma sätt behöver vi titta på vilket tillstånd ärendet måste befinna sig i för att på ett någorlunda förutsägbart sätt kunna behandlas i detta steg. Vi måste definiera ett görbarhetskriterum (Definition of Ready) för att kunna bestämma om ärendet ens är görbart.

Det blir nu ganska uppenbart att värdeflödet inte fungerar om inte görbarhetskriteriet för nästa steg är detsamma som klarkriteriet för vårt steg, eller om vårt görbarhetskriterium inte matchar det föregående stegets klarkriterium. Start- och slutvillkoren för våra respektive steg är som kontrakt i flödet. Vi måste samarbeta om dem.

Våra organisationer är tyvärr ofta utformade så att de som hanterar ärendet medan det har lågt värde inte sällan har större makt än de som hanterar ärendet i slutet. Det skapar en vilja att försöka forcera igenom ärenden (tryckande flöde), vilket skapar en enorm mängd spill i form av överlast och ojämnhet. I stället ska flödet fungera dragande, eftersom nästa steg i kedjan vet precis vad som krävs för att nå nästa delmål.

Men om man tittar på stegen tillsammans kommer man att upptäcka ställen där viktiga delar av värdeskapandet ramlar mellan stolarna. Låt företrädarna för efterföljande steg hela tiden ställa krav på de tidigare, och inför nya steg när ni ser att det är ett hopp mellan det ena stegets klarkriterium och nästa stegs krav på ärendet. Man ska kunna se hur ärendet i en obruten kedja får högre och högre värde.

Genom att ha detta fokus på värdet blir både syftet med hela kedjan tydligt, liksom syftet med varje steg. Detta är en nödvändig förutsättning för att kunna organisera själva arbetet, mödan, inom varje steg. Har vi inte koll på nyttan kommer vi inte ha koll på hur vi bör arbeta.

Bilden är från Wikipedia Commons.

Det här blev den första i en serie om flöden:

• Flöde, möda, och nytta
• Köer - om att köer är naturliga men inte speciellt effektiva.
• Den fåfänga kapacitetsökningen - om att den spontana impulsen att öka resurserna när det går trögt inte alltid är så smart.
• Sluta börja, börja sluta - om att lösningen är att påbörja färre saker och istället färdigställa desto fler.
• Begränsa er och bli bättre - och att begränsningar av hur mycket jobb man tar på sig faktiskt kan förbättra genomströmningen i flödet.
• De usla jonglörerna - om att vi är usla på att hantera flera saker samtidigt.
• Infarkten - om det havererade flödets sluttillstånd.

Flödestavlan

Verktygen för visuell styrning kan delas in i olika kategorier beroende på syftet. Processplanscher synliggör gruppens överenskomna arbetssätt. Stora väggkalenderar är ett fantastiskt verktyg för att hålla tidplaner och skapa en gemensam förståelse för vad som brinner i knutarna och vad man kan vänta med. Människokartor som visar vilka människor som huserar var i organisationen sätter ett ansikte på var och en och ökar vi-känslan (till skillnad från organisationskartor som gömmer bort att det är folk inblandade).

Och så har vi förstås den traditionella flödestavlan, känd från produktionsplaneringen och systemutvecklingen.

Idén bakom flödestavlan är att den ska få alla att se var olika ärenden befinner sig i värdeflödet. Annars har vi lätt att tänka att ärenden tillhör den-eller-den organisationsdelen eller är den-eller-den människans ansvar; vilket är sätt att tänka som skapar mycket spill.

I en flödestavla representeras varje ärende av ett kort som löper från vänster till höger. Kortet hoppar fram mellan olika kolumner, där varje kolumn motsvarar ett moment där ärendet antingen arbetas på (för att kunna hoppa till nästa kolumn), eller där ärendet vilar.

Vissa flöden är mycket detaljerade, med många kolumner som visar varje arbetsmoment. Men det finns också flöden som likt den traditionella flödestavlan i Scrum bara visar om ett ärende ska göras, arbetas på, eller är färdigt.

Vilken grad av detaljrikedom som krävs måste gruppen som har nytta av tavlan bestämma. Det finns en frestelse i att detaljera allt, vilket skapar merarbete och kan orsaka brist på nödvändig flexibilitet. I synnerhet finns en frestelse att från ledningshåll vilja detaljera allt, så att ledningen utifrån tavlan alltid ska få rätt slags rapporter. Det är ett misstag och ett stort slöseri. Flödestavlan ska koordinera samarbeten runt smidiga värdeflöden, för dem som har behov av denna koordination, och inte vara till för någon annan. Det finns betydligt bättre och effektivare sätt för en ledning att skaffa sig kunskap om sakernas tillstånd i värdeflödena.

Skälet till att ett Scrumlag klarar sig med den allomfattande kolumnen "Arbetas på" är att man svärmar runt ärendena. Laget jobbar tillsammans och har inte behov av att koordinera sig med hjälp av verktyg, eller att formalisera sin interna process. Kolumnerna "Att göra" och "Klart" är däremot samarbetspunkter där andra intressenter lämnar över eller tar vid.

På samma sätt kan man resonera i alla flöden: när samma lag behandlar ett ärende finns kanske inte behovet av att detaljera hur det görs. Det får i så fall laget bestämma, kanske är värdeprocessen såpass komplex att visualisering hjälper. Men när olika grupper av människor måste samarbeta, till exempel om att prioritera ärenden, eller precisera och bryta ner dem, då är separata kolumner på en flödestavla ett utmärkt hjälpmedel för att få alla som inte jobbar tillsammans dagligen att förstå hur landet ligger.

Det finns mer att säga om flödestavlor, till exempel om hur köer på tavlan kan vara både bra och dåligt, och hur man genom att ändra regelverket runt tavlan kan få flödena att bli bättre på olika sätt. Och inte minst hur man kan använda data från tavlan för att kunna göra prognoser. Men det får bli en annan gång, det är söndag morgon och jag ska till kyrkan.

Bilden visar en scrumtavla hos en av mina kunder.

Dokumentation?

Det agila manifestet för mjukvaruutveckling säger att man bör värdera fungerande mjukvara framför utförlig dokumentation. Slarviga läsare har tagit den raden som skäl att strunta i allt vad dokumentation heter, och ängsliga processmänniskor har tagit raden som skäl att bli oerhört tveksamma till metoder som kallar sig "agila". En process som inte förskriver precis vilka dokument som behövs kan ju inte vara en bra process, eller hur?

Men som sagt: Agilt är ingen process eller beskrivning av en metod. Agilitet är en egenskap ett samarbete kan behöva (tillsammans med slankhet, styrka och uthållighet) för att bli smidigt. För att kunna tackla frågan om dokumentation behöver man förstå varför manifestets undertecknare skrev som de gjorde.

Vad är syftet? Detta är alltid den första frågan. Att undra över hur man gör (t ex med dokumentation) är en signal om att man kanske inte har målet riktigt klart för sig.

Syftet, slutpunkten i alla värdeprocesser, är alltid minst en människa som blir glad över något. Vilka ska använda dokumentationen? Till vad?

När det gäller tjänster (och fungerande mjukvara är en tjänst) finns det två huvudsakliga lägen: du utvecklar tjänsten, och du utför tjänsten. Det agilister och lean-folk har upptäckt är att precis, kortfattad och lättförståelig dokumentation är nödvändig för att kunna utföra tjänsten rätt. En processbeskrivning gör att vi inte brakar ihop när läget blir pressat. Vi vet hur matbiten ska stekas, vi kan söka upp det kodstycke där felet i inloggningsrutan troligen finns, vi vet att krutladdningen som ska spränga bort dörren och blåsa upp flygplanets nödrutschbanor faktiskt är apterad. "Cabin crew: arm slides! Cross-check and report!"

Så dokumentation över hur saker fungerar ingår i tjänsten som utvecklingen levererar. Ingen tjänar på att den är extensiv och sitter i tjocka pärmar eller ligger på ett intranät. Däremot att den är lätt att hitta och hitta i. Planschprincipen, att all processdokumentation ska sitta i form av planscer på väggarna, ett ögonkast bort, är ett sätt. Människan som behöver dokumentationen behöver den fort, i en form som är anpassad för hennes hjärna.

Men hur är det med dokumentation för att utveckla själva tjänsten? Här brukar det finnas mycket att tjäna. Som det heter i den här utmärkta vägledningen för agil dokumentation: "Well-written documentation supports organizational memory effectively, but is a poor way to communicate during a project."

Det visar sig nämligen att tjänster i osmidiga organisationer gärna utvecklas i silos, att olika discipliner sitter på varsin kammare och klurar på sin del. Delarna lämnas sedan över till nästa kammare, och nu måste dokumentationen vara mycket omfattande för att informationen ska kunna klara av denna överlämning utan att sippra bort.

Men ändå sipprar det bort, för information överförs inte bäst med hjälp av dokument. Att utveckla en tjänst är att samla in, raffinera, och slutligen - vid behov - kodifiera denna kunskap. Det gäller mjukvara (mjukvara är kodifierad kunskap) och det gäller arbetsrutiner vid en hotellreception. Bäst på kunskapsraffinering är de som har de effektivaste flödena för att göra gemensamma insikter.

Gemensamma insikter görs i dialog. Riv upp alla silos där det går och svärma runt det som ska utvecklas. Om ni måste ha olika avdelningar med tillhörande överlämningar: ta bort all dokumentation som bara finns där för att stödja överlämningen. Ersätt den enkelriktade överlämningen med täta dialoger, och låt den skriftliga dokumentationen bli till i ett gemensamt avdelningsöverskridande samarbete om samma dokument. Och det är alltid de som ska utföra nästa steg i raffineringen som vet vad som behövs; information ska alltså inte tryckas fram i systemet utan efterfrågas från de som ska göra jobbet.

Ni har själva insikten om vilken dokumentation ni behöver. Det gäller bara att våga nöja sig med den.

Bilden föreställer processdokumentationen hos en av mina kunder, publicerat med tillstånd. Så snart man på ett förbätringsmöte/retrospektiv beslutat om att testa en liten förändring av processen (PDca) sätter man en handskriven post-it med den nya varianten rätt på väggen, där man önskar förändringen. Så snart man beslutat om att permanenta förändringen (pdCA) skriver man ut ett papper och förändrar dokumentationen. Planschprincipen, "Standardized work", och "Visual management" i ett kompakt litet smidigt nötskal.

Alltid en människa

En viktig del av alla smidiga tekniker (lean, agilt och så) är att få syn på värdet. Slöserier definieras som: nedlagd möda och material som inte ökar värdet jämfört med alternativen. Man gör värdeströmskartläggningar för att se när processen tillför värde och när den inte gör det. Allt ska underordnas värdeflödet.

Men värden finns inte. Inte i sig själva. Någon måste värdera för att man ska kunna säga att något är värt. Om värden är globala och eviga eller ej, det vet vi inte (här kommer tron in), utan allt vi vet om värden är att det är människor som värderar. Värderar olika, dessutom.

Ett värdeflöde slutar alltså alltid med en människa som blir glad. Med den insikten ramlar många pusselbitar på plats. Själv brukar jag aldrig närma mig en whiteboard som workshopverktyg utan att överst i högra hörnet rita en glad människa i profil. Det hjälper oss som är i lokalen att hela tiden påminna oss om varför vi är där:

Det är alltid en människas glädje, längst ut i slutet av värdeprocessen, oavsett vad vi försöker åstakomma; som är vårt yttersta mål.

Tilliten i systemet

För att öka räckvidden på sin ingrupp ("Öka vi-känslan" som det heter på hurtig konsultsvenska) behöver vi tillit. För att våga exponera resultat vi varit delaktiga i (en förutsättning för att kunna ta kommandot över sitt arbete) behöver vi tilliten att ingen angriper oss därför. Tillit är livsnödvändigt för den goda organisationen.

Det finns individualpsykologiska mekanismer som ökar tilliten. Att bli anförtrodd saker, dvs att någon visar tillit till en själv, ökar både ens egen grad av tillit till andra och ens benägenhet att inte svika dessa förtroenden.

Vi brukar önska mer tillit, vi idealiserar chefen som vågar delegera, och vi längtar efter det tillitsfulla arbetslaget. Hur ska vi nå dit? Chefscoachning på temat "Våga lita på dina medarbetare"? Försäkran gång på gång från ledningen att "Här får man misslyckas, här får man misslyckas"? Kanske påverkar till viss del, men önskar vi inte mer?

Det finns en faktor som påverkar tilliten mycket starkare än att folk i organisationen kommunicerar vilken tillitsnivå de önskar. Det är ju så att tillit är en ganska skör sak. Om jag som chef anförtror medarbetarna något och de ändå misslyckas gång på gång? Om gruppen inte klarar av sitt självstyre, och jag som en medlem av gruppen hela tiden blir delaktig i felen de andra gör? Om chefer och andra anförtror mig uppgifter, men jag hela tiden underpresterar eftersom det faktiskt är väldigt svårt?

Det som till slut avgör tilliten är inte ambitionen, utan den faktiska förmågan att leverera. Tillit skapas på det plan i vårt medvetande som arbetar med associationer, och vi har lätt att associera människor (inklusive oss själva) med "klarar inte av, klarar inte av". Levererar folk inte det förväntade och önskade, så slås tilliten sönder.

Men samtidigt vet vi att det är systemet mer än individerna inom det som bestämmer resultatet. En organisation, ett samspel, är alltid perfekt riggat för att ge det resultat det ger idag. Känslomässigt knyter vi visserligen tillit till om vi upplever att folk ger oss det vi önskar, men vi vet att det är omständigheterna som styr. Inte folks attityder eller förmåga att kämpa emot ett skakigt system.

Tricket är alltså att göra systemet mer värt vår tillit. Förbättras systemet kommer allas förmåga att leverera bli säkrare, och då ökar den mellanmänskliga tilliten till varandra. Vi måste alltså ta ansvar för processerna, så att det blir lättare att åstadkomma ett gott resultat inom dem. Driva ut rädslan för att göra fel genom att göra det svårare att göra fel. Inte genom att försöka inspirera folk att bli mer dumdristiga.

När Deming i sina fjorton punkter om ledarskap pratar om att skapa tillit ("Drive out fear, so that everyone may work effectively") gör han det som en kommentar till den föregående punkten om det viktiga ledarskapets roll, och då inte om ledaren som inspiratör och hejarklack utan en som ser till att processerna åstadkommer en trygg och produktiv miljö. Verksamheten ska inte vara så skör att folk blir rädda för att ta ansvar för delar av den.

Det finns i de smidiga arbetssätten många exempel på tekniker för att förbättra systemen. Jag har nämnt vissa redan här på bloggen och jag tänker skriva om fler. Men jag tänkte avslutningsvis i det här inlägget lyfta fram tre principer, som på ett särskilt sätt ökar just tilliten.

Det första är transparens. Ett system kan fungera riktigt dåligt och ändå inte vara en otrygg plats, om alla bara får omedelbar återkoppling från systemet självt om hur resultatet av deras olika vägval. Är du som chef obekväm med att delegera är det förmodligen av goda skäl, troligen är systemet för otydligt för att du ska vara trygg. På samma sätt upplever den som ska ta på sig arbetsuppgifterna en otrygghet. Men varje lättviktig synliggörandeteknik (korta cykler mellan avstämningarna, arbetstavlor som visar värdeflödet etc) motverkar detta.

Det andra är automatiska nödstopp, principen som på japanska kallas jidoka. Det gör att problem inte sprider sig när de uppstår. När en maskin löper amok ska hela produktionskedjan stoppas, när balansräkningen i ett företag börjar se ut på ett visst sätt ska styrelsen och VD genast tänka om, osv. Tokigheter uppstår, men vi ska tryggt kunna lita på att inget tokigt fortgår.

I Scrum sätter man till exempel upp ett sådant jidoka-larmsystem när det självstyrande utvecklarlaget larmar beställaren/kravchefen så fort de märker att delmålet för den pågående 2-4-veckorsperioden inte kommer att nås. Ingen behöver nervöst följa upp att de når målen, utan kan tryggt lita på att de får en omedelbar signal så fort det inte är fallet.

Det tredje är samarbeten. När centrala funktioner i verksamheten isoleras till enstaka individer ökar risken för haveriet markant. Genom att samarbeta, svärma, runt värdeflödena uppstår en gemensam syn på vad som sker och vad som ska göras, och ingenting vilar på en enstaka persons stackars axlar.

Allt detta ökar systemets förmåga att leverera, vilket ökar tilliten till systemet, vilket ökar tilliten mellan människor. Rädsla, i synnerhet befogad rädsla, bygger inte tillit.

Hat är starkare än kärlek

Nej, det där kanske kom ut fel. Men rädsla hos oss människor är starkare än nyfikenhet och öppenhet. Och hat kan ju vara ett försvar inför ett upplevt hot, en rädsla.

Rädslan ska vara starkare. En gång för länge sedan var det ett barn som sa: Kolla! Vilken konstig krokodil! Den vill jag undersöka! Det barnet fick aldrig möjlighet att bli anförälder till någon av oss. Våra släktingar, barnets kompisar, var av en betydligt mer lättskrämd sort.

Om vi inte har detta klart för oss får vi svårigheter på vår väg mot smidighet. Smidighet kräver ju att vi utmanar vårt eget och andras beteende, i den ständiga förbättringsprocessen. Men att utmana beteenden väcker frågor, rädslor, och tvekan:

Blir det rätt och riktigt om vi gör på det nya sättet? Blir det nya konstellationer? Måste jag ge upp mina gamla kolleger? Försvinner valmöjligheter? Blir vi processlavar? Kommer vi alls att kunna navigera i detta nya? Vad händer med min förmåga att påverka? Vilka kommer att få lov att påverka mig?

Det här är subtila hot som våra hjärnor ständigt undersöker om vi är utsatta för. Vid blotta misstanken om fara går en signal in till det innersta, vårt limbiska system, som rent fysiskt förmår blockera all öppenhet för det nya och istället får oss att värna det vi redan känner till.

Chefer brottas med det här problemet när de vill möta en ändrad omgivning med en ändrad organisation. De upplever att många anställda vägrar följa efter. Att folk trilskas och sätter klackarna i backen. Men i själva verket är det helt normala och faktiskt riktigt bra larm som startar. En begriplig omvärld, trygga relationer, och möjlighet att påverka på ett schysst sätt är djupt liggande mänskliga behov. Tillgodoses inte dessa inom en organisation bestående av människor kommer inte organisationen kunna göra bra ifrån sig.

På samma sätt, och detta kan komma som en överraskning för anställda som organiserar sig som självstyrande arbetslag och börjar skaffa sig kontroll över värdeflödet, så kommer vissa chefer att uppleva stor otrygghet inför det nya. Till och med då chefen står bakom dem och faktiskt aktivt önskar eller tillochmed bestämmer att de ska börja tillämpa smidigare arbetsmetoder; till och med då kan chefen trilskas och sätta klackarna i backen.

Säga att självstyret ska komma igång, men aktivt motverka det.

Återigen är det vår mänskliga, helt normala och helt ändamålsenliga överaktiva rädsla som gör sig påmind.

Motgiftet? Jo:

Gå långsamt fram. Gör ständiga små förändringar, utförda som experiment innan de permanentas.

Tala om vad som sker. Synliggör arbetsflödet och organisera er runt det. Lyft upp alla hinder mot smidighet som blockerar och föreslå själva en lösning.

Samarbeta i lag. Var skoningslösa mot er själva när det gäller att visa total transparens. Var mjuka och respektfulla mot alla och tryck och gapa inte igenom saker. Fundera över hur Shingo Shigeos principer är tillämpliga hos er.

För alla individer i ett komplext system gäller att beteendet och utfallet av beteendet till allra största delen beror på systemet och inte på individernas egenskaper var för sig. Detta gäller även den högsta ledningen. De delar av systemet som består av våra mest primitiva neurala skyddsmekanismer kan vi inte negligera. Bättre att se det som naturligt, och samarbeta runt strategier för att minska de dåliga och öka de bra effekterna av något som ändå är ett faktum.

Chefskap och ledarskap

Detta är en liten utvikning på avslutningen i det här inlägget som handlade om olika sorters ledarskap i en typisk smidig/agil kontext. Jag avslutade med orden I en mer primitiv organisation har man Chefen på alla dessa positioner, dvs en chef sätts att ensam försöka utöva alla sorternas ledarskap. Jag konstaterade även att Det skapar både bräcklighet och toppstyre.

Det är lätt att sätta likhetstecken mellan chefskap och ledarskap. En svensk fackförening för chefer heter Ledarna, och chefsutbildningar handlar ofta om att förbättra sitt chefskap genom att bättra på sina ledarfärdigheter.

Att man som chef behöver gå ledarskapsutbildningar är ett tydligt tecken på att chef och ledare faktiskt inte är samma sak, och att det därmed inte är givet att den som leder måste vara chef. I smidiga tekniker som bygger på självstyrande arbetslag, t ex Scrum, är det tvärtom så att en grupps förmåga till självstyre påverkas negativt av att utsättas för ledarskapsambitioner utifrån.

1977 skrev Abraham Zaleznik en sedermera klassisk artikel där han utforskade skillnaden mellan att vara chef (manager) och ledare (leader). En chef förvaltar en (del av en) organisation, beslutar om regler och arbetsgångar, fördelar resurser, och agerar skiljedomare när andra organ inte når fram till beslut.

Zaleznik pratade om att den viktiga Ledaren, istället för att som chefen fokusera på organisatoriska system, förmår inspirera människor och vägleda dessa genom kaos och turbulenta omständigheter. Sedan denna artikel publicerades har också chefsidealet ändrats: från att vara någon som bestämmer från ovan till att vara någon som går i bräschen, och är personlig och närvarande.

Här uppstår två problem.

För det första är det precis som William Deming säger: organisationens förmåga att skapa grejer beror till allra största delen (Deming pratade om 95%) på hur samspelet - själva systemet - fungerar. Individernas kapacitet har väldigt lite att göra med resultatet i ett såpass komplext samspel som en modern organisation.

När cheferna inriktar sig på att vara varje medarbetares ledargestalt abdikerar de från ansvaret för hur systemet fungerar. De frågar hur individerna mår, men saknar förmåga att designa om arbetssystemet (Hey, det är ni som är experterna!) i det fall systemet gör individerna illa. De fokuserar på frågan hur varje enskild medarbetare har lyckats, istället för på frågan vilka systemfel som finns som hindrar medarbetaren från att göra sitt jobb. Själva ansatsen att inspirera individer, hur välvillig den än är, utgår från den dolda föresatsen att det är individernas brist på inspiration som på något sätt är problemet.

Så chefskap är alls inget som ska överges, bara för att vi har insikten att chefskap inte är liktydigt med ledarskap. Till produktionen krävs många underleveranser, och chefskapet ska leverera beslut och allokerade resurser för att skapa förutsättningarna för ett gott arbetssystem. Med smidiga metoder upprättar man ofta en ständig återkopplingsmekanism som lyfter de systematiska hinder som medarbetarna har identifierat, och det är en typisk chefsuppgift att med det formella mandatets tyngd ta bort dessa hinder.

Det andra problemet är att kombinationen av stora (alla?) formella mandat, parat med de beteenden och institutioner som stärker ledarens inflytande (du får feedback av mig, det är jag som sätter målen, det är min tolkning av verkligheten som gäller); det skapar ett mycket starkt personberoende maktcentrum.

Zalenzik varnade för detta redan i sin artikel:

Power in the hands of an individual entails human risks: first, the risk of equating power with the ability to get immediate results; second, the risk of ignoring the many different ways people can legitimately accumulate power; and third, the risk of losing self-control in the desire for power.

Det första: att mandat att styra inte automatiskt betyder att man har förmågan att styra, är något som vi alltid trycker på i alla agila utbildningar. Det är det starkaste argumentet för delegering av mandat som finns: mandatet ska ligga där förmågan finns.

Dessutom tillkommer alltså de vanliga farorna med stor makt, antingen dessa beror på maktberusning eller att man gör folk illa enbart genom sin tyngd utan att vilja det eller vara medveten om det. Som lösning på detta problem föreslår Zalenzik samma ansats som vi agilister förespråkar:

The need to hedge these risks accounts in part for the development of collective leadership and the managerial ethic

Ledarskap ska utövas av många, på alla nivåer i organisationen. Det går inte automatiskt. Om det inte finns ett tydligt mål för organisationen, och inte heller ett tydligt system för hur ledarskapet kan utövas; så är självstyre och kollektivt ledarskap fruktansvärt. Det blir förvirring och kaos. Men denna förvirring är då inte (som man kan tro) en frukt av självstyret, utan en följd av bristen på ramar och goda och trygga institutioner.

Men när det däremot finns ett chefskap som tar ansvar för arbetssystemet och resursallokeringen och att metoderna som används är sunda och gjorda för självstyre och ständigt förbättring; så är det delegerade, emergenta ledarskapet istället en tillgång. Och då märker man hur ansatser att vilja centralisera ledarskapet till samma fåtal personer som innehar chefskapet istället blockerar smidigheten.

Mål, maskineri, människor

Kanske är Syfte, steg, samspel en dum översättning av Purpose, process, people. Den är inte så tydlig.

Jag provar att använda Mål, maskineri, människor istället.

• Mål—purpose: att vi först och främst måste klargöra vad vårt samspel ska uppnå.
• Maskineri—process: att vi därefter enas om vilka mått och steg vi måste ta för att komma dit.
• Människor—people: sedan kan vi tänka över vem av oss som gör vad.

Många upplever en motsättning mellan denna ordningsföljd, och det agila manifestets ord om att Människor och deras samspel är viktigare än processer och verktyg. Fel använt kan det naturligtvis bli så. Men som jag ser det så är detta i full harmoni: om vi fördelar arbetet mellan oss utan att ha en överenskommelse om vari arbetet består (dvs om vi tänker på människor innan vi resonerat klart om maskineriet), så kommer vi visserligen att få ett maskineri, ett emergent, men hur det ser ut blir inte på något sätt transparent. Vi kommer att dölja individerna och deras interaktioner. Utformningen av processen delegeras ner till ensamma personers försök att göra sitt bästa, och då skapas mycket spill.

Det blir också starka personberoenden vilket skapar stor press (=stress =överlast) på människorna i samspelet, och en stor känslighet och variation i hela kedjan.

Hemligheten är att vi genom att tänka maskineri före människor faktiskt sätter människors samspel först. När vi funderar på målet och maskineriet så är vi ju människor som samspelar. Felet många begår är att de inte gör en gemensam process av detta tänkande, denna utformning av arbetsgången. De har inte självstyret på plats, utan tänker sig att det är ett upphöjt geni som åt andra tänker ut processen. De har inte infört att experterna själva leder och fördelar sitt arbete.

Värdeskapandet, själva processen, är ett grupparbete. Vi har upptäckt att det finns fördelar med att låta även utformningen av processen vara ett grupparbete. Då är det klokt om gruppen tänker i den här ordningen: Vilket är vårt mål, vad behöver vi göra för att nå dit, och vem av oss gör vad?

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