Når I læser dette er min dykkerferie tæt på at være historie, og jeg er i gang med at "afgasse" efter de mange dyk. Og som den sidste gæst i min klumme er det mig en særlig ære at introducere Morten Egan.
Hans far, Mogens Egan, og jeg delte kontor i Sparekassen SDS fra 1987 til 1990, hvor vi legede med et KÆMPE Oracle Datawarehouse, der endte med at være næsten umuligt at håndtere, idet det nærmede sig 6 Gigabytes i størrelse...
Nå, men Morten kunne jeg så senere ansætte som trainee i Oracle Support, og efter en glorværdig karriere i Oracle-verdenen i Danmark drog han til Singapore og har siden fået så rigeligt at lave som chef for alt muligt i en stor bank.
Jeg håber, at Morten lige gider skrive et sted i klummen, hvad han egentlig går og laver, og hvorfor han har et fast sæde på et fly til og fra Hong Kong.
Der er én detalje, der normalt ville få Morten kategoriseret som decideret mærkelig, men lad os nøjes med at kalde ham original: Han SVÆRGER til PL/SQL, Oracles procedurale extension til SQL-sproget, og tilmed den eneste reminiscens af sproget Ada, der skulle have været The Mother Of All Languages, men endte med at blive til ingenting.
Morten kan nærmest lave alt i PL/SQL. Det er meget underligt.
Nå, men lad os høre, hvad han har af nyt ude fra det fjerne Østen!
Morten Egan: Jeg sad en sen aften på mit hotel i HK og så at min gode ven Mogens havde tænkt sig at holde ferie og at han gerne ville have et par gæsteskrivere til sin klumme.
Jeg har læst de fleste (en af de få faste danske ting jeg læser), og havde en god ide til et indlæg, der var dels i Mogens ånd, men som også kunne være en lille modvægt til hvad der nogen gange kan virke som en enegang mod Agile/Scrum.
Jeg sidder i øjeblikket på mit sædvanlige sæde C70 i CX710 på vej tilbage til Hong Kong igen, hvor jeg arbejder på et lille projekt der skal skifte en core banking platform der 40+ år gammel og kører på mainframe med en lidt mere moderne og fleksibel udgave. Og selvfølgelig kører det Agile med Scrum og hele moletjavsen. Og jeg vil påstå at det er en af grundene til at det måske ikke kører så godt som det kunne.
Så min arbejdsplads skiftede til Agile/Scrum tilbage i 2018 eller deromkring. Men det er ikke bare den “klassiske” udgave (hvordan den nu end ser ud). Næh vi kører med SAFE (Scaled Agile Framework) som er Agile på steroider. Se kortet her.
Man bliver træt af bare at prøve at finde ud af hvor man starter på denne fantastiske togrejse. Det er som om at man har søgt på alle fancy udviklings keywords og fået det til at passe ind på en slide.
Så hvad er det præcis jeg har imod Agile/Scrum/SAFe? De sidste 6 år har jeg arbejdet på 3 store projekter og et mindre projekt. Et stort projekt er som regel med et budget på 100+ millioner USD. Disse store projekter har alle haft en fint afgrænset definition af hvad de skulle levere.
Et projekt skulle erstatte 35 forskellige investment portfolio performance applikationer med en standardiseret applikation, et andet skulle samle alle de forskellige “statement engines” vi havde til en og så implementering af et system/flow til at typer betalinger som vi har kørende igennem banken.
Vi er en bank der er til stede i rigtig mange lande (mest Asien og Afrika) og historisk set, har der været en tendens til at hvert land har haft deres egne applikationer til det meste. Det har nogle enkelte gode argumenter, men for det meste er det rigtig dyrt at vedligeholde og det gør fejlfinding og overvågning nærmest umuligt at standardisere også.
Det første projekt kørte “klassisk waterfall” hvorimod de andre kørte med vores nye måde at levere på, og her kommer mit første ankepunkt.
Sprints eller en rigtig Tidsplan?
Hvis vi på et stort projekt ved præcist hvad vi skal levere, vi ved præcist hvilke funktioner der er krævet hvor og vi har en fastlagt tidsramme. Så hvor er det lige at det giver mening at køre med sprints, squads, stand-ups? Et sprint er altså en fjollet måde at skulle strukturere sig efter, når man prøver at splitte 2 års arbejde ned i 2/4 ugers elementer.
Det giver måske mening hvis du ikke ved helt præcist hvad det er slut produktet skal være, men ikke her. De fleste projekter vi har kørt har vi vidst hvad slut produktet er, og der var ikke mange funktioner eller features der gav mening at splitte op over 2 uger.
Stand-ups: En fantastisk måde at spilde tid på
Når vi så kører i vores sprints, skal vi selvføglig også have stand-ups. Jeg tror aldrig der har været en større spild af tid hvis du spørger mig. Hver eneste dag er det samme, og hvis vi er heldige kan det gøres på en halv time, men de fleste tager en time, fordi vi jo skal kunne skalere vores squads, så de er som regel på 20-30 mennesker.
Er der noget mennesker er gode til så er det at finde mønstre. Så de fleste der deltager i en stand-up får efter et stykke tid, nærmest den samme opdatering ord for ord. Så giver de altså ingen mening.
Jeg kan sagtens se hvad der er blokeret lige nu, og vi burde altså alle være voksne nok til at håndtere vores “blockers” uden at skulle nævne dem i et ligegyldigt møde hver morgen.
Epics, User stories og lav fokus på dokumentation
En anden ting der sniger sig stille og roligt ind, er ideen om at vi skal bare lave epics og user stories, og fokuserer på det i stedet for at starte med en omfattende dokumentation.
Problemet er bare (i hvert fald i den branche jeg er i) at de fleste ting vi koder, er jo ikke en fantastisk ny app som kan revolutionere verdenen. Næh, det meste vi koder or som regel ret fast defineret og skal arbejde sammen med nogle allerede enten industry defineret protokoller og systemer, eller eksisterende systemer internt i vores firmaer. Hvis alt så bare er user stories så kommer vi altså ingen veje.
Hvis jeg skal kode et betalings flow hvor jeg skal integrere med SWIFT/CIPS er det altså nødvendigt at jeg har komplet dokumentation fra dem men så sandelig også på min side. Det nytter altså ikke noget at jeg starter med “a user must be able to transfer HKD to RMB from his internet banking app”.
Ikke alene ender det rigtigt galt, men jeg får altså også på puklen fra samtlige tilsyn som er involveret, fordi de sjovt nok vil have at jeg skal dokumentere alt, når jeg sådan render rundt og flytter på folks penge.
Mennesker er vigtigere end processer og værktojer
Jeg tror bare vi lader diskussionen om Jira ligge til en anden dag :)
Selvfølgelig er det vigtigt at vi som mennesker har en hverdag som hjælper os til at udføre vores job på den bedst mulige måde, og uden alt for meget udenoms snask. Så her er måske nok det punkt hvor jeg er mest enig med det oprindelige agile manifest ….
Men jeg vil altså alligevel lige tillade mig at være lidt gammel og bitter igen. Værktøjer er fint nok med mig - Så længe valget passer ind i det tekniske fundament som jeres firma har.
Så hvis i er hoppet på Microsoft-vognen, så giver det jo nok mest mening at køre Office365, kode i Visual Studio/Code, bruge ADO i stedet for Jira osv. Det er vigtigere at ting kan arbejde ordentligt sammen, end at Morten over i hjørnet kan få lov helt selv at vælge at kode i Lua og LOLCODE (https://en.wikipedia.org/wiki/LOLCODE).
Men processer (og jeg ved at mange der kender mig, bliver overrasket nu) er altså vigtige. De kan være tåbelige og spilde tid, og så skal vi lave dem om, men de er vigtige. Specielt hvis du arbejder i et firma med mere 50+ i udviklingsafdelingen.
Jeg er altså nødt til at vide hvor lang tid ting tager, hvor mange sikkerhedstjek jeg skal opfylde, hvor jeg skal registrere mit system for at det kan køre i produktion, om jeg må have det i skyen eller ej .. osv.
Mange penge små
Jeg kan desværre ikke give jer de rigtige tal fordi de er interne, men jeg loggede ind på vores program/project management platform og kiggede lidt på det.
Jeg tror hvis jeg bare skal give min egen ide om det, at Agile projekter i gennemsnit ser ud til at tage ca. 50% længere tid end før vi skiftede til Agile.
Den største grund til dette, er altså bare at Agile passer ikke ind i en branche som er så top-styret af tilsyn og regulativer fra både lokalt, region og verdensplan. Så vi kan ret hurtigt udelukke Finans, Medicin, Transport og Food&Beverage og hvad er der så tilbage?
Når vi laver det Agile, så har vi det med at glemme at se på hvor mange penge vi rent faktisk bruger på de små ting, fordi alt er splittet op i sprints. Den reelle kost forsvinder i larmen. Og selvom jeg ikke kan give jer rigtige tal, så er jeg altså ikke den eneste der har den holdning:
Ham Morten er nok bare en gammel bitter projekt mand
Nu er der måske en del læsere der efter at have læst overstående, mener at jeg bare er en old-school projekt mand, som bare vil have at alting er som før, men det er altså ikke helt sandt.
Det er rigtigt at jeg i dag, måske har mere ansvar, men størstedelen af min dag, går altså stadigvæk med at kode.
Jeg vil gerne levere et godt stykke arbejde ligesom de fleste af os, og jeg tror bare ikke at Agile/Scrum er det rigtige i de fleste tilfælde. Er det så den gamle vandfaldsmodel der er rigtig?
Sikkert ikke 100%, men jeg vil vove at påstå at hvis vi gerne vil levere software som vores kunder kan bruge og kan lide, så er den bedre en hvor de fleste af os er nu. Vi har nu som branche prøvet det her eksperiment længe nok, og jeg tror vi er nødt til at tage et skridt tilbage og blive enige om at det måske nok ikke var det bedste valg.
/Morten Egan
PS: Der skal jo være en PS sektion, så måske i kunne bruge lidt ekstra indspark, fra folk som ikke er mig :) Jeg er i hvert fald ikke den eneste der går rundt med de her tanker og hvis i søger lidt kritisk på google, så er der mange flere artikler og eksempler.
https://www.theregister.com/2024/08/07/agile_catastrophes_risk_undermining_the/