Kan du forestille dig, at der i disse dage er nogen virksomhed med respekt for sig selv, der vil sige: ”Nej, her hos os er vi overhovedet ikke agile, og vi overvejer heller ikke at blive det”? Nej vel! Det er ikke særligt sandsynligt. At arbejde agilt – hvad man end måtte lægge i det – er efterhånden blevet standardtilgangen.

Men hvad betyder det egentlig? Det kan faktisk være meget forskelligt, fordi der findes ikke et agilt facit, der har to streger under. Der er mange forskellige måder at gå til det agile på. Der er forskellige metoder og frameworks at vælge mellem, forskellige ambitionsniveauer, forskellig organisatorisk og agil modenhed osv.

Det er nemt at forstå, hvorfor man jagter højere agilitet, for hvis man kan få det agile til at spille, kan man skabe ganske overvældende positive resultater. Problemet er bare, at selv de mest populære agile systemer er meget komplekse (og dyre) at komme i gang med (især SAFe), og agiliteten opstår altså ikke, blot fordi man ændrer sin organisation og giver folk nye titler.

Som agil rådgiver, coach og underviser med +10 års praktiske erfaringer i bagagen fra en perlerække af teams og organisationer, står det helt klart, at der nogle mønstre, der går igen ”derude”. Desværre er der tale om anti-patterns, og det er uanset om valget er faldet på Scrum, Kanban eller SAFe. Disse mønstre trækker i den stik modsatte retning af agil effektivitet.

Det er ærgerligt, dels fordi der bliver brugt enorme summer på (mislykkede) agile transformationer, og dels fordi det giver kæmpe frustrationer over hele linjen, når den store forandring, man har været igennem, ikke giver de resultater, man var ude efter.

Hvad er det så, der går galt?

Det er der flere ting der gør, men her kommer de vigtigste:

1. At arbejde agilt medfører, at man skal tænke projektarbejde på en temmelig anderledes måde. Men ofte er hverken medarbejdere eller ledere forberedte på den forandring, som en agil implementering fører med sig. Viljen til forandring er heller ikke altid til stede.
   
2. Ledelsen sætter sig ikke grundigt nok ind i, hvad det kræver at dreje organisationen i en mere agil retning. Man vurderer primært ”mekanikken” i metoden: Hvilke møder skal vi holde, hvilke roller har vi osv. Erkendelsen af, at det handler om at ændre kultur og vaner – også i ledelsen – mangler. At lave organisationsændringer skaber i sig selv ingen agilitet
   
3. Der findes en agil lemmingeeffekt. Det betyder, at de fleste vælger det, de andre gør eller det, der lige nu er oppe i tiden. Der bruges ikke tid nok på at forstå de forskellige agile systemer, så man kan vælge den agile vej, der er det bedste match til ens organisation og det, man arbejder med. Mange vælger simpelthen forkert
   
4. Man er ikke helt parat til at forlade den måde man plejer at arbejde på. I de fleste organisationer er ledelsen stadig mere optaget af, at alle medarbejdere er fuldt udnyttet end på at skabe flow i værdikæden. Man fastholder sin governance-model fremfor at skabe en ny, der understøtter det agile. Man har ikke helt tillid til, at de agile principper og teknikker kan virke.
   
5. Arbejder man inden for IT, så er der i udgangspunktet stor kompleksitet. Denne kompleksitet forsvinder ikke, fordi man begynder at arbejde agilt. Hvor skulle den forsvinde hen? På overfladen ser de mest populære agile modeller besnærende enkle ud, men går man et enkelt spadestik dybere, vil man se, at det er de ikke. Det har man bare ikke erkendt, og forventer derfor det umulige

“Doing agile og being agile?”

Om man er agil eller ej bliver ofte en strid om, hvorvidt man bruger den ene eller den anden metode eller framework, man lad os glemme religionskrigene. Skåret ind til benet handler agilitet om at levere den rigtige vare i en ordentlig kvalitet til sine kunder og gøre det så hurtigt, man kan.

For at kunne vide om man arbejder ”så hurtigt man kan”, bliver man nødt til at måle på, hvor effektivt man leverer.

Forestil dig, at du skal købe en eller anden vare. Det er ligegyldigt, om det er et par nye bukser, du køber på nettet eller en ny vaskemaskine, en cykel eller hvad det nu er. Som kunde (i hvert fald hvis du ligner mig) vil du især være interesseret i, hvor lang tid der går, fra du har lagt din ordre til du står med varen i hånden. Det er det, man kalder gennemløbstiden (på engelsk: lead time).

I agile sammenhænge er gennemløbstider ekstremt vigtige. Hvis man vil undgå forsinkelser og skabe forudsigelighed, er det faktisk helt afgørende, at man kender sine gennemløbstider. Så kan man nemlig begynde at analysere, hvor i ens arbejdssystem, der opstår forsinkelser. På den måde kan man optimere systemet og forkorte sine gennemløbstider – til kundernes store begejstring.

Ser man på de gængse agile systemer, er det kun Kanban, der har benhårdt fokus på at måle. Særligt gennemløbstider. Kanban er et flow-system, der ikke dikterer en bestemt organisering. Scrum og SAFe er samarbejdsmodeller med bestemte roller, møder m.v., og man skal arbejde i sprints.

Der kan pudsigt nok være stor modstand mod at måle effektivitet. Særligt i mere umodne teams og organisationer, hvor man ser det som en ny form for kontrol fra ledelsens side, så de kan holde øje med om man bestiller noget. Det er selvfølgelig ikke det, der er meningen med det hele.

Meningen er at få folk vænnet af med at være agile robotter, der pænt går til en række møder, fordi metoden dikterer det, og i stedet blive proaktive flow-managers, der bestandigt vurderer, hvorfor der opstår afhængigheder, hvorfor aktiviteterne går i stå, hvor lang tid de ligger stille, hvad man kan gøre for at forhindre det osv. De har fuldt fokus på, hvordan man kan bringe sine gennemløbstider ned og blive mere forudsigelige, så man kan love sine kunder noget, der også holder i virkeligheden.

”Agile” er ikke et ”easy fix”

Virker de agile systemer? Ja, absolut! Hvis altså man bruger dem, som det er tænkt. Ellers får man bare mere af det, man hele tiden har haft, selvom man kalder tingene og rollerne noget andet.

Nogle agile metoder og frameworks er voldsomt komplicerede, mens andre er nemmere at gå til. Nogle kræver stor forudsigelighed for at fungere. Andre kan håndtere uventede situationer. Derfor er det så vigtigt at vurdere, hvilke arbejdsopgaver man løser, om der opstår mange uventede ildebrande, om man har mange individualister og personsiloer m.m., før man vælger sin agile vej.

Skal man lykkes med sit agile initiativ, er det også vigtigt, at man fra starten har gjort sig klart, hvad man gerne vil opnå. Det gør det muligt at planlægge implementeringen og sætte en konkret retning.

Med andre ord kan et grundigere forarbejde sikre, at man ikke vælger en agil tilgang, som aldrig vil kunne fungere under de givne omstændigheder.

Sidst med absolut ikke mindst skal man erkende, at det er en kulturforandring af de større, man kaster sig ud i. Det tager tid, og lederne skal gå forrest, for den slags forandringer opstår ikke nedefra. Men hvis man holder fast, vil resultaterne vise sig.