10 förutsättningar för skalbarhet att känna till innan du skalar upp

Om du har arbetat med programvaruutveckling tillräckligt länge har du sannolikt upplevt den här mardrömmen:

1. Kunden lovas massor av funktioner på en orealistiskt kort tidsram (som ingen vågar ifrågasätta).
2. Senare, när tidsfristen närmar sig farligt snabbt, beslutar någon med makt att kasta in fler team i problemet för att hinna hålla tidsfristen.
3. Saker börjar falla samman.

Låter det bekant?

I den här artikeln förklarar jag vad du behöver göra för att undvika den mardrömssituationen igen (eller, om du har haft tur nog att slippa uppleva den, för att undvika den helt och hållet).

Mina insikter i den här artikeln kommer från skalning av programvaruutvecklingsteam, men du kan tillämpa den grundläggande teorin på skalning av ett företag eller tillväxt av ett team inom vilken bransch som helst. Du kommer att ha nytta av detta även om du använder ett av de färdiga skalningsramverken—Large Scale Scrum (LeSS), Scrum@Scale, SAFe.

Det beror på att jag fokuserar på flera viktiga aspekter av skalbarhet som aldrig nämns i dessa metoder—den grundläggande sanningen om vad det innebär att skala upp, som ofta glöms bort eller ignoreras.

Den grundläggande skalningslagen

Den grundläggande skalningslagen är en empirisk observation av vad som händer i projekt när de skalas upp:

Att skala upp förstärker det dåliga och gör det goda svårare.

Jag formulerade orden, men jag är varken den enda eller den första som kommit fram till insikten.

Låt oss se vad lagen innebär i praktiken med några exempel på skalbarhet.

1. Exempel: Kommunikation och skalbarhet

Det första och mest uppenbara exemplet är kommunikation. Det är välkänt att antalet kommunikationskanaler ökar när antalet personer i ett projekt ökar. Om kommunikationskanalerna inte är tillräckligt bra från början kommer uppskalning att förvärra problemet.

Å andra sidan kommer uppskalning att medföra vissa utmaningar även om kommunikationskanalerna är bra från början, inte bara på grund av det ökade antalet personer utan också på grund av deras geografiska spridning. Ofta skapas nya team på olika platser, vilket tvingar fram förändringar i kommunikationskanalerna—till exempel genom att gå från möten ansikte mot ansikte till videokonferenser eller genom att ersätta en whiteboard med ett elektroniskt verktyg.

2. Exempel: Kontinuerlig integration/ kontinuerlig leverans och skalbarhet

Vi ser också den grundläggande skalningslagen i pipelines för kontinuerlig integration (CI) och kontinuerlig leverans (CD). När det bara finns ett team är saker och ting ganska raka.

När man går från ett till två team blir CI- och CD-systemen mer komplicerade—vanligtvis tenderar antalet CI-pipelines att vara n+1 när det finns n team (en pipeline per team plus en för integration). Detta får uppenbara följder för provisionering av miljöer och för samordningen mellan teamen.

3. Exempel: Återkopplingsloopar och skalbarhet

Ett sista exempel: återkopplingsloopar. Större projekt har längre återkopplingsloopar. Därför blir det mycket svårare att förfina systemet på ett iterativt sätt, vilket ökar risken för att bygga fel produkt.

Det här är bara tre exempel på några av de utmaningar som uppstår vid uppskalning. Jag är säker på att du kan komma på många fler.

Anta att du är villig att acceptera de kompromisser som krävs. Nästa sak du behöver är att ditt projekt uppfyller några viktiga förutsättningar för att bevisa sin skalbarhet.

10 förutsättningar för skalning

Huruvida du har ett skalbart företag, projekt eller team beror på flera av förutsättningarna nedan. Om du uppfyller dessa förutsättningar har du hög skalbarhet. Omvänt ökar risken för misslyckande dramatiskt om någon av dem inte är uppfylld.

1. Tydliga, gemensamma mål

Det här borde vara självklart, men enligt min erfarenhet är avsaknaden av tydliga, gemensamma mål extremt vanlig. Utan dessa kommer teamen att dra åt olika håll, vilket gör det svårare att leverera något användbart.

2. Användning av lämpliga mätvärden

Ju större projektet är, desto viktigare är det att kunna mäta effekten av de beslut som fattas. Förbättrade till exempel tillägget av ett nytt team projektets förmåga att leverera? Pressar vi teamen så hårt att kvaliteten sjunker? Arbetar teamen bra tillsammans, eller stör de varandra?

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.

Create Free Account

Have an account? Log In

3. En lämplig arkitektur

Om systemets ”form” inte överensstämmer med teamstrukturen kommer fler team bara att göra situationen värre. Detta är en direkt följd av Conways lag, en välkänd empirisk observation som har bevisats i praktiken.

4. Tillgång till ledarskaps- och teknisk kompetens

Problem som beror på bristande kompetens får en förstärkt negativ effekt när projektet växer.

5. Bra kommunikationskanaler

Ju fler personer som är involverade, desto mer kommunikation äger rum. En framgångsrik uppskalning kräver en effektiviserad kommunikation.

6. Bra prioritering och planering

Brist på lämplig prioritering och planering är enligt min erfarenhet en mycket vanlig faktor vid projektmisslyckanden. När mer än ett team är involverat måste i synnerhet prioriterings- och planeringsaktiviteterna ta hänsyn till att motverka effekterna av förseningar och bristande samordning.

7. Bra kravinsamling och kravhantering

Detta går hand i hand med prioritering och planering. Dessutom förstärks effekten av felaktiga, missförstådda eller onödiga krav när antalet team ökar.

8. Arbete av hög kvalitet

Ju större projektet är, desto större blir den negativa effekten av dålig kvalitet. I vissa patologiska (och vanliga) scenarier kan vissa buggar bli funktioner, eftersom återkopplingslooparna för att åtgärda dem kan vara så långa att andra team kan ha utformat sina lösningar för att neutralisera dem.

9. Tillgång till resurser

Fler team behöver fler skrivbord, datorer, verktyg och miljöer.

10. Hårdhänt automatisering

Varje manuell aktivitet är en flaskhals vars effekter blir värre ju fler personer och team som är involverade. Ett (mycket vanligt) exempel är manuella testaktiviteter för att säkerställa att inga regressioner har införts före en produktionssättning. Enligt min erfarenhet är detta en av de största flaskhalsarna i alla projekt, men särskilt i projekt med mer än ett team.

Se upp med för tidig uppskalning

Skalbarhet står högt på dagordningen för nystartade företag och serieentreprenörer – och de har en eller två lärdomar att förmedla om att skala upp för tidigt.

Om du inleder en uppskalning innan du verkligen har uppfyllt förutsättningarna för att framgångsrikt skala upp ett företag, team eller en organisation får du det som startupvärlden kallar ”för tidig uppskalning”.

En enkel definition av för tidig uppskalning från serieentreprenören Jim Pitkow:

För tidig uppskalning: att växa i förväntan på efterfrågan i stället för efterfrågestyrd tillväxt.

Att skala upp på rätt sätt tar verkligen tid – och verklig skalbarhet drivs av ett verkligt behov av uppskalning på grund av efterfrågan, inte av en artificiellt påtvingad idé om att helt enkelt bli större och göra fler saker snabbare.

Startupvärlden erbjuder ett par lärdomar som vi kan ta med oss tillbaka till våra team och projekt när vi funderar på om det är dags att skala upp eller inte. Här är några siffror från Startup Genome-rapporten Extra om för tidig uppskalning:

• Startupföretag som skalar upp på rätt sätt behöver 76 % längre tid för att nå sin teamstorlek än startupföretag som skalar upp för tidigt.
• 74 % av internetstartupföretag med hög tillväxt misslyckas på grund av för tidig uppskalning.
• Startupföretag som skalar upp på rätt sätt växer ungefär 20 gånger snabbare än startupföretag som skalar upp för tidigt.

Om du är intresserad av fler siffror om entreprenörskap kan du läsa vår studie om de mest entreprenöriella delstaterna i USA.

Är du verkligen redo att skala upp?

Om ditt projekt drivs väl och uppfyller ovanstående förutsättningar bör din nästa fråga vara:

”Hur många team kan bidra produktivt?”

Vi besvarar den frågan i nästa avsnitt.

Vad är gränsen för skalbarhet? Brooks och Amdhals lagar

Det är ett välkänt faktum att det inte nödvändigtvis ökar produktiviteten att lägga till fler personer i ett mjukvaruprojekt.

Faktum är att fler personer i de flesta fall leder till en kraftig produktivitetsminskning.

Fred Brooks gjorde denna observation i sin bok Den mytiska människomånaden, vilket blev känt som Brooks lag:

”Att lägga till arbetskraft i ett försenat mjukvaruprojekt gör att det blir ännu senare […] Antalet månader för ett projekt beror på dess sekventiella begränsningar. Det maximala antalet personer beror på antalet oberoende deluppgifter. Utifrån dessa två storheter kan man ta fram tidsplaner med färre personer och fler månader[…]. Man kan däremot inte skapa genomförbara tidsplaner med fler personer och färre månader.”

Den senare delen av citatet ovan är enligt min mening den mest intressanta. Den är faktiskt i princip den vardagliga versionen av Amdhals lag—en formel som anger den maximala teoretiska hastighetsökningen för ett parallellt system:

Amdhals lag

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

Där:

s = andel sekventiella uppgifter

p = andel parallella uppgifter

s + p = 1

n = antal processorer (team i vårt fall)

Ett projekt med flera team är faktiskt ett slags parallellt system där varje team är en bearbetningsenhet. I praktiken innebär Amdhals lag att den maximala mängden parallellt arbete begränsas av mängden sekventiellt arbete som måste utföras.

Med enkla ord innebär detta att det som måste göras i en viss ordning begränsar hur mycket arbete teamen kan utföra samtidigt.

Vad är sekventiellt arbete i ett mjukvaruutvecklingssammanhang?

Du kanske undrar vilken typ av arbete som är sekventiellt och påverkar mjukvaruteam.

Här är några exempel (jag är säker på att du kan komma på många fler):

• Allt arbete med integrations- och distributionspipelines
• Sammanfogning av programvaruändringar i kod som delas av olika team
• Alla typer av synkronisering—till exempel när ett team är beroende av leveranser från ett annat innan arbetet kan fortsätta
• Att vänta på att resurser ska tillhandahållas

Att tillämpa Amdhals lag på skalning av team

Diagrammet nedan visar konsekvenserna av Amdhals lag när antalet team ökas och hur det påverkar produktiviteten.

Vi kan se att produktiviteten ökar sublinjärt när antalet team ökar—fram till en topp, varefter den åter minskar.

En illustration av Amdhals lag: Genomströmningen av leveranser ökar med antalet team, men bara till en viss punkt—och det är vanligtvis inte vad chefer hoppas på.

Om du bara kommer ihåg en sak från den här artikeln, låt det vara denna:

Att öka antalet team kan öka genomströmningen—men bara till en viss punkt.

Så vilket är det idealiska antalet team för ett visst projekt?

Tyvärr finns det inga ekvationer för att på förhand beräkna det idealiska antalet team för ett visst projekt. Det enda sättet är att använda en uppsättning projektmätvärden för att mäta sådant som produktivitet och kvalitet och se vad som händer när team läggs till eller tas bort. Min rekommendation är att börja i liten skala med ett team på 3-6 personer och bara skala upp när och om det behövs.

Så småningom kanske du upptäcker att du redan har nått det maximala antalet team, men att projektet fortfarande inte kan uppfylla sina åtaganden. Då kommer din förmåga att prioritera och kommunicera väl till nytta, eftersom du kan behöva ha några tuffa samtal med dina kunder.

Överväganden kring teamstruktur: funktions- eller komponentteam?

Hur ska ett nytt team arbeta när det läggs till i projektet? Börja med att ställa dig själv dessa två frågor:

1. Kommer de att ansvara för att utveckla kundsynliga funktioner från början till slut, eller genom att ändra något i systemet för att uppnå sitt mål?
2. Kommer de att ansvara för att arbeta med en specifik komponent som tillhandahåller en del av någon användarsynlig funktionalitet?

Om du svarade ja på #1 kommer teamet att vara ett funktionsteam.

Om du svarade ja på #2 kommer det att vara ett komponentteam.

Tips för att välja rätt teamstruktur

Att välja lämplig teamstruktur och teamorganisation är mycket viktigt, men det är inte enkelt. För närvarande verkar funktionsteam vara det föredragna alternativet i de flesta situationer. Detta val baseras dock ofta på vana eller rutin i stället för på data.

Verkligheten är att ”det beror på”. Mer specifikt beror det på systemets arkitektur. Programvaruprojekt tenderar att följa det som kallas Conways lag—en empirisk observation av Mel Conway:

”Organisationer som utformar system… begränsas till att skapa utformningar som är kopior av dessa organisationers kommunikationsstrukturer”

Med andra ord måste teamstrukturens ”form” motsvara systemets ”form”, annars kommer projektet att drabbas av allvarliga problem.

Det är därför jag alltid rekommenderar chefer att involvera seniora arkitekter och tekniska ledare i beslut om teamstruktur—annars utformar chefer i praktiken systemet utan att inse det (och utan lämplig kompetens). Det kan i sin tur kraftigt öka risken för att projektet misslyckas.

Två paradoxer för skalbarhet

Utifrån min erfarenhet som konsult i ett antal storskaliga projekt har jag kommit fram till att projekt i de flesta fall skalas av fel anledningar.

Jag har formulerat två paradoxer som sammanfattar det jag har sett i praktiken:

Den första paradoxen kring skalning

De flesta projekt skalas upp eftersom de inte uppfyller förutsättningarna för skalning

Den andra paradoxen kring skalning

Projekt som uppfyller förutsättningarna för skalning har mindre behov av att skalas

Den första paradoxen säger att projekt i de flesta situationer fortskrider långsamt helt enkelt eftersom de inte hanteras väl.

Den andra säger att välskötta projekt har mindre behov av att skalas, helt enkelt eftersom de hanteras väl.

De mest produktiva projekt jag har sett hade faktiskt bara ett eller två små team och uppfyllde alla förutsättningar för skalning. Av alla storskaliga projekt jag har varit involverad i har jag inte sett ett enda där alla förutsättningar för skalning var uppfyllda. Faktum är att alla hade stora problem med att uppfylla någon av förutsättningarna.

Om du är involverad i ett projekt som har problem och förseningar är den bästa rekommendationen jag kan ge att först skala ned röran innan du överväger att skala upp projektet.

Viktiga slutsatser för att skala dina team på rätt sätt

Att skala programvaruteam är inte enkelt och måste göras med största försiktighet. Innan du går vidare kommer här några avslutande tankar om hur du hittar det mest effektiva sättet att skala ett programvaruutvecklingsteam:

1. Om du arbetar med att uppfylla förutsättningarna för skalbarhet kan du upptäcka att du kan hålla teamet litet och undvika alla problem som följer med en större storlek.
2. Om ditt projekt däremot redan är stort och har problem bör du först fokusera på att skala ned röran.

Här är de första stegen jag föreslår att du tar efter att ha läst den här artikeln:

1. Ta reda på vad som händer i praktiken
2. Inför mätetal för att kunna bedöma den aktuella situationen samt kvaliteten på de beslut som fattas.