Per essere AGILE e gestire progetti in maniera agile non basta una dichiarazione: le organizzazioni devono “realizzare il cambiamento”. Molto spesso le organizzazioni pensano di essere o di poter essere agile, ma in realtà non hanno fatto i conti con quello che definisco un “DNA” interno, ovvero una forte cultura aziendale che potrebbe non essere a favore dello sviluppo di pratiche agile. Prima di essere un metodo di project management, AGILE è innanzitutto una mentalità, un atteggiamento, un modo di essere.
Le organizzazioni hanno scelta? Forse no… Il nostro mondo in continua evoluzione rende piuttosto irrealistico fare piani a lungo termine (da 3 a 5 anni). Le organizzazioni affrontano così tante nuove sfide da dover essere pronte a tutto. Questo significa che devono essere in grado di avviare rapidamente progetti e di coinvolgere risorse qualificate, che siano interne all’organizzazione o acquisite attraverso contratti di subappalto o un mix di entrambe le opzioni.
La guida AgilePM di ABC (Agile Business Consortium) include un interessante documento chiamato “PAQ: Project Approach Questionnaire” utilizzato all’inizio del progetto. Questo questionario è una valutazione del rischio per la parte manageriale del progetto. Aiuta a definire se tutti gli stakeholder sono effettivamente in grado di lavorare in maniera Agile.
Vediamo 5 esempi di aree da testare prima di lanciare un progetto agile.
La tua organizzazione è davvero pronta a accettare la filosofia di lavoro agile?
La guida AgilePM del Business Consortium definisce la filosofia agile in questo modo:
“Il massimo valore aziendale si afferma quando i progetti sono allineati con chiari obiettivi di business, hanno consegne frequenti e prevedono la collaborazione di risorse fortemente motivate.”
Una volta concordata la filosofia, stakeholder di business e tecnici devono concordare i principi. I principi sono fondamentali, perché definiranno il modo in cui verrà gestito il progetto in maniera agile. Un workshop collaborativo all’inizio del progetto è il modo migliore per l’intero team per concordare questi “valori” di gestione. Gli 8 principi indicati nella guida AgilePM sono:
- Focus on the Business Need
- Deliver on Time
- Collaborate
- Never Compromise Quality
- Build Incrementally from Firm Foundations
- Develop Iteratively
- Communicate Continuously and Clearly
- Demonstrate Control
Il lato business della tua organizzazione è pronto a collaborare pienamente al progetto?
Mentre un progetto tradizionale garantisce la comunicazione col business, nei progetti agile il business non solo ha una visione chiara del cambiamento ma il business team diventa parte del team di progetto.
In che misura il business è pronto ad impegnare a tempo pieno dei rappresentanti nel team di progetto?
Un coinvolgimento attivo del business è fondamentale perché la fiducia tra il business e il progetto cresca con il tempo. Un’analisi condivisa da parte degli stakeholder di business e tecnici riguardo la soluzione sviluppata tramite il progetto mostra come il valore del business possa essere realizzato in maniera incrementale. Il business gioca un ruolo chiave in questa parte del progetto.
Dopodiché il business deve dimostrare una titolarità proattiva nel progetto e collaborare con il team di sviluppo fornendo le risorse di business. Queste non si occuperanno solo dei requisiti ma parteciperanno anche alla preparazione e esecuzione dei test funzionali in modo da convalidare i requisiti funzionali.
Il business è pronto ad accettare la flessibilità di una “soluzione” pienamente funzionante?
Se il progetto tradizionale consegna un “prodotto” che genererà benefici, lavorare in maniera agile va un passo oltre. Il cliente sta affrontando una “problematica da risolvere” e il progetto agile fornirà una “soluzione” completa funzionante che ovviamente include prodotti ma anche tutto ciò che possa contribuire alla realizzazione dei benefici e al valore del business come supporto, formazione, call center, analisi dei dati, change management ecc.
Una volta fatta una prima analisi dei dati, è possibile identificare alcune priorità? La prioritizzazione è molto importante perché, visto che il progetto agile è condizionato da un framework non modificabile di Tempo / Costi / Qualita, la flessibilità dovrà essere nelle feature, ovvero le caratteristiche della soluzione. Nel peggiore dei casi non tutte le feature (lo “scopo”) verranno consegnate, ma la soluzione sarà “lavorabile” e apporterà benefici.
Il Business deve capire che la soluzione avrà questa particolare flessibilità, che il cambiamento è inevitabile e che non c’è bisogno di entrare troppo nel dettaglio all’inizio. La soluzione si svilupperà con l’avanzamento del progetto in modo da essere la migliore soluzione possibile nel framework stabilito di Tempo / Costi / Qualità. La pianificazione è veramente adattabile e ha questa caratteristica di flessibiltà intrinseca per poter accogliere il cambiamento. La qualità e i test saranno integrati dall’inizio alla fine.
Gli stakeholder di business e tecnici sono convinti che lo sviluppo della soluzione possa essere organizzato in questo modo?
La tua cultura aziendale sarebbe pronta a stabilire team e ruoli di project management agile?
I metodi di project management forniscono un framework per rendere il progetto di successo e questo framework deve tenere in considerazione il progetto e il suo ambiente. Ma questo non basta. Uno dei maggiori fattori di successo di un progetto riguarda le risorse coinvolte. Ogni membro del team deve capire il suo ruolo e le sue responsabilità, altrimenti le risorse finiranno per fare solo ciò che vogliono o che sanno fare meglio… Ma questo potrebbe non essere quello di cui il progetto ha bisogno… Come risultato, il team di progetto sarà molto impegnato ma in realtà non starà ottenendo buoni risultati. La tua cultura aziendale è pronta a creare dei team di project management agile? I tuoi project manager sono pronti? Alcuni si sentono più a loro agio con un approccio tradizionale.
Il metodo di Project Organisation viene affrontato in modo diverso nelle diverse guide di project management, alcune accentreranno tante responsabilità in pochi ruoli, altre faranno l’opposto e saranno più dettagliate. La prima opzione ha il vantaggio della semplicità, naturalmente nel caso si trovi la risorsa giusta (magari un po’ rischioso?). La seconda opzione assegnerà più precisamente le responsabilità a diversi ruoli creando un gruppo di opinioni aperte al dibattito e alla creatività, ma che ha bisogno di più pianificazione e controllo… la tua organizzazione è pronta a questo? La guida AgilePM tratta in maniera approfondita questa tematica con 13 ruoli ben definiti nella guida.
Le risorse nella tua organizzazione sono pronte a lavorare al Solution Development Team (SDT)?
Sotto l’autorità delegata della governance di progetto, il Solution Development Team (SDT) è responsabile di trasformare le richieste nella soluzione. Ciò viene fatto in maniera iterativa. Il lato business dell’organizzazione supporta in maniera attiva l’SDT e alloca correttamente le risorse a disposizione per il successo della realizzazione.
I team Agile sono piccoli, comunicano bene e la maggior parte delle volte in maniera informale, e hanno un alto livello di fiducia e collaborazione. Sono esperti competenti che ricevono l’incarico dal loro management. L’SDT crea e convalida il suo stesso planning, la misurazione dei progressi è basata sui risultati e non sulla ripartizione dei compiti.
Ogni risorsa dell’SDT ha diverse competenze: il team ha una conoscenza collettiva di soft skill e competenze tecniche. I team sono stati formati sulle pratiche e gli strumenti utilizzati nel progetto agile, come ad esempio la raccolta di requisiti attravero le “user stories”, tutte le tecniche quantitative agile (per esempio Poker planning), workshop facilitati… I tuoi colleghi sono pronti a lavorare in questo modo?
