#Team Building: La dimensione di un team di #progetto, qual è ottimale?

By /

Quanto deve essere la dimensione di un team di gestione di un progetto? Quando devono essere gli sviluppatori per singolo team? Qual è la dimensione ottimale in Scrum? Quale in DSDM®? Lo sport ci insegna che il numero è variabile: nel calcio le squadre sono composte da 11 giocatori, nel rugby 15, 13 o 7, nella pallavolo in campo sono 6. Ma in un team di progetto? Parlando con Steve Messenger del DSDM® Consortium, una delle cose che più mi ha fatto riflettere è che per lui in italiano è normale tradurre “Team” in “Squadra”, mentre in ambito Gestione Progetti siamo soliti lasciare la parola “Team” in inglese.

Formare i team è un elemento critico per il successo del progetto. COCOMO II, modello matematico per la stima dello sviluppo software, considera il fattore “personell/team capability” con un peso di 3.53 su 4.00. Il Manifesto Agile indica che sono più importanti “Gli individui e le interazioni più che i processi e gli strumenti“. Il PMBOK®, arrivato alla sua quinta edizione, dedica un intero capitolo alle risorse umane, in “Project Human Resource Management” e 4 processi a riguardo. PRINCE2®, nonostante escluda dal suo ambito gli elementi di leadership, considera molto importante il team nel suo principio “ruoli e responsabilità predefiniti”.

Uno degli elementi cruciali nel formare un team è capire la sua dimensione ottimale.

Studi sulla dimensione del Team

Sono stati eseguiti diversi studi a riguardo.

Già nel 1913 Maximilien Ringelmann aveva teorizzato che la produttività di un team era inversamente proporzionale alla sua dimensione, a causa di problemi di motivazione e coordinamento. Questa teoria è anche conosciuta come “Effetto Ringelmann”.

Nel 1970 J. Richard Hackman e Neil Vidmar, professori di Psicologia Sociale e delle Organizzazioni ad Harvard, esaminando il lavoro di gruppo dei loro studenti, hanno identificato la dimensione di un team perfetta: 4.6.

Nel 1972 Ivan Steiner, dopo ulteriori studi esaminando i fattori indicati nell’Effetto Ringelmann ha identificato un picco di produttiivtà quando la dimensione di un team è parti a 5 persone.

Jennifer Mueller, Assistant professor di Management all’Università della Pensilvenia, indica più in generale che “Se facciamo gruppi troppo grandi, saranno le persone stesse a farne di più piccoli. Formando delle cricche”.

Parere interessante è di Jeff Bezos, CEO di Amazon.com, che indica la “Regola delle due pizze”, meglio conosciuta come “Two-pizza rule”, se ad un team non puoi dar da mangiare con due pizze, allora è troppo grande.

Relativamente ai framework agili, ognuno propone direttive sulla dimensione di un team.

Dimensione di un Team Scrum

In Scrum i team sono auto-gestiti ed interfuznionali. La Scrum Guide indica che la dimensione ottimale di un Team di Sviluppo deve essere abbastanza piccola per rimanere agile e abbastanza grande per avere le competenze necessarie. Un Team di Sviluppo composto da meno di tre persone può avere problemi relativamente alle competenze necessarie, un team composto da più di nove persone invece può incorrere in problematiche di coordinamento. Questi numeri escludono il Product Owner e lo Scrum Master, a meno che non facciano anche parte del Team di Sviluppo.

Dimensione di un Team DSDM® o Agile Project Management®

In DSDM® Atern® e Agile Project Management® sono presenta due principi relativi al team “Collaborate” e “Communicate continuously and clearly“. Il Solution Development Team è interfunzionale: sono previsti diversi ruoli, e una persona può ricoprire più ruoli. La dimensione ottimale è di 7 +/- 2 persone. Se non è possibile avere la dimensione ottimale va trattato come un rischio, quindi registrato nel Risk Register. Se i team sono più piccoli allora va gestita l’eventualità che non si riesca a consegnare in tempo, ad es. in caso di assenza di una persona. Se i team sono più grandi allora si presenta è possibile che ci siano problemi di comunicazione. In caso di team troppo grandi, DSDM® Atern e Agile Project Management® consigliano infatti di dividere il team in team più piccoli, così da ottimizzare i rischi.

E’ interessante notare che questa direttiva corrisponde alla nota Legge di Miller del 1956 dove viene indicato che i chunk di informazioni processabili dalle persone sono “Cinque più o meno due”.

Riferimenti

Scroll to Top