Le aziende che non riescono ad implementare una metodologia di project management in azienda adottano agile.
Hai provato ad introdurre una metodologia di project management in azienda, ma il risultato è stato catastrofico?
Hai sentito che con la metodologia agile è possibile avere un time to market più ridotto del tuo progetto software e ci credi?
I tuoi progetti che hai provato a gestire con una metodologia di PM tradizionale tipo PMP o Prince2 sono finiti tutti in ritardo e over budget?
…e stai ora pensando di adottare agile.
Vorrei chiarire subito un punto: Agile non vuol dire più economico. Agile non vuol dire più veloce. Agile non significa migliore qualità.
Agile si basa su 3 assunti:
- Le attività da svolgere e le funzionalità da sviluppare possono cambiare durante il progetto senza un sistema di controllo o necessità di approvazione da parte del project sponsor e senza un sistema di change management.
- Non esiste un project manager responsabile per il progetto nella sua interezza ma solo dei facilitatori o coordinatori che insieme al cliente decidono cosa sviluppare ad ogni sprint.
- La documentazione di progetto deve essere ridotta al minimo.
Problema numero 1: costi di sviluppo
Per prima cosa i costi di implementazione di un progetto in modalità agile non sono controllabili per definizione: primo perché non non esiste un project manager, né tantomeno una funzione di controllo del progetto. Mentre nelle metodologia di project management tipo PMI l’attività di Project control è presente e può essere in carico al Project Manager o ad una figura dedicata a seconda della dimensione del progetto.
Problema numero 2: tempi di consegna
Siccome le specifiche di un prodotto possono variare nel tempo anche da sprint a sprint, in generare ogni due settimane, i tempi di consegna di un prodotto sono potenzialmente infiniti. Sta al buon senso del team e del Product owner di non cambiare troppo spesso idea o di cercare di tenere il timone dritto al fine di andare live con qualche cosa. Nella metodologia PMI ma anche Prince 2, i cambiamenti di specifiche o di “scope” devono essere richieste e approvate dal team di controllo del progetto che può essere uno steering committee o il project sponsor.
Problema di agile 3: la qualità (o ambito di progetto)
Siccome i requisiti di prodotto possono variare nel tempo, non è detto che il prodotto finale rispecchi la richiesta iniziale del cliente. Agile presuppone che il cliente sia parte integrante del progetto e che contribuisca al progetto partecipando agli stand up meeting e decidendo sulle priorità e approvando direttamente modifiche. Ma nella realtà il cliente o non è presente o non è rappresentato a livello adeguato, mi spiego, negli stand up meeting potrebbe essere presente un rappresentante del cliente che non ha adeguato potere decisionale o esperienza. Suona familiare?
La qualità del prodotto non sarà migliore applicando la metodologia agile perché la stessa non prevede la definizione di specifiche contro le quali misurare la qualità del prodotto. In altre parole meno documentazione di progetto = minore possibilità di verificare che il prodotto rispetti dei criteri di qualità perché mancano le specifiche di progetto e prodotto. Ad esempio un BRD.
Problema di agile 4: la responsabilità
In Agile la responsabilità è del team, che è composto dagli sviluppatori e da un figura business. Quando il progetto è in ritardo o over budget, di chi è la responsabilità? Non è una domanda retorica. In una matrice RACI la regola numero uno è che solo una persona è Accountable, ci sarà un motivo, no?
Welcome changing requirements
Agile Manifesto https://agilemanifesto.org/principles.html
Ma sì! …cambiamo i requisiti anche ogni giorno, tanto paga il cliente.
Time to market
Il time to market non è controllabile, la possibilità di cambiare direzione al progetto in continuazione può impedire al prodotto di essere messo in produzione in quanto vengono cambiate le ragioni di essere dello stesso.
Progetti complessi con agile
Agile diventa poi particolarmente inefficace quando si tratta di implementare un progetto complesso come il re-platforming di un sito ecommerce. Immaginate di dover migrare un sito ecommerce da una piattaforma and un’altra supponiamo da Magento a Salesforce.
Ma pensiamo anche alla costruzione di una nave o di un ponte, agile sostiene che si possa sviluppare un prodotto senza conoscerne i dettagli prima di svilupparlo, di sicuro questo non è possible con un prodotto fisico, ma non è possibile nemmeno con un prodotto software complesso o un prodotto software che debba rispettare dei requisiti legali come un software bancario. Poi per carità tutto è possibile, ma difficilmente riuscirò a pensare che si possa portare in produzione un software che debba rispettare delle normative bancarie basandoci su un team di sviluppo che decide quali funzionalità sviluppare e come.
Se quindi iniziamo ad escludere agile dallo sviluppo di prodotti fisici e da prodotti software definiti da specifici requisiti, potremmo direi che l’utilizzo di agile è relegato ad un ambito di applicabilità ristretto.
Project management in azienda
Per questo, qualsiasi azienda che voglia adottare una metodologia di project management che non sia poco di più che un approccio di team work per far lavorare insieme un team di sviluppatori con una figura di business (product manager), sarebbe opportuno che imparasse a gestire i progetti con una metodologia strutturata come PMI o Prince2