Fremtiden er agile !

For nylig snakkede jeg arbejde med en far til en af knægtenes legekammerater. Han arbejder som afdelingschef ved et af de større arkitektfirmaer her i smilets by og han fortalte begejstret om deres nye arbejdsmetode.
Metoden gik blandt andet ud på at de kørte agil konceptudvikling på deres projekter han fortalte om hvordan de afholdte scrums *og planlagde deres arbejde i *sprints, ligesom vi gør i IT projekter.

Det passede perfekt ind i arkitektarbejdet, hvor man har brug for at køre små sprints med skiftende bemanding i et større byggeprojekt, hvor alle krav ikke er kendt på forhånd og hvor fleksibiliteten er vigtig for at nå i mål indenfor en ofte stram økonomi.

Det er sjovt at man sådan støder på agile udenfor IT branchen, for selvom den agile tankegang ikke er en ny ting, så møder man den relativt sjældent rendyrket i IT branchen, desværre.

Hvorfor mon ikke? Måske fordi der er ret langt fra at køre en god, gammeldaws vandfald til at skifte helt over i den agile metodik.
Jeg møder flere der kører iterativt - hvilket i visse tilfælde vil sige gentaget vandfald, hvilket kun lugter en lille smule af agile.

Men jeg tror også der eksisterer en del myter om den agile model, der afholder folk fra at bruge det.
F.eks. at den er topmålet af projektmæssig principløshed eller at agile er en undskyldning for at leverandøren kan få en stor sæk penge og så blot køre derudaf uden at have en kravspecifikation at blive holdt op på.

Og ja, agile bliver også misbrugt på den måde, men hey folk slår jo også hinanden med baseballbats og derfor kan de da være ret nyttige til andre ting, som f.eks. øh... baseball ![Eksternt billede](http://www.version2.dk/uploads/smil3dbd4d6422f04.gif" alt=")

Hvorfor agile?

Agile udvikling er godt i de projekter, hvor man ikke kender alle krav - eller den præcise tolkning heraf up-front. Og en del IT projekter passer faktisk glimrende ind i denne definition.

Der er meget lang vej fra en ide om et system fødes til kravene specificeres, tilbud indhentes og accepteres og til systemet står klart i en version 1.
Jo større systemer, desto længere tid kan denne periode strække sig over - vi taler måske 3-4 år ved f.eks. større offentlige IT-udbud.

Det ville gavne en del, hvis man i den slags udbud tænker i agile rammer fremfor at fokusere så meget på modenhed og certificering af projektledelse.
Evnen til at tilpasse sig forandringer er langt, langt vigtigere i et stort strategisk projekt end at kunne gennemføre en multiple-choice eksamen om en given projektmodel, der måske/måske ikke passer til projektet.

Agile passer også glimrende til kunder, der ikke kender så meget til IT og måske først skal lære hvordan forretning og IT passer sammen.
Her kan man opleve at kundens måde at planlægge og indføre IT understøttelse i en organisation også med fordel kan køres agilt.

Agile++

Når jeg tænker agile, så er det med udgangspunkt i principperne i "The agile manifesto" - en hensigtserklæring fra en række erfarne herrer fra IT branchen, hvori de erklærer, at det handler om:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Den slags principper passer jo glimrende til mange samarbejdsformer - også til hvordan vi arbejder sammen i en virksomhed - eller afvikler en børnefødselsdag ![Eksternt billede](http://www.version2.dk/uploads/smil3dbd4d6422f04.gif" alt=")

De er også glimrende som rettesnor for et samarbejde med innovative kunder, der i stigende grad viser vejen for nye måder at købe IT på.
De køber ikke store, all-in-one systemer mere, men shopper rundt omkring og kombinerer små systemer, der hver især præcis opfylder deres behov indenfor et område.

Kunderne kræver at systemerne skal fungere som dele i et samlesæt, der tilsammen matcher kundens måde at køre sin forretning på - og derfor søger de ikke - som tidligere - et standardssystem der skal vrides og drejes for at kunne understøtte forretningen.

Den slags fleksibilitet kræver agile tankegange helt oppe i ledelsen, det kræver et tillidsfuldt og åbent samarbejde med leverandører og en evne og vilje til at tilpasse sig nye markedskrav.

Jeg tror tankerne bag de agile principper mere end nogensinde passer til den måde vi bygger IT løsninger på nu og i de kommende år.

Så "Go agile - young man" - du vil ikke fortryde det ![Eksternt billede](http://www.version2.dk/uploads/smil3dbd4d6422f04.gif" alt=")

Kommentarer (5)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Therese Hansen

Agile principper holder hele vejen set fra et teknisk synspunkt!

Det, som kan holde det agile lidt igen, kan være noget af det du rammer til sidst i dit indlæg - den påkrævede fleksibilitet kræver tillid. En tillid som it-branchen ikke nødvendigvis har fortjent.

Jeg bliver altid sur, når jeg hører en it-kyndig forsøge at bullshitte en ikke-it-kyndig med forklaringer på f.eks. fejl og forsinkelser, som nærmest er tekniske termer sat i tilfældig rækkefølge og uden sammenhæng med problemet - men det ved de ikke-it-kyndige jo ikke. Og det har jeg faktisk hørt flere it-kyndige prale med...

Derudover så skræmmer fortiden jo også med hype under it-boblen og forliste projekter med forlængelse af deadlines i en uendelighed.

Jeg mener bestemt, at agile udviklingsmetoder kan hjælpe os til at undgå en ny Amanda og den type skræmmescenarier, men jeg forstår godt forbehold på ledelsesniveau.

  • 0
  • 0
Morten Norre Christensen

En agil arbejdsform fordrer, at man arbejder iterativt, og at leverandøren til stadighed viser resultater for kunden. Derved vindes og fastholdes kundens tillid. Leverandøren gør sig så at sige fortjent til tilliden, og hvis man ikke er i stand til at levere varen, vil det vise sig hurtigt og tydeligt for kunden.

Det er blot et af ganske mange punkter, hvor jeg synes, at "agile software development" positivt adskiller sig fra sekventielle udviklingsmetoder :-)

  • 0
  • 0
Mogens Heller Grabe

Det sjove er jo så, at det burde kræve mere tillid fra kundens side at underskrive en kravspecifikation, og så lade et firma arbejde indeni en sort hule i et par år, hvorefter man får et stykke software udleveret... som måske/måske ikke var det man havde tænkt.

Når man kører agile har man jo som kunde hele tiden fingeren på pulsen og har dermed også indflydelse på hvor det hele styrer hen.

  • 0
  • 0
Martin Rytter

Jeg er meget enig med hvad der hidtil er blevet sagt. Tillid er noget man skaber.

Desuden tror jeg det ligger dybt i mange at man som kunde "køber en pakke" og venter på den bliver leveret. Man er som kunde ganske enkelt ikke vandt til at blive inddraget i skabelsesprocessen, hvilket er en nødvendighed hvis agile udvikling skal være en succes.

Vi i IT-branchen skal være bedre til at sige til kunden: "Vi kan hjælpe jer med det her, men i skal være med, hele vejen. I skal være til rådighed hele tiden så vi kan træffe beslutninger og komme videre. Til gengæld kan vi love løbende at have noget at vise frem. På denne måde sikrer vi at vi ikke bruger adskillige måneder på noget der er forkert eller ganske enkelt ikke behov for." Fornuftige kunder forstår udemærket dette budskab.

Når der først er opnået enighed om denne arbejdsform er det vigtigt at holde fast. Accepter ikke at kunden tager telefonen og svarer: "vi skal lige tænke over det, vi vender tilbage om 2 uger". I sådanne situationer må man have en endelig løsning NU, eller opnå enighed om hvad vi gør indtil vi er blevet klogere. Når først beslutninger begynder at blive udskudt forsvinder den naturlige lyst til at tale sammen og finde ud af hvordan ting skal virke. Det betyder at vi som udviklere begynder at gætte, eller vi udskyder de svære problemer og løser alt det lette først i stedet. Det er den sikre opskift på katatrofe i agile projekter.

Så kort fortalt er opskriften:

1) Forklar hvad den agile metode betyder og hvad det kræver af kunden.
2) Hold fast. Kommuniker!

/mrj

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