J’ai intégré la société WOW après avoir quitté IS2. Durant l’entretien d’embauche, j’avais eu l’occasion d’échangé à propos des méthodes agiles et avais envoyé, dans la foulée, la liste de mes dernières lectures au manager de l’équipe.
Lors de mon entré en fonction comme développeur, j’ai voulu engager l’équipe sur la voie de l’agilité. Mon manager ayant lu (en diagonale seulement) “Scrum et XP depuis les tranchés“, il était assez d’accord pour faire un essai. Malheureusement, lire un seul ouvrage sur l’agilité ne permet pas d’en comprendre toute la portée. Quand le manager interprète mal les concepts agiles ou ne retient que ce qui l’intéresse, l’issue est prévisible : l’échec !
Le manager d’équipe y a vu une méthode de contrôle du “en cours” et non une méthodologie de planification et d’amélioration. Il parlait de Scrum mais ne voulait pas perdre de temps en réunion ! Pas de sprint planning, pas de rétrospective, pas de sprint demo, pas de pair programming, pas de, pas de … Pire, pour favoriser “l’efficacité”, ils nous était “interdit” de déranger un collègue avant 13h ! La seul chose mise en place de la méthode fût un tableau d’équipe à trois colonnes (Todo, In progress, Done).
On pourrait penser que c’est déjà un début ! Mais, nous n’avions pas de product owner, pas de product backlog, pas de definiton de ready, seulement un tas de post-it. Les post-it devaient être rédigé individuellement, avant de faire la tâche, voir après l’avoir réalisée. Elle était affichée au tableau, mais ne servait à rien si ce n’est rendre visible “un pseudo état d’avancement”. Sans le daily meeting, ce tableau ne servait à rien. Certains développeurs ne prenaient même pas la peine de remplir les post-it.
Ce qui n’a pas fonctionner et une
proposition de solution:
Problème n°1 : Tout d’abord, je dirais qu’un certain type de manager déteste être épaulé, c’est comme si on les dépossédait de leur pouvoir. Il refuse de tirer profit de l’expérience, voire l’expertise de leurs “subordonnés”. Si le sujet fait partie de leur giron, ils refusent de prendre en compte les conseils avisés qu’un tiers pourrait leur donner. Vous l’aurez compris, c’était bien de la planification itérative dont il était question.
Solution : Faire lâcher prise en obtenant un mandat. Il faut être sur le même pied d’égalité que le manager afin de pouvoir expérimenter sans contraintes. Attention cela ne veut pas dire une bataille pour le pouvoir, il s’agit de mettre en place un esprit de collaboration et de changement. Une autre solution consisterait de faire intervenir un coach agile extérieur, mais cela à un coût.
Problème n°2 : Une équipe … de dix équipes … de un membre ! Dix membres organisés méticuleusement en silos. Un ensemble de projets “individuel” et une organisation visant à imposer à chacun son projet ! Comment entreprendre une démarche agile si il n’y a aucune volonté de briser les silos ? Pourquoi est-ce si difficile de faire comprendre la différence entre briser les silos et supprimer les spécialités (dont il n’était nullement question) ? Parce que, les membres de l’équipe doivent avoir la volonté de communiquer une partie de leur savoir-faire, de regarder dans l’assiette de l’autre, de sortir de leur zone de confort et d’entamer une appropriation collective du code. Le management est-il capable de comprendre l’utilité de la manœuvre et l’accepterait-il au détriment de la productivité ?
Solution : Enumérer les différents silos et leurs dangers ; le premier étant le départ d’un des membres ‘clé’ de l’équipe. Le turn over dans une équipe est inévitable. Si le départ est volontaire, le membre qui quitte l’équipe est plus ouvert à la transmission de son savoir. En revanche, en cas de licenciement, d’accident ou de licenciement sans préavis, la transmission du savoir est nulle ou pratiquement. Le pair programming peut être un bon début pour l’appropriation collective du code et de ses standards.
Petite mise à jour, j’ai eu l’occasion dans les quelques années qui ont suivies de rencontrer des personnes ayant travaillé chez WOW, ils n’y ont pas fait long feu pour diverses raisons. Au moins l’un d’eux était responsable projet et la remise de ses projets a été laborieuse. Un autre développeur est parti pour des raisons d’organisation du département, la transmission de son savoir fût quasiment nulle par manque de personnel polyvalent. Pour ma part, mon départ s’est fait après six mois et cinq jours de préavis, autant dire une transmission très limitée dans le temps, de plus je devais vite finir quelques points sur lesquelles je travaillais…
Problème n°3 : L’implémentation d’une méthode agile doit faire l’objet de réunion d’équipe, de rétrospectives afin de se fixer des objectifs, de prendre en compte l’avis de chacun et de migrer l’existant. Comment faire quand les réunions ne sont que partiellement tolérées ? Quand il faudrait avoir fini avant d’avoir commencé ?
Solution : Obtenir un mandat et un soutien inconditionnel de la direction afin de pouvoir disposer de manière rationnelle des ressources humaines et matérielles. Réunir l’équipe, commander des post-it ou installer des tableaux, nécessite l’approbation de la direction. Sans ce mandat ni ce soutien, il est impossible d’avancer. L’adoption de l’agilité ne touche pas que l’équipe de développement ; l’agilité est une mutation de l’ADN de l’entreprise.
Problème n°4 : A mon sens, il est impossible d’imposer le changement sans tenter d’obtenir un certain degré d’approbation de l’équipe. La résistance au changement est très forte dans une équipe constituée de longue date. Je me rends compte de l’importance de former l’équipe au changement, de leur communiquer les objectifs et d’énumérer les rôles et artefacts utilisés. Ils doivent être en mesure de le comprendre avant de l’accepter. Je comprends mieux maintenant certaines réflexions tel que : “Ca ne sert à rien ! Pourquoi devrais-je le faire, je n’ai jamais fait comme ça, …”.
Solution : Si le niveau de l’agiliste en charge est suffisant, former l’équipe en interne est la solution la moins onéreuse. Sinon, opter pour un cycle de formation par un organisme externe ou via un coach agile. Attention, je ne parle pas d’une “information” en interne mais bien d’une formation donnée par un formateur agréé et compétent. L’agilité mal amenée est source d’échec. Les responsables doivent être formé au même titre que les membres de l’équipe. Le changement doit être proposé en tenant compte de l’avis de l’équipe et de son historique. Le changement doit être proposé sous forme d’expérimentation et non sous forme de règles imposées. Bien entendu pour certaines d’entre elle, il ne faut pas y déroger. Ex. : « On va essayer le pair programming à une telle fréquence et dans 15 jours on en reparle et on voit ce que ça donne. » Il est évident qu’il y a un certain degré d’imposition, l’équipe n’a pas le choix, elle doit essayer le pair programming mais elle a l’opportunité de choisir comment elle va l’adopter et le faire évoluer.
Problème n°5 : Vous êtes-vous déjà demandé pourquoi certaines sociétés refusent-elles d’admettre qu’elles sont éditrices de logiciel ? Il n’y a pourtant pas photo, 10 personnes qui travaillent dans un département de développement, c’est plus que pour Windows 1.0! Dès lors, pourquoi refusent-elle obstinément de payer des licences pour des outils de développement performant ? Pourquoi seul l’open source y a t’il sa place ? “L’éditeur Vi” c’est bien si on est en 1981 ; Visual Studio c’est mieux si on est en 2011 ! Que ce soit VS ou un autre, les nouvelles génération de IDE sont fait pour augmenter notre productivité et il faut avouer que certain outils sont “Has been”. Malgré tous les plugins qu’ils peuvent embarquer, ils ne deviendrons jamais la Rools du développeur!
Solution : Pour faire du bon travail il faut les bon outils ! C’est une manière d’augmenter la productivité sans effort. Il ne faut pas hésiter à explorer d’autre options, d’interroger les membres de l’équipe ou d’autres équipes et maintenir une veille technologique. Si on gagne sa vie en faisant du développement, il faut aussi accepter de rétribuer d’autre développeur pour leur travail. Le coût d’un IDE performant est sans aucune mesure moins élevé que le coût d’un développeur!
Mais encore : De nombreux autres chantiers aurait pu être entamé afin d’améliorer l’environnement de travail tel que : L’amélioration du contrôleur de code source, l’utilisation d’un outils d’ALM pour la centralisation d’un backlog, l’établissement d’une stratégie de test et d’environnement de test, la création de comité d’architecture, la création de librairie/framework partagés, …
Solution : Le plus simple et le plus pérenne, consiste à enligner les changements les uns après les autres et surtout ne pas essayer de tout faire simultanément. Un bon point de départ consiste à mettre en place Scrum et en même temps un outil pour gérer le backlog. Ensuite, Extreme programming regroupe un bon nombre de pratiques qui peuvent être implémentées. Mais attention à ne pas essayer de tout faire en même temps surtout s’il s’agit d’une équipe et d’un produit existant. Le changement peut prendre du temps. Un an peut paraître long mais pas quand on parle changement profond dans les mentalités, c’est court ! Ne négligez pas le côté humain, il est extrêmement important !
Ma conclusion est sans appel ! Je suis le seul responsable de cet échec. Avec le recul et l’expérience, je sais que je n’aurais pas dû travailler sans mandat et sans le soutien de la direction. J’aurais dû planifier une réunion avec la direction pour exposé la méthode. Une formation à l’agilité aurait été la bienvenue afin que l’équipe soit sur la même longueur d’onde. Je n’aurais pas dû croire que le manager comprendrait de lui-même, et qu’il accepterait de l’aide d’un nouveau venu. Suite à l’échec du démarrage, j’ai baissé les bras au lieu de rebondir et d’essayer de faire entendre ma voix … mais cela était-il possible ?