Project Management: fai le cose in modo agile

Alle soglie dell’estate gli allenamenti progettuali vanno intensificati. La tua “prova progetto”, impegnativa quanto quella “costume”, potrebbe essere organizzare le prossime vacanze in funzione del tempo e delle risorse disponibili, con il mix di natura, famiglia, amici, relax e arte che preferisci.

Da questo inverno ti stai allenando duramente sul potenziamento e sul “fondo”. Dopo aver definito cosa sia un progetto ti ho proposto esercizi su come risolvere problemi, su come anticiparli gestendo i rischi, su come indirizzare il progetto per realizzare qualcosa che serva davvero a qualcuno, su come gestire scadenze non modificabili come una prova d’esame e su come mantenere sempre alta la motivazione, tua e del team di lavoro.

A questo punto hai bisogno di agilità. E’ una qualità importante, in qualche caso fondamentale, nella prestazione progettuale. Te ne ho accennato nella scheda di preparazione agli esami di maturità di inizio aprile. In quel caso, la modalità con cui consigliavo di studiare, attraverso una serie di iterazioni di lavoro e incrementando la tua preparazione un pezzetto alla volta, è quella tipica delle pratiche e dei metodi agili.

La parola “agile” è sempre più presente nel linguaggio professionale e di business. Non è una sensazione. E’ un fatto. Da Google Trends, le ricerche in internet con la keyword “agile” hanno avuto il loro picco massimo nel mondo all’inizio del 2018 e, con qualche mese di ritardo come di consueto, tra aprile e maggio anche in Italia. Il tasso di crescita di ricerche specifiche come “agile project management” o “agile management” è di oltre il 200%. Una ricerca su Linkedin restituisce invece oltre 3 milioni di profili professionali, di cui circa 23 mila in Italia, che utilizzano la parola “agile” all’interno della loro headline di presentazione, abbiamo tra gli altri: Agile Practitioner, Agile Developer, Agile Coach (moltissimi…), Agile Test Manager, Agile Product Manager, Agile Project Manager, Agile Facilitator, Agile Trainer, Agile Innovator, Agile Specialist e persino semplici “Agile Enthusiast”. Insomma “Agile-whatever-you-want”.

Con tutta probabilità, i professionisti che, pur non usando questa parola nella loro denominazione professionale, conoscono o applicano pratiche e tecniche agili sono molti di più.

Però non ti devi preoccupare se di “agile” e “agilità” non ti intendi granché mentre tutti attorno a te ne parlano. Parafrasando Ken Schwaber, inventore insieme a Jeff Sutherland del più diffuso metodo agile (SCRUM), “agile è facile da imparare ma molto difficile da padroneggiare”. Molti sono affascinati da questa suggestione ma ne hanno una conoscenza superficiale. Il rischio è una applicazione senza reale consapevolezza da parte di alcuni. Quello che posso fare è darti qualche esercizio per cominciare dalle basi in modo semplice, ma spero completo ed equilibrato, stimolando eventuali approfondimenti da parte tua.

Come altre pratiche e tecniche già viste in passato, anche quelle agili possono essere applicate a tutto ciò che soddisfa la definizione di progetto: un insieme di attività coordinate per realizzare specifici obiettivi entro tempi definiti.

Fai le cose in modo agile e pian piano imparerai ad “essere” agile”

Dal vocabolario Treccani, l’agilità (in fisica e nella tecnica) è “la capacità di un sistema di variare facilmente uno o più dei suoi parametri operativi”. Per quale motivo? Per adattarsi al cambiamento che, diceva Eraclito di Efeso, “è l’unica costante” e che secondo Ray Kurzweil si manifesta in modo sempre più rapido (lui la chiama “legge dei ritorni accelerati”).

Un esempio è la conquista del volo. Ci sono voluti ben 420 anni per passare dai disegni della vite aerea nel Codice Atlantico di Leonardo da Vinci al primo volo controllato di un mezzo più pesante dell’aria (il Flyer dei fratelli Wiright nel 1903) e poi sono bastati solo altri 66 anni per portare il primo uomo sulla Luna con la missione dell’Apollo 11. Un tempo quasi 7 volte inferiore per colmare una distanza concettuale e tecnologica enormemente più grande.

In tempi di rapido cambiamento la mancanza di agilità può essere fatale. Quando cadde l’asteroide i Dinosauri non riuscirono a “variare rapidamente i loro parametri operativi” e si estinsero.

Anche nel mondo dei progetti le cose cambiano sempre più in fretta. La Digital Transformation rappresenta un poderoso fattore di accelerazione, i contesti di business sono sempre più dinamici, la virtualizzazione di beni e servizi aumenta nel mondo la quota di “knowledge project” a produzione concettuale e immateriale, dove più che seguire un piano precostituito è importante saper soddisfare requisiti in costante evoluzione.

Warm up

Lo scopo di qualsiasi progetto è realizzare o evolvere un prodotto o servizio (materiale o immateriale). Il ciclo di vita del prodotto/servizio inizia “prima” del progetto, con un Business Plan che formalizza una opportunità di business descrivendo l’idea di prodotto/servizio da realizzare e valutandone sostenibilità e ritorno economico.

A questo punto parte il progetto vero e proprio, che, oltre a quelle di avvio e chiusura, si snoda su tre tipologie di attività principali:

• pianificazione, rispetto alla diverse dimensioni del progetto (dello scope, ossia del lavoro da svolgere, dei tempi, dei costi, delle risorse, etc.)

• esecuzione del lavoro, per la realizzazione del prodotto/servizio

• monitoraggio e controllo, per verificare periodicamente lo stato di avanzamento dei lavori e di quanto realizzato, misurandone lo scostamento eventuale da quanto previsto in fase di pianificazione e definendo le relative azioni di recupero.

La differenza tra un progetto “tradizionale” e un progetto “agile” consiste nel modo con cui queste tre fasi vengono messe in atto.

Il Project Management tradizionale è “deterministico”. Prima definisci bene cosa vuoi realizzare, quindi derivi tempi, costi e risorse necessari e ti fai in anticipo “il film” di tutto ciò che dovresti fare (il cosiddetto Project Management Plan). Queste valutazioni le fai all’inizio del progetto e prima di cominciare la fase di esecuzione vera e propria.

Il problema però è il cambiamento. Le cose cambiavano anche prima, ma assai più lentamente e quindi farsi il film aveva senso. Oggi i requisiti e gli obiettivi cambiano continuamente e ci sono settori dove i prodotti/servizi sono intrinsecamente più dinamici.

Se elabori oggi il piano di progetto per la costruzione di una diga e lo chiudi in cassetto ritirandolo fuori tra 4 anni, con tutta probabilità sarà in gran parte ancora valido. Se fai lo stesso con un’applicazione software o un servizio digitale, dopo 4 anni devi ripensare tutto daccapo, perché nel frattempo saranno cambiate le norme, il mercato, i competitori e le esigenze degli utilizzatori.

In questi casi hai bisogno di un approccio adattivo/agile, rinunciando a prevedere in anticipo tutto quello che potrà succedere, cosa sempre più complessa e inattuabile, per procedere a piccoli passi tenendoti pronto a correggere il tiro in corso d’opera.

Prima definisci le caratteristiche generali e imprescindibili del prodotto/servizio da realizzare (quelli bravi lo chiamano MVP, Minimum Viable Product) con tempi e budget prefissati, rinunciando però a catturare tutti i particolari come nella pianificazione predittivo/deterministica. In pratica, più che il film ti fai una “sceneggiatura di massima” (Product Roadmap).

Il tempo viene organizzato in “scatole” di durata breve e fissa (2-3 settimane) dette iterazioni, all’interno delle quali vengono eseguite tutte e 3 le fasi di pianificazione, esecuzione, monitoraggio e controllo. Praticamente è come se ogni iterazione fosse un mini progetto che realizza un incremento del prodotto/servizio finale, scegliendo di volta in volta quali caratteristiche o funzionalità implementare nella iterazione successiva in base alle priorità del momento.

Al termine di ciascuna iterazione presenterai l’incremento di lavoro realizzato al cliente/committente, che lo validerà in funzione dei criteri di accettazione concordati. Se qualcosa dovesse andar male o fosse cambiato nel frattempo, nel caso peggiore perderai il lavoro di una sola iterazione (comunque breve) limitando il danno, ma potrai correggere il tiro prima dell’inizio dell’iterazione successiva. Nella gestione di progetto tradizionale, se sbagli qualcosa nella tua pianificazione deterministica rischi di accorgertene troppo tardi, causando maggiori perdite di tempo ed economiche.

Lo schema seguente riporta le due filosofie a confronto.

L’approccio adattivo/agile dà effettivi vantaggi negli scenari dove i requisiti del prodotto/servizio da realizzare sono instabili o dinamici e dove è possibile coinvolgere attivamente e frequentemente il cliente/committente, in particolare le figure di business, chiamate in causa al termine di ciascuna iterazione di lavoro per verificare/validare l’incremento di prodotto realizzato.

Esercizi

La industry di riferimento per l’adozione di metodi e tecniche agili è senza dubbio l’IT e in particolare lo sviluppo software. Pur essendo molti concetti originari di altri settori, soprattutto quello automotive giapponese, lo spartiacque si ha nel 2001, quando un gruppo di esperti internazionali dell’ingegneria del software (tra cui i già citati Schwaber e Sutherland, inventori di Scrum) pubblicano il Manifesto Agile per lo sviluppo software, basato su 4 valori e 12 principi fondanti.

Tutti i metodi successivamente sviluppati sono coerenti con tali valori e principi, che rappresentano la cartina di tornasole per stabilire se un approccio o una modalità operativa possano definirsi o meno “agili”. Gli esercizi che ti propongo consistono nell’applicare i 4 valori del Manifesto Agile a un contesto progettuale di tua scelta (l’organizzazione della tua vacanza, la ricerca di una nuova posizione professionale, la preparazione ad un esame, etc.) adattando consigli e prescrizioni allo specifico contesto.

Esercizio 0: in questo esercizio preliminare devi selezionare il progetto a cui applicare i 4 valori agili degli esercizi seguenti. I possibili criteri per stabilire se puoi gestire in modo agile un progetto sono numerosi e hanno a che fare con la dimensione organizzativa, culturale e operativa della tua organizzazione. Per semplicità, puoi applicare questi 2 criteri di base:

• Valuta su una scala da 1 a 10 il grado di dinamicità/stabilità nel tempo del prodotto servizio che devi realizzare, dove 1 significa “molto stabile con caratteristiche che non cambieranno o cambieranno molto poco” e 10 “molto instabile con caratteristiche soggette a frequente evoluzione e cambiamento”. Più il valore si avvicina a 10 più il tuo progetto risulta adatto ad un approccio agile.

• Valuta su analoga scala da 1 a 10 il grado di coinvolgibilità attiva del tuo cliente/committente e la sua reale disponibilità a sedere costantemente al tavolo di progetto, dove 1 significa “pochissimo coinvolgibile” e 10 significa “del tutto coinvolgibile”. Più il valore si avvicina a 10 più il tuo progetto risulta adatto ad un approccio agile.

Esercizio 1: “people and interactions over processes and tools”, l’approccio agile riconosce l’importanza di strumenti e procedimenti per guadagnare efficienza, ma la differenza la fanno le persone e le interazioni tra le persone. Questo è tanto più vero quanto più il tuo progetto è ad “alta intensità di lavoro umano”. Parla con gli utilizzatori del prodotto/servizio che intendi realizzare, nessun processo potrà dirti cosa sia utile e cosa no meglio di quanto possano fare loro. Favorisci il confronto e la comunicazione quotidiana tra i “tecnici” e le figure di business. Grazie al confronto, il tecnico capirà meglio gli obietti economici e strategici del prodotto/servizio da realizzare, mentre il commerciale comprenderà meglio vincoli e dipendenze di natura tecnica. Privilegia, ove possibile, la comunicazione di persona, face-to-face, dove alla comunicazione verbale si aggiunge quella non verbale e prossemica che massimizzano il trasferimento di informazioni.

Esercizio 2: “working software over comprehensive documentation”, il Manifesto Agile è stato scritto da esperti di sviluppo software ma questo valore specifico puoi adattarlo anche a progetti che non abbiano a che vedere con l’IT. Documentare le cose è importante ma è ancora più importante realizzare un prodotto/servizio di qualità che rilasci valore ai suoi utenti. Un prodotto/servizio ben fatto ma scarsamente documentato è preferibile ad un prodotto/servizio scarso ma perfettamente documentato. Come criterio pratico, ogni volta che devi documentare qualcosa chiediti sempre qual è il valore che quella documentazione apporta al prodotto/servizio che realizzi. Se fatichi a trovare una risposta probabilmente si tratta di documentazione inutile.

Esercizio 3: “customer collaboration over contract negotiation”, questo valore agile riprende uno dei criteri di valutazione dell’Esercizio 0. Se con il tuo team realizzi un prodotto/servizio commissionato da qualcun altro, ovviamente il contratto è un elemento fondamentale di tutela per entrambe le parti e ad esso si ricorre quando ci sono dubbi su come interpretare le cose o per verificare cosa sia incluso e cosa no nella fornitura. Tuttavia, il progetto si fa sempre in due, fornitore e committente e la possibilità di “portare a bordo” il cliente facendolo partecipare attivamente, coinvolgendolo in verifiche frequenti, consente di realizzare qualcosa che risponda molto meglio alle sue esigenze e necessità, minimizzando il disconoscimento alla termine del progetto di quanto realizzato e anche l’eventuale necessità di ricorrere al contratto per dirimere incomprensioni o contenziosi.

Esercizio 4: “responding to change over following a plan”, questo è probabilmente il valore agile più dirompente. Non che seguire un piano, spesso faticosamente costruito, sia sbagliato ma in tempi caratterizzati da quello che i consulenti bravi indicano con l’acronimo VUCA (Volatility, Uncertainty, Complexity, Ambiguity) il fattore decisivo è la capacità di rispondere agli inevitabili cambiamenti “variando rapidamente uno o più parametri operativi”. Questo non vuol dire nel modo più assoluto “non pianificare”. Si tratta solo di non concentrare la pianificazione solo nella fase iniziale, tentando di prevedere come andranno le cose sino alla fine del progetto, ma distribuendola sulle diverse iterazioni di lavoro e riservandosi la possibilità di continui aggiustamenti in corso d’opera. Nel corso di una iterazione di 2-3 settimane cambiano molte meno cose di quante ne cambiano lungo tutta la durata di progetto. Insomma “think globally” (perché gli obiettivi generali e la vision devono essere chiari) ma “plan locally”.

Defaticamento e stretching

L’agilità è una dote importante, che riflette la capacità di adattamento a contesti dove tutto cambia a velocità crescente.

I messaggi che ti ho dato oggi sono in contraddizione solo apparente con quanto già visto nelle precedenti schede. Ti avevo detto in passato quanto sia importante tracciare e documentare quello che fai nel progetto e sul progetto, per poter risalire in qualsiasi momento alla radice delle decisioni prese, o quanto sia fondamentale pianificare le attività (e la gestione dei rischi) prima di far partire qualsiasi attività realizzativa.

Oggi invece, tra le altre cose, ti ho detto che documentare è importante ma mai quanto realizzare un prodotto/servizio davvero utile e di qualità e che è più importante riuscire ad adattarsi al cambiamento piuttosto che seguire una pianificazione.

Ogni progetto è diverso dall’altro. Ci sono contesti più stabili dove un approccio classico e predittivo funziona ancora ottimamente. Ci sono contesti più dinamici e instabili dove vincono flessibilità e adattabilità (da non confondere con l’improvvisazione…).

In definitiva, fare un piano e tentare di seguirlo è giusto e sbagliato al tempo stesso. Si tratta di un paradosso, cioè di una cosa contemporaneamente vera e falsa, un po’ come lo stato di salute del famoso “gatto di Schroedinger”. Può essere sconcertante, anche per una mente agile, ma Niels Bohr, Premio Nobel per la fisica che ha dato contributi fondamentali alla nostra comprensione della struttura della materia, diceva “Ci siamo imbattuti in un paradosso? Benissimo! Adesso abbiamo speranza di un qualche progresso.”