Hvad betyder teknisk agilitet egentlig?
Teknisk agilitet, synonymt med letvægts systemudvikling eller produktudvikling, drejer sig om evnen til nemt og risikofrit at tilpasse sig og ændre kurs når der opstår forhindringer, eller når ny information nødvendiggør en ændring. Agilitet handler grundlæggende om det faktum at vi kommer til at begå fejl, at kommer til at tage fejl, og at usikkerhed er en del af den branche vi arbejder i. Selv tech-giganter som Google, Microsoft og den ikoniske Steve Jobs har af og til taget fejl i deres forudsigelser – det kommer vi også til. Teknisk agilitet giver os midlerne til at håndtere fejl og hurtigt at ændre retning baseret på erfaring og feedback. At lære af sine fejl er fundamentalt i systemudvikling – det vi laver er per definition innovation; vi kan ikke udvikle det næste produkt på nøjagtig samme måde som det forrige.
Fordele ved teknisk agilitet
En teknisk agil tilgang strømliner udviklingscyklusser og giver hurtigere brugerfeedback. Ved at følge korte udviklingscyklusser, ofte kaldet sprints, skabes der mulighed for hurtigt at tilpasse og forbedre produktet. Metoden er mere effektiv sammenlignet med den traditionelle vandfaldsmetode hvor arbejdet udføres i sekvenser, hvilket potentielt forlænger tiden til produktlancering. Ægte feedback fra rigtige brugere kommer til sidst, når det er mest udfordrende og dyrt at tilpasse efter.
Fra vandfaldsmodellen til agile metoder – ingen hybrider
I den traditionelle vandfaldsmetode foregår kravspecifikation, udvikling og test i sekvenser. Som en helt anden tilgang lægger den agile metode vægt på samarbejde og iteration. Korte udviklingscyklusser giver mulighed for løbende justering af krav og retning, med fokus på at skabe værdi i hvert stadie. Samarbejde mellem forskellige teamkompetencer gør at man kan undgå flaskehalse og forbedre kommunikationen mellem interessenter, udviklere og kvalitetssikring.
Den mest almindelige misforståelse er, at en hybrid tilgang virker. Mit yndlingssvar til denne opfattelse er: “Du kan ikke køre lidt til højre og lidt til venstre og håbe på at høste fordelene ved begge dele.” Det koster altid mere end det er værd, at arbejde på den måde. Det er bedre at beslutte sig for en måde at arbejde på og så acceptere ulemperne: Hvis du føler behov for at bruge “big design up front” og frigive produktet i store bidder, kan du i det mindste optimere til det, i stedet for at foregive at være lidt agil ved siden af. At køre to metoder parallelt fordobler administrationen og eliminerer stort set alle fordele.
Tips til en smidig agil start
- Begynd med teknisk agilitet: Før du går i gang med en omfattende Agile-transformation, er det afgørende at sikre, at dine tekniske udviklingskompetencer er på plads. Kvalitet og hastighed er grundlæggende.
- Begynd småt: Indfør ændringer gradvist, og begynd med at anvende agilitet på små projekter eller dele af arbejdet. Det giver mulighed for læring og justeringer undervejs.
- Fokuser på værdi: Det er afgørende at identificere det højest prioriterede og mest værdiskabende arbejde. Reglen om én – én uge, én opgave, ét team – kan hjælpe med at fastholde fokus. Det er meget udfordrende, men det er netop derfor det kan give en fordel i forhold til konkurrenterne.
- Udfordre afhængigheder: Opbyg organisationen omkring værdistrømme snarere end teknologi eller funktioner. Minimer afhængigheden mellem teams, og gør det lettere at få hurtig feedback.
- Test: Når man begynder at teste, så opdager man hvor det gør ondt. Grunden til at agile transformationer mislykkes er ofte, at man forsøger at finde ud af tingene og rulle dem ud i stedet for at teste. Test produktet med rigtige brugere, test tilgangen med rigtige medarbejdere og lyt til deres feedback. Hvis brugerne ikke kan lide din idé, er det en dårlig idé.
- Lær af fejl: Agilitet omfavner usikkerhed og fejl. Erfaringerne fra fiaskoer er en værdifuld ressource, der kan vejlede dig i fremtiden.
Standarder og rammer for teknisk agilitet
Inden for teknisk agilitet er der relativt få alment vedtagne standarder og rammer. Her er dog nogle eksempler:
- Extreme Programming (XP): En samling af tekniske fremgangsmåder, der fremmer kvalitet og fleksibilitet i teknisk udvikling. XP omfatter metoder som parprogrammering og testdrevet udvikling for at sikre kvalitet og fleksibilitet.
- Kanban: Et visuelt værktøj, der hjælper med at visualisere workflow og styre opgaver. Det letter prioriteringen og identificerer flaskehalse i udviklingsprocessen.
- DevOps: En metode, der kombinerer udvikling og drift for at skabe en sømløs proces fra kodning til implementering. Jo hurtigere du kan få din kode ind i et produktionslignende miljø, jo hurtigere kan du få feedback.
- Scrum: Det mest udbredte framework inden for agil projektudvikling med fokus på korte udviklingscyklusser og samarbejde i teamet.
En praktisk analogi: At skabe værdi i udviklingsprocessen
Lad os illustrere vigtigheden af at skabe værdi ved at se på en hverdagsanalogi. Forestil dig en gruppe mennesker, der samarbejder om at lave aftensmad sammen. En person mester i at lave saucer, men midt i processen opdager vedkommende at kødet brænder på. Hvis den ene kun fokuserer på sin opgave, tænker de måske: “Jeg er ikke god til at stege kød, der må være en anden der er bedre til det, og det er deres problem.” Men hvordan bliver det færdige måltid mon hvis man tænker sådan? Uanset hvor god saucen er, kompenserer den ikke for det faktum at kødet er brændt på.
Denne analogi afspejler kernen i agilitet. I udviklingsprocessen handler det ikke kun om at være specialist i en bestemt opgave; det handler om at være opmærksom på hele processen og handle, når det er nødvendigt. At skabe værdi er nøglen. Hvis vi allerede har sovs nok til aftensmaden, er der ingen grund til at lave mere. I stedet overvejer vi, hvad vi kan gøre for at bidrage til det endelige resultat: i dette tilfælde, hvad der er nødvendigt for at gøre middagen så lækker som muligt.
Udfordringen ligger i, at både organisationen og brugerne skal være villige til at omfavne denne måde at arbejde på. Mange organisationer har en iboende tendens til at forsøge at kontrollere alt på forhånd, og det anses som bedre ikke at gøre noget overhovedet (men at have meget god tid til at rapportere om, hvad der ikke er blevet gjort) end at gøre noget der måske går galt, men som til gengæld giver indsigt i hvad der kan være rigtigt i fremtiden.
Det er her, den tidligere madlavningsanalogi passer meget godt. Ligesom i madlavning er det ikke kun mængden, der betyder noget; det er kvaliteten af hver komponent og hvordan de interagerer, der skaber det perfekte resultat. Ved at følge en god opskrift, smage og modtage feedback kan vi fortsætte med at forbedre og tilpasse vores produkter, så de bedst muligt opfylder vores brugeres behov.
Vil du gerne lære mere om teknisk agilitet?
Vi tilbyder flere kurser i forskellige agile arbejdsmetoder. Tjek Consids kurser ud.
