Lors de l’Agile Tour Paris, j’au pu assister à la présentation de Tuan VO VINH, architecte à la SGIB, qui nous livre une liste des dix pièges de l’agile sous forme d’un retour d’expérience.
Voici un résumé, en dix points donc, de ce que j’ai appris :
1) arnaque sur la marchandise
Quand on achète une voiture, on s’attend à ce que les portes s’ouvrent, disait le chef de Tuan. Quand on se lance dans un projet agile, on a tendance à croire que ça va forcément réussir. Il faut donc mettre en place une liste d’exigences au début du projet, quitte à la aire évoluer en court de route
2) prime d’assurance
Il faut anticiper le coup de l’agilité. Les différentes cérémonies coûtent cher. Par exemple, le stand up meeting de 15 minutes qui se déroule chaque matin. Multiplié par le nombre de développeurs et de jour, ça peut vite monter. Pour une équipe de 8 personnes, ça représente donc une charge de 20 heures (plus de trois jours) sur un sprint de deux semaines. Dès le départ, il faut en être conscient et ne pas croire que c’est un coût transparent. Je donne l’exemple du stand up mais les autres cérémonies ou actions ne sont pas moins longues, bien au contraire.
Et il ne faut surtout pas se dire que c’est du temps de perdu. Ces cérémonies coûtent du temps mais en font gagner ailleurs.
3) l’oublie de la vision
Au fur et à mesure des différents sprints, on a tendance à oublier la cible finale en se concentrant sur les échéances rapides. Tuan cite cette équipe qui s’était tellement focalisée sur les échéances à court terme qu’elle a produit un logiciel qui n’était plus compatible avec les évolutions prévues pour la v2. Ça a alors nécessité plusieurs Sprints pour le remettre sur la bonne voie.
4) in god we trust
On fait trop confiance au PO qui peut se tromper. Il faut que le PM le chalenge. L’équipe de dev ne doit pas tout faire aveuglément mais faire des propositions au PO.
5) engagement mou
Certains sprints échouent systématiquement, sans que l’équipe ressente de la tristesse.
Le chef peut alors jouer au jeu du bâton et de la carotte : Heures sup et vendredis offerts… Mais c’est généralement contre productif. Dans l’agile, l’engagement doit être pris par l’équipe et non par le manager.
6) ne pas déranger (effet boîte noire d’un sprint)
On doit pouvoir se permettre de changer un sprint en cours de route en fonction des imprévus. Le backlog ne doit pas être sacré au point de plomber le projet.
7) faire plaisir au client et oublier le reste
Il ne faut pas déprioriser les tâches importantes pour faire entrer une tâche avec l’objectif de faire plaisir au client ou au chef d’un autre département. En agile on réalise des projets. On est pas là pour se faire des copains.
8) ce que vous voyez n’est pas ce que vous avez (Effet demo)
Le client croit que si ça marche en démo, ça marchera en prod. Le client ne sait pas que la démo ne remplace pas les tests. Dans une démo, on montre globalement à quoi ça ressemble mais ça ne garantie en rien que les fonctionnalités sont terminées. Il faut bien l’expliquer au client.
9) armée des clones
L’équipe parle d’une seule voix mais ça peut cacher les problématiques personnelles. En effet, on ne peut pas voir si l’un travail super bien ou super mal. Et les membres des équipes ont tendance à se couvrir entre eux (même si c’est vrai qu’on tombe de temps en temps sur des vrais connards, et j’en connais). Parfois une personne n’est pas à sa place, au sens qu’elle s’épanouirait surement mieux dans un autre rôle. Un des rôles du chef, c’est aussi de s’intéresser aux individus.
10) agile c’est pas pour les babies (newbies)
Le chef doit expliquer la méthode pour tuer les rumeurs, anticiper les coûts, conserver une discipline forte et favoriser le courage et la transparence. Il faut savoir être ferme mais aussi faire en sorte que les consignes soient bien comprises.
ROTI : 4/5
Bonjour et merci pour ces précisions constructives.
Pour le point (2) il n’est pas question de pinailler sur le coût mais d’en être conscient. En effet, trop de « chefs » oublient de compter la durée des différentes cérémonies dans le budget. Elles sont pourtant indispensables et elles coûtent cher une fois mises bout à bout. Ce coût est toutefois compensé ailleurs et assumé.
Je n’ai pas encore l’article dont tu parles à propos du point (5) mais je voudrais donner mon avis personnelle. À mon sens, la confiance ne devrait jamais exister dans un projet. La méfiance n’a pas sa place non plus. Je m’explique, on dispose d’un grand nombre d’outils pour tester les applications avec des méthodes comme 3T et TDD à leur tête. Je demande donc toujours à mes clients de ne jamais me faire confiance mais d’exiger des preuves. Ceci doit rester dans la limite du raisonnable.
Quant à la confiance entre les membres de l’équipe, j’aurais plutôt tendance à me baser sur l’historique en me disant qu’une personne va fonctionner pareil d’un sprint sur l’autre. Pour un « chef », le pire truc, ce n’est ni les diva ni les blaireaux mais les lunatiques.
Pour le point (7), je répondrais simplement qu’il ne faut pas faire de scrum (ou d’agile) si on ne veut pas en suivre les règles de base. Les PO qui demandent des petits trucs en plus, sauf quand c’est vraiment indispensable, c’est souvent pour rattraper leurs conneries ou pour gagner des points bidons. Le rôle du chef, ou du scrum´master, c’est de préserver l’équipe de ce genre de connerie. On ne va pas foutre en l’air le projet pour faire plaisir à Intel.
Alors on peut se dire qu’une fois ou deux, ça passe encore mais c’est la porte ouverte aux abus. Bien entendu, il faut rester ouvert aux événements importants. Si on prend Kanban, on a justement la première ligne qui est réservée pour des urgences. Notez que je parle d’urgence et pas de aire plaisir à untel.
Pour la demo (8) c’est justement une erreur de faire un raccourci entre une fonction qui marche au sens et la demo et une fonction qui marche au sens général. Dans la demo, on te montre les cas qui fonctionnent, ceux la peuvent passer en prod. Mais les cas annexes, aux limites ou non, c’est une autre histoire.
Je vais donner un exemple abusif mais concret pour expliquer. Disons qu’on calcule le factoriel d’un entier positif. On fait la demo avec factoriel de 3 et de 5. Ça me parait légitime de penser que factoriel de 4 va marcher aussi. Mais on a rien dit à propos de 6, 7, 8… Et beaucoup de gens croient à tort que c’est implicite.
Bonjour,
Certains des points présentés dans ce billet risquent, à mon avis, d’apporter de la confusion pour qui débuterait dans l’agilité.
#2 : se focaliser sur le coût est un plus grand risque que d’oublier de tenir des comptes précis. Le plus important c’est la *valeur produite* pour un coût fixé, quel que soit celui-ci. Si on a une équipe de 8 personnes, intéressons-nous à ce qu’elles peuvent concrètement apporter à des utilisateurs en une itération et essayons d’oublier les comptes d’apothicaires.
#5 : on donne souvent à l’engagement une place trop importante par rapport à la confiance nécessaire entre les membres de l’équipe. Plus de détails ici : http://agilitateur.azeau.com/post/2012/10/15/Engagez-vous-ils-disaient…
#7 : Il ne faut pas oublier que s’il n’y a pas de client, on ne travaille pas. C’est peut être une banalité mais ça peut être utile de le répéter de temps en temps. Donc, l’objectif est quand même quelque part de faire plaisir au client. A partir de là , on peut légitimement se demander en quoi une tâche est importante si elle n’est pas en accord avec cet objectif.
#8 : Quand on arrive à une démo, c’est que le logiciel est potentiellement livrable. Cela signifie que les fonctionnalités sont terminées, au sens où elles sont réellement utilisables dans le monde réel même si elles ne sont pas aussi complètes que ce que le client attend sur le long terme.
#10 : le chef doit surtout faire en sorte, dans la durée, d’être de moins en moins utile en tant que « chef ». L’autonomie d’une équipe est à ce prix. Sur la place des chefs, je conseille vivement la lecture de ce livre sur le lean management : http://informatique-conviviale.eyrolles.com/