Dansk professor advarer mod ensidigt fokus på agil-udvikling

Agil udvikling trænger til mere struktur, målbarhed og forudsigelighed for at blive en ægte succes. Det mener dansk professor i datalogi.
Lars Mathiassen. Illustration: Mikkel Meister

Den agile systemudvikling har været en regulær energibombe under softwareudviklerne de senere år. Også herhjemme, hvor vi har været flinke til at tage imod alternativet til den klassiske systemudvikling.

Men den nye metode bærer ikke svaret på alle softwareudviklernes problemer i sin favn, advarer den danske professor i datalogi ved Georgia State University i USA, Lars Mathiassen.

Det fortalte han på konferencen Beyond Agility i Aalborg tidligere på måneden.

For selvom agiliteten langt hen ad vejen har været et friskt pust henover softwareland, er der alvorlige risici ved at fokusere for ensidigt på den. En tendens, som han mener, at softwareudviklerne ligger under for lige nu.

»Det agile manifest siger, at vi skal fokusere på organisk nærmere end bureaukratisk softwareudvikling. Det er jo meget godt, og der mener jeg, at det agile manifest har været fantastisk effektivt, hvad enten man taler om store eller små virksomheder. Det har givet energi til folket,« sagde Lars Mathiassen.

»Men den agile metode er også naiv på samme måde, som vi har en tilbøjelighed til at være inden for vores fag. Vi tror ofte, at alt bliver fantastisk, når vi får en ny metode. Og så glemmer vi, hvad vi havde i forvejen, som rent faktisk fungerede. I selve grundkonstruktionen af den her bevægelse ligger der noget religiøst«.

Balance mellem modsætninger

Kort fortalt handler det om at balancere to meget modsætningsfyldte størrelser: Den agile metode, som gør udviklerne i stand til at reagere hurtigt og dynamisk på ændringer til kravene i et system. Og på den anden side den klassiske systemudvikling, som giver forudsigelighed, struktur og målbarhed.

Ingen af metoderne er som regel tilstrækkelige hver for sig, siger Lars Mathiassen. Men kan man balancere dem op mod hinanden, kan det både give bedre software og sikre innovation i virksomheden. I forskningen kaldes det contextual ambidexterity.

En af hans pointer er, at den agile metode ikke besvarer, hvordan man balancerer kravene med de resurser, man har til rådighed. Her bør man kigge i retning af den af, hvad den klassiske organisationsteori har beskæftiget sig med årtier før det agile manifests fødsel i 2001.

Det drejer sig dels om at indføre metrikker - kvantificering af koden - på en måde, så det passer med den agile tankegang, siger Lars Mathiassen. Men det handler også om at lade være med at se forudsigelighed og struktur som noget, der ikke spiller sammen med agiliteten.

»Vi taler på den ene side om response-ability, som er evnen til at reagere på et krav som en impuls. Den modsatte teori er repeat-ability. Hver gang, der kommer et krav, ved vi nøjagtigt, hvad vi skal gøre. Vi skal passe på med ikke at se repeat-ibility som noget bureaukrati,« sagde Lars Mathiassen.

Samtidig - og det gælder ifølge Lars Mathiassen for store dele af softwareindustrien uanset metode - har man ofte en tendens til at fokusere på projektniveauet, mens produkt- og porteføljeniveauet får en stedmoderlig behandling. Det går ud over innovationen, mener han.

»Innovation foregår på virksomhedsniveau, ikke på det enkelte projekt. Har man ikke styr på produkt- og projektporteføljen, kan man glemme alt om innovation,« sagde professoren.

Lars Mathiassen erkender, at balancen mellem de to modsatrettede størrelser kan være svært at opnå i praksis.

Men man er godt på vej, hvis man lægger den agile systemudvikling inden for rammerne af eksempelvis vandfaldsmodellen.

Læs også: Efter 6 års maratonudvikling: Ny Hitman er både agil og vandfald

»Hvis der er brug for noget som modvægt til den rent agile tankegang, så er det jo den mere strukturerede tankegang. Agiliteten er god til adaptation og responsiveness, men hvad med lidt mere struktur, repeatabilty og garanti?« siger professoren til Version2.

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

Min opfattelse er, at balanceproblem oftest skyldes, at der i produktets kravspecifikation (hvis den overhovedet findes) ikke er specificeret projektrelaterede krav. Når der ikke findes krav til projektets gennemførelse, vil der uvægreligt opstå tvivl om hvordan det skal gennemføres og hvilke projektrelaterede egenskaber, som skal fastholdes.
Hvis f.eks. der ikke stilles krav til produktets vedligeholdelsesmuligheder efter projektet er afsluttet, vil nogen synes, at der skal være noget, mens andre ikke interesserer sig for efterløbet.
Det har betydning i den agile proces, hvor de manglende krav bevirker, at deltagerne koncentrerer sig om det agile og måske glemmer, at der kan være behov for f.eks. sporing. Netop sporingen har betydning i forhold til 'hvad man skal gøre' (jfr artiklen) og registreringen af hvad der er blevet gjort glemmes ofte i den agile iver.
Agilt betyder desværre ikke, at anarkiet får lov at råde, men at der er plads til i projektet at reagere hensigtsmæssigt. Dette skal så stemme overens med kravene til projektet selv.
Det er ikke muligt at balancere, hvis det ikke er beskrevet hvad der skal balanceres efter.

  • 0
  • 0
Henrik Winther Jensen

Efter en del år i branchen er jeg kommet frem til at jo mere et projekt er præget af metoder, og flere metodeeksperter der er involveret. Jo mindre er sandsynligheden for success, og jo flere ressourcer vil blive spildt. Man kan kan selvfølgelig ikke sige at metoder er årsagen til al elendighed, men det er afgjort den væsentligste. Det bedste de agile metoder har gjort for branchen er at de har givet fornuftige mennesker et værktøj til at holde metodefanatikerne stangen, i og med at agile metoder er simple og præget af sund fornuft i stedet for abstraktioner, teori og regulære dagdrømme.

  • 0
  • 2
Carsten Poulsen

Jeg synes, at det er lidt odiøst at kalde det fanatikere.
Det er som om, der er to modstridende parter, som dybest set vil det samme: Den ene er en Maverick, vil have fuld frihed til at gøre som han vil og den anden er blot ude på at samle nyttig information sammen og udnytte en gevinst, som består i at gøre det samme som sidst i stedet for at opfinde den dybe tallerken igen, bare lidt anderledes. Og ikke mindst sørge for at vi husker hvad vi skal lave og har lavet, så kunden i sidste ende bliver tilfreds og vil købe noget mere. Det er trods alt det vi lever af.

  • 0
  • 0
Henrik Winther Jensen

Det har du sådan set ret i. At jeg anvender vendingen udspringer af mine direkte erfaringer med mange mennskers holdning til deres arbejde. Disse personer insisterer på at de kan forudsige virkeligheden flere år frem, og når deres forudsigelser fejler fastholder de at det er fordi analysen ikke var grundig nok. Mennesker som tilsyneladende nægter at acceptere at deres erfaringer ikke stemmer overens med deres erfaringer, er i min verden fanatikere. Selv om det selvfølgelig ikke er på et religiøst plan, jeg tvivler på at de vil være parate til at ofre deres liv for deres tro :-)
De rigtige Mavericks er, som jeg ser det, de mennesker som isolerer sig i en IT afdeling med en kravspecifikation i skrivebordsskuffen, og ikke mener at det er deres ansvar at sætte sig ind i hvad forretningen har brug for.

Jeg gætter på at du også har mødt disse mennesketyper, hvis du har været rundt i IT industrien i en længere periode.

Men jeg er godt klar over at jeg står ret alene med mine standpunkter, tendensen til at mennesker specialicerer sig bliver bare stærkere og stærkere med tiden.

  • 0
  • 0
Carsten Poulsen

Hvis det er dine erfaringer, så forstår jeg dig godt og er langt han ad vejen enig. Så du står ikke helt alene med dine standpunkter.
Jeg tror heller ikke, at det er muligt at analysere sig til en spådom, blot der er oplysninger nok. Det er kaosteorien en indikation for.
Min indgangsvinkel til problemet er, at en udvikler skal ikke bekymre sig mere endhøjst nødvendigt om andet end at lave god kode (hvis det er SW - men der gælder det samme for alle udviklere) og lave små notater de rigtige steder om, hvad det er der er lavet. Der skal så være andre, som sørger for, at udvikleren på en sammenhængende måde kan komme af med informationen og blive forsynet med ny relevant information i forhold til det arbejde, som skal udføres.
Jeg mener, at Maverick skal have adgang til relevant information på det rigtige tidspunkt og kunne aflevere på samme måde. Det hedder vist LEAN. Processen mellem disse to punkter kan så være agil. Det er fint.
Men hvis ikke rollerne i den totale proces er på plads og accepteret af de involverede, så giver det anledning til anarkistiske tendenser og rodet udvikling, som kunden i sidste ende ikke bliver tilfreds med.
Kernen i dette er, at resultatet bliver ikke bedre end forventningerne.
Hvis der ikke er klare udmeldinger om hvad resultatet af et projekt skal være, vil det være umuligt at finde den rette balance i aktiviteterne.

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