10 forudsætninger for skalerbarhed, du skal kende, før du skalerer op
Forbered dig, for jeg er på vej til at fortælle dig den barske sandhed om skalering.
Vi begynder med at være realistiske omkring skalering i virksomheder:
De fleste skaleringsforsøg mislykkes.
Så hvad er den hemmelige opskrift? Hvordan skalerer man et team med succes, og hvorfor er det så svært?
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Hvis du har arbejdet med softwareudvikling længe nok, har du højst sandsynligt oplevet dette mareridt:
- Kunden loves masser af funktioner på urealistisk kort tid (som ingen har modet til at udfordre).
- Senere, når deadline nærmer sig faretruende, beslutter en person med magt at sætte flere teams på problemet for at overholde deadline.
- Tingene begynder at falde fra hinanden.
Lyder det bekendt?
I denne artikel forklarer jeg, hvad du skal gøre for at undgå den mareridtsagtige situation igen (eller, hvis du har været heldig nok til ikke at opleve den, for helt at undgå den).
Min indsigt i denne artikel kommer fra skalering af softwareudviklingsteams, men du kan anvende den grundlæggende teori på skalering af en virksomhed eller vækst af et team i enhver branche. Du vil finde dette nyttigt, selv hvis du tager en af de færdige skaleringsrammer i brug—Large Scale Scrum (LeSS), Scrum@Scale, SAFe.
Det skyldes, at jeg fokuserer på flere vigtige aspekter af skalerbarhed, som aldrig nævnes i disse metoder—den grundlæggende sandhed om, hvad det vil sige at skalere op, som ofte bliver glemt eller ignoreret.
Den grundlæggende lov om skalering
Den grundlæggende lov om skalering er en empirisk observation af, hvad der sker i projekter, når de skaleres op:
Opskalering forstærker det dårlige og gør det gode vanskeligere.
Det er mig, der har formuleret ordene, men jeg er hverken den eneste eller den første, der er nået frem til denne indsigt.
Lad os se på, hvad loven betyder i praksis, med nogle eksempler på skalerbarhed.
1. Eksempel: Kommunikation og skalerbarhed
Det første og mest oplagte eksempel er kommunikation. Det er et velkendt faktum, at antallet af kommunikationskanaler stiger, når antallet af personer i et projekt øges. Hvis kommunikationskanalerne ikke er gode nok til at begynde med, vil opskalering gøre problemet værre.
Hvis kommunikationskanalerne derimod er gode til at begynde med, vil opskalering medføre nogle udfordringer, ikke kun på grund af det øgede antal personer, men også på grund af deres geografiske fordeling. Ofte oprettes nye teams på forskellige lokationer, hvilket tvinger ændringer i kommunikationskanalerne igennem—for eksempel ved at gå fra møder ansigt til ansigt til videokonferencer eller ved at erstatte en whiteboardtavle med et elektronisk værktøj.
2. Eksempel: Kontinuerlig integration/kontinuerlig levering og skalerbarhed
Vi ser også den grundlæggende lov om skalering i pipelines til kontinuerlig integration (CI) og kontinuerlig levering (CD). Når der kun er ét team, er tingene forholdsvis ligetil.
Når man går fra ét til to teams, bliver CI- og CD-systemerne mere komplicerede—som regel gælder det, at antallet af CI-pipelines, når der er n teams, har tendens til at være n+1 (én pipeline pr. team plus én til integration). Det har åbenlyse konsekvenser for klargøring af miljøer og koordineringen mellem teams.
3. Eksempel: Feedbacksløjfer og skalerbarhed
Et sidste eksempel er feedbacksløjfer. Større projekter har længere feedbacksløjfer. Derfor bliver det meget vanskeligere at forfine systemet iterativt, hvilket øger risikoen for at bygge det forkerte produkt.
Dette er blot tre eksempler på nogle af de udfordringer, som opskalering medfører. Jeg er sikker på, at du kan komme i tanke om mange flere.
Lad os antage, at du er villig til at acceptere de involverede kompromiser. Det næste, du har brug for, er, at dit projekt opfylder nogle vigtige forudsætninger, så du kan bevise dets skalerbarhed.
10 forudsætninger for skalering
Om du har en skalerbar virksomhed, et skalerbart projekt eller et skalerbart team, afhænger af flere forudsætninger, som er angivet nedenfor. Hvis du opfylder disse forudsætninger, har du høj skalerbarhed. Omvendt øges risikoen for fiasko dramatisk, hvis blot én af dem ikke er opfyldt.
1. Tilstedeværelsen af klare, fælles mål
Dette burde være en selvfølge, men efter min erfaring er fraværet af klare, fælles mål ekstremt almindeligt. Uden disse vil teams trække i forskellige retninger, hvilket gør det vanskeligere at levere noget nyttigt.
2. Anvendelsen af passende målepunkter
Jo større projektet er, desto vigtigere er det at kunne måle effekten af de beslutninger, der træffes. For eksempel: Forbedrede tilføjelsen af et nyt team projektets evne til at levere? Presser vi teamene så hårdt, at kvaliteten falder? Arbejder teamene godt sammen, eller forstyrrer de hinanden?
3. En passende arkitektur
Hvis systemets ”form” ikke passer til teamstrukturen, vil flere teams kun gøre tingene værre. Det er en direkte effekt af Conways lov, en velkendt empirisk observation, som er blevet bevist i praksis.
4. Tilgængelighed af ledelsesmæssige og tekniske kompetencer
Problemer som følge af manglende kompetencer vil have en forstærket negativ effekt, efterhånden som projektet skaleres op.
5. Gode kommunikationskanaler
Jo flere mennesker der er involveret, desto mere kommunikation finder der sted. Succesfuld skalering kræver strømlinet kommunikation.
6. God prioritering og planlægning
Manglende passende prioritering og planlægning er efter min erfaring en meget almindelig faktor i projektfejl. Især når der er mere end ét team involveret, skal prioriterings- og planlægningsaktiviteter tage højde for at afbøde effekten af forsinkelser og manglende synkronisering.
7. God afdækning og håndtering af krav
Dette hænger tæt sammen med prioritering og planlægning. Desuden vil effekten af forkerte, misforståede eller unødvendige krav blive forstærket, efterhånden som antallet af teams vokser.
8. Arbejde af høj kvalitet
Jo større projektet er, desto større er den negative effekt af dårlig kvalitet. I nogle patologiske (og almindelige) scenarier kan nogle fejl blive til funktioner, fordi feedbacksløjferne til at rette dem kan være så lange, at andre teams kan have designet deres omgåelsesløsninger for at neutralisere dem.
9. Tilgængelighed af ressourcer
Flere teams har brug for flere skriveborde, computere, værktøjer og miljøer.
10. Konsekvent automatisering
Enhver manuel aktivitet er en flaskehals, hvis effekt bliver værre, jo flere mennesker og teams der er. Et (meget almindeligt) eksempel er manuelle testaktiviteter for at sikre, at der ikke er introduceret regressioner før en produktionsudgivelse. Efter min erfaring er dette en af de største flaskehalse i alle projekter, men især i projekter med mere end ét team.
Pas på med for tidlig skalering
Skalerbarhed står øverst på dagsordenen for nystartede virksomheder og serieiværksættere – og de har et par lektioner, de kan lære os om for tidlig skalering.
Hvis du begynder at skalere, før du reelt har opfyldt forudsætningerne for at skalere en virksomhed, et team eller en organisation succesfuldt, får du det, som startupmiljøet kalder ”for tidlig skalering”.
En enkel definition af for tidlig skalering fra serieiværksætteren Jim Pitkow:
For tidlig skalering: at vokse i forventning om efterspørgsel i stedet for efterspørgselsdrevet vækst.
At skalere korrekt tager ganske vist tid – og ægte skalerbarhed drives af et reelt behov for skalering på grund af efterspørgsel, ikke af en kunstigt pålagt forestilling om blot at blive større og gøre flere ting hurtigere.
Startupmiljøet giver os et par lektioner, som vi kan tage med tilbage til vores teams og projekter, når vi overvejer, om det er tid til at skalere. Her er nogle få statistikker fra Startup Genomes ekstrarapport om for tidlig skalering:
- Nystartede virksomheder, der skalerer korrekt, bruger 76 % længere tid på at nå deres teamstørrelse end nystartede virksomheder, der skalerer for tidligt.
- 74 % af internetvirksomheder i høj vækst mislykkes på grund af for tidlig skalering.
- Nystartede virksomheder, der skalerer korrekt, vokser omkring 20 gange hurtigere end nystartede virksomheder, der skalerer for tidligt.
Hvis du er interesseret i flere statistikker om iværksætteri, kan du se vores undersøgelse af de mest iværksætterprægede delstater i USA.
Er du virkelig klar til at skalere?
Hvis dit projekt drives godt og opfylder ovenstående forudsætninger, bør dit næste spørgsmål være:
”Hvor mange teams kan bidrage produktivt?”
Det besvarer vi i næste afsnit.
Hvad er grænsen for skalerbarhed? Brooks’ og Amdahls love
Det er et velkendt faktum, at det ikke nødvendigvis øger produktiviteten at tilføje flere personer til et softwareprojekt.
Faktisk vil det i de fleste tilfælde føre til et betydeligt produktivitetsfald at tilføje flere personer.
Fred Brooks gjorde denne observation i sin bog Den mytiske mand-måned, som blev kendt som Brooks’ lov:
“At tilføje arbejdskraft til et forsinket softwareprojekt gør det endnu mere forsinket […] Antallet af måneder, et projekt tager, afhænger af dets sekventielle begrænsninger. Det maksimale antal personer afhænger af antallet af uafhængige delopgaver. Ud fra disse to størrelser kan man udarbejde tidsplaner med færre personer og flere måneder[…]. Man kan dog ikke udarbejde brugbare tidsplaner med flere personer og færre måneder.”
Den sidste del af citatet ovenfor er efter min mening den mest interessante. Faktisk er det grundlæggende en version i almindeligt sprog af Amdahls lov—en formel, der angiver den maksimale teoretiske hastighedsforøgelse for et samtidig system:
Amdahls lov
Hastighedsforøgelse = 1 / (s + p / n )
Hvor:
s = procentdel af sekventielle opgaver
p = procentdel af parallelle opgaver
s + p = 1
n = antal processorer (teams i vores tilfælde)
Et projekt med flere teams er faktisk en form for samtidig system, hvor hvert team er en behandlingsenhed. I praksis fastslår Amdahls lov, at den maksimale mængde samtidige opgaver begrænses af den mængde sekventielt arbejde, der skal udføres.
Med andre ord betyder det, at de ting, der skal udføres i en bestemt rækkefølge, begrænser mængden af arbejde, som teams kan arbejde på samtidig.
Hvad er sekventielt arbejde i forbindelse med softwareudvikling?
Du undrer dig måske over, hvilken slags arbejde der er sekventielt arbejde, som påvirker softwareteams.
Her er nogle eksempler (jeg er sikker på, at du kan komme i tanke om mange flere):
- Alt arbejde med integrations- og implementeringsforløb
- Sammenlægning af softwareændringer i kode, der deles af forskellige teams
- Enhver form for synkronisering—for eksempel et team, der er afhængigt af leverancer fra et andet team, før det kan fortsætte sit arbejde
- Ventetid på klargøring af ressourcer
Anvendelse af Amdahls lov på skalering af teams
Grafen nedenfor viser konsekvenserne af Amdahls lov, når antallet af teams øges, og hvilken effekt det har på produktiviteten.
Vi kan se, at produktiviteten skalerer sublineært, når antallet af teams øges—indtil et toppunkt, hvorefter den falder igen.
En illustration af Amdahls lov: Gennemløbet af leverancer stiger med antallet af teams, men kun indtil et bestemt punkt—og det er normalt ikke det, ledere håber på.
Hvis du kun skal huske én ting fra denne artikel, er det denne:
Hvis du øger antallet af teams, kan du øge gennemløbet—men kun indtil et bestemt punkt.
Hvad er så det ideelle antal teams til et bestemt projekt?
Desværre findes der ingen formler til på forhånd at beregne det ideelle antal teams til et bestemt projekt. Den eneste måde er at bruge et sæt projektmålinger til at måle ting som produktivitet og kvalitet og se, hvad der sker, når teams tilføjes eller fjernes. Min anbefaling er at starte i det små med ét team på 3-6 personer og kun skalere op, når og hvis det er nødvendigt.
På et tidspunkt finder du måske ud af, at du allerede har nået det maksimale antal teams, men at dit projekt stadig ikke kan leve op til sine forpligtelser. Det er her, dine evner inden for prioritering og kommunikation kommer til deres ret, da du måske bliver nødt til at have nogle vanskelige samtaler med dine kunder.
Overvejelser om teamstruktur: funktions- eller komponentteams?
Hvordan skal et nyt team arbejde, når det tilføjes til projektet? Start med at stille dig selv disse to spørgsmål:
- Vil de være ansvarlige for at udvikle kundevendte funktioner fra start til slut eller ved at ændre noget i systemet for at nå deres mål?
- Vil de være ansvarlige for at arbejde på en specifik komponent, der leverer en del af en brugersynlig funktionalitet?
Hvis du svarede ja til nr. 1, vil teamet være et funktionsteam.
Hvis du svarede ja til nr. 2, vil det være et komponentteam.
Tips til valg af den rigtige teamstruktur
Det er meget vigtigt at vælge den rette teamstruktur og organisering af teamet, men det er ikke nemt. I øjeblikket synes funktionsteams at være den foretrukne løsning i de fleste situationer. Dette valg er dog ofte baseret på vane eller rutine i stedet for data.
Virkeligheden er, at “det afhænger”. Mere specifikt afhænger det af systemets arkitektur. Softwareprojekter følger typisk det, der er kendt som Conways lov—en empirisk observation af Mel Conway:
“Organisationer, som designer systemer…er begrænset til at producere design, der er kopier af disse organisationers kommunikationsstrukturer”
Med andre ord skal teamstrukturens “form” matche systemets “form”, ellers vil projektet opleve alvorlige problemer.
Det er grunden til, at jeg altid anbefaler ledere at inddrage erfarne arkitekter og tekniske ledere i beslutninger om teamstrukturen—ellers designer lederne reelt systemet uden at være klar over det (og uden de rette kompetencer). Det kan igen øge risikoen for, at projektet mislykkes betydeligt.
To paradokser ved skalering
Ud fra min erfaring som konsulent på en række store projekter er jeg nået frem til den konklusion, at projekter i de fleste tilfælde skaleres af de forkerte grunde.
Jeg har opfundet to paradokser, som opsummerer det, jeg har set i praksis:
Det første paradoks ved skalering
De fleste projekter skaleres op, fordi de ikke opfylder forudsætningerne for skalering
Det andet paradoks ved skalering
Projekter, der opfylder forudsætningerne for skalering, har mindre behov for at skalere
Det første paradoks siger, at projekter i de fleste situationer skrider langsomt frem, ganske enkelt fordi de ikke ledes godt.
Det andet siger, at velledede projekter vil have mindre behov for skalering, ganske enkelt fordi de ledes godt.
Faktisk havde de mest produktive projekter, jeg har set, kun ét eller to små teams og opfyldte alle forudsætningerne for skalering. Af alle de store projekter, jeg har været involveret i, har jeg ikke set et eneste, hvor alle forudsætningerne for skalering var opfyldt. Faktisk havde de alle masser af problemer med at opfylde nogen af forudsætningerne.
Hvis du er involveret i et projekt, der oplever problemer og forsinkelser, er den bedste anbefaling, jeg kan give, at reducere rodet, før du overvejer at skalere projektet op.
Vigtige pointer til at skalere dine teams på den rigtige måde
Det er ikke nemt at skalere softwareteams, og det skal gøres med stor omhu. Inden du går videre, kommer her nogle afsluttende tanker om, hvordan man finder den mest effektive måde at skalere et softwareudviklingsteam på:
- Hvis du arbejder på at opfylde forudsætningerne for skalerbarhed, vil du måske opdage, at du kan holde teamet lille og undgå alle de problemer, der følger med en større størrelse.
- Hvis dit projekt derimod allerede er stort og udfordret, skal du først fokusere på at reducere rodet.
Her er de første skridt, jeg foreslår, at du tager efter at have læst denne artikel:
- Find ud af, hvad der sker i praksis
- Implementer nogle målinger, så du kan vurdere den aktuelle situation samt kvaliteten af de trufne beslutninger.
