Teams #1 - Størrelse af team
Vi har kørt et par projekter efterhånden her på den blå, og jeg er begyndt at tænke på, hvor smertegrænsen for størrelsen af et team ligger i forhold til team-performance, kommunikation og sociale relationer.
Cockburn's Crystal clear siger noget i retningen af max 9 på teamet, inkl. testere og designere. En artikel på InfoQ siger "productivity drops off a cliff as team size increases". I den kvantitative ende kan man enddog finde formler for, hvordan størrelsen af et team er direkte relateret til kommunikationens kompleksitet.
Jeg er egentlig nået frem til, at den absolutte smertegrænse her på den blå befinder sig ved omkring 6 teammedlemmer. Vi har tidligere kørt med noget større teams, hvor vi også gjorde brug af outsourcing til Indien. Kompleksiteten var ekstrem høj i forhold til kommunikationen (flere sprog, flere kulturer og subadfærdsmønstre) og de sociale relationer (subgrupperinger indenfor teamet etc), at det gik meget ud over performance på den måde, vi søger det her. Team-performance betyder for mig, at en gruppe af mennesker bliver så sammentømret, at planlægning og fremdrift flyder frit som en naturlig del af teamets momentum. At skabe et sådan momentum kræver meget af de enkelte teammedlemmer. Pludselig bliver elementer som nedenstående vigtige:
Hvad er jeres erfaringer? Hvilken størrelsen dur de teams i deltager i? Og ikke mindst hvorfor?
Cockburn's Crystal clear siger noget i retningen af max 9 på teamet, inkl. testere og designere. En artikel på InfoQ siger "productivity drops off a cliff as team size increases". I den kvantitative ende kan man enddog finde formler for, hvordan størrelsen af et team er direkte relateret til kommunikationens kompleksitet.
Jeg er egentlig nået frem til, at den absolutte smertegrænse her på den blå befinder sig ved omkring 6 teammedlemmer. Vi har tidligere kørt med noget større teams, hvor vi også gjorde brug af outsourcing til Indien. Kompleksiteten var ekstrem høj i forhold til kommunikationen (flere sprog, flere kulturer og subadfærdsmønstre) og de sociale relationer (subgrupperinger indenfor teamet etc), at det gik meget ud over performance på den måde, vi søger det her. Team-performance betyder for mig, at en gruppe af mennesker bliver så sammentømret, at planlægning og fremdrift flyder frit som en naturlig del af teamets momentum. At skabe et sådan momentum kræver meget af de enkelte teammedlemmer. Pludselig bliver elementer som nedenstående vigtige:
- Åben kommunikation
- Holde en god tone
- Respekt
- Anerkendelse af personer og deres styrker og svagheder
- Planlægning
- Støtte når nogen har behov for det
Hvad er jeres erfaringer? Hvilken størrelsen dur de teams i deltager i? Og ikke mindst hvorfor?
indsendt af Rune Mai kl.
16:08
2 kommentarer:
Jeg har stort set ingen empiri at dække mig ind under, men min mavefornemmelse er også at teams skal holdes små. Et team på 9 personer er stort, især hvis projektet følger SCRUM, hvor der lægges stor vægt på kommunikation og etableringen af fælles ejerskabsfølelse. Et team på 9 personer antyder en projektopgave der er så stort, at ingen enkeltperson kan overskue den, og dermed at alle ikke er involverede i alle opgaver. Det kræver nok sin SCRUM master at holde team-worket på et niveau, hvor ingen spilder tiden med møder og diskussioner de reelt ikke bidrager til, og hvor ingen skaber støj i form af at skulle blande sig eller kommentere alting. Jeg har i alt fald haft mine udfordringer med at holde stand-up møder nede på 15 minutter, og der var vi kun 5 (!).
I større software projekter (måske >6) vil jeg mene at projektet hensigtsmæssigt kan organiseres i delprojekter, f.eks. efter geografi, discipliner eller resultat (alt efter hvad der giver mest mening). Et spørgsmål er, hvordan projektdeltagerne bruger deres arbejdstid mest effektivt, et andet er hvor stort teamet skal være før projektlederen mister overblikket, eller simpelthen ikke har timer nok i døgnet til at udføre sine opgaver. Ingen projekter eller virksomheder er ens, men på min tidligere arbejdsplads var min egen tommelfinger-regel at der skulle 1 projektleder til 4 udviklere. Men her var også tale om en bureaukratisk og politisk organisation, der krævede stor indsats af projektlederen at navigere i. Groft sagt ville et projekt med 12 udførende formodentligt resultere i et PM team på 1 overordnet projektleder og 2 delprojektledere. På et tidspunkt bliver projektet så så stort, at den overordnede projektleder må slippe team ledelsen af udviklerne, og koncentrere sig 100% om det overordnede projekt.
Bare mine 5 cents :)
Venlig hilsen,
Jakob Veje Hansen
Tak for informationen Jakob! Masser af gode pointer, og jeg er også selv nået til konklusionen om, at teams helst ikke skal være større en 5-6 stykker. Faktisk har jeg en del gange observeret, at det team jeg er del af nu fungerer super godt, når der kun er 4 udviklere til stede. I forhold til dine scrummøder har jeg et godt tip: lav en seddel med møde agendaen på, lad den gå på omgang på teamet. den der har sedlen styrer mødet. Mødet skal køres kontant og fuldstændig uden løsningsforslag. Efter vi har indført det "pattern" så er vi nu i stand til at holde mødet på 10-15 min. med 7 mand.
Send en kommentar
<< Startside