Povl gav op på møderne: Hjælp, jeg er ikke agil!

Det er sjældent, at jeg kommer op og skændes med folk. Det er endnu sjældnere, at det er sket på mit arbejde.

Men det var nu alligevel præcis, hvad der hændte engang, da mit team sad i den rituelle ”retrospective”. Retro er et begreb fra metodeapparatet “scrum”, der ligesom andre såkaldt agile arbejdsmetoder oprindeligt stammer fra IT-udviklingsbranchen, men efterhånden har fundet vej ind på mange andre typer arbejdspladser. Således også på den, hvor jeg arbejdede, da skænderiet fandt sted.

Slet ikke dumt

Agilitet er ikke nødvendigvis dumt. Det er dybest set en tankegang og nogle organisatoriske greb som for eksempel målnedbrydning, samarbejde, ressourcebevidsthed, prioritering, løbende evaluering, kontinuerlig læring og værdiskabelse i tæt parløb med kunden.

Alt sammen glimrende på rigtig mange arbejdspladser, også udenfor IT-branchen. Det er derfor hverken fjollet eller et ligegyldigt modelune, når ledere i mange sektorer har et godt øje til agilitet. Det kan faktisk være rigtig fornuftigt.

Men alligevel var det agilitet, der førte til skænderiet mellem mig og nogle endnu fredeligere kollegaer. Når det kunne ske. Endda midt under en ceremoni som retro, der blandt andet har til formål at skabe et trygt og behageligt samarbejdsklima.

Så giver det stof til eftertanke. Både for mig personligt og i forhold til agilitetsdagsordenen, der i disse år bliver rullet ud på overraskende mange danske arbejdspladser og kontorjobs som mit, der ikke havde ret meget med softwareudvikling at gøre.

Klagesange fra sjæledybet

Skænderiet gik i bund og grund ud på, at jeg endnu engang var frustreret. Eller måske ligefrem jamrede, alt efter hvem man spørger. Det var ikke første gang i løbet af det lille halve år, mit team havde arbejdet agilt.

Min tilbagevendende brok gik ud på, at størstedelen af mine arbejdsopgaver ikke rigtigt lod sig passe ned i den agile ramme, vi arbejdede efter. Agilitet fungerer som regel bedst, når man nogenlunde kan estimere opgavernes omfang og har kontrol over sin tid.

Det havde jeg ikke, og derfor fungerede rammen dårligt for mig og mit arbejde. Syntes jeg selv. Men det var vi altså uenige om. Klagesangen mødte mildest talt ikke resonans hos alle mine teamkammerater, og efter nogle gensidige misforståelser kørte det op i en spids. Det vil jeg gerne bruge denne anledning til at undskylde overfor samtlige, der var tilstede.

Efter støvet havde lagt sig, og alle var gode venner igen, var jeg dog ikke holdt op med at spekulere. Var det mig, der var noget i vejen med, når jeg tilsyneladende var så uagil? Eller er det faktisk sådan, at agilitet ikke passer lige godt til alle typer arbejdsopgaver? Det ene udelukker selvfølgelig ikke det andet.

Et agilt problembarn

Hvis jeg skal starte med mig selv, er der helt sikkert noget om det. Jeg trives ikke specielt godt med meget fastlagte planer og skemaer. Jeg holder af struktur. Dog kun til et vist punkt, for derefter kan det føles som en spændetrøje.

Selvom agilitet – som navnet antyder – umiddelbart er en smidig og løs ramme, kan den hurtigt blive det modsatte med krav om klare forudsigelser af, hvilke leverancer man har tænkt sig at præstere i den kommende tid. Det passer ikke vildt godt til mit temperament.

Min tålmodighed er heller ikke ligefrem designet til den mængde dokumentation og administration, som agilitet også kan medføre.

Endelig besidder jeg en ikke altid rimelig skepsis overfor buzzwords og etablerede sandheder og alt, hvad der er ”one size fits all”.

Man kunne således betragte mig som en kreativ, fleksibel, selvstændig og kritisk tænkende ressource. Men i et agilt setup er jeg desværre nok mest bare til besvær. Jeg kommer i hvert fald selv let til at føle mig gammel, sur og vrangvillig.

Kan man drive en agil brandstation?

Men jeg tror nu altså også, at mindst en del af hunden ligger begravet i, at arbejdsopgaver nu engang er forskellige og ikke alting passer lige godt ind i et agilt mindset. Bare fordi metoderne er gode til softwareudvikling er de jo ikke nødvendigvis gode til alt.

Kan man for eksempel drive en brandstation agilt? Jov, helt sikkert, når det gælder vask og vedligehold af brandbiler, udarbejdelse af vagtplaner og andre opgaver, der kan planlægges.

Men man kan vel umuligt forudse præcis, hvor mange udrykninger der skal håndteres de næste par uger, og hvor tidskrævende de bliver. Den type opgaver kan ikke på forhånd målnedbrydes, tidsestimeres og prioriteres. De er en løbende forpligtelse, og jeg regner da med at brandfolkene prioriterer samtlige alarmopkald, uanset hvor mange der kommer.

Jeg håber inderligt, at de bruger al den tid, det tager at slukke brandene fuldstændigt uden at skele til deres forudgående planlægning, og jeg ville forvente, at de udsætter at vaske bilerne, hvis der kommer flere alarmopkald end sædvanlig den dag, hvor det var programsat.

At planlægge 0 sekunders arbejde

Selvom mit arbejde nok aldrig har været lige så vigtigt som en brandmands, har det nok oftere haft flere ligheder med brandmandsarbejde, end med den IT-udviklingsverden, hvor agilitet stammer fra.

Mine opgaver har ofte haft karakter af brandslukning, men endnu oftere har de været afhængige af leverancer fra eksterne. Andre mennesker, der af uforklarlige årsager har været fuldstændigt ligeglade med min planlægning og leveret på en uforudsigelig måde, både hvad angår kvalitet og timing.

Denne type opgaver vil typisk tage alt mellem 0 sekunder og et par dage at løse indenfor en overskuelig tidshorisont. Det har ofte været et vilkår for mit arbejde, og det plejer jeg at trives fint med.

Men det passer nok bare ikke så godt i et agilt setup. Og derfor trives jeg ikke særlig godt med agilitet i almindelighed og med skænderier med højt skattede kollegaer i særdeleshed.

All in eller cherry picking

Alt i alt vil jeg påstå, at ligesom agile metoder har deres åbenlyse kvaliteter, har de deres begrænsninger. Det har de nok især i teams med opgaver, der ikke så let lader sig planlægge.

Som leder for sådan et team, må man derfor træffe et valg:

- Skal man gå all in, og prøve at massere så meget agilitet ind i sin organisation som muligt. Det kræver en investering. Man bliver nødt til at uddanne sine medarbejdere i metoderne, teambuilde og forventningsafstemme omkring dem. Og man må berede sig på at skulle håndtere de frustrationer og mægle de konflikter, der måtte opstå.

Man må acceptere, at det nok aldrig kommer til at køre helt glat uanset hvad. I yderste konsekvens må man nok også være klar til at udskifte de mest vrangvillige folk som mig selv med nogle lidt mere agil personligheder.

- Eller også skal man gå den anden vej. Blot lade sig inspirere af principperne og håndplukke de elementer, der giver mest mening. Men lade være med at kalde det agilitet. Så snart man indfører det ord skaber man nemlig en masse forventninger hos dem, der trives godt med den agile metode, og kan blive frustrerede, når virkeligheden ikke lever op til forventningerne.

Hvis agilitet er svaret, hvad var så spørgsmålet?

Den sidste mulighed medfører selvfølgelig en risiko for, at man går glip af nogle af den agile verdens potentielle gevinster. Og endnu værre kan det selvfølgelig ske, at man som leder må lide et statusfald overfor alle de andre ledere, for hvem alene ordet ”agil” markerer dig som the shit indenfor moderne ledelse.

Til gengæld kan man måske undgå at gøre sine gamle, sure medarbejdere endnu mere sure. Valget er dit, kære leder.

Ikke så galt og godt for mange

Det hører med til historien, at der findes masser af medarbejdere, der fungerer helt fint med agilitet, uanset om deres arbejdsopgaver passer godt eller kun halvgodt ind i tankegangen.

På mit nuværende arbejde findes der masser af dem, og nogle af mine nærmeste kollegaer hjælper endda andre med at lære og få det bedste ud af metoderne. Det har jeg den dybeste respekt for, og jeg glæder mig oprigtigt over hver gang, agil metode – og alle andre metoder – er en hjælp til at løse opgaver eller gøre det sjovere at gå på arbejde.

Og selv brandfolk kan vel lære noget af kontinuerlig evaluering og øget bevidsthed om deres ressourceforbrug.