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:

• Å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

Sjovt nok peger alle disse elementer i sidste ende på den enkelte person, altså det skal forstås som et skillset som et teammedlem skal have eller oparbejde for at kunne deltage i super produktive teams. "Teamwork is an individual skill", siger Christopher Avery i en god og praktisk bog om emnet.

Hvad er jeres erfaringer? Hvilken størrelsen dur de teams i deltager i? Og ikke mindst hvorfor?

Teams og Gandhi

Tyvstjålet fra et indlæg på lifebeyondcode kommer her et Gandhi-citat:

"A small group of determined spirits with an unquenchable thirst for their mission, can alter the course of history".
- Mahatma Gandhi

Rajesh Setty (bloggeren på lifebeyondcode) bruger citatet til at filosofere over sin personlige indstilling til livet, men jeg tænkte selvfølgelig straks på projekter og teams.

"..determined spirits with an unquenchable thirst for their mission" - dette er for mig at se kardinalpunktet for ethvert projekt. Hvis man sikrer at teamet arbejder mod samme og meget nøje defineret målsætning, og at alle individder i teamet kan se deres funktion i opnåelsen af målsætningen, så kan man sku "...alter the course of history"! Så lad det blive en god notabene til alle projektledere...

Giv magten til dit team #1 - Medbestemmelse

På det seneste har ideen om motivation af projektteamet fyldt mit sind meget. Derfor har jeg tænkt at starte en føjleton på området, som sikkert kunne skabe lidt sund debat :)

Grundlæggende bygger mange agile processdiscipliner på en antagelse om at motivation og empowerment af projektteamet er væsentligt for at kunne skabe gode resultater, og indenfor softwarebranchen dermed god software. Eksempelvis har Scrum sit udgangspunkt i at projektteams/udviklingsteams skal være selvorganiserende for at kunne levere fremragende software tilpasset kundens, produktejerens, ønsker og behov.

Jeg kunne godt tænke mig at dykke lidt ned i, hvad der gør et super team, og her tænker jeg specielt på, hvad man som leder kan gøre gøre for at sætte scenen i den forbindelse.

Første ting jeg har tænkt mig at skrive lidt om er noget som ligger mig meget nært i mit ledelsesarbejde: medbestemmelse, så her kommer det...

#1 Medbestemmelse
I modsætning til traditionel management tankegang, hvor projektlederen udstikker opgaver og får projektteamets medlemmer til at løse dem, så tror jeg på, at teamet selv skal lede og fordele det stykke arbejde, som de udfører. Projektlederen skal blot fascilitere at dette bliver gjort og bistå med gode indspark til processen, hvor nødvendigt. Dette er væsentligt af flere grund, men vigtigst er dog, at man som projektleder skal befri sig fra kontrolcenter-metaforen, hvor man kan sidde i sit eget skønne elfenbenstårn og styre sine projekter via flotte charts og reports. Teamet skal deltage i centrale beslutninger for projektet. På den måde får man også flere perspektiver på en given problematik, end man ellers ville have gjort. Som projektleder bør du

1. Involvere dit team i beslutningsprocesser, som omhandler teamet eller det produkt, som der arbejdes på
2. Sikre at teamet er klar over sit ansvar
3. Gøre det klart for teamet, at de har de kompetencer, der skal til for at kunne træffe de rigtige beslutninger
4. Sikre at der altid følges op på de beslutninger, der træffes (dvs. får dem omformet til planer, kommunikeret til stakeholders etc.)

Hvad får du ud af at gøre det? I mine øjne er der nærmest kun gevinster at hente (hvis det rigtige setup etableres):

1. Du får adgang til en meget bredere, og multi-perspektiveret, vidensbase (som i tekniske henseender er langt mere kompetent end du nogensinde kan være)
2. Ved at spørge teamet nedarves der konsensus for forslaget, som skal vendes. Teamet kommer op med løsningsforslag, som bliver til planer, og disse planer vil i sidste ende være produktet af løsninger tænkt af teamet selv og ikke af dig
3. Når mennesker adspørges om deres mening, så arbejder de hårdt for at komme op med gode ideer. Dette er et kæmpe plus, når man står midt i en kritisk situation i sit projekt og skal træffe vigtige beslutninger, om hvilken retningen arkitekturen eksempelvis skal tage

Medbestemmelse betyder dog ikke, at du kan læne dig tilbage og lade andre beslutte alt for dig. Du skal skabe det forum, hvori medbestemmelsen opstår, men som ordet medbestemmelse også ligesom indikerer, så er du også selv en deltager i processen. Måske beslutter du ikke noget om teknikken, men måske har du gode retningslinier for tænkningen eller scopet af diskussionen.

Sidst vil jeg lige nævne, at medbestemmelse også stiller store krav til projektlederens rolle som leder. Projektlederen skal være den toneangivende og altid gå foran som det gode eksempel. Hvis man som projektleder lader teamet træffe beslutninger på halvt grundlag, hvad lærer man så sit team? - At det er ok at træffe beslutninger på ufuldstændig information.. osv.

Kliche, floskel eller ej - teambuilding uden for kontoret er godt!

Vi har i dag spenderet en hel dag i Ebeltoft Zoo, eller rettere Ree Park, på både at diskutere værdier i IT-organisationen og løse praktiske fysiske opgaver i teams. Det er efterhånden en fortærsket kliche, at den slags virker, men alligevel vil jeg nu gerne have lov til at råbe det lidt igen: at lave noget sammen udenfor kontorets rammer, det booster sku team-spirit, korpsånd og venskab! Jeg tror mange har tendens til at tilsidesætte den slags tiltag, fordi de virker floskelagtige og "set før"... men måske er der en grund til at de virker som "set før"? Jeg er sikker på, at IT afdelingen vender tilbage på mandag med forfrisket ånd og styrke. Mere af den slags, tak.

Ønsker man at basere sin organisation på team-arbejde, så bør aktiviteter som nævnt i dette indlæg ikke forbigås. Der må også meget gerne følges op på den slags aktiviteter, så man som team og organisation kan forbedre sig og lære af sine erfaringer.