Que dire de Belsim? Quand j’ai intégré l’équipe de Belsim, l’agilité était déjà bien en place. L’équipe de développement contenait sept personnes, un Product Owner, six développeurs dont l’un joue le rôle de Scrum Master.
Voyons si notre implémentation de Scrum était du faux ou du vrai agile…
Les rôles : Un product Owners qui s’occupe du product backlog et qui est en relation avec les clients. Un Scrum master facilite les réunions et s’assure que le processus soit respecté.
Les évènements : Les sprints durent 4 semaines, ils démarrent par un planning et se cloture par une revue face aux clients interne et une rétrospective. Chaque jour un daily meeting est tenu à heure fixe autour d’un kanban. De plus, le product backlog est estimé durant des séances de poker planning.
Les artefacts : Les user stories sont groupées dans un product backlog. Les user stories ont un titre, une description, une estimation et un numéro. Chaque sprint planning donne naissance à un sprint backlog composé des user stories et des tâches pour chacune d’elles. A la fin de chaque sprint et grace au gestionnaire de source, il est possible d’isoler un incrément qui pourrait être déployé. Ah, il manque quelque chose, le burndown chart. Il n’est pas généré ni utilisé… Il existe cependant une liste des améliorations à faire et en cours.
Vrai ou faux agile ? Je dirais vrai ! Comment Belsim est-il arrivé à une implémentation presque parfaite ? Belsim a d’abord bénéficié de formations agiles dispensées par la Scrum Alliance. Chaque développeur a été formé et certifié Scrum Master et le Product Owner a également été certifié. Était-ce suffisant ? Bien sûre que non, un coach agile a été appelé pour lancer la manœuvre. La direction et les clients internes ont été informé et soutenaient la démarche.
Tout n’était évidemment pas rose, je me souviens avoir passé deux jours à faire des estimations à l’aide du poker planning. Les rétrospectives étaient toujours les mêmes menées sans panache et ne déboulant généralement à rien. Après un certain temps, il a été décréter que les revues de sprint était inefficace et ont été annulées. Peut-être le début d’une fin…
Round 2
Après quelques années dans une autre mission, je suis revenu chez Belsim. Le premier constat, l’agilité est toujours en place… enfin presque. Durant cet entracte, de l’eau a coulé sous les ponts. Il y a eu pas mal de turn over. Le scrum master, le team leader et un développeur ont quitté le navire. Il ne reste plus que quatre développeurs, un junior, deux médiors et un sénior. Celui-ci a repris le rôle de team leader. Un product owner non certifié à la charge du projet. Un testeur à mi-temps a été engagé mais clairement sous exploité et souvent accaparé par son travail d’ingénieur. Les rétrospectives sont moles du genou, les membres de l’équipe ne sont pas forcément engagés lors des réunions.
Première constat, il y a du travail pour remettre en place l’agilité, second constat, l’équipe doit impérativement croitre. Les objectifs de la direction imposent une accélération du développement. Cela implique différentes choses :
- Le backlog doit être toiletté, complété et priorisé,
- Le testeur doit impérativement augmenter son temps de travail pour la partie test de sa mission,
- L’équipe de développement doit être renforcée,
- La formation des nouveaux arrivants doit être assuré pour assurer la meilleure intégration dans l’équipe,
- Les évènements scrum doivent être améliorés.
Nous avons engagé trois développeurs mais avons perdu le junior qui faisait déja partie de l’équipe ! L’un des développeurs est un ancien Belsim qui a déjà la certification Scrum Master, pour lui pas de problème d’intégration, ni dans le code ni dans l’organisation du travail. Les deux autres, un sénior et un médior, manque de compétences dans les outils utilisés et n’ont jamais évolués dans un environnement agile.
L’adoption de scrum par les deux nouveaux s’est déroulé sans encombre. Provenant d’une société sans méthode de planification, ils n’ont pas été difficile à former et à convaincre. Il faut même avouer qu’ils sont demandeur et donc moteur. Pour l’adoption du code, nous avons tenté de systématiser le pair programming. Nous avions eu pas mal de déboire avec le junior précédent qui présentait certaines lacunes, pour éviter le même problème avec les nouveaux, nous avons mis en place le code review. Notre architecte assure cette pratique. Elle présente plusieurs avantages :
- Le respect des coding guide lines,
- La vérification que le nouveau code s’enregistre dans la même démarche que le précédent,
- L’assurance de l’exacte compréhension du code,
- L’accroissement des compétences de l’équipe.
Je voulais enregistrer l’équipe dans une nouvelle dynamique, un dynamique qui permettrait au processus scrum de s’auto amélioré. Si l’équipe à la patate, ça se ressent pendant la journée, durant les pauses et par conséquent durant les événements scrum. Nos trois nouveaux développeurs amènent de la fraicheur dans l’équipe et du dynamisme… même si l’un d’entre eux travaille de Thaïlande.
Il ne faut pas non plus penser que tout s’est passé d’un coup de baguette magique, j’ai donné un petit coup de pouce à l’équipe. Je ne peux pas espérer que les autres change si je ne change pas moi-même, si je n’envisage pas d’autres perspectives et si je ne donne pas l’impulsion de départ. J’ai trouvé une nouvelle inspiration dans deux ressources, la première c’est le nouveau livre de Claude Aubry “L’art de devenir une équipe agile“. La deuxième c’est le site web retromat, il est un excellent référentiel de méthode pour animer les rétrospectives. Certaines d’entre elles sont tellement innovantes qu’elles poussent à se surpasser, elles font sortir des sentiers battus.
J’ai utilisé une grande diversité de rétrospective, de celles innovantes mais aussi de celles plus traditionnelles pour que l’équipe puisse respirer. Je ne me suis pas contenter d’améliorer les rétrospectives, j’ai travaillé sur le fond de l’équipe, sur ses valeurs et ses affirmations. Après plusieurs mois, et de nombreux sprints, après avoir améliorer notre processus, nous avons retrouvé une équipe agile mais à quel point ? La réponse, nous l’avons obtenue grâce au Test Nokia, il est constitué de 10 questions à choix multiple dont chaque réponse est pondérée. Le résultat est exprimé en %, le nôtre était de 77%. Ce test nous a permis de voir ce qui est bien dans notre équipe, ce qui l’est moins et ce qu’il nous manque. L’air de rien, nous avons mis au jour de nouvelles pistes d’améliorations.
Nous avons introduit un nouvel évènement scrum, il est abordé dans le livre de Claude Aubry : Le refinement meeting. A de nombreuses reprises, nous avons été confrontés à un problème de planification, des user stories non prêtes ont été poussées dans le sprint. Bien qu’elles soient débattues en sprint planning, celles-ci ne pouvaient être réalisées pour telles ou telles raisons. En organisant un refinement meeting de façon hebdomadaire, ça pousse l’équipe à se réunir et à réfléchir sur le contenu du backlog. Le product owner prépare une série de stories que nous parcourons en détail. Nous vérifions que les informations nécessaires à la réalisation soient bien présentes, nous réévaluons ou découpons les stories si nécessaire et nous planifions de nouvelles analyse pour améliorer les stories ou en créer d’autres. Bien évidement certain diront que cela peut être fait durant le sprint planning mais par expérience, on se rend vite compte que la durée du planning peut vite déraper au déficit de sa qualité.
L’épopée Belsim n’est pas finie mais elle est interrompue par le confinement du Covid 19. Mon seul regret est de ne pas avoir pu travailler avec une équipe à distance, de pouvoir mettre en place un travail collaboratif. J’aurais voulu voir si il était possible d’enchainer les sprints sans interaction physique et de tout faire par vidéo conférence.
Fin …