Hvis Agile aldrig gør ondt, gør du det forkert

1. apr.

Skrevet af

Benjamin Rasmussen
Udvikler

Det er meget svært at finde gode, konkrete eksempler på Agile fra den virkelige verden —så nu kommer jeg med mine, fra min egen hverdag. Her vil jeg fortælle dig lidt om, hvorfor jeg elsker Agile, selvom det er hamrende irriterende at arbejde med.

Jeg har tidligere skrevet om, hvorfor ordet ‘Agile’ giver mange mennesker en dårlig smag i munden og om, hvordan det ofte hænger sammen med, at folk og firmaer misforstår, hvordan man bruger Agile. Lang historie kort — Agile er et mindset, ikke en værktøjskasse.

Man kan være fristet til at se nogle af de Agile processer som puslespils-brikker, der kunne indsættes i en eksisterende konstellation. Det kan man selvfølgelig godt — og det er da ikke utænkeligt, at nogle af de processer isoleret set kan forbedre ting — men hvis du sammenligner det med alt det hype, der er omkring Agile, vil du nok blive slemt skuffet.

Det er jo sådan set logisk nok. Hvis noget er åbenlyst værdigivende, så er det selvfølgelig klart, at det bliver brugt. Problemet med Agile er, at jo mere værdi det giver, desto mindre synligt er det.

Eksempler fra den virkelige verden

Det er sindssygt frusterende at prøve at finde konkrete eksempler på Agile i den virkelige verden. Den åbenlyse årsag er som sagt at det er, når Agile er mindst synlig, at det giver mest værdi. Men helt ærligt så tror jeg også, det hænger sammen med, at Agile er blevet så abstrakt for så mange mennesker, at man er bekymret for at sige noget konkret i frygten for, at man har misforstået noget og ligner en idiot.

På trods af at jeg har arbejdet i et agilt bureau i 5 år, har jeg da også den frygt — men nu giver jeg det et skud alligevel. Reloads vinkel på Agile er baseret på at gøre op med de traditionelle silo-roller. Organisationen har generelt et meget fladt hierarki, og det afspejler sig både i vores interne og eksterne arbejde. Min egen oplevelse med det flade hierarki i Reload har jeg også skrevet lidt om her.

Reload-projekter har semi-faste teams, men rollerne er en del mere flydende, end jeg har oplevet tidligere. Som team-medlem har du meget autonomi, og det er super fedt at have muligheden for at bruge sin personlige erfaring og viden til at influere projektets retning.

Det betyder dog også, at hele teamet har et fælles ansvar for, at ting lykkedes. Den mere traditionelle bureaukrati-silo-model er netop bygget op omkring, at folk skal blive i deres afdeling, og at ansvaret dermed er delt ud. Det kan lyde meget trygt at vide, hvilke roller og hvilket ansvar man har, men det er nærmest designet til at afholde innovation og vidensdeling fra at ske.

På mine tidligere arbejdspladser var det meget begrænset med direkte kontakt til kunder/projektejere. Tankegangen var, at man skulle begrænse, hvor meget “spildtid” udviklerne brugte på ikke at kode — og at det var projektlederen, der brugte sin ekspertise til at snakke sammen med kunden og finde ud af ønskerne, retningen og planen

Det lyder måske meget godt på papiret, men i virkeligheden betød det så, at en helt masse af den viden jeg havde, ikke blev brugt i planlægningen, og at planen sådan set var lagt på forhånd. Det betød også, at jeg kun fik en overfladisk forretningsforståelse, så den smule rådgivning jeg fik lov at give havde begrænset værdi.

Jeg kunne selvfølgelig komme med kommentarer løbende, men eftersom der allerede var blevet brugt en masse dyr mødetid på at komme frem til løsningen, var der en naturlig modvilje imod at ændre planerne. Så, i stedet for at virkeligheden satte planen, blev virkeligheden justeret til at passe til planen. ( 🚩 !!!)

Nogle gange kan man være heldig at nå mållinjen med noget, der faktisk ligner de originale ønsker inden for det originale budget, men selv når det sker, så står du ofte med et produkt, hvor projektejerens egne ideer ikke er blevet sundt udfordret. Det hele må briste eller bære på projektejerens antagelser og uden den ekspertrådgivning, som kunden nok havde forventet mere af til prisen.

Vejen til helvede er brolagt med gode intentioner

Det der dog ofte sker er, at projektet går i gang, de forskellige parter kan se røde flag, men ingen har rigtigt mandat eller mulighed for at gøre noget ved det. Skinnerne er lagt, og straks lider alle af get-there-itis.

“get-there-itis”

- 1. (aviation) The determination of a pilot to reach a destination even when conditions for flying are very dangerous (in technical terms, a form of plan continuation bias).

Ofte står du tilbage med et projekt, hvor ingen er glade. Kunden føler sig ført bag lyset af dårlige undskyldninger, udvikleren har lavet en ustabil løsning, som hun vidste var forkert, og et eller andet sted i midten står projektlederen der har gjort det bedste, han kunne for at styre en raket der aldrig skulle have lettet.

Det er svært at bebrejde kunden for at følge sig snydt. Det er også svært ikke at ytre bandeord, når et it-bureau endnu engang har formået at lave et offentligt it-projekt, der er gået 1.5 milliarder over budget, 3 år over tid — og som skaber flere problemer end det løser. Man kan være fristet til at tro, at det er ond vilje, og det kan jeg selvfølgelig ikke kunne 100% sige, at det ikke er. Jeg tror dog, at det er bureaukrati-silo-metoden der er designet til, at det næsten kun kan ende sådan her — ond vilje eller ej.

“Det skal gøre ondt, før det gør godt. Hvis det var nemt, ville alle gøre det.”

Benjamin Rasmussen

Drømmen om at tage ansvar

Tilbage til det Reload-ansvar jeg snakkede om tidligere. Det var lidt af et kulturchok, da jeg startede som udvikler i Reload og pludselig havde så meget kundekontakt. Jeg var lidt skeptisk over at blive inviteret med til alle møderne, og det trak virkelig tænder ud, når man skulle sidde i et 3-timers sprintplanlægningsmøde hver anden uge.

På trods af alle de ting jeg havde oplevet tidligere, så endte jeg da også med direkte at stille spørgsmål om det her virkelig var den bedste måde at bruge min tid og kundens penge. It-projekter formår nærmest altid at have en eller anden irriterende, arbitrær deadline og allerhelst ville jeg bare i gang. Vi vidste jo godt alle sammen, hvad der skulle laves, ikke?

Men jeg blev overbevist om, at der var mening med galskaben, så jeg fortsatte med at komme med til møder, hvor der ofte blev stillet spørgsmål ved retningen, og hvor planer sjældent fik lov til at forblive statiske længe.

Igen — det var så frusterende ikke at have en klar plan og et rent billede af, hvad vi faktisk ender op med at lave. Ja tak, den generelle retning forblev for det meste, men det var da nærmest også det eneste der var stabilt. Det var ikke kun mig, der havde det svært ved det. Selvom de var blevet solgt ind på processen, så var det til tider også svært at overtale kunderne til at stole på fremgangsmåden.

Jeg forstod udmærket deres skepsis. Det er ret skræmmende kun at styre ud fra en retning uden helt at vide, hvor man ender. Især når man har sit eget bagland, der skal overbevises. Men på trods af de løbende frustrationer blev jeg gang på gang overrasket over, at vi nåede i mål — og at alle var glade (?!). Vi havde ikke brugt dobbelt så meget budget. Der var ingen, der var overraskede over det endelige produkt. Når deadlinen ramte, havde vi altid noget der faktisk fungerede. Selvfølgelig var der kedelige overraskelser undervejs. Estimater der ikke holdte, eller antagelser der var forkerte.

Før projektet havde kunden en idé om, at de skulle bruge en rumraket. Nu, efter en hel proces står de med en Volvo. Ja okay, Volvoen kan ikke flyve til månen, men nu skulle den jo egentlig også kun bruges til at køre i Brugsen. Sammenlign det med silo-projekter hvor man blindt går i gang med at bygge en rumraket, der aldrig kommer ud af carporten.

Agile er frustrerende — og det er også meningen

Det tog et par projekter, før jeg virkelig begyndte at tro på den her proces. Det er egentlig ret utroligt, da jeg burde have været brændt nok tidligere til at kunne værdsætte de her projektafslutninger — men det er svært at slukke for den lille fristende stemme i hovedet.

“Du behøver ikke tage med til det møde, det er bare PL-snak.”
“Kan vi ikke bare hoppe stand-up over i denne uge? Vi ved jo godt, hvad vi er i gang med”
“Vi har sindssygt travlt, kan vi ikke skrotte vores retrospektiv-møde, så vi har mere tid til at arbejde?”

Nogle gange vinder fristelsen og nogle gange går det — men andre gange har jeg da også selv oplevet, hvordan det kan starte en ubehagelig spiral, hvor tingene kommer mere og mere ud af kontrol. Når man først står der, så er det svært at sætte bremsen i og nulstille processen for at genvinde kontrollen. Man lider pludselig af det “get-there-itis” som jeg beskrev tidligere.

Hvor silo-metoden er designet til, at folk arbejder blindt efter en plan, er Agile designet til, at der konstant er forhindringer i vejen. Forhindringer, der tvinger dig til at stoppe op og reflektere over, om det man er i gang med er rigtigt.

En generel misforståelse er, at Agile er en direkte modsætning til fast-pris projekter, og at det så betyder, at du som kunde ingen kontrol har over, hvor meget det koster.

Det passer ikke. Du har faktisk mere kontrol med Agile. Med Agile arbejder vi hele tiden på at lave det vigtigste først og aldrig at slutte et sprint med halv-færdige ting. Det betyder så også, at man i teorien, på et hvilket som helst tidspunkt, kan sætte budget-bremsen i og sige “Så! Nu lancerer vi!”. Selvfølgelig er der i den virkelige verden smertegrænser der er for store til at lancere under. Men det er ikke fordi, at et klassisk fastprisprojekt beskytter dig mere fra det.

Hvis du har fået overtalt et bureau til at levere et specifikt sæt features til en fast pris, og det ikke er realistisk, så er der reelt kun 2 udfald:

Bureauet får dig overtalt til at lægge flere penge

eller:

De arbejder videre, men da bureauet mister penge på hver time de ligger, er der kun incitament til at gøre tingene hurtigt og ikke ordentligt.

Til sidst står kunden med en dårlig smag i munden, bureauet har brændt (endnu) et kundeforhold og en slutbruger sidder et sted og bander over Aula.

*Trustpilots bruger giver deres besyv med…*

Tillid er svær at vinde — men er uundværlig

Reload har et værdisæt, som vi bruger som vores ledestjerne.

Den første og vigtigste værdi er efter min mening den om ærlighed:

Vores integritet er hellig.
Vi gør, hvad vi siger, holder, hvad vi lover og er ærlige i vores ageren. No bullshit. Vi skal til enhver tid være 100% troværdige. Vi siger fra, hvis vi mener noget er forkert. Vi gør det rette — selv når ingen kigger. Vi fortæller de svære sandheder — også når det gør ondt på os selv eller kunden. Vi skal altid kunne stå inde for vores handlinger.

Værdier er nemme at have, men svære at efterleve. I Reload kan jeg ærligt sige, at vi virkelig gør vores bedste for altid at være ærlige.

Jeg har set flere situationer, hvor vi sagtens kunne have løjet om noget for at skaffe flere penge i kassen eller komme med realistiske undskyldninger for fuck-ups. Men det er ikke i vores DNA.

Fuldkomment ligesom de fristelser jeg nævnte tidligere, så er uærlighed en fælde, man skal undgå, for hvis ikke du har dine samarbejdpartneres tillid, så har du et råddent fundament.

Jeg kan være helt ærlig omkring mine holdninger, idéer og tanker. Jeg kan råbe højt, når noget virker dumt, og jeg er ikke bange for at fortælle, når det er mig, der har lavet en fejl.

Ved at spare op på tillidskontoen er det også nemmere at arbejde sammen. Nemmere at være modig nok til at prøve innovative idéer af som i sidste ende resulterer i et federe produkt, et federe projekt og et federe samarbejde.

Det hele hænger sammen. Tillid fungerer ikke uden ærlighed, og Agile fungerer ikke uden tillid.

Agile tvinger dig til at stoppe op og være ærlig. At se virkeligheden i øjnene og tage stilling til om projektet er på rette vej.

Tak fordi du læste med!