De færreste udviklingsafdelinger vil stå frem og sige, at de arbejder efter vandfaldsmodellen. Det er moderne at udvikle agilt, som opfattes som en proces, der står i kontrast til de store, dyre og langstrakte it-projekter, der prægede 1990’erne.
Men én ting er at sige, organisationen arbejder agilt - noget andet er, om man faktisk bruger de principper, der blev beskrevet i det agile manifest fra 2001.
»Scrum blev til et 'brand'. Så nu kunne du tage på et kursus og komme tilbage og kalde dig 'Scrum Master'. Men var du på magisk blevet forandret? Nej, det er bare et stykke papir, og chefer elsker papir,« sagde agil udviklingsekspert Dan North i sin keynote på udviklerkonferencen Goto 2016.
Ikke at der er noget galt med Scrum i sig selv, men det er ifølge Dan North vigtigt at huske, at der ikke er én agil metode. Derimod handler agil udvikling om en række principper, og der findes en bred vifte af metoder, der understøtter dele af den agile tankegang.
»Du bør designe din egen metode, der passer til din organisation. Der er ikke én agil metode. Scrum er bare én løsning til bestemte problemer,« sagde Dan North.
Men selve det agile manifest trænger også til en finjustering. Det blev skrevet af en gruppe midaldrende softwareudviklere, der alle havde arbejdet med de samme idéer og variationer over de samme løsninger. Men det betyder også, at det for eksempel ikke taler tydeligt til alle parter i processen.
Eksempelvis taler det første af manifestets 12 principper om 'værdifuld software', men det bør ifølge Dan North omskrives til blot 'værdi', fordi det ikke kun handler om et softwareprodukt, men også dets funktion.
Det vil også give mening at omskrive det andet princip om at imødekomme ændringer i krav undervejs. Ifølge Dan North er det mere praktisk at formulere det som 'imødekomme krav, der opstår undervejs'.
Et af problemerne med vandfaldsmodellen var, at milepælene, hvor en del af programmet skulle afleveres, blev meget afgørende. Det var ikke blot et spørgsmål om at have leveret en vis mængde funktionalitet, der opfyldte nogle krav.
Det handlede også om, at ansvaret for produktet blev afleveret fra ét hold til et andet.
Det opstillede nogle meget skarpe grænser, hvor der ikke var nogen vej tilbage, deraf metaforen om vandfaldet, hvor der ikke var nogen vej tilbage, når først man havde bevæget sig ud over kanten.
Men vi er ikke helt fri for de samme tankegange, selvom vi arbejder agilt ifølge Dan North.
»Det er meget sjældent, at vi arbejder rigtig iterativt og går tilbage og koder noget om. I stedet bliver det mere 'incremental delivery'. Men de færreste af os kan bare sætte en ændring i produktion. Der er stadig én der skal godkende vores arbejde. Så vi har noget, der kan kaldes 'water Scrum fall',« sagde Dan North.
Alliér dig med den rigtige mellemleder
En af de store udfordringer ved agil udvikling er, at det ikke kun er en metode for den enkelte udvikler eller blot det enkelte team. Det omfatter større dele af organisationen, og det medfører en vis modstand, som man er nødt til at forstå, hvis man som udvikler gerne vil forandre udviklingsprocessen.
Mens der er de udviklere, der helst ville klare sig helt uden mellemledere, så er det lederne, der er nødvendige, hvis de agile principper skal have en chance for reelt at påvirke måden, organisationen arbejder på.
»Men hvordan fortæller man chefen, at 'agilt er fantastisk, og du vil stå uden arbejde!'? Du er nødt til at udnytte systemet til at forandre systemet,« sagde Tony Grout, der tidligere har stået i spidsen for at få store organisationer som IBM og Microsoft til at arbejde agilt.
Det klogeste, man kan gøre som udvikler, der ønsker at gå over til en agil arbejdsproces, er at finde den rigtige mellemleder, man kan alliere sig med. Det forudsætter imidlertid, at man forstår mellemledernes verden.
»Observér cheferne. Find ud af, hvad valutaen er i din organisation og sæt det agile ind i det økonomiske system og vis chefen, hvordan agilt kan hjælpe med at give afdelingen mere af organisationens valuta,« sagde Tony Grout.
Valutaen er forskellig fra virksomhed til virksomhed. Det er typisk nogle KPI'er, der er vigtige. Hos Microsoft var det på Tony Grouts tid værdifuldt at kunne tilføje mange features til produktet, mens det hos IBM var vigtigst at forbedre bundlinjen med færrest mulige medarbejdere.
Ved at sætte agile principper ind i et organisatorisk perspektiv, hvor chefen kan se, at forandringen kan give bedre resultater, så øger man chancen for en positiv modtagelse.
På den anden side skal man ikke spilde kræfter på at overbevise en skeptisk chef. Det er bedre at finde de chefer, der er lige på vippen.
»I en politisk debat kan du aldrig overbevise din fjerneste modstander til at skifte holdning, men du kan trække nogle af tvivlerne over på din side,« sagde Tony Grout.
Mellemlederne vil generelt modsætte sig forandring, hvis de sidder i en stor organisation, hvor tingene går godt. De vil se et skift til en ny arbejdsproces som at gå fra noget, hvor de fremstår som vindere i organisationen til en situation, hvor de har chancen for enten at vinde eller tabe.
Men selvom en chef er positivt indstillet, så er det ikke sikkert, at det er den rette allierede. Her bør man vurdere, om chefen er en type, der oprigtigt vil arbejde for dine idéer, eller om chefen er typen, der løber med idéen og vender den til noget, der meler hans egen kage og får ham til at fremstå som en vinder - uden organisationen nødvendigvis har fået den gevinst, du oprindeligt ønskede.
»Det fører til 'proceteater', hvor man gør en masse ting, der ligner at arbejde agilt, men bare er skuespil,« sagde Tony Grout.
I stedet kan det være en idé at finde en chef, som har et problem i sit chefarbejde, som man kan foreslå en løsning på. På den måde kan man vinde chefens tillid og få en allieret.
»Der er måske dem, der vil sige, at det er ufint, men held og lykke med at være fin i den virkelige verden,« sagde Tony Grout.
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
