Réfléchissons un peu avant d’agile!

« Soyons agiles », « entreprise agile », « budgets agiles », « équipes agiles »… Arrêtons!

Arrêtons de penser que l’agilité est la réponse à tous les problèmes, mêmes ceux qui ne sont pas identifiés…

Les méthodes agiles, ça ne fonctionne pas pour tout: en fait, ça ne fonctionne bien que dans quelques cas de figure précis:

• on ne sait pas définir précisément le produit/service à réaliser
• ET qu’il peut être construit itérativement
• ET qu’on accepte de le sortir alors qu’il n’est pas fini

Explicitons un peu ces 3 éléments.

On ne sait pas définir précisément le produit/service à réaliser

Vous savez décrire précisément le périmètre? N’utilisez pas une méthode agile! Il y a tous les outils nécessaires dans les méthodes classiques pour adresser les risques et les changements. Il y a un effort à fournir dans l’expression du besoin, mais que de temps gagné par la suite… Mais attention, ne pas savoir(vouloir) décire précisément le périmètre n’est pas une « excuse » pour passer en mode agile: les itérations (sprints) sont des phénomènes vivants difficiles à maitriser. Paradoxalement, le Product Owner responsable d’orienter/traduire les besoins des utilisateurs et les représenter, doit avoir une très bonne maîtrise du produit/service à développer. Ce rôle est central dans les méthodes agiles et les volontaires sont difficiles à recruter…

il peut être construit itérativement

même si un des slogans de l’agile est « on peut se tromper, mais le plus vite possible », les allers/retours et changements de directions en cours de développement sont déstabilisants et il vaut mieux les éviter. Etre agile, ça ne veut pas dire s’agiter: un temps de réflexion est nécessaire avant de se lancer. Il faut également que le produit/service puisse être constitué de briques agrégées les unes aux autres, avec des bases solides posées dès le début.. Sinon, gare aux rétro-pédalages douloureux. Ce socle initial est une question difficile à organiser en mode agile, car il nécessite au contraire de bien comprendre le périmètre à livrer. D’où l’importance du Product Owner.

On accepte de sortir le produit/service alors qu’il n’est pas fini

En effet, une composant centrale des méthodes agiles, c’est l’interaction avec le client/utilisateur. Il faut lui montrer rapidement quelque chose sur lequel il puisse réagir, rebondir et qu’ils puissent s’approprier. C’est une contrainte forte qui amène son lot de déconvenues: de la frustrations lorsque les livraisons ne suivent pas ou la qualité n’est pas au rendez-vous; de la démotivation lorsque les fonctionnalités demandés ne sont pas priorisées comme le souhaitent les utilisateurs; du septiscisme lorsque l’ergonomie ou le visuel n’est pas soigné, voire l’impasse lorsque les évolutions techniques ou de plate-forme ne sont jamais priorisées par les utilisateurs. Ceci implique une équipe d’utilisateurs forte, impliquée et motivée à 100%, prête à s’investir sur la durée et ouverte au dialogue!

Dans tous les cas, l’agilité nécessite une formation préalable, car ces méthodes changent radicalement de l’approche classique. C’est un petit investissement qui vous rendra de grands services..

En bref, et à moins que vous cherchiez à développer 3 pages de code d’une application non stratégique, posez-vous la question plutôt en ces termes: suis-je sûr de ne pas pouvoir utiliser une méthode classique?!

Retrouvez la formation Skills4All de préparation à la certification SCRUM Master ici: https://www.skills4all.com/certification/scrum-master-formation/