verificare se andate nella direzione giusta e se è veramente ciò che

le persone vogliono? E controllare se ci sono modi di migliorare come

fate ciò che fate, per farlo meglio e più velocemente, e che cosa
potrebbe ostacolarvi dal farlo.
È quello che viene definito il ciclo “ispeziona e adatta”. A brevi
intervalli, fermatevi e rivedete quello che avete fatto, controllate se è
ancora quello che dovreste fare e come potreste farlo meglio. È un’idea
semplice, ma applicarla richiede riflessione, introspezione, onestà e
disciplina. Scrivo questo libro per mostrarvi come farlo. E non solo
nelle software company. Ho visto utilizzare con successo Scrum per
costruire automobili, dirigere una lavanderia, insegnare in classe,
costruire razzi spaziali, pianificare un matrimonio e persino, come ha
fatto mia moglie, per assicurarsi che ogni weekend io porti a termine i
compiti che mi assegna.
Il risultato finale di Scrum – l’obiettivo di progettazione, se
vogliamo – sono team che migliorano drasticamente la produttività .
Negli ultimi vent’anni ho costruito team di questo genere
ripetutamente. Sono stato il CEO, il CTO o il responsabile
dell’engineering di dozzine di società , da piccole start-up con poche
persone in una sola stanza a grandi imprese con uffici sparsi su tutto il
pianeta. Ho fatto da consulente e da coach in centinaia di altre ancora.
I risultati sono stati così eclatanti che ormai grandi imprese di
ricerca e analisi come Gartner, Forrester Research e Standish Group
dichiarano che il vecchio stile di lavoro è obsoleto. Le imprese che si
attengono alle vecchie, ma false, idee di comando e controllo per
imporre una rigida prevedibilità sono semplicemente destinate a
fallire se i loro concorrenti utilizzano Scrum. La differenza è troppo
grande. Alcune imprese di venture capital come OpenView Venture
Partners di Boston, per la quale faccio da consulente, sostengono che
Scrum offre un vantaggio competitivo talmente grande che non può
non essere utilizzato. Queste non sono persone cordiali e vaghe, ma
gente interessata a fare soldi, e dicono semplicemente: “I risultati sono
indiscutibili. Le imprese hanno due scelte: cambiare o morire”.

AGGIUSTARE L’FBI
All’FBI, il primo problema che il team di Sentinel ha dovuto affrontare
sono stati i contratti. Ogni singolo cambiamento finiva con il diventare
un negoziato sul contratto con Lockheed Martin. Quindi Jeff Johnson e
Chad Fulgham spesero mesi per sbrogliare i contratti, portare
all’interno lo sviluppo e ridurre lo staff da un centinaio di persone a
meno di cinquanta. Il team centrale era ancora più piccolo.
La prima settimana fecero quello che molta gente fa in queste
circostanze: stamparono tutta la documentazione sulle specifiche. Se
non vi è mai capitato di vedere a quanto ammonta per un grande
progetto, può arrivare a centinaia e centinaia di pagine. Ho visto pile di
fogli alte anche qualche metro. L’ho visto accadere in un progetto dopo
l’altro: le persone copiano, incollano e le mettono nei loro scritti, ma
nessuno legge veramente tutte quelle migliaia di pagine. Non è
possibile, è questo il punto. Hanno messo insieme un sistema che le
costringe a sostenere una fantasia.
“C’erano 1.100 specifiche. La pila dei fogli era spessa diversi
centimetri” afferma Johnson. Anche solo pensare a quei fogli mi fa
provare compassione per quelle persone che probabilmente hanno
speso settimane delle loro vite per produrre documenti che non
avevano alcuno scopo. FBI e Lockheed Martin non sono le uniche: l’ho
visto accadere praticamente in tutte le imprese con cui ho lavorato. Il
grande mucchio dell’inutilità è una delle ragioni per cui Scrum può
essere un cambiamento così potente per le persone. Nessuno
dovrebbe buttare la propria vita in lavori senza senso. Non è solo un
cattivo modo di fare business, ma uccide anche l’anima.
Poi, dopo aver ottenuto il loro mucchio, l’analizzarono e misero in
ordine di priorità le specifiche. Il che è di importanza vitale, e molto
più difficile di quanto possa sembrare. Spesso le persone si limitano ad
affermare che tutto è importante, ma quello che dovrebbero chiedersi,
quello che il team di Sentinel si è chiesto, è che cosa apporterà
maggior valore al progetto? Fate prima queste cose. Nello sviluppo del
software c’è una regola, nata da decenni di ricerche, secondo la quale
in ogni parte del programma l’80% del valore risiede nel 20% delle
caratteristiche. Pensateci: quando è stata l’ultima volta che avete usato
l’editor di visual basic di Microsoft? Probabilmente non sapete
neanche che cos’è, quindi men che meno lo usereste. Però c’è, e
qualcuno ha speso del tempo per implementarlo ma, ve lo garantisco,
non ha aumentato di molto il valore di Word.
Disporre le cose in ordine di priorità secondo il valore fa in modo
che le persone producano prima quel 20%. Spesso, quando hanno
finito, si rendono conto che non hanno bisogno veramente del restante
80, oppure che quello che sembrava importante all’inizio non lo è più .
Per il team di Sentinel, la domanda divenne: “Okay, stiamo
lavorando su questo progetto enorme e di importanza vitale e sul
quale abbiamo speso centinaia di milioni di dollari. Quando sarà
finito?”. Dopo averci pensato, promisero la consegna per l’autunno del
2011. Il report dell’Ispettore generale dell’autunno del 2010 è un
esempio di incredulità :
L’FBI ha affermato che userà una “metodologia agile” per completare lo
sviluppo di Sentinel, utilizzando meno dipendenti provenienti da FBI,
Lockheed Martin e dalle società che hanno fornito la maggior parte dei
componenti pronti di Sentinel. L’FBI prevede di ridurre il numero dei
dipendenti degli appaltatori che lavorano su Sentinel da circa 220 a 40. Nello
stesso tempo, anche il numero dei dipendenti FBI assegnati al progetto
diminuirà da 30 a 12. L’FBI ci ha riferito che crede di poter completare
Sentinel con i circa 20 milioni di dollari rimasti nel budget e in 12 mesi
dall’inizio di questo nuovo approccio3.

L’uso dell’espressione “metodologia agile” denota quanto poco

l’Ispettore generale sapesse di Scrum. Il termine “agile” risale a un
convegno del 2001 in cui io e altri sedici esperti di sviluppo software
scrivemmo quello che in seguito è diventato noto come il “Manifesto
per lo sviluppo agile”. In esso vengono dichiarati questi valori: gli
individui e le interazioni più che i processi e gli strumenti; il software
funzionante più che la documentazione esaustiva; la collaborazione
col cliente più che la negoziazione dei contratti; rispondere al
cambiamento più che seguire un piano. Scrum è il framework che ho
costruito per mettere in pratica questi valori. Non c’è nessuna
metodologia.
Ovviamente la promessa di Johnson di chiudere in 12 mesi era in
qualche modo fuorviante, perché in realtà non ne erano certi. Non
potevano esserlo. L’FBI non sapeva quanto potesse lavorare
velocemente il suo team in realtà . Si tratta di qualcosa che dico ai
dirigenti tutte le volte: “Saprò quale sarà la data quando vedrò quanto
migliorano i team. Quanto velocemente ci arrivano. Quanto
accelerano”.
Era anche cruciale, ovviamente, che i membri del team potessero
immaginare che cosa li avrebbe trattenuti dall’accelerare. Come dice
Johnson: “Ho gestito la rimozione degli impedimenti”.
L’“impedimento” è un’idea che viene dalla società che per prima ha
dato vita a molte idee su cui è basato Scrum: Toyota. E, più nello
specifico, il Toyota Production System di Taiichi Ohno.
Non scenderò nei dettagli qui, ma uno dei concetti chiave
introdotti da Ohno è l’idea di “flusso”; vale a dire che la produzione
dovrebbe fluire velocemente e tranquillamente attraverso il processo,
e, sostiene, uno dei compiti del management è identificare e
rimuovere gli impedimenti a questo flusso. Tutto ciò che si mette in
mezzo è spreco. Nel suo classico libro Lo spirito Toyota, Ohno definisce
la valenza morale e per il business dello spreco: