Marco Caressa

https://www.linkedin.com/in/marcocaressa/

La trasformazione agile non è un

pranzo di gala

Tutti parlano di trasformazione agile e quando un termine diventa popolare dovremmo

per prima cosa condividerne definizione e ambito.

In questo caso mi riferisco alla sperimentazione e adozione di metodi e pratiche agili

nella gestione di progetti da parte di un’organizzazione, sia essa pubblica o privata. Può
trattarsi di progetti grandi o piccoli. Interni (svolti dall’organizzazione per sé stessa)
oppure esterni (realizzati su committenza).

Queste note sono un banale alert sul fatto che non si diventa agili seguendo un corso
Scrum di 2 giorni o facendo prendere qualche certificazione in ambito a qualcuno
all’interno dell’organizzazione. Quella è semmai una tessera del mosaico, ma affinché
pratiche e tecniche agili possano essere applicate con profitto e generino davvero
valore, TUTTA l’organizzazione deve predisporsi a lavorare in modo diverso. Non solo i
team di progetto, che in questo caso ne rappresentano la testa di ponte.

Se questo non accade, il cambiamento non attecchisce e alla fase dell’entusiasmo segue
quella del disorientamento e infine quella del rifiuto, con la conclusione che “agile non
funziona”. In realtà, è probabile che tu non ci abbia nemmeno provato ad essere
davvero agile.

Sappi che tutto ciò costa notevole impegno in termini di tempo e risorse, ma è un
passaggio obbligato. In definitiva, la trasformazione agile non è un pranzo di gala. E’
piuttosto un atto di violenza organizzativa che cambia il modo di lavorare dei singoli e
dei gruppi.
IMPARARE DAGLI ERRORI

Sottovalutare gli impatti organizzativi di un progetto o un’iniziativa di cambiamento è un

problema antico, che spesso deriva dal vedere l’innovazione solo in chiave di soluzione
tecnologica o metodologica (e se te lo dice un tecnologo/metodologo puoi crederci…
😊 ).

Come quella volta che avevi convinto il CEO a finanziare quel progetto interno di
realizzazione di una piattaforma di knowledge management per l’archiviazione e il
riutilizzo di documenti e informazioni aziendali.

L’obiettivo era chiaro e inconfutabile: non reinventare la ruota ogni volta. Ogni volta
che parte un progetto o bisogna redigere una proposta, con tutta probabilità qualcuno
in azienda avrà già fatto qualcosa di simile in passato, avrà già scritto un documento che
con pochi adattamenti potresti riutilizzare. Aumentare il riuso rende i processi interni
molto più efficienti. Non fa una grinza.

Nel kick-off di progetto avevi spiegato al CEO di aver individuato una “soluzione
innovativa basata sul prodotto XYZ” che grazie alla potenza del cloud computing
avrebbe consentito di archiviare e classificare un numero qualsiasi di documenti e
contenuti di qualsiasi formato, garantendo backup e disponibilità, eliminando il rischio
di perdita di dati dovuto ai singoli PC che svampano o agli hard disk che tirano
improvvisamente le cuoia.

Perché allora, dopo il rilascio della piattaforma sulla intranet aziendale e il lancio con
comunicazione urbi et orbi, a distanza di 6 mesi la knowledge base era ancora
desolatamente vuota? Nessuno, o pochissimi, l’avevano alimentata. Nella tua
infatuazione per la soluzione tecnologica (il prodotto XYZ strafico, basato su un mix di
intelligenza artificiale e blockchain) avevi sottovalutato l’impatto che l’utilizzo del
sistema avrebbe avuto sul modo di lavorare delle persone e sull’organizzazione.

Un sistema di knowledge management funziona se tutti lo alimentano e se ciascun

contributore si preoccupa di verificare periodicamente la validità del contenuto inserito.
Perché le informazioni, soprattutto quelle tecniche, scadono come le mozzarelle.
Inserire contenuti nel sistema richiede tempo e impegno, perché quelle informazioni per
essere “trovabili” devono essere classificate secondo schemi e modelli che ne facilitino il
recupero, senza però rendere l’inserimento da parte dei singoli contributori una mission
impossible.

Insomma, prima di far acquistare il prodotto XYZ, avresti dovuto come minimo:
 • Prevedere una fase di studio dei documenti usati dai processi di business
dell’organizzazione, modellare degli schemi di classificazione specifici (non troppo
dettagliati né troppo laschi)…
• …parlare coi Project Manager dicendo loro di prevedere un effort specifico
all’interno di ciascun progetto per caricare sul sistema documenti rilevanti e
potenzialmente utili per usi futuri (insomma, strutturare le lesson learned)
• …suggerire la definizione di nuovi ruoli nell’organizzazione, almeno un Knowledge
Manager che avesse visibilità dei contenuti e del loro riuso per misurare il
successo dell’iniziativa…
• …e molto altro ancora.

Insomma, l’introduzione di un prodotto o di una soluzione tecnica determina SEMPRE la

nascita di nuove attività e nuovi ruoli nell’organizzazione, la scomparsa di altri o il loro
accorpamento e più in generale un ripensamento del modo di lavorare a livello
sistemico.

ORA, TORNIAMO ALLA TRASFORMAZIONE AGILE E IMMAGINA DI AVER

LAVORATO PER ANNI…

…col caro vecchio ciclo di vita waterfall. Dove ad ogni fase di progetto corrisponde un
avanzamento di stato del prodotto/servizio da realizzare. Se fosse un’applicazione
software con 15 funzionalità da realizzare, lo schema sarebbe più o meno questo qui di
seguito.
Ora, lasciamo perdere vantaggi o svantaggi, se convenga o meno prima analizzare tutto
in anticipo, poi progettare tutto, poi realizzare tutto, poi testare tutto e infine rilasciare
tutto insieme. Fatto sta che clienti come una PA o un grande istituto di credito per anni
ti hanno chiesto, per contratto, di lavorare così.

Questo significa una serie di cose:

• Che i tuoi progetti richiedono l’allocazione nel team di specifiche competenze un

po’ alla volta. Nella fase di analisi coinvolgerai solo gli analisti di business e
funzionali che poi, una volta terminato il loro compito, potranno passare ad
occuparsi delle attività di una fase analoga di un altro progetto. Nella fase di
design solo i progettisti e gli architetti software, in quella di sviluppo solo i
programmatori, etc.
• Che negli anni avrai specializzato le persone su ruoli verticali (analista di
business, designer, sviluppatore, tester, etc.) da spostare da un progetto all’altro
in funzione delle attività richieste nella specifica fase.
• Che essendoci elevato turnover del team (ad ogni fase c’è un sostanziale
ricambio di persone perché arrivano gli specialisti delle attività della fase
entrante) il Project Manager deve tenere le fila di tutto il discorso, coordinando,
controllando e verificando. Poi siccome sai (perché lo sai vero?) che il PM non
può fare anche il tecnico, magari avrai previsto delle figure di technical manager
di supporto al PM e presenti nel progetto per tutta la sua durata. Dopo tutto, il
PM non può intendersi di analisi, progettazione, sviluppo e test, ha già le sue
gatte da pelare per gestire comunicazione e stakeholder, piani di lavoro, verifica
di stati di avanzamento, etc.

Tutto ciò è l’ovvio e normale risultato di un adattamento progressivo della tua

organizzazione alla tipologia di progetti che, per abitudine o per necessità, hai portato
avanti per anni.

POI HAI DECISO CHE VUOI DIVENTARE AGILE…

…che, detto tra noi, è un’ottima scelta, soprattutto se sviluppi applicazioni software
come quella che abbiamo descritto nell’esempio.

Siccome leggi Wired, frequenti LinkedIn e partecipi ai forum di discussione, scopri che
esiste un framework molto diffuso e popolare che si chiama Scrum con cui potresti fare,
come disse uno dei suoi creatori, “il doppio delle cose nella metà del tempo”.
Chi non vorrebbe un simile vantaggio competitivo? Così decidi di adottarlo per i tuoi
progetti e, siccome vuoi fare le cose per bene, non ti limiti a distribuire la guida ufficiale
del framework ma investi sulla formazione e certificazione di alcune persone dei tuoi
gruppi di lavoro.

Quelli tornano dalle giornate d’aula con slide e documenti e ti dicono “da oggi i progetti
dobbiamo farli così”

Brevi iterazioni di 2 settimane all’interno delle quali viene realizzato un incremento di

prodotto rilasciabile. Questo vuol dire che invece di lavorare stato per stato sull’intero
insieme di funzionalità/requisiti, scegli un insieme di requisiti che in quel momento
valuti (o meglio, il cliente valuta…) come prioritari e li “lavori” in modo completo (analisi
di dettaglio, progettazione, sviluppo, test e rilascio).

Ciò renderà il cliente più felice, perché non dovrà più aspettare la fine del progetto per
avere anche solo una funzionalità disponibile per il suo business (rilascio di valore
anticipato) e darà modo a te di correggere il tiro, pianificando iterazione dopo
iterazione un pezzetto di lavoro alla volta, con minori rischi di rework su cose i cui
presupposti nel frattempo potrebbero essere cambiati.

C’è solo un piccolo particolare. Il fatto che al termine di ogni iterazione tu debba
potenzialmente rilasciare qualcosa di fatto e finito, fa si che ciascuna di esse sia una
specie di “mini progetto” con tutto il ciclo di attività necessarie.

Questo significa una serie di cose:

• Che i tuoi progetti richiedono l’allocazione completa del team e di tutte le
competenze richieste per l’intera durata del progetto. In altre parole, in ogni
iterazione avrai bisogno dell’analista di business, dello sviluppatore, del tester,
etc.
• Questo vuol dire azzerare (idealmente) il turnover. Si sta sul progetto dall’inizio
alla fine. E se gestisci un software lab, quindi sei un portfolio manager che deve
trovare il modo più efficace ed efficiente per allocare le risorse (anche umane) sui
vari progetti, dovrai farlo eliminando ogni sorta di parallelismo. Una persona
lavora su un progetto alla volta.
• Questo crea un problema. L’analista di business che prima, quando finiva il suo
lavoro su un progetto veniva spostato su un altro, ora rimane nel team ma rischia
di rendersi utile solo per una frazione del tempo di una iterazione di lavoro.
Questo se sa fare solo l’analista di business…( la cosa vale ovviamente anche per
lo sviluppatore o il tester). Ora, nessun progetto può sostenere economicamente
un’organizzazione del lavoro in cui una persona sia allocata per un’intera giornata
ma abbia attività solo per 2 ore di questa. La soluzione? Ogni professionista deve
saper fare più cose, le competenze di ciascuno dovrebbero essere più ampie e
sovrapponibili, ma non è facile perché per anni hai puntato sulla specializzazione
verticale dei tuoi collaboratori, favorendo una parcellizzazione delle competenze.
E adesso?
• Abbiamo detto che con agile non abbiamo turnover. Il fatto di avere un team più
stabile e coeso ti porta dei vantaggi. Primo tra tutti quello di poter completare
più facilmente lo “sviluppo” del team. E’ probabile che riuscirai a portare a
termine tutte le fasi del Modello di Tuckman arrivando sino al “performing” e a
permetterti uno stile di leadership improntato alla delega (Modello Hersey-
Blanchard , quadrante in basso a sinistra, low task, low relationship) cosa che in
un team waterfall, soggetto a innesti e cambiamenti frequenti, è molto più
difficile.
• A questo punto, però, il Project manager come lo intendevi prima non ha più
ragion d’essere. Un team coeso a cui il lavoro viene delegato è in grado di auto-
organizzarsi nei task di dettaglio (self-organisation). Gli devi dire solo “cosa”
vogliamo ottenere. Al “come” pensano loro. Quindi la figura di cui hai bisogno
non è più un manager in senso stretto (il team da questo punto di vista si
autogestisce) ma un “servant leader”, che si metta a disposizione del team
garantendo che questo abbia le condizioni per lavorare senza intoppi e rafforzi
continuamente la visione di progetto e gli obiettivi da raggiungere. In Scrum una
figura di questo tipo si chiama Scrum Master, in altri metodi come XP si chiama
Agile Coach. Ora, al di là di come lo vuoi chiamare, stiamo parlando di un animale
diverso dal PM che conoscevi. E con i PM che hai formato (e certificato) negli anni
cosa ci fai? Bella domanda…
Potrei andare ancora avanti. Potrei dire ad esempio che tutti i metodi agili privilegiano il
team co-locato, dove tutti si trovino fisicamente nello stesso luogo di lavoro. In questo
modo, la comunicazione face-to-face consente di trasferire le informazioni in modo
poco formale e massimamente efficace.

Però sai meglio di me che questo non è sempre possibile. La delocalizzazione e la

virtualizzazione delle attività (aka, smart working e sostenibilità) spingono in senso
opposto, e un corretto punto di equilibrio non è facile da trovare.

E in tutto questo non hai fatto i conti senza l’oste. Anche se avessi chiesto al genio della
lampada di esaudire un paio di “desideri agili”, tipo trasformare i tuoi specialisti verticali
in “generalizing specialist” in grado di fare (bene) più cose e mutare i Project Manager
“ranocchi” in “principi” della Servant Leadership, dovresti farti un’ultima domanda: il
mio cliente/committente è in grado di seguirmi?

Perché, molto più che in passato, un progetto agile si fa con tutti gli stakeholder seduti
allo stesso tavolo, soprattutto quelli di business. Per cui, puoi essere l’azienda più agile
del mondo ma se il cliente ti chiede per contratto di formalizzare delle stime di dettaglio
ad inizio progetto per dare il go / no-go, dovrai rassegnarti a rititare fuori dal cassetto
WBS, analisi reticolare, Gantt, matrice di tracciabilità dei requisiti e definire un processo
di gestione della Change Request che non ti faccia fare un bagno di sangue.

I MIEI 2 CENTESIMI: SE VUOI DIVENTARE AGILE C’E’ UNA BUONA

NOTIZIA…

…sarai in grado di affrontare con successo una casistica più vasta di progetti, perché ci
sono scenari nei quali l’approccio agile è pressoché obbligato. Questo darà a te e alla tua
organizzazione molte più possibilità (se no, rischi di fare la fine dell’analista funzionale di
cui sopra, che per un’azienda si traduce nel rischio di uscire dal mercato).

Però se vuoi farlo davvero, senza pericoli di rigetto che ogni cambiamento si porta
dietro, devi prepararti per tempo:

• Rivedendo i profili professionali dei tuoi collaboratori, non limitandosi a

cambiargli nome (il Project Manager che diventa Scrum Master per imposizione
delle mani) ma riempiendo questi profili di reali competenze.
 • Riprogettando di conseguenza in modo radicale formazione e crescita delle
persone, passando gradualmente da specialisti verticali di stampo tayloristico a
specialisti generalizzati (es. l’analista che sappia anche scrivere codice e
progettare ed eseguire test).
• Modificando profondamente i criteri di allocazione dei team di lavoro e
verificando quali impatti su quali unità organizzative questo comporti.

Nelle tre linee di intervento di questo elenco c’è anche la frequenza a corsi e
l’acquisizione di certificazioni di questo o quel metodo o framework agile ma, come puoi
capire, c’è anche molto altro di più.

Ah, un’ultima cosa. Qualsiasi iniziativa di trasformazione agile tu voglia intraprendere,

spiega bene al tuo CEO (assicurandoti che capisca) che andrà condotta con un approccio
di limited blast radius, traducibile in modo non letterale come “area di impatto limitata”
(il blast radius è la distanza dal punto di un’esplosione che individua l’area interessata
dagli effetti dell’esplosione stessa).

Questo significa andare per gradi (del resto, iteratività e incrementalità sono capisaldi
del mindset agile). Non pensare di convertire ad agile tutti i team di progetto nel giro di
tre mesi, piuttosto individua un team che sarà stato preparato per tempo, magari
coinvolgendo le persone più curiose e motivate, e affidagli un progetto “non critico”,
dove sperimentare ed eventualmente fallire senza troppi danni. Del resto, se stai
imparando ad andare in bicicletta ci sta di cadere ogni tanto e sbucciarsi. Sarebbe
stupido però andare a fare da subito pratica su una superstrada trafficata.

Se poi in questa impresa pensi di farti aiutare da un qualche Agile-Life-Psycho Coach-

Evangelist-Guru va benissimo, ma sincerati che costui/costei, oltre a conoscere bene il
punto di arrivo (quelli bravi direbbero il TO-BE) conosca altrettanto bene se non meglio
il punto da cui parti (AS-IS), magari per averci lavorato ed essercisi sporcato le mani.
Sarà una polizza assicurativa in più non da poco.

Buona fortuna e ricorda, la trasformazione agile non è mai un pranzo di gala 😉

Marco Caressa

P.S. Sono Agile Certified Practitioner del PMI e Scrum Master Certified, ma questo conta
davvero poco. Per me conta più l’aver partecipato a team agili di progetto da oltre 20
anni, usando Scrum e XP dalla metà degli anni ’90, ben prima che uscisse il manifesto
agile del 2001 e che sul mercato si rendessero disponibili le settordicimila certificazioni e
credenziali oggi presenti. Soprattutto, ho praticato e pratico agile cercando di
rispettarne lo spirito di adattabilità che ne è alla base, combinando pratiche e metodi in
funzione dello specifico contesto di progetto. Del resto, come fai a definirti agile se per
te l’unico modo di fare progetti è con un solo framework, con quei soli ruoli e con quei
soli eventi e cerimonie? 😉

NOTA FINALE: Come puoi utilizzare o condividere questi contenuti?

Questo documento è distribuito con licenza Creative Commons, di tipo Attribution +

Non Commercial (BY-NC). Puoi copiare, distribuire, produrre contenuti derivati da
questo documento o re-mixarli esclusivamente per scopi non commerciali e citandomi
come autore del materiale originale.