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 tenue en respect, 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é.

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 »,…

Des releases trop fréquentes

La fin d’une itération donne lieu à une démonstration qui n’a aucune connotation de recette MOA. Cette démo consiste à vérifier que le réalisateur colle bien au besoin, il ne s’agit pas de trouver des bugs. Seule la release dont la fréquence est à définir avec le commanditaire peut avoir une connotation de recette. Planifier des releases fréquentes implique un coût à prendre en considération (stabiliser l’application, produire le build, livrer, qualifier et prendre en compte ou non les demandes de corrections dans l’itération suivante,…)

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".