Si l'agile ne marche pas dans les entreprises, c'est parce que la fonction métier n'est pas suffisamment représentée dans les équipes projets.
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.
Prenons quelques exemples pour clarifier la dynamique :
- 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
etc.
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.
Il est clair que pour des projets complexes, il est nécessaire d'adopter une méthode de planification vagues roulantes planifier ou simplement adopter certaines bonnes pratiques telles que tenir une liste d'activités incomplètement définies et analyser leurs dépendances pour comprendre si celles-ci pourraient avoir un impact sur la durée totale du projet.
Les outils que les méthodologies traditionnelles de gestion de projet mettent à disposition pour gérer ces situations sont :
- Questions ouvertes (journal)
- Liste des problèmes (journal)
- Définition des activités bloquantes et non bloquantes
- Document des exigences du projet
- Document sur les exigences du produit