Tuttavia, quando Jeff e il suo capo, il CIO Chad Fulgham,

analizzarono il piano nella primavera del 2010, lo conoscevano per

quello che era, per quello che tutti i diagrammi di questo tipo sono:
una pura invenzione. Quando i due uomini iniziarono a esaminare lo
stato di realizzazione e le cose che potevano effettivamente essere
considerate consegnabili, si resero conto che il problema non poteva
essere risolto. I nuovi difetti del software emergevano più
velocemente di quanto non venissero risolti quelli vecchi.
Chad disse all’ufficio dell’Ispettore generale del Dipartimento della
giustizia che avrebbero potuto completare il progetto Sentinel
riportando in casa lo sviluppo, tagliando il numero degli sviluppatori e
che, in questo modo, avrebbero completato la metà più difficile del
progetto in meno di un quinto del tempo e con meno di un decimo
della cifra stanziata. Lo scetticismo presente nei report dell’Ispettore
generale al governo – che sono già per definizione asciutti – è
palpabile. Nel report dell’ottobre del 2010, dopo aver delineato quelli
che per loro erano i nove punti critici della proposta, i cani da guardia
dell’Ispettorato generale concludevano: “In definitiva, nutriamo
significative preoccupazioni e interrogativi sulla capacità di questo
nuovo approccio di completare il progetto Sentinel restando nel
budget, in modo tempestivo e con funzionalità simili…”2.

UN NUOVO MODO DI PENSARE

Il nuovo approccio si chiama Scrum. L’ho creato venti anni fa. Oggi è
l’unica via certa per aiutare progetti di questo tipo. Ci sono due modi
per fare le cose: il vecchio metodo “a cascata” che spreca centinaia di
milioni e non ottiene nulla, oppure quello nuovo, con il quale, con
meno gente e in minor tempo, si possono realizzare più cose di qualità
migliore e a costi inferiori. So che sembra troppo bello per essere vero,
ma la prova sta nei risultati. Funziona.
Venti anni fa ero disperato. Avevo bisogno di un nuovo modo di
pensare al lavoro. Attraverso tonnellate di ricerche e di esperimenti e
rianalizzando i dati passati mi sono reso conto che avevamo tutti
bisogno di un nuovo modo di organizzare lo sforzo umano. Niente di
trascendentale, se ne è già parlato. Esistono studi risalenti alla
seconda guerra mondiale che delineano alcuni dei modi migliori con
cui lavorano le persone, ma per qualche ragione nessuno ha mai
messo insieme i pezzi. Negli ultimi due decenni ho tentato di fare
proprio questo, e ora questa metodologia è diventata onnipresente nel
primo campo in cui l’ho applicata: lo sviluppo del software. In giganti
del calibro di Google, Amazon e Salesforce.com, e in piccole start-up di
cui non avete ancora sentito parlare, questo framework ha
radicalmente cambiato il modo in cui le persone fanno le cose.
Il motivo per cui questo framework funziona è semplice. Ho
osservato come le persone lavorano veramente, e non come dicono di
lavorare. Ho analizzato le ricerche svolte nel corso dei decenni e le
best practice in aziende di tutto il mondo, e ho osservato attentamente
i migliori team all’interno di queste. Che cosa li ha resi superiori? Che
cosa li ha resi diversi? Perché alcuni team raggiungono la grandezza e
altri la mediocrità ?
Per ragioni che illustrerò nei prossimi capitoli, ho chiamato questo
framework per la performance del team “Scrum” (mischia, n.d.t.). Il
termine viene dal rugby e si riferisce al modo in cui il team lavora
collettivamente per muovere la palla sul campo. Allineamento
scrupoloso, unità di intento e chiarezza dell’obiettivo viaggiano
insieme. È una metafora perfetta di quello che io voglio che facciano i
team.
Per tradizione, i manager vogliono due cose da qualsiasi progetto:
controllo e prevedibilità . Ciò conduce a un gran numero di documenti,
grafici e diagrammi, proprio come in Lockheed. Mesi di sforzi per
pianificare ogni dettaglio, quindi non ci saranno errori, sforamenti di
costi e le cose saranno consegnate secondo calendario.
Il problema è che questo scenario roseo non si dispiega mai
veramente: tutti gli sforzi riversati nella pianificazione, tentando di
restringere il cambiamento – di conoscere l’inconoscibile – vanno
sprecati. Ogni progetto comporta scoperta di problemi ed esplosione
di ispirazione. Ogni tentativo di restringere uno sforzo umano di
qualsiasi ampiezza a grafici e diagrammi con codifiche colorate è
sciocco e destinato al fallimento. Questo non è il modo in cui lavorano
le persone, e non è il modo in cui i progetti progrediscono. Non è il
modo in cui le grandi idee diventano fruibili o vengono realizzate le
grandi cose.
 Al contrario, produce persone frustrate che non ottengono ciò che
desiderano. I progetti vengono ritardati, il budget sforato e, in troppi
casi, finiscono in fallimenti disastrosi. Ciò è specialmente vero per i
team coinvolti nel lavoro creativo di realizzare qualcosa di nuovo.
Nella maggior parte dei casi, il management non impara la via dorata
verso il fallimento finché milioni di dollari e migliaia di ore non
vengono investiti vanamente.
Scrum si interroga sul perché ci vogliono così tanto tempo e sforzi
per fare le cose, e sul perché siamo così incapaci di stimare quanto
tempo e quanti sforzi ci vorranno. La cattedrale di Chartres ha
richiesto cinquantasette anni di lavoro per essere completata.
Scommetterei che all’inizio del progetto i capomastri hanno guardato
il vescovo e gli hanno detto: “Vent’anni al massimo, probabilmente ce
la facciamo in quindici”.
Scrum coglie l’incertezza e la creatività . Definisce una struttura
intorno al processo di apprendimento, mettendo i team in grado di
valutare sia quello che hanno creato sia – altrettanto importante – il
modo in cui l’hanno fatto. Il framework Scrum incanala il modo in cui
il team lavora veramente e gli fornisce gli strumenti per
autorganizzarsi e migliorare rapidamente velocità e qualità del lavoro.
Nella sua essenza, Scrum si basa su un’idea semplice: ogni volta
che avviate un progetto, perché non controllarlo regolarmente,