L'outil ne fait pas le moine, et encore moins l'agiliste

dim. 04 janvier 2015

Bien que n’ayant encore jamais eu l’occasion de travailler sur un projet respectant une approche Agile, je me considère comme ayant une assez bonne sensibilité en la manière. J’ai déjà lu sur le sujet, vu plusieurs conférences, et discuter un peu avec des comparses qui avaient pratiqués et, dans l’ensemble, la philosophie agile me semble assez… logique et naturelle.

Mais assez récemment, j’ai travaillé dans deux contextes qui ont voulu aller vers l’agile :

  • Mon projet en agence où, sans quitter le cycle en V, il y a eu une volonté d’agiliser à grand renfort de management visuel.
  • Un projet en clientèle qui, officiellement, suit les grands principes de Scrum.

Dans les deux cas, je ne dirais pas que le bilan est négatif, mais un ressenti persiste toutefois : celui de n’être absolument pas plus agile. Le changement est toujours aussi douloureux qu’avant, et la « valeur » n’est pas davantage mis en avant que via une gestion classique. Pourquoi ?

Dans le premier cas, l’agilité passait par le déploiement d’un tableau de postit où regroupé les tâches, ainsi que du très fameux « Daily Meeting ». Point de vue communication, visibilité sur le projet dans son ensemble, il y a du mieux. Mais concrètement, cela ne change rien au quotidien du projet : on continue d’essayer de prévoir une version de A à Z dès le début du projet, et donc de subir les travers liés à cette approche.

Dans le second cas, la mise en place de Scrum présente pour moi plusieurs problèmes :

  • Le Product-Owner est avant tout le « Client », mais malgré cela il doit faire avec ce qui a déjà été décidé ou des contraintes qui ne lui appartiennent pas. Ses objectifs ne sont pas les nôtres et son pouvoir de décision peut être remis en question.
  • Le Scrum Master est un ancien chef de projet, et, au final, il continue à jouer ce rôle dans le projet.
  • Une partie de l’équipe est fortement ancré dans l’ancien process et vit cela comme une contrainte.

Là, je pense que l’on est dans le lot de toutes les transformations agiles. Mais je rajouterai pour moi un problème qui me semble réellement être à l’origine : encore une fois, la transformation c’est transformé sur les outils et méthodes, et non sur la philosophie en elle-même.

Daily meeting ? Sprint backlog ? Chiffrage en point ? Review ? Dashboard ? Toutes ses pratiques sont là, mais est-ce l’essentiel ? Pour moi, non, il faut avant tout comprendre la raison d’être et le pourquoi, avant de s’attacher aux outils.

Je termine ce commentaire avec une petite phrase qui m’a fait bondir : « On ne peut pas faire de l’agile sans tests automatisés ! ». Je suis totalement pour les tests mais… Pourquoi l’agile serait-il lié ?