IN BREVE

Azionate la leva giusta. Modificate la performance del team, che ha un impatto

molto maggiore – di vari ordini di grandezza – rispetto alla performance
individuale.

Trascendenza. I grandi team hanno una finalità che va oltre l’individuo; per
esempio accompagnare degnamente all’ultima dimora il generale MacArthur,
vincere il campionato NBA.

Autonomia. Date ai team la libertà di decidere come agire, di mettere in pratica le

loro competenze professionali. La capacità d’improvvisare farà tutta la differenza,
qualunque cosa stia facendo il team: raccontare una rivoluzione in diretta o
concludere una vendita.

Interfunzionalità. Il team deve avere tutte le competenze necessarie per portare

a termine un progetto, quale che sia la sua missione: realizzare il software di
Salesforce.com o catturare dei terroristi in Iraq.

Piccolo è bello. I piccoli team fanno il lavoro più rapidamente dei grandi team. La
regola empirica indica un numero ideale di sette membri, più o meno due.
Tenetevi bassi.

Cercare il colpevole è stupido. Non cercate dei colpevoli; cercate dei sistemi
disfunzionali; sistemi che incentivano un comportamento improduttivo e
premiano una performance scadente.
 4
Il tempo

Il tempo è l’estremo limitatore dello sforzo umano, che incide su tutto,

dal modo in cui lavoriamo alla durata dei processi e al successo che
otteniamo. Il flusso monodirezionale incessante del tempo condiziona
il modo in cui vediamo il mondo e noi stessi. Come scriveva il poeta
seicentesco inglese Andrew Marvell, “Se avessimo solo abbastanza
esperienza del mondo e abbastanza tempo”, si potrebbe realizzare
qualunque cosa. Naturalmente, però , la consapevolezza della mortalità
aleggia su tutti i nostri sforzi. Sappiamo che il nostro tempo è limitato.
Dunque sprecarlo non è il peggiore dei crimini? Sentiamo ancora
Marvell:
Così, anche se non possiamo fermare il Sole, possiamo farlo correre 1.

Ma come facciamo? È abbastanza facile gridare “Carpe diem!” da

un palcoscenico per ispirare una folla, ma come si mette
concretamente in pratica questo principio? Gran parte dei testi dicono
ai lettori di sedersi alla scrivania, legarsi alla sedia e fare orari
impossibili. “Non pensare al mondo esterno”, ci dice implicitamente il
nostro capo. “Non pensare ai tuoi figli, al surf e neppure alla cena –
pensa soltanto a lavorare, datti da fare ancora di più e sarai
ricompensato. Avrai quella promozione. Riuscirai a concludere quella
vendita. Porterai a termine quel progetto”.
Anche se non ho nulla contro le promozioni, le vendite o i progetti,
sta di fatto che gli esseri umani soffrono moltissimo a lavorare in quel
modo. Siamo pessimi focalizzatori, trascorriamo in ufficio molte più
ore del necessario e non abbiamo idea di quanto tempo ci voglia a fare
le cose. E sto parlando di tutti, perché noi esseri umani siamo fatti così.
Quando mi sono messo a tavolino a sviluppare Scrum, non avevo
nessuna intenzione di creare un nuovo “processo”. Volevo solo
mettere insieme tutte le ricerche che erano state effettuate nell’arco di
decenni sulle modalità di lavoro più efficaci ed emularle. Volevo
incorporare le best practices e impossessarmi di tutte le idee migliori
che mi venivano sottomano. Poco prima di lanciare il primo vero
Scrum, nel 1993 in Easel, lavoravo in un’azienda situata a pochi isolati
dal Media Lab del MIT, da cui ho preso in prestito un’idea che poi è
diventata l’essenza stessa di Scrum: lo Sprint.

LO SPRINT

Nei primi anni Novanta il Media Lab ne pensava di tutti i colori. È in

quegli anni che ha preso forma il World Wide Web; e inventavano di
tutto, dai robot all’inchiostro elettronico che rende possibili gli e-
reader, a nuove soluzioni per la codifica del suono. Era un periodo
straordinariamente entusiasmante, e io tendevo ad assumere studenti
che uscivano da quel laboratorio perché erano pieni di idee, avevano
un’eccezionale capacità di creare cose che incontravano il favore delle
masse, ed erano in grado di costruirle in tempi brevi.
La loro velocità si doveva a una politica che il Media Lab applicava
a tutti i suoi progetti. Ogni tre settimane ciascun team doveva
presentare ai colleghi il progetto su cui stava lavorando. Era una
dimostrazione aperta; poteva presenziare chiunque. E se quella
dimostrazione non era al tempo stesso convincente ed entusiasmante,
i direttori del laboratorio mettevano fine al progetto. Ciò obbligava gli
studenti a costruire rapidamente dei prototipi di qualità , e soprattutto
a ottenere un feedback immediato su di essi.
Pensate a tanti dei progetti che seguite. Sono pronto a
scommettere che non ottenete quasi mai feedback su di essi finché
non li portate a termine, e ciò potrebbe accadere a distanza di mesi, se
non di anni. Potreste andare completamente nella direzione sbagliata
per mesi senza averne la benché minima idea. Significa buttare via
pezzi consistenti della vostra vita. Nel business potrebbe costituire la
differenza tra il successo e il fallimento. Lo vedo accadere in
continuazione: un’azienda dedica anni a un progetto che sembrava
una buona idea quando i dipendenti ci hanno messo mano, ma quando
finalmente tagliano il traguardo, il mercato si è modificato
radicalmente. Prima portate i nuovi prodotti ai clienti, prima possono
dirvi se ne hanno realmente bisogno.
Perciò , quando ho sviluppato il primo Scrum in Easel e ho detto al
CEO che non gli avrei mostrato un lungo e dettagliato diagramma di
Gantt di cui conoscevano entrambi la perfetta inutilità , mi ha risposto:
“Benissimo. Che cosa mi farai vedere?”. E io gli ho spiegato che gli
avrei mostrato ogni mese un pezzo di software pienamente
funzionante. Non qualcosa che funziona nella parte inaccessibile
all’utente. Non un pezzo di architettura del sistema. Un software che il
cliente può usare veramente. Una caratteristica pienamente
implementata.
“OK” mi ha detto “Vai avanti”.
Così il mio team si è messo a lavorare su quelli che chiamavamo
“Sprint”. Li chiamavamo così perché quel nome evocava l’intensità .
Avremmo lavorato a tutta velocità per un breve periodo di tempo e poi
ci saremmo fermati per fare il punto della situazione.
“Team WIKISPEED” è un gruppo fondato da Joe Justice (un nome
che è tutto un programma!). Producono automobili. Automobili che
fanno più di 40 chilometri con un litro di benzina, possono circolare
legalmente sulle strade, ottengono il massimo punteggio nei crash test,
viaggiano a oltre 200 chilometri all’ora e si possono acquistare a un
prezzo inferiore a quello della Camry. WIKISPEED migliora
costantemente quella vettura, ma se volete acquistarne una versate
25.000 dollari sul sito wikispeed.com, e ve la procureranno in tre mesi.
Per farlo usano Scrum. Come molti dei team più efficaci di oggi,
lavorano in Sprint di una settimana. Ogni giovedì si mettono intorno a
un tavolo ed esaminano l’enorme quantità di cose che hanno da fare:
un po’ di tutto, dallo sviluppo del prototipo di un nuovo cruscotto alla
sperimentazione delle frecce. Mettono in ordine di priorità l’elenco, e
poi si dicono: “OK, quante di quelle cose possiamo fare questa
settimana?”. E per “fare”, intendono “portare a termine”, terminare del
tutto. Queste nuove caratteristiche funzionano. L’automobile va avanti
benissimo. Ogni settimana. Ogni Sprint.
Facendo due passi nella sede di Team WIKISPEED, situata a nord
di Seattle, in un qualunque giovedì, potete vedere lo spettacolare caos
organizzato che è l’officina di produzione di una macchina. Ci sono
bidoni pieni di attrezzi e seghe elettriche, componenti elettronici, viti e
chiavi inglesi. Un router CNC giace in un angolo accanto al telaio
semiultimato di un’automobile nel reparto numero 3. Un trapano a
colonna e una piegatrice stanno da una parte come cuccioli in attesa di
giocare. Il giorno della nostra visita, sopra la vettura in costruzione è
appesa una fotografia del suo acquirente: Tim Myer. Gli piace scalare
le montagne, mangiare patatine fritte e bere sidro. Non gli piace non
sapere cosa sta succedendo e non avere opzioni. Potete trovarlo sulle
colline nei weekend e al Tractor, una locale dedicato alle danze
country, ogni due lunedì sera.
Di fronte, nel reparto 1, si trova la prima vettura costruita dal
Team WIKISPEED, quella che ha partecipato a un concorso da 10
milioni di dollari di XPrize per le automobili che raggiungono
un’efficienza energetica di 100 mpg (miglia per gallone, n.d.r.). Team
WIKISPEED si è piazzato al decimo posto superando più di 100
concorrenti di grandi case automobilistiche e università . Di
conseguenza, è stato invitato all’Auto Show 2011 di Detroit, dove ha
avuto uno stand di prima fila, tra Chevy e Ford. Oggi questa macchina
è il luogo di sperimentazione di nuove idee. Accanto a essa c’è una
lavagna a muro alta quasi 4 metri che si estende per tutta la larghezza
dell’officina. Ci sono appiccicate decine e decine di uno degli oggetti
più comuni che si trovano in Scrum: i foglietti adesivi. Su ognuno di
questi Post-it dai colori brillanti c’è una cosa da fare: “Trapanare il
tubo per la scatola dello sterzo” … “Preparare lo stampo interno” …
“Installare delle alette sui parafanghi per prevenire gli schizzi d’acqua
dalle gomme” ecc.
La lavagna è divisa in colonne: Backlog … Cose da fare … Cose fatte.
A ogni Sprint, i membri del Team WIKISPEED mettono nella colonna
Backlog un numero di Post-it corrispondenti alle cose che pensano di
riuscire a fare quella settimana. Giorno per giorno, un membro del
team si fa carico di uno dei quei compiti e sposta il relativo foglietto
adesivo nella colonna Cose da fare. Una volta terminata l’operazione, il
foglietto viene spostato nella colonna Cose fatte. In qualunque
momento, ogni membro del team può vedere su cosa stanno
lavorando tutti gli altri colleghi.
Una notazione importante: nessun foglietto viene spostato nella
colonna Cose fatte se il relativo risultato non può essere utilizzato dal
cliente. In altre parole, potete guidare la macchina. E se qualcuno la
guida e dice: “Ehi, le frecce restano bloccate”, quel problema viene
affrontato nello Sprint successivo.
Gli Sprint prendono spesso il nome di “time boxes”. Hanno una
durata prefissata. Non potete fare uno Sprint di una settimana e poi un
altro Sprint di tre settimane. Dovete essere coerenti. Dovete stabilire
un ritmo di lavoro in base al quale le persone sanno quanto possono
realizzare in un periodo di tempo prestabilito. E spesso quella
quantità le sorprende.
Un elemento cruciale del singolo Sprint, tuttavia, è che nel
momento in cui il team si impegna a realizzare certe cose, quei compiti
diventano vincolanti e circoscritti. Nessun altro al di fuori del team
può aggiungerne altri. Più avanti spiegherò meglio le ragioni di questo
vincolo, ma per ora vi basti sapere che le interferenze e le distrazioni
rallentano pesantemente il lavoro del team.
Come ho già accennato, nel primo Scrum facevamo degli Sprint di
quattro settimane. Verso la fine del primo abbiamo avuto la
sensazione di non andare ab