Når et team bliver langsommere, er det sjældent fordi udviklerne er blevet dårligere. Forklaringen ligger næsten altid i ét af tre lag: koden er blevet sværere at ændre, processen har fået flere ventetider, eller organiseringen giver flere afbrydelser. Find det lag, inden I gør noget. Ansætter I flere til et problem i koden, bliver det ofte værre. Mål på flowet gennem teamet frem for på den enkelte udvikler. Det giver et svar, I kan bruge.
Årsager i koden
Hver genvej, der blev taget for at nå en deadline, gør de næste ændringer dyrere. Det kaldes teknisk gæld. Tegnene er, at små ændringer tager lang tid, at én ændring ødelægger noget et helt andet sted, og at udviklerne undgår dele af koden. Automatiske test kan også mangle, så al kontrol skal ske i hånden, før en ændring kan komme ud.
Spørg teamet: hvilke dele af produktet ville I helst ikke røre? Svaret plejer at komme hurtigt, og det er et godt sted at begynde. Grundlaget er et register over gælden. Er det et bestemt område, ingen tør ændre, så læs ingen tør røre den del af koden.
Årsager i processen
Den største del af en opgaves levetid går tit med at vente. Den venter på en afklaring, på kodegennemgang, på test eller på næste release. Selve programmeringen er ofte den mindste del.
Tegnene er mange halvfærdige opgaver på samme tid, lange køer til gennemgang og releases, der kun sker sjældent, fordi de er besværlige. Følg en typisk opgave fra idé til kunde, og skriv ned, hvor længe den lå stille og hvor. Det tager en time, og det viser ofte mere end nogen analyse. De vigtigste rutiner står i artiklen om processen i et lille team.
Årsager i organiseringen
Når virksomheden vokser, bliver der flere, der vil noget. Salg har en kunde, der haster. Support har en fejl. En direktør har en idé. Hver afbrydelse koster mere end den tid, den tager, for en udvikler skal bagefter ind i opgaven igen.
Andre tegn er prioriteter, der skifter fra uge til uge, opgaver, der ikke er færdigtænkte, og for mange ting i gang på samme tid. Flere folk kan også i sig selv gøre teamet langsommere i en periode, for de nye skal læres op, og der er flere at tale sammen med, se fra fem til tyve udviklere. Tjek også, om alt går gennem én person, se lead developeren er blevet flaskehalsen.
Og så er der den tid, ingen tæller. Drift, support, kundetilpasninger og sikkerhedsopdateringer vokser med produktet. Et team, der for tre år siden kunne bruge næsten al tiden på nyt, bruger den måske nu mest på at holde det hele kørende. Teamet arbejder lige så hårdt, og mere af arbejdet er usynligt for ledelsen.
Mål flowet gennem teamet
Linjer kode og antal opgaver pr. udvikler viser ikke, hvor problemet er, og det får folk til at optimere på det forkerte. Mål i stedet, hvordan arbejdet bevæger sig gennem teamet.
Der findes et sæt målinger, der er udbredt i faget, kendt som DORA-målinger. De stammer fra forskningsprogrammet DevOps Research and Assessment og har intet at gøre med EU’s regler af samme navn for finansielle virksomheder. DORA beskriver dem som to grupper.
Tempo:
- Leveringstid for ændringer: hvor lang tid der går, fra en ændring er lagt ind, til den er ude i produktion.
- Hyppighed af udgivelser: hvor ofte I sender noget ud.
- Tid til genopretning: hvor hurtigt I er tilbage efter en udgivelse, der mislykkedes.
Stabilitet:
- Andel af fejlende ændringer: hvor mange udgivelser der kræver et hurtigt indgreb, fx at rulle ændringen tilbage.
- Omarbejde: hvor mange udgivelser der var uplanlagte og skyldtes en hændelse i drift.
For en ledelse er det vigtigste, at tempo og stabilitet hører sammen. Går I hurtigere ved at give slip på kvaliteten, viser det sig på målingerne for stabilitet.
DORA gør selv opmærksom på, at målingerne bruges bedst på ét produkt eller én tjeneste ad gangen, og at formålet er at blive bedre over tid. De egner sig ikke til at sammenligne team eller udviklere. Brug dem derfor til at se jeres egen udvikling. Et lille team kan begynde med to af dem, typisk leveringstid og andelen af fejlende ændringer. Der skal ikke købes et værktøj for at komme i gang. Jeres eksisterende systemer kan ofte give tallene.
Sådan finder I årsagen
En enkel fremgangsmåde kan klares på få uger:
- Tal med teamet. Spørg, hvad der er sværere nu end for et år siden.
- Følg et par opgaver. Se, hvor de lå stille.
- Se på, hvad tiden går til. Hvor meget er nyt, hvor meget er fejl og drift?
- Find ét tal. Vælg en måling, der kan vise, om ændringen virker.
- Ret én ting. Tag det, der giver mest, og se effekten, før I går videre.
Svaret bør formuleres til ledelsen på almindeligt dansk, se teknologien på ledelsesmødet. Hvis en stor del af problemet viser sig at være gammel teknologi, eller at produktet er vokset fra sin form, er det et større spørgsmål. Læs mere under det gamle produkt.
Det skal I lade være med
- At ansætte flere, før I kender årsagen · nye folk gør et team langsommere først.
- At presse teamet med deadlines · det giver mere gæld og næste års langsomme tempo.
- At bruge målingerne til at rangere udviklere · tallene bliver pyntet, og I mister tillid.
Det skal I kræve af den eksterne
- ☐ En forklaring på, hvor tiden forsvinder, baseret på samtaler og faktiske opgaver.
- ☐ En opdeling af årsagerne i kode, proces og organisering.
- ☐ Enkle målinger, som teamet accepterer og selv kan bruge.
- ☐ En kort plan, hvor ledelsens egen andel også står med.
Kilder
- DORA: Software delivery performance metrics: målingerne, og råd om at bruge dem på ét produkt ad gangen.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Hver release er en risiko · Hvorfor holder estimaterne aldrig?
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
