Er du i fuld gang med at øge agiliteten i din virksomhed, men har dine teams svært ved at følge med til dine ambitioner? Så kan én af problemerne være en teknisk platform, der ikke understøtter det. Vi deler her nogle af vores erfaringer.
De fleste virksomheder, der beskæftiger sig med udvikling af digitale produkter, kan finde et par scrum teams rundt omkring i sit organisationsdiagram. Nogle virksomheder har høstet mange af frugterne ved at søge mod en mere agil tilgang til produktudvikling. Dog ser vi også mange der kæmper med at udfolde potentialet. En af årsagerne kan være forankret i systemarkitekturen og de grundlæggende IT-systemer.
Hver gang dine digitale produkter ændrer sig i forbindelse med udvikling af nye funktioner vil det for det meste medfører et behov for at ændre eksisterende dele af din kodebase. De nødvendige ændringer, der ikke prioriteres, kendetegnes som teknisk gæld. Vokser din tekniske gæld påvirkes dine teams hastighed negativt. En platform med stor teknisk gæld er typisk også sværere at vedligehold og vil oftest være præget af lavere kvalitet og flere fejl. Begge kan nedsætte din evne til at release og i sidste ende agiliteten i din forretning.
I denne episode dykker vi ned i den tekniske platform, der skal understøtte at I hurtigt kan sende digitale produkter på markedet, der rammer jeres kunder i hjertet.
Din arkitektur spejler din organisation
Måden som en virksomhed organiserer sig har en meget stor indflydelse på evnen til at eksekvere. Et ofte overset aspekt, når organisationsændringer iværksættes, er sammenhængen mellem organisationen og de tekniske systemer. Helt tilbage i 1960’erne identificerede Melvin Conway en sammenhæng, der siden er kendt som Conway’s law:
“Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure”
Conway’s law er i allerhøjeste grad gældende indenfor softwareudvikling, hvor strukturen af hvad der bygges langt hen ad vejen afspejler organiseringen af de teams, der bygger det. En meget simpel forklaring er at kommunikationen i enkelte teams er lettere end kommunikationen i funktionelle enheder, der igen er lettere end kommunikationen mellem funktionelle enheder. I takt med at systemet vokser og afstanden mellem teams bliver større er en naturlig konsekvens, at softwaren modulariseres i komponenter og der introduceres interfaces.
Når virksomheder ønsker at øge agiliteten af deres organisation er en af de typiske elementer etableringen af produkt eller feature teams. Hvis arkitekturen er inddelt i komponenter kan den nye teamstruktur kræve, at medlemmerne skal arbejde i en uhensigtsmæssig stor og meget forskelligartet kodebase. Det kan både medføre introduktion af fejl og en nedsættelse af teamets hastighed. For at opnå den ønskede effekt er det derfor nødvendigt både at arbejde med ændringer i organisationen og i systemets arkitektur. For at øge agiliteten er det essentielt at have en platform, der understøtter udvikling og release i korte iterationer i de teamstrukturer, der skal udføre arbejdet.
Arkitekturen er ikke statisk
Når organisationen udvikler sig, når produktporteføljen udvides eller når nye teknologier bliver tilgængelige påvirkes kravene til den grundlæggende systemarkitektur og virksomhedens IT-systemer. Hos Jayway ser vi regelmæssigt, hvordan systemarkitekturen og IT-systemerne både understøtter og forhindrer udviklingen af succesfulde digitale produkter hos vores kunder. Systemarkitekturen og de grundlæggende IT-systemer er fundamentet for hele den digitale forretning, og det er afgørende at dens kontinuerlige udvikling prioriteres. Varetagelsen af den tekniske platform er ikke en supporterende aktivitet, men en integreret del af forretningsudviklingen.
Kan du release?
En af de fundamentale forudsætninger for den tilgang til produktudvikling, der behandles i denne serie, er evnen til at release tidligt, ofte og kontinuerligt gennem hele produktets livscyklus. Mange andre tiltag for at at øge agiliteten vil ikke have den nødvendige gennemslagskraft, hvis de ikke bygges ovenpå et teknisk fundament, der tillader inkrementel værdiskabelse. En af de meget normale udfordringer vi oplever hos vores kunder er i grænselandet mellem udviklingen af brugervendte digitale produkter og de grundlæggende IT-systemer. Mange af de brugervendte produkter er ofte forankret under en digital chef, hvor de grundlæggende IT-systemer findes under IT-chefen. De to grene i organisationen varetager forskellige opgaver. Hvor IT-systemerne udvikles med fokus på sikkerhed, stabilitet og standardisering udvikles de brugervendte produkter med fokus på time-to-market, agilitet og innovation. Begge er vigtige for virksomhedens succes, men uden en arkitektur med en veldefineret ansvarsfordeling og veldefinerede interfaces vil det forskellige fokus være en hindring for at begge opgaver varetages optimalt.
Er din platform stabil?
En anden forudsætning for at kunne release er at kvaliteten af den udviklede software er i fokus. For systemer, hvor kvaliteten halter, ses ofte at der releases med en lavere frekvens, da nye releases repræsenterer en høj usikkerhed og en stor arbejdsbyrde i manuelle tests og fejlrettelser. Der er mange måder at øge kvaliteten af kodebasen. Nogle typiske værktøjer er automatiserede tests, etablering af continuous integration & continuous delivery pipelines, DevOps, code reviews og løbende refaktorering. Fælles for et succesfuldt løft af kvaliteten er at det skal forankres i mindsettet – både hos de enkelte teams og hos ledelsen. Synlighed er et stærk motivator og en datadrevet tilgang med målinger og dashboards er gode værktøjer.
En måde at sætte fokus på kvaliteten er tilgangen “You operate what you build” – altså at teamet både varetager ansvaret for at udvikle og drifte produktet. Derved bliver konsekvenserne af en lav kvalitet meget synlige for de enkelte teams. Når deadlines presser og bølgerne går højt er ambitionerne for kvaliteten ofte det første der rammes for at nå kortsigtede mål. Det kan dog være skadeligt at introducere teknisk gæld, hvilket har det med at vokse. Generelt kan det her være bedre at arbejde med scope, så der bygges mindre, men at det der bygges, bygges ordentligt.
Key takeaways:
- Der er sammenhæng mellem din systemarkitektur og din organisation
- Når større organisatoriske ændringer iværksættes bør der være et stort fokus på om din nuværende systemarkitektur og dine grundlæggende IT-systemer understøtter de nye teams og de nye processer
- For at kunne release uden store risici og en stor arbejdsbyrde kræves en stor kvalitet i kodebasen
- At øge agiliteten bygger på en teknisk platform der understøtter at kunne release tidligt, ofte og kontinuerligt gennem hele produktet livscyklus
Dette er den fjerde artikel i en serie af fem, hvor vi deler nogle af vores erfaringer i at skabe succesfulde digitale produkter. De forrige artikler kan findes her.
Vil du vide mere om os?