La proliferazione delle logiche agili

Le aziende oggi devono affrontare un crescente livello di competizione. Grazie alla digitalizzazione dei servizi e una crescente globalizzazione dei mercati, devono difendersi sia da esperti competitor internazionali sia da un numero sempre maggiore di piccole start-up che si affacciano sui loro mercati erodendo i loro margini o distruggendo le dinamiche esistenti.

In questo scenario, diventa fondamentale essere capaci di sviluppare velocemente nuovi prodotti e servizi, non solo per rispondere alle pressioni dei competitor, ma anche per anticiparle. Si assiste quindi ad una ricerca costante di nuove metodologie e pratiche che le rendano più veloci e flessibili, e quindi una crescente attenzione verso l’approccio Agile.

Questo approccio è utilizzato per rispondere rapidamente alle richieste dei clienti focalizzando l’attenzione sulla creazione del valore e la riduzione di tutti gli sprechi. Questa filosofia emerge chiaramente nei quattro valori fondamentali che vengono considerati mantra nelle aziende agili:

1. Individui e interazioni più che processi e strumenti;
2. Lavorare allo sviluppo più che scrivere documentazione;
3. Collaborazione più che negoziazione con il cliente;
4. Rispondere al cambiamento più che seguire un piano prestabilito.

Dallo sviluppo software all’azienda in generale

Per queste ragioni, l’approccio Agile, nato nell’ambito dello sviluppo software, ha “contaminato” molti mercati dove i progetti di sviluppo prodotto erano gestiti da sempre con il più tradizionale approccio waterfall o stage-and-gate, quali ad esempio l’industria manifatturiera e aeronautica.

Tuttavia, applicare queste metodologie a questi mondi si è rivelato spesso complesso e controproducente. Le grandi industrie con le loro organizzazioni strutturate sono molto differenti rispetto alle più piccole e flessibili aziende di sviluppo software. La presenza contemporanea di molti progetti, la natura dei progetti e le dinamiche più stabili hanno reso impossibile per alcune imprese abbracciare completamente la nuova metodologia, il che ha portato a sviluppare delle soluzioni intermedie. Ma i due approcci sono sostanzialmente opposti.

Waterfall vs. Agile

L’approccio waterfall si focalizza sull’anticipazione di tutte le criticità e sullo sviluppo di prodotto ben studiato e pianificato. Il successo del progetto risiede nella capacità di pianificare dettagliatamente e poi di svolgere esattamente quello che si era previsto, mentre nell’approccio Agile la pianificazione è eliminata a favore di una rapida esecuzione. A inizio progetto, si dedica tempo a definire una Vision di prodotto ma non si definisce con dettaglio cosa si andrà a realizzare.

Nell’approccio tradizionale è prevista una chiara divisione dei compiti e assegnazione delle responsabilità, mentre nell’approccio Agile il team di progetto si auto-organizza e definisce giorno per giorno che cosa andrà a svolgere. Le logiche di base sembrano molto in contrasto, quindi nasce spontanea la domanda: è possibile la coesistenza di approcci così diversi dentro i confini di una stessa azienda?

Modelli ibridi

Esiste una crescente letteratura accademica che risponde in modo affermativo. Sono stati proposti modelli, chiamati ibridi, che prevedono una commistione di approcci all’interno dello stesso progetto: lo sviluppo di una logica stage and gate a livello strategico e complessivo di progetto insieme all’ibridazione di alcune fasi esecutive e specifiche che sono invece trattate con metodi Agile.

In questo modo, sostanzialmente il progetto mantiene una logica tradizionale e solo qualche fase viene svolta in modo più flessibile. Tuttavia questo non sempre basta. Alcune aziende hanno iniziato a sviluppare progetti interamente Agili mantenendo la loro struttura tradizionale. Questa co-esistenza si è rivelata difficile. La logica Agile è basata su una prospettiva di breve periodo, ma le imprese hanno la necessità di incasellare i propri progetti in una vista più strategica. La domanda importante da risolvere è: come si può gestire la connessione tra l’organizzazione che esegue progetti di sviluppo agili e gli obiettivi strategici che devono essere raggiunti?

Al fine di rispondere a questa domanda e capire quindi come l’Agile possa avere una valenza strategica e non solo operativa, è stata svolta una ricerca empirica intervistando professionisti del settore. Questo articolo, infatti, è un estratto della ricerca svoltasi per la tesi di Laurea di Edoardo Bevilacqua dal titolo Agile and traditional project management approaches: coexisting framework and managerial practices. Dalle interviste sono state individuate le pratiche comuni utilizzate, che poi sono state riassunte nel framework descritto di seguito.

 

Un framework per l’integrazione con la strategia

Il framework è composto da due principali cicli.

Nel primo ciclo si alternano la definizione della visione globale dell’organizzazione, con la definizione della visione del singolo progetto. Questa alternanza è cruciale per il management in quanto permette di verificare che il lavoro del team sia coerente con gli obiettivi strategici dell’organizzazione.

Non importa quindi quale sia il metodo di lavoro utilizzato dal singolo team o dalla singola business unit, l’importante è che tutte la parti dell’organizzazione remino nella stessa direzione per il raggiungimento di un obiettivo comune.

Nel secondo ciclo si aggiungono invece due fasi volte a verificare che il team sia effettivamente in grado di raggiungere gli obiettivi definiti: Team Assessment e Process Assessment.

 

La visione strategica: il Department Envisioning

Il framework assume come input il piano industriale: dove vuole arrivare l’azienda tra 3-4 anni? Prendiamo ad esempio una compagnia aerea, un obiettivo potrebbe essere quello di aumentare del 30% i ricavi provenienti dai servizi annessi: attrazioni turistiche, affitto di camere, noleggio auto etc.

Dato questo input l’azienda deve strutturarsi di modo da essere in grado raggiungere l’obiettivo posto. Ovviamente non c’è una sola via per incrementare i ricavi provenienti dai servizi ma, per esempio, si potrebbe lavorare su un’applicazione annessa, sui touchpoint fisici, sul sito web e così via.

Durante la fase di Department Envisioning a cui partecipa la parte dirigenziale dell’azienda, l’obiettivo è definire questi macro-obiettivi e organizzare l’azienda in modo che gli obiettivi siano perseguibili. Ad esempio potrebbe essere necessario inserire nuove competenze in un determinato team oppure ridisegnare interamente il team di modo che sia cross-funzionale.

In questa fase i team devono essere disegnati in modo che siano il più autonomi possibile. Questo non solo garantisce maggiore efficienza del team, ma migliora anche gli indici con i quali vengono misurate le sue prestazioni, in quanto questi indicatori sono basati su obiettivi che il team può effettivamente raggiungere.

 

In questa fase è consigliato costruire una Kanban Board [1] che permetta di tenere traccia e avere una visione di alto livello delle iniziative che i diversi team stanno svolgendo.

 

Product Envisioning

Dopo aver stabilito il macro-obiettivo che il team dovrà raggiungere, il processo si muove verso la definizione di visione di alto livello del prodotto che il team dovrà poi andare a realizzare.

In questa fase è importante la partecipazione non solo di tutti i membri del team, ma anche dei principali stakeholder e di tutti coloro che saranno coinvolti nel progetto. A tale scopo, un tool che può essere utilizzato è la “Power Interest Grid” [2] che classifica i diversi stakeholder in base all’influenza che hanno riguardo le decisioni sul progetto (power) e in base al loro interesse (interest).

 

Il coinvolgimento degli stakeholder e di un set eterogeneo di attori è cruciale per diversi aspetti. Innanzitutto diverse persone con diversi background e competenze incrementano la creatività del team offrendo diversi punti di vista e quindi aumentando la possibilità di arrivare a definire un prodotto migliore.

Un altro aspetto fondamentale è l’incremento dell’efficienza ed efficacia del team. Torniamo per un attimo all’esempio della compagnia aerea e consideriamo il team addetto alla campagna marketing. Se il team è snello, cross-funzionale e possiede tutte le competenze necessarie, si potrebbe parlare di “esperimento” di marketing e non più di “campagna” marketing. Mettendo intorno a un tavolo un esperto di marketing, un esperto del prodotto, un designer, un paio di sviluppatori e uno stakeholder che abbia l’autorità di autorizzare la campagna, potenzialmente nell’arco di un paio di giornate potrebbe essere elaborata, sviluppata, approvata e messa in produzione la nuova campagna.

 

Tuttavia, come abbiamo sottolineato, non è importante mantenere solo la visione operativa del team, ma è cruciale avere una visione globale dell’organizzazione. Per questo motivo dopo la “Product Envisioning” c’è un nuovamente un ritorno alla “Department Envisioning”.

In questo modo è possibile verificare che ciò che il team andrà a realizzare sia coerente con il piano strategico dell’organizzazione.

 

Chi fa cosa: il Team Assessment

Una volta che la visione di alto livello è stata confermata, il team può procedere nuovamente con una fase di Product Envisioning più dettagliata, andando a definire le proto-personas, facendo ricerche di mercato e così via.

Tuttavia, come riportato da un Agile Coach durante un’intervista: «La fase di Product Envisioning è come uno spettacolo: sali sul palco e il concerto dura un’ora e mezza; c’è però un team di venti persone che sul palco, per mezza giornata, ha montato, smontato, ha provato i microfoni e gli amplificatori, fatto i test ambientali eccetera». Prima di definire la Product Envisioning è importante quindi fare due passaggi, il primo dei quali è il Team Assessment.

In questa fase il team si “auto-analizza” per capire se sono presenti tutte le competenze che saranno necessarie per la realizzazione del progetto. Questa fase è importante perché permette al team di capire se ci sono competenze sovrapposte e quali sono le aree di miglioramento. A tale fine può essere utilizzata una “Skills Matrix”.

 

Lavorare sul team: Process Assessment

Una volta che il team è al completo in termini di competenze, è importante valutare in processi interni ed esterni, di modo da rimuovere eventuali ostacoli al lavoro.

Un primo step è la definizione di norme di lavoro condivise tra i membri del team. Per fare ciò può essere costruito un “Work Agreement Manifesto”, un poster in cui il team definisce le regole di convivenza tra persone che lavorano fianco a fianco tutti i giorni. Ad esempio vengono stabilite l’ora dello stand-up, le modalità di svolgimento delle cerimonie e così via.

Riferendosi al modello di Tuckman [4], questa fase ha l’obiettivo di ridurre il tempo di “storming”, nella quale la presenza di diverse personalità all’interno del team porta ad avere conflitti interni, per arrivare più velocemente alla fase di “performing”, fase in cui vi è collaborazione tra i membri del team che lavora come unità focalizzata. Questo porta quindi a un incrementando dell’efficacia del team.

 

Un secondo obiettivo di questo primo step è quello di rompere le barriere emozionali tra i membri del team. Ognuno deve capire che contributo può dare, ma anche come il team può aiutare il singolo individuo a crescere. In secondo luogo il team deve capire come è inserito all’interno dei processi aziendali: a che vincoli è sottoposto? È completamente autonomo nello svolgimento del progetto? Chi sono i principali stakeholder? Per rispondere a tutte queste domande il team internamente potrebbe costruire una “Mind Map” [5] in cui vengono tracciate tutte le relazioni strette con attori esterni.

 

Una volta identificate le relazioni — e quindi anche i colli di bottiglia a cui è soggetto il team — sarà più facile per il management rimuovere tali ostacoli.

 

E infine si ritorna all’operatività: Implementation

Dopo aver integrato il progetto con la strategia dell’impresa, si inizia a svolgerlo. A questo punto, definita la parte di integrazione, si può selezionare la metodologia più opportuna. Chi lavora con Scrum inizierà la fase di Product Envision e chi lavora in logica tradizionale probabilmente inizierà una pianificazione dettagliata.

Durante la Produc Envision il team Scrum andrà quindi a definire il backlog elencando le attività da svolgere durante l’esecuzione del progetto. Dopodiché le attività verranno prioritizzate durante gli sprint planning ed eseguite nel corso degli sprint.

 

Conclusioni

Il framework descritto è il risultato una ricerca approfondita sull’operato di Agile Coach che ogni giorno lavorano per una migliore integrazione tra le logiche tradizionali di Project Management e le metodologie Agili. I coach intervistati — che hanno lavorato in più di quaranta aziende molto diverse per settore, grandezza, organizzazione e prodotti — descrivono una migliore gestione del portafoglio dei progetti in presenza di queste fasi.

Sono unanimi nel definire l’importanza di allineare, nelle prime fasi, le persone alla strategia aziendale per renderli pienamente consapevoli del loro ruolo per il raggiungimento di tale obiettivi. L’alternanza tra le fasi “Department Envisioning” e “Product Envisioning” proposta nell’infrastruttura metodologica qui presentata, garantisce il coinvolgimento delle persone negli obiettivi strategici, stimolando un continuo confronto tra la visione del singolo team e la visione globale dell’organizzazione.

L’importante non è solo essere agili e veloci nel proporre nuovi prodotti e servizi, ma anche orientare questa flessibilità verso un obiettivo strategico più ampio. In questo modo, qualunque sia la metodologia che ogni team definisce nell’operatività, ci si assicura che il suo svolgimento sia un contributo utile per il raggiungimento della strategia globale dell’impresa.