Introduzione

Alcune domande che ho avuto in testa nei miei primi approcci all’Agilità, intesa come modalità di condurre i progetti e lavorando nel settore dell’information technology in stile waterfall, erano: come faccio a gestire un progetto in modalità Agile dovendo gestire anche la pianificazione di budget e di scadenze? In altre parole se l’agilità accetta ed anzi promuove i cambiamenti in quanto fonte di miglioramento, come faccio a gestirmi il piano? Cambiano i tempi di consegna se accetto, anzi promuovo le modifiche in corso d’opera? Per non parlare dei costi.

Potrei anche accettare di non basarmi su un Gantt ma se ho stimato 100 giorni uomo e un costo di qualche centinaio di migliaia di euro, come faccio ad andare dal committente a dirgli che qualcosa è cambiato nella data di rilascio e nei costi?

In questa serie di tre articoli vi proporrò un percorso che ha come tema la pianificazione in ambito progettuale. Nel primo articolo analizzeremo la necessità di pianificare, nel secondo perché la pianificazione fallisce ed infine nel terzo ed ultimo vedremo l’approccio Agile alla pianificazione. Riassumendo come gestire l’incertezza iniziale di alcuni (o forse molti) progetti cambiando approccio.

Perché si pianifica 

Quanto mi costa? Quando me lo consegnerai ? Quando potrò vedere qualcosa? 

Spesso queste domande arrivano in coda al primo incontro col cliente in cui si sta delineando l’opportunità di realizzare un progetto/prodotto/servizio.

Le risposte a queste domande servono per pianificare campagne di marketing, gestire i costi aziendali, organizzare l’eventuale training degli utenti e così via.

Non è sempre possibile dare risposte perché non abbiamo chiaro il contesto o tutti i dettagli necessari. Non è solo importante la vision del progetto ma anche la vision degli stakeholder. In altre parole cosa vogliamo realizzare per loro? Se vogliamo avvicinarci alle loro aspettative dobbiamo quasi sicuramente avanzare a step. Se invece il nostro obiettivo è realizzare un progetto “chiavi in mano” e puntare a consolidare tutti gli step in anticipo, anche perchè non siamo troppo avvezzi ai cambiamenti, allora molto probabilmente avremo una visione degli stakeholder come soggetti che sono quasi fastidiosi nell’ambito del progetto. Gli stakeholder introducono cambiamenti, chiariscono in ritardo rispetto all’inizio e quindi alterano i piani.

Già da queste considerazioni si capisce bene il senso del concetto “mindset Agile”. Andare verso l’agilità non è solo organizzare persone e lavoro in modo da cambiare il nome alle riunioni e fare qualche board dove appendere i nostri post-it, bensì è qualcosa di concettualmente più profondo. Le interessantissime testimonianze portate da alcune persone, principalmente HR e It manager nel corso dell’Agile for management forum tenutosi a Milano e organizzato da AgileReloaded lo hanno dimostrato: 

l’agilità è sistemica. 

Sebbene molti abbiano iniziato con un progetto pilota, il progetto per essere sostenuto e per potersi poi diffondere ha bisogno di appoggi da parte di diverse funzioni aziendali. 

Per dirla con un bellissimo concetto espresso da Marquet nel libro Turn the Ship Around, non dobbiamo spostare l’informazione verso “l’alto” (intesa come vertici aziendali) ma portare “l’alto” verso l’informazione. Nell’agilità è proprio questo uno dei passaggi fondamentali. “L’alto” deve andare “in basso” e acquisire le necessarie informazioni per capire le criticità e per vedere come un diverso modo di organizzare il lavoro può migliorare il processo e la vita stessa dei dipendenti. 

Quando il piano sfugge

Recentemente mi sono trovato a parlare con il mio istruttore di vela e amico (M.V. metto solo le iniziali per rispettare la sua privacy), ottimo velista, imprenditore e skipper. Mi chiedeva cosa fosse l’agilità e scrum. Nello spiegarglielo (spero chiaramente) ho fatto spesso riferimento al suo mondo professionale: le barche a vela e la nautica.

Progettare in modo Agile vuol dire accettare di andare a vela. Conosco il tuo porto di arrivo ma quasi mai lo puoi raggiungere con una rotta diretta, se ho il vento contro dovrò “bordeggiare”, vedi figura.

Andatura di “bolina” di una barca a vela

Bordeggiare vuol dire adattarsi ai cambiamenti del vento, risalire le difficoltà, con una modalità antifragile piuttosto che robusta.

Sempre per rimanere in un contesto nautico, quanto impiega una barca a vela per raggiungere l’isola al largo delle coste dalle quali siamo partiti? Possiamo fare una stima certo, considerando il vento che probabilmente ci sarà, ma dovremmo anche considerare la corrente, già più difficile da calcolare. Quindi come facciamo a capire dopo quanto tempo arriveremo?

Stimiamo il percorso e accettiamo di avere una stima non totalmente precisa, iniziamo a percorrerne una parte e poi rifacciamo la stima per il percorso rimanente. Reiteriamo questo procedimento fino alla fine ad intervalli regolari. Questo è sinteticamente l’approccio che possiamo seguire ma, comandante dell’imbarcazione, equipaggio e persone che ci attendono a terra devono tutti essere consapevoli della modalità con la quale stiamo conducendo il nostro viaggio altrimenti andremo a creare delle false aspettative rispetto all’orario di arrivo.

Nell’accezione Agile di progettazione i cambiamenti sono i benvenuti. Naturalmente non è il solo principio da seguire, ma quello che vorrei qui mettere in evidenza. Se i cambiamenti sono i benvenuti e se i clienti sono sempre da soddisfare allora non sarebbe più facile lavorare day-by-day senza piani? Non avremmo l’assillo delle deadline, dei release plan, la velocity, gli sprint e quant’altro.

Chi ha lavorato con questa modalità sa, senza altro aggiungere, che lavorare così è una vera tortura. Alcuni addirittura si spingono a sostenere che non ci sono altre possibilità. 

Purtroppo a volte hanno ragione ed in contesti in cui gli stakeholder non sono in grado di formulare le proprie esigenze e il business dell’azienda è confuso non è facile pianificare e progettare. Malgrado queste premesse rimane costante domanda che tutti noi progettisti, PM, Agilisti e quant’altro temiamo:

“Ma quanto mi costa e quando me lo consegni?”

Sempre per cercare dei parallelismi credo che nessuno vada in concessionaria chiedendo: ”Vorrei un’auto che sia comoda da guidare in città e anche per lunghi viaggi con un pò di optional carini e utili e che trasporti un pò di persone. Quanto mi costa e per quando sarebbe pronta?”

Nella seconda parte di questo articolo risponderemo a queste domande.