“Fristen” nærmer seg. Vi jobbet så fort vi kunne og visste at vi kom til å levere noen uker for sent. Vi kjente arkitekturen og oppgavene vi skulle løse, og vi tok de snarveiene vi turte. Da bestemte ledelsen seg for å sette på to utviklere til. Har du ikke hørt om Brooks’ lov, spurte jeg. Nei, var svaret. Med to ekstra utviklere så ville vi få større kapasitet og klare å nå «fristen». Jeg protesterte, men hadde ingen gode argumenter å komme med, der og da.
Så hva skjedde? Jo, Brooks’ lov slo til, og vi klarte ikke å levere. Vi måtte nå bruke tid til opplæring og kommunikasjon. De nye var dyktige, men de trengte tid på å forstå og skjønne problemene som skulle løses og hvordan vi jobbet. Vi måtte forklare arkitekturen, hvordan vi hadde organisert koden og hvilke oppgaver som skulle løses. At de skulle klare å ta til seg det vi andre hadde brukt mange måneder på å lære på noen få uker, gikk ikke. Ledelsen presset på at vi skulle levere på «fristen». Det økte stressnivået, førte til mange feil og høy teknisk gjeld.
Hvorfor økte ikke effektiviteten slik ledelsen ønsket seg? Det ga jo motsatt effekt, vi ble mindre effektive. Og hvorfor kjente ikke ledelsen til Brooks’ lov? Den har vært kjent siden 1975. Da gav Fred Brooks ut boka «The Mythical Man-Month». Der formulerte han loven som er oppkalt etter ham.
« Adding manpower to a late software project makes it later. »
Brooks forklarer at det innen systemutvikling må settes av mye tid til kommunikasjon om hvordan oppgavene løses, og måten en oppgave blir løst på, legger føringer for hvordan de neste oppgavene skal løses, som igjen krever mer tid til koordinering. Tiden det tar å kommunisere rundt oppgaveløsningen beskriver han med følgende formel, hvor n er antall personer i teamet:
Hvis oppgavene kan løses uten at man trenger å kommunisere, så vil det å øke kapasiteten med flere arbeidere, redusere løsningstiden vesentlig. Tiden det tar å løse o oppgaver med n personer kan da beskrives slik:
For estimering innen systemutvikling må de to formlene kombineres. Figuren under viser dette. Anta at vi har 200 planlagte oppgaver, hvor hver oppgave er estimert til å ta en dag å løse. Kurvene viser estimert tid for forskjellige teamstørrelser. Den nederste kurven viser estimert løsningstid dersom det ikke er behov for å snakke sammen. Den øverste kurven viser estimert løsningstid i systemutvikling (hvor det er behov for å snakke sammen for å løse oppgavene). I starten gir det stor effekt å legge på flere, men etter hvert går det med mer og mer tid til kommunikasjon, som raskt spiser opp den forventede kapasitetsøkningen.
Hvorfor tror mange at vi kommer raskere i mål med flere på teamet? Jeg tror det er fordi de ikke skjønner hvor mye mer tid som da må brukes til kommunikasjon.
Neste gang en slik situasjon oppstår, kan jeg vise frem grafen og har argumentene klare. Den forventede kapasitetsøkningen av flere på teamet, blir raskt spist opp av at mer tid går med til at teamet må snakke sammen om løsningen.
Alle bør kjenne til Brooks’ lov. Det å legge på flere når man er forsinket, kan skape kaos, krever mer tid til kommunikasjon, og resulterer ganske sikkert i at man ikke blir ferdig til avtalt tid. Det som er sikkert, er at det blir dyrere.
Her er tabellen som grafen er basert på.
Denne artikkelen er skrevet av David Skogan, han er arkitekt og jobber hos PROMIS Navigate. Er du interessert i å vite mer om oss, ta kontakt!