Il y a un peu moins d’un an, Hugues touchait le sujet des scrums sur un projet à sa charge. Rapidement Scrum est une méthode agile de gestion de projet logiciel. Les prémisses sont très simples et focussés sur l’équipe de travail ainsi que sur le travail à accomplir. L’overhead réduit à un minimum. Pour plusieurs compagnies c’est la méthode de gestion
de projet idéale. Enfin, pour celles qui l’appliquent correctement. J’en ai encore eu l’exemple ce matin… et j’était bien heureux de ne pas participer à ce scrum. Donc, en regardant le déroulement d’un sprint au quotidien, voyons ce qui n’a pas été ce matin: La réunion quotidienne permet à tout les participants (le ScrumMaster, les développeurs, les testeurs, le directeur de produit) de connaître l’avancement du projet, de connaître les problèmes encouru. C’est le point de communication de la journée. Ce matin, la réunion s’est tenu entre les développeurs et le gestionnaire du département. Donc l’équipe de test ne sais pas nécessairement ce qui s’en vient et le directeur de produit ne sait pas non plus ce qui vas lui être livré (il y a d’autres problèmes à ce niveau mais on pourra toujours en parler plus tard). Le ScrumMaster dirige la réunion. Plutôt, il maintient le protocole de la réunion en demandant tour à tour à chaque équipier les trois questions rituelles (Qu’est-ce que tu as fait hier, Qu’est-ce que tu vas faire aujourd’hui, Quelles difficultés as-tu rencontrées). La réunion appartient à l’équipe de travail après tout. C’est une des valeurs de scrum… une équipe qui s’auto-organise et trouve des solutions par elle-même.
Il y a un autre but au protocole: la réunion devrait en tout et partout durer au maximum 15 minutes. Si on s’étends sur les tâches et les problèmes la réunion débordera du temps alloué, la valeur de l’échange est diminué (vraiment… est-ce que le directeur de produit a besoin de comprendre les problèmes de création d’une table… pas vraiment, mais il a besoin de savoir qu’un problème est présent et que ça peut impacter la livraison). Revenons donc à ce matin… la réunion s’étends sur au moins 30 minutes (j’ai quitté pour aller dinner à un certains points…) mais entre temps, le gestionnaire de l’équipe a questionné chaque développeur sur les problèmes, donné ses recommendations sur les solutions à implémenter ce qui a généré des discussions entre les développeurs eux-même… enfin pas tous, certains regardait leur montre avec impatience. Au retour de mon diner, l’équipe travaillait. Les discussions sur les problèmes se sont continué (heureusement) et les problèmes résolus… pourtant, je suis certains qu’à demander à qui que ce soit dans l’équipe s’ils ont vraiment avancé vers la livraison… hum… je ne crois pas qu’ils auraient pu m’aider puisque l’équipe ne s’est pas organisé et planifié rapidement leurs actions pour la journée. D’après vous… qu’est-ce qui ne fonctionne pas dans l’équipe? Plusieurs choses… 1. Le gestionnaire ne laisse pas l’équipe se gérer. Tout le monde est d’accord pour dire que plusieurs têtes valent mieux qu’une. Pourtant lorsqu’il vient le temps d’organiser le travail c’est souvent une seule tête qui décide pour tout le monde des actions à prendre. Problème de confiance? Problème de compétence? Difficile à dire, mais c’est certains qu’on manque bien des points de vue dans ces temps là 2. Les roles ne sont pas respectés. Que le gestionnaire du département dirige le scrum est parfaitement acceptable… mais son rôle devrait se limiter à enforcer le protocole. De cette façon l’équipe peut se concentrer sur le but de la réunion (qui est très simple après tout)… la débuter, prendre l’information et les décisions nécessaire et retourner faire ce qui permet vraiment de livrer un logiciel fonctionnel. 3. L’absence du directeur de produit et des autres personnes intéressées aux progrès et problèmes. La réunion quotidienne du scrum n’ est pas un brainstorming. C’est un point de communication qui réponds à des questions essentielles. Sans ces gens la réunion perds beaucoup de valeur comme point de communication. Et voilà! Un long blogue après une absence si prolongée. Mais comme disent les sages, il faut bien commencer quelque part 😉 ou bien recommencer quelque part. Vous avez des expériences agiles qui n’ont d’agile que le nom? Allez-y j’aimerais bien les entendre. À très bientôt!
Jean-Marc
