Voyons ensemble ce que peut vous apporter cette méthode mais également ses défauts

Commençons par ses dangers

  • Mauvaise compréhension de l’agilité Un réel investissement de l’entreprise est nécessaire en temps, en effort et en argent. Car au-delà de l’équipe de développement, toute l’organisation doit être formée et changer ses process de fonctionnement et de décision.
  • Patrimoine documentaire des produits incomplet Un travers de la méthode est que le développement va vite en s’adaptant aux changements d’exigence des clients mais sans que tout soit documenté correctement. A moyen terme, la documentation du produit devient donc incomplète voire fausse. L’arrivée d’un nouveau membre dans l’équipe sera donc compliquée si le patrimoine documentaire du produit n’est pas correctement suivis au fil de l’eau.
  • Changement de mindset parfois difficiles à adopter Certains principes ne sont pas faciles à accepter car en rupture forte avec le mode de management traditionnel ==> Par exemple, l’équipe ne vous donnera pas de planning ni de roadmap long terme ; en effet la réalisation des demandes ( US ) se fait à chaque vague de développement ( SPRINT ). Ensuite, la disponibilité des clients est indispensable pour les démonstrations et tests. Nous sommes loin du client qui donne son cahier des charges et revient 6 mois plus tard pour prendre livraison du résulat. Dernier point qui peut heurter les managers, la réalisation des développements est pilotée par la priorisation des besoins des clients et la valeur apportée pas par le budget et la hiérarchie.
  • Pas de roadmap ou feuille de route à long terme Comme évoqué au point précédent, la méthode de priorisation par la valeur et le besoin des clients ne permet pas de construire cette roadmap. La construction du budget et la planification sont donc difficiles à prévoir correctement.
  • Difficile à mettre en place pour un projet complexe et d’une trop grande envergure Cela fonctionne bien pour des petites ou moyennes équipes, idéalement entre 5 et 10 personnes. Pour une équipe importante ou un gros projet, nous conseillons le framework SAFe.

Continuons avec les apports positifs de cette méthode

  • Meilleure maîtrise sur le produit final Le produit est construit au fil des sprints de manière incrémentale. A chaque sprint, l’équipe de développement peut prendre en compte les retours des utilisateurs suite à la démonstration. Le produit final est donc “ajusté” au fil de l’eau pour être en parfaite adéquation avec le besoin et nos utilisateurs ou clients.
  • Efficacité des équipes accrue La forte responsabilisation des équipes, le fait d’aller à l’essentiel et surtout à ce qui ramène le plus de valeur augmente considérablement la productivité de toute l’équipe projet.
  • Qualité des livraisons Des tests des développements sont prévus à la fin de chaque sprint. La non-régression est systématiquement vérifiée ce qui assure naturellement une bonne qualité du produit final.
  • Augmentation de la satisfaction des utilisateurs Comme déjà expliqué, les clients ou utilisateurs sont impliqués au coeur du projet, assistent aux démonstrations et font des tests. Ils adaptatent également leur demande d’origine, en fonction des échanges avec l’équipe de développement ou de nouvelles contraintes. Tous ces éléments améliorent évidemment leur satisfaction au fil des sprints.
  • Améliorer la rentabilité du produit final La priorisation des US à forte valeur ajoutée et la définition du MVP (Minimum Valuable Product) impliquent la mise en place d’une application “qui rapporte“ plus rapidement que dans une méthode classique. Le time to market est donc optimisé.

Dans un prochain article, nous verrons ensemble un peu de vocabulaire et la méthodogie ( US,sprint, backlog, MVP etc… )