Il motivo per cui agile non funziona nelle aziende è perché la funzione business non è adeguatamente rappresentata nei team di progetto.
Se vi ricordate di come è composto un team agile, il team agile è fatto per essere autonomo nelle decisioni e nell’esecuzione delle attività di progetto, infatti ci dovrebbe sempre essere un rappresentante del business che sostanzialmente decide sulle funzionalità da sviluppare e la priorità degli sviluppi.
Ora, sebbene sembri facile avere un rappresentante del business all’interno dei team agile nella pratica non è né facile né scontato che se presente un rappresentante del business, questa persona abbia le competenze, l’esperienza e l’autorità per decidere le funzionalità da sviluppare e la loro priorità.
In realtà il rappresentante del business all’interno del team agile potrebbe decidere sulle funzionalità da sviluppare e la loro priorità solo nel caso in cui sia lui il responsabile del prodotto che il team sta sviluppando.
Supponiamo che un team stia sviluppando l’applicazione nativa per un retailer e che il product owner dell’app nativa venga assegnato al team agile di sviluppo. Bene, il product owner nel momento in cui viene messo di fronte alle scelte decisionali relative all’applicazione da sviluppare si troverà nella condizione di dover chiedere pareri e autorizzazioni per ogni singola decisione rilevante che abbia un impatto sulle altre funzioni organizzative con cui l’app dovrà necessariamente interagire.
Facciamo alcuni esempi per chiarire la dinamica:
- Dobbiamo decidere la grafica dell’app –> Bisogna contattare l’art director o l’ufficio immagine dell’azienda per avere il sign off sulla grafica dell’app –> Il team agile deve aspettare le approvazioni del caso.
- Dobbiamo decidere sui metodi di pagamento da attivare sull’app –> Abbiamo bisogno del direttore finanziario che approvi i metodi di pagamento e faccia le configurazioni
- Dobbiamo decidere sui contenuti del catalogo dell’app –> Abbiamo bisogno del direttore merchandising che definisca quali sono i prodotti da mettere in vendita
e via dicendo.
Tutti questi intoppi possono essere adeguatamente gestiti con un lavoro di pianificazione iniziale e un’attività di stakeholder management che è prassi normale in un progetto gestito in modalità waterfall.
Chiaramente per progetti complessi occorre adottare una modalità di pianificazione rolling wave planning o più semplicemente adottare alcune best practice come tenere una lista di attività non completamente definite e analizzare le dipendenze delle stesse per capire se queste possano avere un impatto sulla durata totale del progetto.
Gli strumenti che le metodologie di project management tradizionale mettono a disposizione per gestire queste situazioni sono:
- Open questions (log)
- Issue list (log)
- Definizione di attività blocking e non-blocking
- Project requirements document
- Product requirements document