iagrammi di Gantt hai visto nella tua carriera?” gli chiesi.

“Centinaia” rispose.
“Quanti erano corretti?”.
Fece una pausa. “Nessuno”.
A quel punto gli dissi che alla fine del mese gli avrei consegnato del
software funzionante invece di un diagramma di Gantt disatteso.
Avrebbe potuto controllare personalmente e vedere se eravamo sulla
strada giusta. Dovevamo provarci, se volevamo centrare la nostra
deadline.
Io e il mio team trascorremmo diverse settimane a leggere
centinaia di articoli e libri sull’organizzazione dei team e sullo
sviluppo di prodotto. Poi un giorno uno sviluppatore arrivò con un
articolo della Harvard Business Review del 1986, scritto da due
professori di business giapponesi: Hirotaka Takeuchi e Ikujiro Nonaka.
Si intitolava “The New New Product Development Game”. Takeuchi e
Nonaka avevano studiato i team di alcune delle società più produttive
e innovative del mondo tra cui Honda, Fuji-Xerox, 3M e Hewlett-
Packard. I due sostenevano che il vecchio sistema per lo sviluppo di
prodotto – esemplificato dal Phased Program Planning della NASA, un
sistema a cascata – era fondamentalmente difettoso. Al contrario, le
migliori società utilizzavano un processo di sviluppo sovrapposto che
era più veloce e flessibile. I team erano trasversali. Godevano di
autonomia. Avevano il potere di prendere le loro decisioni. E avevano
uno scopo superiore, stavano puntando a qualcosa di più grande di
loro stessi. Il management non dettava legge, ma al contrario i
dirigenti erano leader-servitori e facilitatori, concentrati più
sull’eliminazione degli ostacoli sulla strada dei team che nel dire loro
che cosa dovevano fare. I professori giapponesi paragonavano il
lavoro dei team a quello di una squadra di rugby e affermavano che i
migliori agivano come se si trovassero in una mischia: “… la palla
viene passata all’interno del team mentre questo si muove come
un’entità unica sul campo”1.
L’articolo di Takeuchi e Nonaka ricevette molta attenzione quando
venne pubblicato, ma ciò era accaduto sette anni prima che lo
leggessimo in Easel. Tutti lo avevano ammirato, ma nessuno lo aveva
utilizzato. Il manager medio americano era incapace di trarne un
senso, sebbene Toyota stesse rapidamente accrescendo la propria
quota di mercato utilizzando questo approccio. In Easel non avevamo
niente da perdere. Decidemmo di provarci, nonostante l’articolo si
concentrasse sulla produzione di beni materiali e non sullo sviluppo
del software. Pensai che le loro idee centravano un elemento
fondamentale, una descrizione di come gli uomini lavoravano insieme
al meglio in ogni tipo di sforzo. Essa si inseriva in tutti gli esperimenti
che avevo condotto, sin dal mio primo lavoro nel settore privato in
MidContinent.
Questa fu la nascita formale di Scrum. Consegnammo il prodotto a
Easel nel tempo previsto di sei mesi, risparmiando sul budget e con
meno bug di ogni altra consegna precedente.
Fui così coinvolto dalle possibilità di questa nuova forma di project
management che tutto il mio lavoro successivo si concentrò sulla
rifinitura di Scrum per le aziende. Nel 1995, a una conferenza di studio
della Association for Computing Machinery, presentai un articolo
insieme a Ken Schwaber intitolato “SCRUM Development Process” che
codificava queste pratiche. Da allora abbiamo tolto qualche maiuscola
e modificato leggermente l’idea, ma i principi fondamentali sono gli
stessi, e le società che adottano il processo di solito riscontrano
benefici immediati2.

ISPEZIONA E ADATTA

I team Scrum che lavorano bene sono in grado di raggiungere quella

che chiamiamo “iperproduttività ”. È difficile da credere, ma tra i
gruppi che implementano bene Scrum assistiamo a incrementi della
produttività tra il 300 e il 400%. I migliori team possono raggiungere
incrementi di produttività dell’ordine dell’800% e replicare il successo
indefinitamente. Inoltre finiscono per migliorare più del doppio la
qualità del loro lavoro.
Quindi, in che modo costruire l’autonomia, la trascendenza e la
fertilizzazione incrociata in un team Scrum e da quella combinazione
ottenere l’iperproduttività ? Bene, il resto del libro parla proprio di
questo, ma qui intendo tracciare la struttura fondamentale. Potete
trovarla descritta in breve anche nell’Appendice.
Dato che Scrum deriva dalle tecniche utilizzate nella manifattura
giapponese, può essere utile imparare qualcosa sul dove i giapponesi
le hanno imparate a loro volta. Curiosamente, ne hanno imparate
molte da un americano: W. Edwards Deming. Deming aveva lavorato
per il generale Douglas MacArthur durante l’occupazione americana
del Giappone appena dopo la seconda guerra mondiale. L’approccio di
MacArthur alla ricostruzione del sistema economico consistette nel
licenziare la maggior parte del senior management delle aziende
giapponesi, nel promuovere i manager di linea provenienti dai ranghi
di queste e nel portare dagli Stati Uniti esperti di business operations
come Deming. L’influenza di quest’ultimo sulla manifattura
giapponese fu eclatante. Addestrò centinaia di ingegneri in quello che
viene definito “controllo statistico di processo”. L’idea fondamentale è
quella di misurare esattamente ciò che si fa, e quanto bene, e di
sforzarsi verso il “miglioramento continuo”. Non solo fare meglio una
volta, ma in modo costante. Cercare sempre qualcosa da migliorare.
Non essere mai soddisfatti del punto in cui si è arrivati. Il modo per
riuscirci è creare continuamente degli esperimenti per verificare se è
possibile migliorare. Se provo questo metodo sarà meglio? E questo? E
se cambiassi solo questa cosa?
Nel 1950 Deming tenne un discorso davanti agli uomini di
business più importanti del Giappone che è diventato famoso. Tra il
pubblico c’erano personaggi del calibro di Akio Morita, fondatore di
Sony. In quell’occasione Deming disse:
… non importa quanto siano bravi i vostri tecnici, se volete che loro siano in
grado di apportare miglioramenti voi che siete i leader dovete sforzarvi di
migliorare la qualità e l’uniformità del prodotto. Il primo passo, dunque, è
del management. Per prima cosa, i tecnici della vostra società devono
sapere che avete una passione per il miglioramento della qualità e
dell’uniformità del prodotto e che vi sentite responsabili per la qualità del
prodotto. Non otterrete nulla se vi limitate a parlarne. L’azione è
importante3.

Lo strumento per agire – e probabilmente la cosa per cui Deming è

più famoso – è il cosiddetto “ciclo PDCA” (Plan, Do, Check, Act). Potete
applicarlo per produrre praticamente qualsiasi cosa, dalla macchina al
videogame, e perfino un aeroplano di carta.
Quando insegno alla gente come utilizzare Scrum è proprio questo
che uso: un aeroplano di carta. Divido le persone in team e dico loro
che l’obiettivo è costruire quanti più aeroplani è possibile che riescano
a volare nella stanza. Ci saranno tre ruoli nel team: una persona
controllerà quanti aeroplani riescono veramente a volare; un’altra farà
parte del processo di produzione ma farà anche attenzione al processo
stesso, cercando di capire in che modo il team può realizzare aeroplani
migliori o velocizzare la produzione. Tutti gli altri si concentreranno
sul costruire nel tempo consentito più aeroplani possibile che possano
veramente volare.
Poi comunico che ci saranno tre cicli da sei minuti di costruzione
degli aerei di carta. I team hanno un minuto per ogni ciclo per
pianificare come intendono costruire gli aerei (Plan) e tre minuti per
realizzarne quanti più possibile e verificare che possano veramente
volare (Do). E infine hanno due minuti per il controllo (Check). In
questa fase il team cerca di capire come migliorare il processo di
costruzione. Che cosa ha funzionato? Che cosa è andato storto? Il
progetto dovrebbe essere cambiato? In che modo si potrebbe
migliorarlo? E poi agisce (Act). Nel mondo di Deming, “agire” significa
cambiare il proprio modo di lavorare basandosi su risultati concreti e
su input reali provenienti dall’ambiente. È la stessa strategia usata dal
robot di Brook.
Ripetete questo ciclo tre volte e – che costruiate aeroplani di carta
o vere astronavi – migliorerete, in modo significativo (nell’ordine di
due o tre volte più veloci e almeno il doppio nella qualità ). Il ciclo
PDCA, un’idea rivoluzionaria quando Deming la espose ai giapponesi,
è lo strumento grazie al quale Toyota è diventata la prima casa
automobilistica al mondo. Ed è il modo in cui viene realizzato qualsiasi
tipo di produzione “lean” (il termine americano con cui si definisce il
Toyota Production System) o sviluppo di prodotto secondo Scrum.

CAMBIARE O MORIRE

Parte della ra