Fare il doppio in metà tempo

Puntare al successo con il metodo Scrum

Jeff Sutherland

• Éditeur: RIZZOLI
• Année: 2015
• ISBN:
  9788858676820
• Sujet: Desarrollo personal
• Sous-sujet: Éxito personal

È molto difficile, e lo proviamo tutti i giorni, fare le cose rapidamente e con efficienza. Spesso i piani migliori sulla carta vanno storti, i team lavorano su obiettivi che si sovrappongono, la pressione conduce a errori e perdite rilevanti. La frustrazione schizza in alto, i risultati non vengono raggiunti. Per ovviare a tutto ciò, la soluzione è in un metodo nato nel settore dello sviluppo software e poi propagatosi a macchia d'olio: si chiama "Scrum" (dal termine inglese che indica la mischia nel rugby) ed è la strategia del futuro per la formazione dei team, l'incremento della produttività (anzi, dell'iperproduttività, secondo chi lo usa) e il raggiungimento degli obiettivi. Basato su uno "schema di gioco" semplice e chiaro, al cui centro sta un leader-facilitatore, prevede un'organizzazione del lavoro in cicli brevi, regolati dal gruppo di persone coinvolte, ed è per questo adatto a ogni tipo di realtà, anche fuori dal business (c'è già chi lo usa nella gestione della propria famiglia, e le applicazioni sono potenzialmente infinite). In questo libro lo presenta il suo ideatore, Jeff Sutherland, pilota da caccia, esperto di biometrica e innovatore tecnologico che ha creato il primo team Scrum più di 20 anni fa. Adottato da molte delle più importanti aziende in Italia e a livello mondiale - da Amazon a Google, da Apple a Ferrari, fino a realtà anche di piccole dimensioni - Scrum è il metodo giusto per i tempi che corrono: ottimizza le risorse, evita gli sprechi e valorizza al massimo il talento delle persone.

1
Il mondo non funziona più come una volta

Jeff Johnson era abbastanza sicuro che non sarebbe stata una buona giornata. Il 3 marzo 2010 il Federal Bureau of Investigation chiuse il suo progetto di modernizzazione più grande e ambizioso, quello che avrebbe dovuto prevenire un altro 11 settembre ma che si era trasformato in uno dei più grandi fallimenti software di tutti i tempi. Per più di un decennio l’FBI aveva tentato di aggiornare il suo sistema informatico, e a quanto pareva avrebbe fallito. Ancora. E ora si trattava della sua creatura.

Era arrivato all’FBI sette mesi prima, convinto dal nuovo Chief Information Officer, Chad Fulgham, con cui aveva lavorato in Lehman Brothers. Jeff era Assitant Director della divisione IT Engineering e aveva un ufficio all’ultimo piano del J. Edgar Hoover Building a Washington, DC. Era un ufficio grande, aveva persino una vista sul Monumento a Washington. Jeff non aveva idea che sarebbe finito in un cubicolo senza finestre nel seminterrato per la maggior parte dei successivi due anni, tentando di far funzionare qualcosa che tutti affermavano fosse impossibile da aggiustare.

“Non è stata una decisione facile” afferma. Lui e il suo capo decisero di dichiararsi sconfitti e chiudere un programma che aveva già richiesto quasi un decennio ed era costato centinaia di milioni di dollari. A quel punto, aveva più senso portarlo in casa e farlo da soli. “Ma doveva essere fatto e fatto bene”.

Il progetto riguardava il tanto atteso sistema computerizzato che avrebbe portato l’FBI nell’era attuale. Nel 2010 – al tempo di Facebook, Twitter, Amazon e Google – l’FBI stava ancora archiviando la maggior parte dei suoi rapporti su carta. Il sistema informatico utilizzato era chiamato Automated Case Support e girava su giganteschi computer mainframe che costituivano lo stato dell’arte in qualche momento degli anni Ottanta. Molti agenti speciali non lo usavano neanche: era troppo scomodo e troppo lento in un’epoca di attacchi terroristici e di criminali che si muovevano veloci.

Quando un agente dell’FBI voleva fare qualcosa – ogni cosa in realtà – dal pagare un informatore a inseguire un terrorista ad archiviare un rapporto su una rapina in banca, il procedimento non era tanto diverso da quello di trent’anni prima. Johnson lo descrive in questo modo: “Dovevate scrivere un documento con un word processor e poi stamparlo in tre copie. Una sarebbe finita nella catena di approvazione; una sarebbe stata archiviata localmente nel caso che le altre andassero perse. Con la terza dovevate prendere una penna rossa – non sto scherzando, una penna rossa – e cerchiare le parole chiave da inserire nel database. Dovevate indicizzare i vostri rapporti”.

Quando una richiesta veniva approvata, la copia su carta ritornava dai piani alti con sopra un numero. Un numero stampato su un pezzo di carta è il modo in cui l’FBI teneva traccia di tutti i suoi casi. Questo metodo era così antiquato e farraginoso da essere stato incolpato almeno in parte dell’incapacità del Bureau di “unire i puntini” che indicavano che vari attivisti di AlQaeda erano entrati nel paese alcune settimane e mesi prima del settembre 2001. Un ufficio sospettava una certa persona. Un altro si domandava come mai così tanti stranieri sospetti stavano prendendo lezioni di volo. Un altro aveva qualcuno su una lista di osservazione ma non lo aveva mai detto a nessun altro. Nessuno nel Bureau aveva messo insieme tutte queste informazioni.

La Commissione sull’11 settembre aveva indagato attentamente dopo l’attacco e aveva tentato di scoprire le ragioni profonde del perché era stato consentito che accadesse. Gli analisti, affermò, non avevano potuto accedere alle informazioni che si supponeva dovessero analizzare. “Lo stato disastroso del sistema informatico dell’FBI” recita il rapporto “ha comportato che tale accesso dipendesse in gran parte dalle relazioni personali di un analista con i singoli nelle unità operative o nelle squadre dove si trovavano le informazioni”.

Prima dell’11 settembre, l’FBI non aveva mai portato a termine una valutazione della minaccia terroristica complessiva nei confronti degli Stati Uniti. Esistevano molte ragioni per questa situazione, che andavano dal focus sugli avanzamenti di carriera alla mancanza di condivisione delle informazioni, tuttavia il rapporto identificò nell’assenza di sofisticazione tecnologica quella che era probabilmente la ragione principale per cui l’FBI aveva fallito in modo così drammatico nei giorni che condussero all’11 settembre. “Il sistema informatico dell’FBI era deplorevolmente inadeguato” conclude il rapporto della Commissione. “L’FBI mancava della capacità di sapere ciò che sapeva: non esisteva un meccanismo efficiente per catturare o condividere la sua conoscenza istituzionale”.

Quando i senatori che componevano la Commissione cominciarono a fare domande scomode, in pratica l’FBI rispose: “Tranquilli, abbiamo già avviato un piano di modernizzazione”. Il piano si chiamava Virtual Case File e si supponeva che avrebbe cambiato tutto. Per trarre il massimo dalla situazione, i funzionari affermarono di aver bisogno solo di altri 70 milioni di dollari in più rispetto ai 100 già a budget per il piano. Se rileggete la stampa del tempo sul VCF, noterete che le parole rivoluzionario e trasformazione si sprecavano.

Tre anni dopo il programma venne chiuso. Non funzionava. Neanche un pochino. L’FBI aveva speso 170 milioni di dollari dei contribuenti per acquistare un sistema informatico che non sarebbe mai stato usato: né una sola linea di codice, un’applicazione o un click di mouse. L’intero piano era un disastro assoluto. E non era come quando IBM o Microsoft commettono un errore: qui, letteralmente, era in gioco la vita della gente. Come disse al Washington Post il senatore del Vermont Patrick Leahy, allora rappresentante Democratico nel Senate Judiciary Committee (una commissione d’inchiesta del Senato degli Stati Uniti, n.d.t.):

Avevamo delle informazioni che avrebbero potuto fermare l’11 settembre. C’eravamo seduti sopra e non abbiamo fatto nulla… Non li ho visti correggere il problema… Potremmo arrivare al XXII secolo prima di ottenere la tecnologia del XXI¹.

Non vale neanche la pena di dire che le persone che erano nell’FBI quando avvenne il disastro del Virtual Case File non lavorano più lì.

Nel 2005 l’FBI annunciò un nuovo programma: Sentinel. Questa volta avrebbe funzionato. Stavolta avrebbero messo in opera le salvaguardie appropriate, le procedure di budget giuste, i controlli adeguati. Avevano imparato la lezione. Il prezzo: solo 541 milioni di dollari. E sarebbe stato pienamente operativo a partire dal 2009.

Che cosa poteva andare storto? Nel marzo del 2010 la risposta atterrò sulla scrivania di Jeff Johnson. Lockheed Martin, l’appaltatore incaricato di realizzare il sistema Sentinel, aveva già speso 405 milioni di dollari. Aveva sviluppato solo metà del progetto ed era già in ritardo di un anno. Un’analisi indipendente stimò che per portarlo a termine occorreva un periodo tra sei e otto anni, e i contribuenti avrebbero dovuto sborsare almeno altri 350 milioni.

Il problema di Johnson era trovare una via per aggirare questo ostacolo.

Che cosa era andato storto e come questa situazione venne risolta sono l’argomento di questo libro. Non è che non fossero persone capaci, né che il Bureau non avesse messo il personale giusto al posto giusto, o non disponesse della tecnologia adeguata. Non era una questione di etica del lavoro o dell’adeguata somministrazione di stimoli competitivi.

Era a causa del modo in cui lavoravano le persone. La maggior parte delle persone. Il modo in cui tutti pensiamo che il lavoro debba essere svolto, perché è il modo che ci è stato insegnato.

Quando sentite quello che è accaduto, di primo acchito sembra sensato: prima di fare un’offerta per l’appalto, la gente di Lockheed si è seduta a un tavolo, ha analizzato le specifiche, e ha iniziato a pensare a come costruire un sistema che facesse tutte quelle cose. Hanno impiegato un gran numero di persone intelligenti per mesi a immaginare che cosa andava fatto. Poi hanno speso altri mesi a pianificare come farlo. Hanno realizzato dei grafici bellissimi che mostravano tutto quello che andava realizzato e il tempo che occorreva per ciascuna fase. Poi, con un’attenta scelta di colori, hanno collegato ogni fase del progetto a quella successiva, come se fosse una cascata.

Il metodo a cascata

Questo genere di grafici è detto “diagramma di Gantt”, dal nome del loro inventore: Henry Gantt. Con l’avvento del personal computer negli anni Ottanta, che ha reso molto facile creare questi grafici complicati – e renderli veramente complessi – sono diventati una vera opera d’arte. Ogni singolo passo del progetto è descritto in dettaglio. Ogni milestone. Ogni data di consegna. Questi grafici sono veramente impressionanti alla vista. Il vero problema è che sono sempre – sempre – sbagliati.

Henry Gantt inventò i suoi famosi diagrammi più o meno nel 1910. Furono usati per la prima volta durante la Grande guerra dal generale William Crozier, che allora dirigeva gli approvvigionamenti per l’esercito americano. Chiunque abbia studiato quel conflitto sa che allora l’efficienza organizzativa non era proprio una caratteristica saliente. Il perché un artefatto della prima guerra mondiale sia diventato uno strumento fondamentale del project management del XXI secolo resta per me un mistero. Abbiamo abbandonato la guerra di trincea, ma in qualche modo le idee che l’avevano organizzata sono ancora popolari.

È proprio una grande tentazione: tutto il lavoro che deve essere fatto in un grande progetto delineato in modo che tutti lo possano vedere. Ho visitato così tante società in cui c’erano persone il cui unico lavoro era aggiornare i diagrammi di Gantt ogni giorno. Il guaio è che quando quel piano splendido ed elegante incontra la realtà crolla. Invece di cancellare il piano, però, oppure di cambiare il modo in cui lo immaginano, i manager assumono persone per fare in modo che sembri funzionante. In pratica, pagano delle persone per farsi raccontare bugie.

Questo modello sfortunato riecheggia quei rapporti che il Politburo sovietico riceveva negli anni Ottanta, poco prima del collasso dell’URSS. Un miraggio assoluto. Oggi come allora, i report diventano più importanti della realtà che dovrebbero descrivere, e se esiste una discrepanza il problema è la realtà, e non i diagrammi.

Quando ero un cadetto di West Point, dormivo nella vecchia stanza di Dwight Eisenhower. Di notte le luci della strada si riflettevano su una targa dorata affissa sulla mensola del camino e qualche volta mi svegliavano. La targa diceva “Dwight D. Eisenhower ha dormito qui”. E io ricordavo che una volta Eisenhower aveva osservato che i piani per il combattimento sono importanti, ma non appena viene sparato il primo colpo si dissolvono in fumo. Perlomeno aveva abbastanza buon senso da non usare un diagramma di Gantt.

Quindi Lockheed presentò all’FBI tutti questi diagrammi carini, e il Bureau firmò. Si può immaginare che il lavoro fosse così ben pianificato che nulla poteva andare storto. “Guarda, è nel piano: tutto codificato con i colori, i tempi e le barre”.

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…”².

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 c...