Den agile organisation

De agile principper og praktikker er i dag accepterede og anvendt i store dele af IT industrien. Erfaringerne er overvejende positive og optimistiske, men erfaringerne viser også, at den omgivende organisation kan have svært ved at ”optage” den agile bevægelse. Det betyder, at der opstår modsætninger imellem agile projekter og resten af organisationen, som vanskeliggør udnyttelsen af potentialet i den agile bevægelse.

Denne artikel belyser sammenhængen mellem de agile principper og praktikker og den organisation, de skal indgå i, og peger på tiltag til en mere effektiv udnyttelse af de agile principper i hele den omgivende organisation.

Af Henrik Sternberg,

Hvad er systemudvikling?

Den agile bevægelse bygger på principper, som vi i systemudviklingssammenhæng i høj grad anser som ”sund fornuft”, om end ganske svære at efterleve. Principper som tæt kundekontakt, høj kundetilfredshed gennem hyppige delleverancer, kvalitet gennem motiverede, dygtige udviklerteams og indbyggede feedback mekanismer.

Men disse principper bygger ikke kun på sund fornuft. De bygger på en grundsolid teori om hvad systemudvikling er, og de vilkår der gælder for faget. Som systemudviklere glemmer vi ofte i vores højpragmatiske verden, at vores fag ER et fag, og at der udover vores mange og uundværlige praktiske erfaringer findes velunderbyggede teorier om systemudvikling. Og vi glemmer tit, at en god forståelse af teorien kan hjælpe os når vores praktiske erfaringer kommer til kort. Og at teorien kan hjælpe os med at etablere et fælles sprog og et fælles begrebsapparat.En af de bedste teorier jeg kender er beskrevet i ”Professionel Systemudvikling” fra 1986 [Andersen 1986]. Kernen i denne teori er en antagelse om sammenhængen mellem systemudviklingens hovedelementer.

Hovedaktiviteterne er de aktiviteter vi ALTID gennemfører i et projekt, uanset valget af metode: analyse, design, realisering, planlægning, vurdering og regulering.

Aktiviteterne er opdelt i 3 modsætningspar. Refleksion overfor forandring, visioner overfor det eksisterende og det produktrettede overfor det procesrettede. ”Analyse” dækker f.eks. over alle de produktrettede aktiviteter, der udføres for at forstå den eksisterende situation, og er altså ikke at tænke som en specifik fase. Modellen har en række teser om relationerne mellem aktiviteterne. Den vigtigste tese er at ”analyse og design forudsætter hinanden og skal udføres i gensidigt samspil”. Man kan ikke gennemføre den ene aktivitet uden den anden. Man kan f.eks. ikke have en analysefase, der har til formål at samle analyseaktiviteter. Man må gennemføre systemudviklingen, så den tager hensyn til den gensidige afhængighed: F.eks. gennem prototyping og iterativ, inkrementel udvikling.

Den agile bevægelse og dens praktiske erfaringer, udtrykt som principper, bygger langt hen ad vejen på denne teori, og som sådan er den agile bevægelse ikke ny eller banebrydende, men ”blot” et udtryk for god systemudviklingsskik.

De agile metoder vi kender og anvender, har på forskellig vis indbygget disse principper i de praktikker, de anvender.

XP er karakteriseret ved den eksplicitte anvendelse af principper og praktikker. Principper som kommunikation, mod, simpelhed og feed back. Og praktikker som parprogrammering, fælles kodeejerskab og simplet design. Karakteristisk for XP er at fokus i høj grad er på støtte til den enkelte udvikler og den umiddelbare nærhed. Og på den produktrettede del af systemudviklingen.

Scrum har i højere grad fokus på samarbejdet i det selvorganiserende team og på samarbejdet mellem teamet og kundeorganisationen gennem produktejerrollen. Altså større fokus på teamet og på de procesrettede aktiviteter.

Unified Process /OpenUP er på mange måder en komplet metode. Men særligt har den indbygget en praktik, som gør den velegnet til kommunikation mellem alle projektets interessenter: Risk Value Lifecycle. Risk Value Lifecycle som agil praktik giver mulighed for gennemsigtighed på et styringsmæssigt niveau. Gennem 4 faser og fire milepæle med kvalitetssikringsfokus kan sponsor/projektejer stille 4 grundlæggende spørgsmål til projektet:

Ved alle i projektet hvad projektets succeskriterier er?
Kan i demonstrere at projektet kan løse opgaven indenfor de givne rammer og betingelser?
Er der en accepteret løsning?
Kan løsningen anvendes i brugerorganisationen?

Denne praktik anvendt som projektstyringsmodel kan i høj grad medvirke til gennemsigtighed i hele projektorganisationen, da måling af projektets fremdrift måles mod generelle, objektive kvalitetstilstande, som giver mening for alle projektets interessenter. Dette i modsætning til måling af fremdrift på baggrund af ressourceforbrug.

Herved tilbyder UP agile praktikker, der understøtter hele den agile organisation og de tværgående aktiviteter: kommunikation, socialisering og beslutning.

Principper over praktikker

De agile metoder og praktikker bygger på en overvejede fælles filosofi og fælles principper for hvad god systemudvikling er, i god tråd med det teoretiske fundament. Beskrevet og udbredt gennem det agile manifest. Men når de agile metoder og praktikker bliver implementeret i udviklingsorganisationer, er det ofte ud fra et ønske om den effektivisering af udviklingsprocessen, som metoderne stiller i udsigt, men lige så ofte uden erkendelse af de mulige organisatoriske konsekvenser, en sådan implementering medfører, eller om de organisatoriske betingelser er til stede for at stryge gevinsten.

Vi ser derfor ikke sjældent eksempler på at agile forsøg, typisk i større organisationer, der resulterer i modstand eller isolation af forsøget, eller direkte udstødelse. Anvendelsen af de agile metoder har her typisk udstillet en organisatorisk konflikt, der er blevet implementeret eller synliggjort med det agile projekt. Konflikter f.eks. om hvad man kan tale med kunder om, eller hvad man kan forvente af dem.

De agile principper handler om evnen til at håndtere usikkerhed. Men denne evne kan ikke opøves uafhængigt i udviklingsorganisationen. Det er en evne som hele organisationen må have. Usikkerhed er et overordnet tema i softwareudvikling, og den skal håndteres af alle projektets interessenter: Udviklere, projektledere, sponsorer, produktejere, krav-stillere, brugere osv.

De agile principper bygger derfor også på antagelser om organisatorisk adfærd og selvforståelse. Mod, anerkendelse, respekt og tillid kan ikke trives isoleret. Tillid forudsætter tillid. Betingelserne for at en organisations medlemmer kan udvise mod, anerkendelse og gensidig tillid er at organisationens filosofi og grundlæggende antagelser understøtter det.

En organisation, der forventer at softwareprojekter kan forudsige og planlægge alle nødvendige systemudviklingsaktiviteter alene på baggrund af skitser til en løsning, og som forstår afvigelser fra planen som uhensigtsmæssige, vil have svært ved at understøtte en projektleders ønske om i et agilt projekt at lave kontrakter uden detaljerede løsningsbeskrivelser.

Så for at opnå den ønskede effekt af de agile praktikker, må vi søge de bagvedliggende organisatoriske principper eller værdier, og sikre at de understøtter den agile tanke. Jeg mener ikke de værdier, der står skrevet på musemåtten eller på postere i kantinen. Jeg mener de værdier, organisationen lever efter.

Hvis en grundlæggende værdi i organisationen er, at kunden er i centrum, og dette leves ud, MÅ det betyde, at kontraktforhandlingerne tager udgangspunkt i den usikkerhed, der er et vilkår for softwareudvikling, og i projekter, der skal arbejde sig frem gennem gensidig læring mod optimale løsninger.

I organisationer, der lever efter principper om hierarkisk, vidensbaseret ledelse (beslutninger træffes af ledere efter grundig analyse) og måling og belønning af personlig indsats, vil agile softwareprojekter let komme til at ”stikke ud”, da de bygger på principper om bl.a. fælles ansvar.

Så de agile principper kan ikke isoleres til systemudviklingsafdelingen. Der må være overensstemmelse mellem de principper, der styrer den generelle adfærd i organisationen, og de principper der gælder for adfærd mellem softwareudviklingsorganisationen og dens interessenter hvis vi skal kunne få den ønskede effekt af procesforbedringsprojekter i softwareorganisationer.

Litteratur

Andersen, Kensing m.fl. Professionel Systemudvikling, Teknisk Forlag 1986