10 forutsetninger for skalerbarhet du bør kjenne til før du skalerer opp

Hvis du har jobbet med programvareutvikling lenge nok, har du sannsynligvis opplevd dette marerittet:

1. Kunden blir lovet mange funksjoner på urealistisk kort tid (som ingen tør å utfordre).
2. Senere, når fristen nærmer seg faretruende, bestemmer noen med makt til å kaste flere team på problemet for å rekke fristen.
3. Ting begynner å falle fra hverandre.

Høres det kjent ut?

I denne artikkelen forklarer jeg hva du må gjøre for å unngå denne marerittsituasjonen igjen (eller, hvis du har vært så heldig å ikke oppleve den, for å unngå den helt).

Innsikten min i denne artikkelen kommer fra skalering av programvareutviklingsteam, men du kan bruke den grunnleggende teorien på skalering av en virksomhet eller vekst av et team i hvilken som helst bransje. Dette vil være nyttig selv om du tar i bruk et av de ferdige skaleringsrammeverkene—Large Scale Scrum (LeSS), Scrum@Scale, SAFe.

Det er fordi jeg fokuserer på flere viktige aspekter ved skalerbarhet som aldri nevnes i disse metodikkene—den grunnleggende sannheten om hva det innebærer å skalere opp, og som ofte blir glemt eller ignorert.

Den grunnleggende loven om skalering

Den grunnleggende loven om skalering er en empirisk observasjon av hva som skjer i prosjekter når de skaleres opp:

Oppskalering forsterker det dårlige og gjør det gode vanskeligere.

Jeg fant på formuleringen, men jeg er verken den eneste eller den første som har kommet frem til denne innsikten.

La oss se hva loven betyr i praksis, med noen eksempler på skalerbarhet.

1. Eksempel: Kommunikasjon og skalerbarhet

Det første og mest åpenbare eksempelet er kommunikasjon. Det er et velkjent faktum at når antallet personer i et prosjekt øker, øker også antallet kommunikasjonskanaler. Hvis kommunikasjonskanalene ikke er gode nok til å begynne med, vil oppskalering gjøre problemet verre.

På den annen side vil oppskalering introdusere enkelte utfordringer hvis kommunikasjonskanalene i utgangspunktet er gode, ikke bare på grunn av det økte antallet personer, men også på grunn av hvordan de er fordelt. Ofte opprettes nye team på forskjellige steder, noe som tvinger frem endringer i kommunikasjonskanalene—for eksempel ved å gå fra møter ansikt til ansikt til videokonferanser eller ved å erstatte en tavle med et elektronisk verktøy.

2. Eksempel: Kontinuerlig integrasjon/kontinuerlig levering og skalerbarhet

Vi ser også den grunnleggende loven om skalering i arbeidsflyter for kontinuerlig integrasjon (CI) og kontinuerlig levering (CD). Når det bare finnes ett team, er ting ganske rett frem.

Når man går fra ett til to team, blir CI- og CD-systemene mer kompliserte—vanligvis er antallet CI-arbeidsflyter n+1 når det finnes n team (én arbeidsflyt per team, pluss én for integrasjon). Dette får åpenbare konsekvenser for klargjøring av miljøer og koordineringen mellom teamene.

3. Eksempel: Tilbakemeldingssløyfer og skalerbarhet

Et siste eksempel er tilbakemeldingssløyfer. Større prosjekter har lengre tilbakemeldingssløyfer. Derfor blir det mye vanskeligere å forbedre systemet på en iterativ måte, noe som øker sannsynligheten for å bygge feil produkt.

Dette er bare tre eksempler på noen av utfordringene som følger med oppskalering. Jeg er sikker på at du kan komme på mange flere.

La oss anta at du er villig til å akseptere avveiningene som følger med. Det neste du trenger, er at prosjektet ditt oppfyller noen viktige forutsetninger for å dokumentere skalerbarheten.

10 forutsetninger for skalering

Hvorvidt du har en skalerbar virksomhet, et skalerbart prosjekt eller et skalerbart team, avhenger av flere forutsetninger som er listet opp nedenfor. Hvis du oppfyller disse forutsetningene, har du høy skalerbarhet. På den annen side øker sannsynligheten for å mislykkes dramatisk hvis noen av dem ikke er oppfylt.

1. Tilstedeværelsen av tydelige, felles mål

Dette burde være en selvfølge, men etter min erfaring er fraværet av tydelige, felles mål svært vanlig. Uten slike mål vil teamene trekke i forskjellige retninger, noe som gjør det vanskeligere å levere noe nyttig.

2. Bruken av passende måleparametere

Jo større prosjektet er, desto viktigere er det å kunne måle effekten av beslutningene som tas. For eksempel: Forbedret tilføringen av et nytt team prosjektets evne til å levere? Presser vi teamene så hardt at kvaliteten synker? Fungerer teamene godt sammen, eller forstyrrer de hverandre?

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get Free Access

Have an account? Log In

3. En egnet arkitektur

Hvis systemets «form» ikke samsvarer med teamstrukturen, vil flere team bare gjøre ting verre. Dette er en direkte følge av Conways lov, en velkjent empirisk observasjon som er blitt bekreftet i praksis.

4. Tilgjengelige ledelsesmessige og tekniske ferdigheter

Problemer som skyldes mangel på ferdigheter, vil ha en forsterket negativ effekt etter hvert som prosjektet skaleres opp.

5. Gode kommunikasjonskanaler

Jo flere som er involvert, desto mer kommunikasjon finner sted. Vellykket skalering krever strømlinjeformet kommunikasjon.

6. God prioritering og planlegging

Mangel på hensiktsmessig prioritering og planlegging er etter min erfaring en svært vanlig faktor ved prosjektfiaskoer. Når mer enn ett team er involvert, må prioriterings- og planleggingsaktivitetene særlig ta høyde for å redusere effekten av forsinkelser og manglende synkronisering.

7. God innhenting og håndtering av krav

Dette henger sammen med prioritering og planlegging. Effekten av feilaktige, misforståtte eller unødvendige krav vil dessuten forsterkes etter hvert som antallet team øker.

8. Arbeid av høy kvalitet

Jo større prosjektet er, desto større er den negative effekten av dårlig kvalitet. I enkelte patologiske (og vanlige) scenarier kan noen feil bli til funksjoner, fordi tilbakemeldingssløyfene for å rette dem kan være så lange at andre team har rukket å utforme omgåelser for å nøytralisere dem.

9. Tilgjengelige ressurser

Flere team trenger flere skrivebord, datamaskiner, verktøy og miljøer.

10. Nådeløs automatisering

Enhver manuell aktivitet er en flaskehals hvis effekt blir verre jo flere personer og team som er involvert. Et (svært vanlig) eksempel er manuelle testaktiviteter for å sikre at det ikke er innført regresjoner før en produksjonssetting. Etter min erfaring er dette en av de største flaskehalsene i alle prosjekter, men særlig i prosjekter med mer enn ett team.

Pass på for tidlig skalering

Skalerbarhet står høyt på agendaen for oppstartsbedrifter og seriegründere – og de har en ting eller to å lære oss om for tidlig skalering.

Hvis du setter i gang en skaleringsinnsats før du faktisk har oppfylt forutsetningene for å skalere en virksomhet, et team eller en organisasjon på en vellykket måte, får du det oppstartsmiljøet kaller «for tidlig skalering».

En enkel definisjon av for tidlig skalering fra seriegründeren Jim Pitkow:

For tidlig skalering: å vokse i påvente av etterspørsel i stedet for etterspørselsdrevet vekst.

Riktig skalering tar faktisk tid – og ekte skalerbarhet drives av et reelt behov for skalering på grunn av etterspørsel, ikke av en kunstig påtvunget idé om bare å bli større og gjøre flere ting raskere.

Oppstartsmiljøet byr på et par lærdommer vi kan ta med tilbake til teamene og prosjektene våre når vi vurderer om tiden er inne for å skalere. Her er noen tall fra Startup Genome-rapporten Ekstra om for tidlig skalering:

• Oppstartsbedrifter som skalerer riktig, bruker 76 % lengre tid på å nå teamstørrelsen sin enn oppstartsbedrifter som skalerer for tidlig.
• 74 % av internettbaserte oppstartsbedrifter med høy vekst mislykkes på grunn av for tidlig skalering.
• Oppstartsbedrifter som skalerer riktig, vokser omtrent 20 ganger raskere enn oppstartsbedrifter som skalerer for tidlig.

Hvis du er interessert i flere tall om entreprenørskap, kan du se nærmere på undersøkelsen vår om de mest entreprenørielle delstatene i USA.

Er du virkelig klar til å skalere?

Hvis prosjektet ditt er godt drevet og oppfyller forutsetningene ovenfor, bør ditt neste spørsmål være:

«Hvor mange team kan bidra produktivt?»

Vi besvarer dette i neste del.

Hva er grensen for skalerbarhet? Brooks’ og Amdhals lover

Det er et velkjent faktum at det å legge til flere personer i et programvareprosjekt ikke nødvendigvis øker produktiviteten.

Faktisk vil det å legge til flere personer i de fleste tilfeller føre til et kraftig produktivitetsfall.

Fred Brooks gjorde denne observasjonen i boken sin Den mytiske mann-måneden, som ble kjent som Brooks’ lov:

«Å tilføre arbeidskraft til et forsinket programvareprosjekt gjør det enda mer forsinket […] Antallet måneder et prosjekt tar, avhenger av prosjektets sekvensielle begrensninger. Det maksimale antallet personer avhenger av antallet uavhengige deloppgaver. Ut fra disse to størrelsene kan man utarbeide tidsplaner med færre personer og flere måneder[…]. Man kan imidlertid ikke lage gjennomførbare tidsplaner med flere personer og færre måneder.»

Den siste halvdelen av sitatet ovenfor er etter min mening den mest interessante. Faktisk er den i bunn og grunn en formulering i vanlig språk av Amdahls lov – en formel som angir den maksimale teoretiske hastighetsøkningen i et system med samtidige prosesser:

Amdahls lov

Hastighetsøkning = 1 / (s + p / n )

Der:

s = prosentandel serielle oppgaver

p = prosentandel parallelle oppgaver

s + p = 1

n = antall prosessorer (team i vårt tilfelle)

Et prosjekt med flere team er faktisk en type system med samtidige prosesser, der hvert team er en behandlingsenhet. I praksis sier Amdahls lov at den maksimale mengden arbeid som kan utføres samtidig, begrenses av mengden serielt arbeid som må gjøres.

Med enkle ord betyr dette at det som må gjøres i en bestemt rekkefølge, vil begrense hvor mye arbeid teamene kan jobbe med samtidig.

Hva er serielt arbeid i forbindelse med programvareutvikling?

Du lurer kanskje på hva slags arbeid som er serielt arbeid som påvirker programvareteam.

Her er noen eksempler (jeg er sikker på at du kan komme på mange flere):

• Alt arbeid med integrasjons- og distribusjonsforløp
• Sammenslåing av programvareendringer i kode som deles av ulike team
• Enhver form for synkronisering – for eksempel når et team er avhengig av leveranser fra et annet team før det kan fortsette arbeidet
• Venting på klargjøring av ressurser

Å bruke Amdahls lov på skalering av team

Grafen nedenfor viser konsekvensene av Amdahls lov når antallet team økes for å øke produktiviteten.

Vi kan se at produktiviteten øker sublineært når antallet team øker – frem til et toppunkt, og deretter synker den igjen.

En illustrasjon av Amdahls lov: Gjennomstrømningen av leveranser øker med antallet team, men bare frem til et visst punkt – og det er vanligvis ikke det ledere håper på.

Hvis du bare skal huske én ting fra denne artikkelen, er det dette:

Å øke antallet team kan øke gjennomstrømningen – men bare frem til et visst punkt.

Så hva er det ideelle antallet team for et bestemt prosjekt?

Det finnes dessverre ingen ligninger som på forhånd kan beregne det ideelle antallet team for et bestemt prosjekt. Den eneste måten er å bruke et sett med prosjektmålinger for å måle ting som produktivitet og kvalitet, og se hva som skjer når team legges til eller fjernes. Min anbefaling er å begynne i det små med ett team på 3–6 personer, og bare skalere opp når og hvis det er nødvendig.

På et tidspunkt vil du kanskje oppdage at du allerede har nådd det maksimale antallet team, men at prosjektet fortsatt ikke klarer å innfri forpliktelsene sine. Det er da prioriterings- og kommunikasjonsevnene dine kommer til nytte, ettersom du kanskje må ta noen vanskelige samtaler med kundene dine.

Vurderinger rundt teamstruktur: funksjons- eller komponentteam?

Når et nytt team legges til i prosjektet, hvordan skal det arbeide? Begynn med å stille deg selv disse to spørsmålene:

1. Vil de ha ansvaret for å utvikle kundesynlige funksjoner fra ende til ende, eller ved å endre noe i systemet for å nå målet sitt?
2. Vil de ha ansvaret for å arbeide med en spesifikk komponent som leverer en del av en eller annen brukersynlig funksjonalitet?

Hvis du svarte ja på nr. 1, vil teamet være et funksjonsteam.

Hvis du svarte ja på nr. 2, vil det være et komponentteam.

Tips for å velge riktig teamstruktur

Det er svært viktig å velge riktig teamstruktur og organisering av teamet, men det er ikke enkelt. For øyeblikket ser funksjonsteam ut til å være det foretrukne alternativet i de fleste situasjoner. Dette valget er imidlertid ofte basert på vane eller rutine i stedet for data.

Virkeligheten er at «det kommer an på». Mer spesifikt avhenger det av systemets arkitektur. Programvareprosjekter følger gjerne det som er kjent som Conways lov—en empirisk observasjon av Mel Conway:

«Organisasjoner som utformer systemer … er begrenset til å produsere utforminger som er kopier av kommunikasjonsstrukturene i disse organisasjonene»

Med andre ord må «formen» på teamstrukturen samsvare med «formen» på systemet, ellers vil prosjektet oppleve alvorlige problemer.

Det er grunnen til at jeg alltid anbefaler ledere å involvere seniorarkitekter og tekniske ledere i beslutninger om teamstruktur—ellers utformer lederne i realiteten systemet uten å være klar over det (og uten de nødvendige ferdighetene). Dette kan i sin tur øke risikoen for at prosjektet mislykkes betydelig.

To paradokser ved skalerbarhet

Gjennom min erfaring som konsulent for en rekke storskalaprosjekter har jeg kommet til den konklusjonen at prosjekter i de fleste tilfeller skaleres av feil grunner.

Jeg har funnet på to paradokser som oppsummerer det jeg har sett i praksis:

Det første skaleringsparadokset

De fleste prosjekter skaleres opp fordi de ikke oppfyller forutsetningene for skalering

Det andre skaleringsparadokset

Prosjekter som oppfyller forutsetningene for skalering, har mindre behov for å skalere

Det første paradokset sier at prosjekter i de fleste situasjoner går sakte fremover ganske enkelt fordi de ikke ledes godt.

Det andre sier at velstyrte prosjekter har mindre behov for skalering, ganske enkelt fordi de er godt styrt.

Faktisk hadde de mest produktive prosjektene jeg har sett, bare ett eller to små team og oppfylte alle forutsetningene for skalering. Av alle storskalaprosjektene jeg har vært involvert i, har jeg ikke sett ett eneste der alle forutsetningene for skalering var oppfylt. Faktisk hadde alle store problemer med å oppfylle noen av forutsetningene.

Hvis du er involvert i et prosjekt som opplever problemer og forsinkelser, er den beste anbefalingen jeg kan gi, å rydde opp ved å skalere ned rotet før du vurderer å skalere opp prosjektet.

Viktige punkter for å skalere teamene dine på riktig måte

Det er ikke enkelt å skalere programvareteam, og det må gjøres med stor forsiktighet. Før du går, kommer noen avsluttende tanker om hvordan du finner den mest effektive måten å skalere et programvareutviklingsteam på:

1. Hvis du arbeider med å oppfylle forutsetningene for skalerbarhet, kan du oppdage at du kan holde teamet lite og unngå alle problemene som følger med større størrelse.
2. På den annen side bør du, hvis prosjektet allerede er stort og utfordrende, først konsentrere deg om å rydde opp ved å skalere ned rotet.

Her er de første stegene jeg foreslår at du tar etter å ha lest denne artikkelen:

1. Finn ut hva som skjer på bakken
2. Innfør noen måltall slik at du kan vurdere den nåværende situasjonen, samt kvaliteten på beslutningene som er tatt.