olossali errori manageriali da cui è derivata la spaventosa crisi

economica con cui stiamo facendo ancora i conti. In molte aziende, le

azioni si basavano unicamente sul vantaggio personale di breve
termine. Non si prendeva minimamente in considerazione ciò che
poteva andare a beneficio di tutti, o l’idea di limitare il danno
all’economia globale.

LA DIMENSIONE CONTA DAVVERO, MA NON NEL MODO CHE CREDETE VOI

Per il solo fatto che l’interfunzionalità può produrre grandi risultati,

però , non dovreste imitare Noè e mettere in un team due
rappresentanti di ciascun reparto. La dinamica positiva che abbiamo
illustrato nel paragrafo precedente funziona bene solo in piccoli team.
Il numero ottimale è sette persone, più o meno due, anche se ho visto
team di sole tre persone funzionare alla grande. La cosa affascinante è
che, dati alla mano, se i componenti sono più di nove, la velocità
operativa del team diminuisce. Proprio così: più risorse lo fanno
andare più piano.
Nello sviluppo del software si cita spesso la “legge di Brooks”,
formulata da Fred Brooks nel lontano 1975 nel suo influente libro The
Mythical Man-Month. In poche parole, la legge di Brooks afferma che
“aggiungendo personale a un progetto software in ritardo lo si fa
ritardare ulteriormente”8. Lo hanno confermato numerosi studi.
Lawrence Putnam è una figura leggendaria in questo campo, un uomo
che ha dedicato la vita a studiare quanto tempo ci si mette a fare le
cose e perché. Il suo lavoro ha dimostrato costantemente che i progetti
su cui operavano 20 o più persone assorbivano più risorse di quelli su
cui ne operavano cinque o sei. Non un po’ di più , ma molte di più . Un
team numeroso impiegava circa il quintuplo delle ore, rispetto a un
team ristretto. Lo riscontrava in continuazione, e a metà degli anni
Novanta ha deciso di condurre uno studio estensivo per stabilire qual
è la dimensione ottimale del team. Perciò ha esaminato 491 progetti di
media complessità , sviluppati in centinaia di aziende. Erano tutti
progetti che richiedevano la creazione di nuovi prodotti o di nuove
caratteristiche, e non l’aggiornamento di versioni precedenti. Ha
diviso i progetti per dimensione del team e ha notato immediatamente
una cosa: quando i team superavano gli otto membri, ci mettevano
molto più tempo a fare le cose. I gruppi composti da un minimo di tre a
un massimo di sette persone richiedevano circa il 25% dell’impegno
lavorativo rispetto ai gruppi composti da un minimo di nove a un
massimo di venti individui, per fare esattamente la stessa mole di
lavoro. Questo risultato si riscontrava in centinaia e centinaia di
progetti. Che i gruppi pletorici facciano di meno sembra essere una
regola ferrea della natura umana.
Ma perché? Per rispondere a questa domanda, dobbiamo prendere
in esame i limiti del cervello umano. Probabilmente avete sentito
parlare del celebre studio di George Miller nel 1956, da cui risultava
che il numero massimo di cifre conservabili nella memoria di breve
termine di una persona media è sette. Probabilmente è per questo che
i numeri telefonici sono di sette cifre. Il problema del lavoro di Miller è
che ricerche successive l’hanno sconfessato.
Nel 2009, Nelson Cowan della University of Missouri si è
domandato se quella regola magica del sette fosse vera e ha svolto una
vasta indagine su tutte le nuove ricerche condotte in argomento. Ha
scoperto così che il numero massimo di cifre che si possono
conservare nella memoria di breve termine non è sette, ma quattro 9.
La gente pensa spesso di poterne memorizzare di più , usando un
supporto mnemonico o solo concentrandosi maggiormente. Però le
ricerche dimostrano chiaramente che siamo in grado di ricordare solo
quattro “blocchi” di dati. Il tipico esempio è questa serie di 12 lettere:
fbicbsibmirs. Di solito la gente riesce a ricordarne solo quattro, se non
si rende conto che si può suddividere in quattro noti acronimi: FBI;
CBS, IBM, IRS. Se riuscite a collegare gli elementi contenuti nella
vostra memoria di breve termine a degli elementi di lungo termine,
potete ricordarne di più . Ma la parte della mente in grado di
focalizzarsi – la parte conscia – può ricordare solo quattro “blocchi” di
dati alla volta.
Dunque c’è un limite strutturale alle informazioni che il nostro
cervello può trattenere. Questa constatazione ci riporta al libro di
Brooks. Quando ha cercato di capire perché mettendo più persone a
lavorare su un progetto i tempi si dilatano enormemente, ha scoperto
che le ragioni sono due. La prima è il tempo che occorre per portare
tutti al massimo livello di efficienza. Come si può immaginare, portare
a regime una nuova persona vuol dire rallentare temporaneamente il
lavoro di tutte le altre. La seconda ragione non ha a che fare solo con il
nostro approccio mentale, ma anche – letteralmente – con la capacità
fisica del nostro cervello. Il numero dei canali di comunicazione
aumenta sensibilmente al crescere del numero di persone, e il nostro
cervello non riesce proprio a gestirli.
Se volete calcolare l’impatto della dimensione del gruppo,
prendete il numero dei componenti di un team, moltiplicatelo per
“quel numero diminuito di un’unità ” e dividete risultato per due:
Canali di comunicazione = n (n – 1)/2.

Così, per esempio, se le persone sono cinque, avrete 10 canali. Se

sono sei ne avrete 15. Se sono sette ne avrete 21. Se sono otto ne
avrete 28. Se sono nove ne avrete 36. E se sono 10 ne avrete 45. Il
nostro cervello non è materialmente in grado di interagire
contemporaneamente con tutte quelle persone. Non sappiamo cosa
sta facendo ognuna di loro. E nel tentativo di capirlo rallentiamo la
nostra attività .
Proprio come accade in un team delle forze speciali, tutti i membri
di un team di Scrum devono sapere cosa stanno facendo tutti gli altri. I
progetti in corso, le difficoltà incontrate, i progressi compiuti, devono
essere conosciuti da tutti. E se il team diventa troppo numeroso, la
capacità di ogni membro di comunicare chiaramente con tutti gli altri,
in ogni momento, ne risente molto. Ci sono troppe correnti trasversali.
In molti casi, il team si divide – socialmente e funzionalmente – in
sottoteam che iniziano a lavorare in maniera disorganizzata.
L’interfunzionalità viene meno; riunioni che prima duravano pochi
minuti si protraggono per ore.
Non fatelo. Tenete il vostro team ai minimi termini.

LO SCRUM MASTER

Al mio primo team Scrum facevo vedere regolarmente un video degli

All Blacks che si preparavano per una gara. Gli All Blacks, mitica
squadra di rugby di un piccolo paese, la Nuova Zelanda, sono un team
trascendente. Prima di scendere in campo si esibiscono nell’haka, la
danza di guerra dei maori che serve a caricare le persone prima della
battaglia. Assistendo a quella performance, sembra quasi di vedere
l’energia dei singoli giocatori sprizzare fuori per fondersi in un tutto
più grande. Con quei passi sincronizzati, accompagnati dal battere
delle mani e da un urlo di guerra – movimenti ritualizzati che
simulano il taglio della gola di un nemico – degli uomini comuni si
trasformano in qualcosa di più grande, in senso fisico e spirituale.
Invocano uno spirito guerriero che non accetta la sconfitta o lo
sconforto.
C’è voluta qualche replica del video, ma alla fine i miei
programmatori un po’ fuori forma hanno cominciato a chiedersi come
emulare gli All Blacks. Hanno identificato quattro cose da imitare. La
prima era una grandissima focalizzazione sull’obiettivo, sostenuta e
rafforzata dal canto. La seconda era una collaborazione totale: braccia
e corpi intrecciati nel perseguimento dello stesso obiettivo. La terza
era la fame di vittoria – al di là di qualunque ostacolo. La quarta era
un’eccitazione universale per ogni azione di sfondamento. Non
contava chi fosse il giocatore: l’azione in sé era motivo di celebrazione.
Abbiamo creato perciò questo schema di riunioni Sprint e Daily S