Les pièges des approches Agiles

Bien qu’elles puissent parfois paraître simples à mettre en œuvre, il n’est pas toujours si évident de tirer parti des méthodes Agiles. Je vous présente donc ici une liste d’erreurs courantes à éviter afin de faciliter votre transition.

Mettre de côté le Manifeste Agile

Le Manifeste Agile contient l’essence de l’Agilité en termes de valeurs et de principes. Lire ce manifeste et méditer sur son contenu permet de mieux s’approprier les approches Agiles et de mieux les mettre en œuvre. Il est important de toujours garder son contenu à l’esprit. C’est l’application de ce manifeste qui permet de retirer l’ensemble des bénéfices de telles approches.

Partir sur une 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 portée. Les méthodes Agiles doivent cependant apporter une réponse aux attentes légitimes d’un client : à 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 par échange de demandes de valeur équivalente, en passant par la forfaitisation de chaque itération. D’autres solutions plus créatives proposent des montages contractuels « gagnant-gagnant ». Quoiqu’’il en soit, sans une base contractuelle saine il est difficile d’apporter la souplesse que peut attendre un client.

Avoir 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 à d’autres méthodes telles que XP ou Kanban par exemple.

Par ailleurs, il est important de rappeler – même si les choses sont en train de changer – que la certification de Scrum Master ne certifie pas grand-chose si elle ne s’accompagne pas d’une démarche individuelle. Elle ne certifie en rien la capacité de mise en œuvre, et même pas toujours la bonne compréhension de la méthode Scrum par le certifié.

Communiquer de façon trop restreinte

Les vieilles habitudes sont souvent tenaces. La chute du mur séparant le métier et le côté technique est nécessaire dans le cadre d’une approche Agile. Conserver les vieux réflexes (communication par courriel, é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égliger la rigueur

Faire son marché dans les méthodes Agiles en retenant les pratiques amusantes 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 Agiles, que ce soit de la part des développeurs (Tests, refactoring, simplicité, intégration continue, préparation des démonstrations au client,…) ou de la part du garant du respect du processus Agile et de ses règles.

Adopter un 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.

Conserver de 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, le fait de coller au plan initial plutôt que s’adapter, le fait de penser « contrat », etc.

Former des équipes trop spécialisées

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 bogue critique en production ou à l’intégration d’une fonctionnalité importante, le risque de criticité est couvert.

De plus, pour concevoir une solution ou investiguer un problème, deux cerveaux compétents (ou plus) sur un sujet valent mieux qu’un. 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. »