15 år efter det agile manifest: Vi er stadig ikke gode til agil udvikling

Dan Norths forslag til at justere det agile manifest til 2016. Illustration: Jesper Stein Sandal
Selvom agil udvikling er populært, så ender vi oftest med en proces, der stadig ligner vandfaldsmodellen.

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.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (13)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Casper Pedersen

Som en der har stået overfor et "agilt" udviklet project/produkt, må jeg nok sige at jeg ikke er specielt imponeret.

Hvordan kan man forklare kunder at man bruger tid på at tilføje de funktionaliteter som man havde lovet skulle være ver. 1.0, og ikke har tid til at rette de fejl der gør at produktet ikke virker.

Kan vi ikke bare blive enige om at Agility er endnu et buzz word som viser at branchen har problemer med at finde sig selv ... vi skal jo alle på en eller anden måde skal have lov ... til at ændre ting.

  • 2
  • 6
Rasmus Kaae

Spændende. Jeg tror du har været involveret i en uheldig omgang Scrum. Ideen er at kunden er involveret og informeret om hele udviklingen via Product Owner.

Agility er et buzzword. Et buzzword der bla advokerer for tillid og samarbejde. To elementer jeg personligt håber forbliver aktuelle i al udvikling.

  • 7
  • 0
Anders Poulsen

Hvis man har travlt med at tilføje mere funktionalitet istedet for at rette de fejl, som er i det man allerede har lavet, så er det godt nok en meget speciel dialekt af agil udvikling du har mødt. Det er normalt ideen at man laver lidt funktionalitet og sikrer sig at det virker som det skal INDEN man bygger mere ovenpå.

  • 5
  • 0
Morten Toudahl

Casper:
Så er det ikke rigtig agil, se anders' svar.

Ud over det, så er der åbenbart også blevet lovet mere end teamet kan holde, hvis de lovede features ikke er blevet implementeret i de lovede iterationer.
Og hvis du taler om efter release, er det endnu et tegn på at der ikke er blevet udviklet agilt. Da man jo ikke låser sig fast på features, men på release date og pris.

  • 1
  • 0
Anonym

Nej agile egner sig ikke til alle projekter alle steder. Det får mig til at tænke på pre-SCRUM metoden DSDM, som starter med at spørge, om projektet og dets deltagere er klar til agile. Desværre døde DSDM lidt i den mere udvikler venlige SCRUM metode, men jeg kan anbefale den hvis man leder efter en metode der ligger mellem vandfald og SCRUM.

  • 0
  • 0
Rasmus Kaae

Hmm. De agile værdier og den kultur der ligger bag er faktisk også relevant i fx vandfaldsprojekter.

Hvornår har man ikke lyst til at involvere sin kunde?

Hvornår har man ikke løst til at behandle ændringsønsker?

Scrum er, som artiklen skriver, blot én løsning. Der kan være flere eg DSDM, Kanban, osv.

  • 0
  • 0
Anders Poulsen

Hver gang man involverer kunden, risikerer man at blive klogere end man var, da projektet blev planlagt. Og da de fleste projektledere bliver målt på om de kan levere til tiden og prisen, vil det være karrieremæssigt selvmord at involvere kunden før det er så sent i projektet at man alligevel ikke kan lave ændringer.

  • 2
  • 0
Martin Jünckow

Jeg har har arbejdet i mange projekter hvor man påstod man anvendte agile development og Scrum, men hvor man i virkeligheden blot havde taget et par elementer uden rigtig at have forstået filosofien og tankerne bag. Det nytter altså ikke meget at indføre daily standups og Jira og tro at nu er man agil hvis man ellers arbejder som hidtil.

Mit seneste kundeprojekt involverede 2000 siders dokumentation og specifikation af det man ønskede leveret til en stram deadline 6 måneder senere - alle sprints var forudfyldte fordi man vidste jo præcis hvad det var der skulle laves hver uge for at det kunne nåes - og det første vi blev præsenteret for var kunden der gik meget op i hvor agile de var og hvor meget de havde omfavnet Scrum ...

Men jeg har også prøvet at arbejde i et projekt hvor vi rent faktisk kørte noget der var meget tæt på ægte Scrum og tilmed i en stor Enterprise virksomhed (60k medarbejdere). Med Scrum-teams bestående af både udviklere og forretningsfolk hvilket resulterede i cross-funktionelle teams uden det her traditionelle skel mellem IT og forretningen og for os gav det et meget bedre indblik i og forståelse for hvad forretningen foretager sig og hvilke udfordringer de har og for dem gav det en meget bedre forståelse for hvad det ville sige at omsætte det til relle praktiske løsninger.

Det var for alvor en øjenåbner for mit vedkommende og hvor jeg tidligere var temmelig skeptisk omkring det hele og mest så det som buzzwords ala Casper udtrykker det, så er jeg nu overbevist om at de fleste organisationer kan have fordel af at gå mere agil, men vel og mærke uden at det bliver sådan en gang halvhjertet halløj som man typisk ser rundt omkring. Jeg vil faktisk anbefale man får sendt sine folk på kursus - både PO, Scrum Master og Udviklere så alle ved hvad det handler om.

Personligt har jeg taget certificering igennem Scrum.org som et 5-dages kursus og selv med 15 år som professionel udvikler hvor jeg ellers ikke forventer meget af den slags, må jeg erkende at det er et af de bedste og mest inspirerende kurser jeg har taget (og nej jeg får ikke penge eller har anden personlig interesse i at sige dette).

  • 3
  • 0
Martin Jünckow

Og så vil jeg sige at alfa og omega er en dygtig Scrum master der ved hvad han laver (og ikke bare er blevet omdøbt fra sin tidligere projekt leder titel, som desværre er kutyme ...).

Det er ham der skal sørge for at mindsettet er rigtigt i teamet (ikke med pisk, men med inspiration) og han skal være i stand til at forklare hvorfor de forskellige elementer skaber værdi også selvom den enkelte udvikler eller PO måske ikke er i stand til at se det samlede billede og gerne vil trække tingene tilbage i mere vante rammer. Og hvis han omvendt ikke kan forklare hvorfor dele af processen skaber værdi, så bør han også sørge for at tage diskussionen med teamet om hvordan man så kan forbedre processen.
Og hvis PO'en ikke har en baggrund i Scrum, så er det også essentielt at Scrum Masteren understøtter denne - uden en ordentlig vedligeholdt backlog, så falder Scrum altså hurtigt fra hinanden.

Det er selvfølgelig en fordel at alle på holdet forstår Scrum og ikke mindst PO'en, men den vigtigste brik ifølge min erfaring er at man har den rigtige Scrum Master på holdet - det er oftest forskellen på et successfuldt Scrum team og et hvor folk brokker sig i krogene og forsøger at ignorere det mest muligt så de kan fortsætte som hidtil.

  • 4
  • 0
Rasmus Kaae

Fuldstændig enig i din observation. Scrum i sig selv gør ikke at man tænker agilt. Det er et process framework som bla kan bruges til at arbejde agilt - men i sin essens er det blot en ekskveringsmekanisme. Det kaldes mekanisk Scrum.

  • 0
  • 0
Carsten Ove Schwartz Nielsen

Interessant artikel med klassiske beskrivelser af frygten/modstanden mod Agile. Det er en svær problemstilling, der drejer sig om basal forandringsledelse, hvor problemerne ved den gammeldags bureaukratiske organisation bør illustreres som de økologiske tab de reelt er. Her skal man være forsigtig fordi en klassisk støvhvirvler som et Projekt Office kan man jo ikke bare sige man vil nedlægge fra dag 1 og erstatte med et med Produkt Ejere i stedet for Projekt Ledere, selv om det sandsynligvis er løsningen, det er en lang proces og den går sommetider op ad bakke i modvind. :-)

Når det handler om udvikling med agile metoder er der ikke noget der hedder vi prøver med lidt af det og så går det nok. På lang sigt er det:

Gør det helt eller fortsæt med at smide penge ud af vinduet på bureaukratisk 'ikke arbejde'.

Og det er her det kniber, nogle antager at man kan plukke det der lige passer ind i ens kram fordi det forstærker ens magtbase/silo/imperie eller på anden måde tilfredsstiller særinteresser. Den adfærd sætter agile udvikling i et dårligt lys og skaber blot yderligere tab og frustration i virksomheden...

  • 1
  • 0
Log ind eller Opret konto for at kommentere