Questo articolo è comparso originariamente su agile monocle, la mia newsletter in lingua inglese in cui parlo di agile non come un martello ma come una lente attraverso cui osservare il modo in cui lavoriamo.

Immagine di testata di Scott Rodgerson.

---

Tutte le volte che si parla di pianificazione è obbligo quasi contrattuale citare il buon Dwight:

“Plans are useless, but planning is indispensable.”

Dwight D. Eisenhower

Il è qualcosa – e probabilmente avete capito che ho la fissa di citare correttamente – che Eisenhower non ha mai davvero detto, ma ha che apparentemente ha sentito dire da qualcun altro:

“Peace-time plans are of no particular value, but peace-time planning is indispensable.”

An anonymous and successful soldier

Il riferimento al tempo di pace per altro mi dà idee relativamente al tema della strategia ma magari di questo scriverò in futuro.

Lo scopo sarebbe coprire alcuni temi di base riguardo la pianificazione: non entrerò nel dettaglio di questa o quella tecnica di pianificazione, ma mi piacerebbe vedere ad alto livello che cos’è la pianificazione, quali sono i problemi più comuni e che cosa significa farlo “in modo agile”.

Giusto per essere chiari, penso che la “pianificazione agile” non dovrebbe nemmeno esistere come termine:

“La pianificazione agile non esiste, ma pianificare tenendo conto della complessità è indispensabile.”

Me

Lo spettro della pianificazione

No, “spettro”, ma non non nel senso del fantasma del Natale passato…

Penso che quello con cui facciamo più fatica a venire a capo quando parliamo di “pianificazione agile” sia il concetto di “pianificare abbastanza”, che è più facile a dirsi che a farsi, e vediamo perché.

Andando in prestito da Peter Gfader, abbiamo davvero bisogno di parlare un momento di cosa intendiamo quando diciamo “lo facciamo in agile”.

La pianificazione non è limitata ad un approccio bi-modale, agile o non-agile. Abbiamo uno spettro di pianificazione, specialmente se stiamo lavorando in ambienti e contesi complessi e grandi aziende, avremo diversi tipi di progetti gestiti in maniera leggermente diversa, e dovremmo essere in grado di riconoscere questo spettro di possibili alternative.

Ora, dato uno spettro che va dal chaos (puoi chiamarlo “ad hoc” per essere diplomatico, io lo chiamo per quello che è) ad BDUF (quelle situazioni in cui hai bisogno della stima della stima della stima, di documentare ogni micro-interazione del front-end, e così via), vediamo cosa la maggior parte delle persone intendono quando dicono “lo facciamo in agile”.

Ed è così: quello che molte persone pensano quando dicono e sentono dire “facciamo questo progetto in agile!” è di saltare la completamente la pianificazione o utilizzare tecnica di stime creative. Questo è un grosso problema, amici miei, perché quella non è la terra dell’agile, è la terra dell’improvvisazione.

Ci piace così tanto improvvisare in un contesto lavorativo?
Credo di no.

La pianificazione agile si colloca nel mezzo di quello spettro, perché prova a riconoscere sia i punti di debolezza che i punti di forza degli estremi. E, come nel mondo fisico, stare in equilibrio lì a metà strada è molto più difficile che stare sugli estremi: ti servono dei buoni addominali.

Adesso prova questo: prova a dare una occhiata allo spettro “graduato” che ho messo qui sotto. Pensa ai tuoi ultimi 5 o 10 progetti. Come si collocano in termini di essere più o meno ad hoc o BDUF? Erano sbilanciati su un lato dello spettro per tutta la durata del progetto? Ci sono stati degli svarioni da un lato all’altro? Quali fasi di progetto tendevano a quale estremo? Perché ogni tanto se perso nel caso mentre altre volte hai delle strette limitazioni sul tuo lavoro?

Stima vs. Previsione

Come prima cosa: non confondiamo mai stima e previsione. Secondo: penso che stimare sia relativamente più facile e nella mia esperienza una pratica molto più comune rispetto alla previsione. Questo non significa che non dovremmo usare sia stima che previsione quando pianifichiamo.

Ma a cosa somiglia una “buona stima” e una “buona previsione”?

• Buona stima: è veloce, può e dovrebbe essere fatta in termini relativi e non assoluti, con dei compromessi ben noti tra accuratezza e precisione;
• Buona previsione: per fare una buona previsione devi tenere sotto controllo tutte le ipotesi del caso, perché nessuna legge statistica o equazione ti salverà se le ipotesi che fai circa il tuo lavoro sono errate.

Forse l’hai intuito: pianificare in Scrum tende ad essere sbilanciato nei confronti della stima, mentre pianificare in Kanban è sbilanciato verso la previsione: e sì, dovresti usare elementi di previsioni in Scrum e elementi di stima in Kanban per rendere il tuo planning un pochino più robusto.

Stima e previsione servono a scopi diversi e per questioni di brevità non mi dilungherò sul tema della previsione questa volta — diciamo solo per il momento che per approcciare delle pratiche di previsione occorre che nella tua azienda ci sia una cultura del dato abbastanza radicata.

Le previsioni vengono azzoppate da conoscenza imperfetta, incompleta, immatura e sbagliata. Il fatto dal fatto che i progetti digitali soffronno, prendendo a prestito da Peter Gfader, di quello che viene chiamato il paradosso dei progetti.

Hai indovinato: proviamo a prendere molte, se non tutte le nostre decisioni all’inizio del progetto, quando abbiamo la minor quantità di informazioni a dispozione — questo paradosso può anche essere visto come un corollario semplificato del cono di incertezza.

Per riassumere, traendo spunto da questo breve ma ricco intervento sulla stima, questi sono i principi che dovrebbero guidare la pianificazione:

• Velocità più che perfezionismo
• Accuratezza più che precisione
• Collaborazione più che assertività
• Relatività più che assolutezza

Non facciamo gli sprint per il gusto di fare gli sprint, non usiamo story point per il piacere di usare gli story points: lo facciamo perché le nostre pratiche di pianificazione hanno delle limitazioni studiate e riconosciute da decenni, dall’inizio dell’era dei progetti informatici, e questo è il motivo per cui quasi mi rifiuto di parlare di “pianificazione agile”.

C’è la pianificazione fatta prendendo in considerazione la complessità, e c’è la pianificazione fatta ignorando la complessità. Stare lì nel mezzo richiede molta disciplina e molto metodo, aspetti per cui le pratiche agili dovrebbero aiutarti: non c’è posto per l’improvvisazione.