Bien qu'elles paraissent simples à mettre en oeuvre, tirer parti des méthodes Agiles n’est pas si évident. Voici une liste d'erreurs courantes à éviter.
Manifeste Agile mis de côté
Le manifeste Agile contient l’essence de l’Agilité en termes de valeurs et principes. Lire ce manifeste et méditer dessus permet de mieux s’approprier l’approche Agile et de mieux la mettre en œuvre. Il est important de garder toujours à l’esprit son contenu. C'est l'application de ce manifeste qui permet de tirer l'ensemble des bénéfices d'une telle approche.
Mauvaise base contractuelle
La contractualisation est souvent considérée comme un obstacle à une démarche Agile. En particulier de la cadre d'un contrat client/fournisseur au forfait fixant délais, budget et périmètre. Les méthodes Agile doivent cependant apporter une réponse aux attentes légitimes d'un client. A savoir le respect d'un budget et d'une date d'obtention pour un produit demandé. Plusieurs solutions existent, du forfait classique moyennant un principe de troc (voir retour d'expérience) à la régie, en passant par la forfaitisation de chaque itération. D'autres solutions plus créatives proposent des montages contractuels "win-win". Quoiqu'il en soit, sans une base contractuelle saine il est difficile d'apporter la souplesse que peut attendre un client.
Trop d’attentes vis-à-vis de Scrum
Scrum est de toute évidence la méthode Agile la plus utilisée. Cependant, elle ne propose pas grand chose en matière de conception et de développement. Se contenter de Scrum ne suffit pas, il faut également s’intéresser aux autres méthodes telles que XP. Par ailleurs, il est important de rappeler – même si les choses sont en train de changer – que la certification de ScrumMaster ne certifie pas grand-chose. Elle ne certifie en rien la capacité de mise en œuvre, ni même la bonne compréhension de la méthode Scrum par le certifié.
Communication trop restreinte
Les vieilles habitudes sont souvent tenaces. La chute du mur séparant le métier et le technique (MOA et MOE) est nécessaire dans le cadre d’une approche Agile. Conserver les vieux réflexes (communication par email, équipes isolées géographiquement, mode guichet,…) peut coûter très cher. La conversation face à face est à privilégier dans la mesure du possible et du raisonnable.
Négligence de la rigueur
Faire son marché dans les méthodes Agiles en retenant les pratiques fun et simples à mettre en œuvre au détriment des pratiques qui nécessitent une certaine discipline est une tentation assez grande. Or la rigueur fait partie intégrante des méthodes Agile, que ce soit de la part des développeurs (Tests, refactoring, simplicité, intégration continue, préparation des démonstrations face au client,...) ou de la part du garant du respect du processus Agile et de ses règles.
Rythme insoutenable
Une équipe respectée (confiance), impliquée, émancipée (à travers plus de responsabilisation) et soumise à un rythme de travail soutenable offrira le meilleur d’elle-même en matière de productivité. A l'inverse, un rythme insoutenable (sous pression) engendre généralement une dégradation de la qualité et de la productivité à long terme.
Conservation des vieilles habitudes
Nous résistons tous naturellement au changement, parfois même inconsciemment. Il faut prendre conscience de nos vieux réflexes à mettre de côté tels que le cloisonnement MOA/MOE, le fait de coller au plan initial plutôt que s’adapter, le fait de penser « contrat »,…
Membres de l’équipe trop spécialisés
Dans la mesure du possible, les membres de l’équipe ou au moins certains d’entre eux doivent être capable de travailler sur plusieurs fonctionnalités différentes. Cette approche relève ni plus ni moins d'une gestion des risques. En cas d’arrêt maladie conjugué à un bug critique en production ou à l’intégration d’une fonctionnalité importante, le risque de criticité est couvert. De plus 2 cerveaux compétents ou plus sur un domaine valent mieux qu’un pour concevoir une solution ou investiguer un problème. Cette multi compétence peut notamment s’acquérir par l’utilisation du « pair programming », de la relecture de code ou encore par un système de rotation. L'objectif étant d'atteindre la notion de "propriété collective du code".
Autre article qui peut vous intéresser : 5 idées reçues sur la gestion de projet agile.