Drupal et Scrum depuis les tranchées - Le scrum quotidien

Le rituel qui se répétera le plus tout au long de vos projets sera le scrum quotidien. Certains l'appelleront la mêlée, le stand-up, le scrum. Tous ces termes représentent la même chose, un moment particulier durant lequel l'équipe se rassemble devant le tableau d'avancement pour faire le point.

Les règles du scrum

  1. La première règle du scrum est que le scrum commence à l'heure. Pas d'excuse pour les retardataires, leur conscience et l'équipe finiront par les rattraper pour qu'ils arrivent à l'heure. C'est une question de respect - j'ajouterai que cela colle bien avec l'esprit agile où l'on doit livrer comme promis et qu'il faut adapter le contenu.
  2. La seconde règle du scrum est que la durée du scrum est limitée. La durée recommandée est 15 minutes. Si cela dure moins longtemps et bien c'est autant de temps de code en plus. Si cela doit prendre plus de temps, c'est sûrement que vous faites mal quelque chose (des explications plus bas ;-)).
  3. La troisième règle du scrum est qu'une seule personne a le droit de parler à la fois. Pas de conversations croisées, on écoute son interlocuteur puisqu'on doit réagir à ce qu'il se dit. C'est de l'écoute active. Le détenteur de la parole peut se matérialiser par un totem / bâton de parole, si vous ne l'avez pas entre les mains et bien... vous ne pouvez pas parler. Cela permet d'éviter que l'on vous coupe la parole.
  4. La quatrième règle du scrum est que le scrum se fait debout. Cela stimule les interlocuteurs et aide à faire en sorte que le point dure moins longtemps. Évidemment on ne lit pas ses emails ou ne joue pas à Candy Crush pendant le point quotidien.

De quoi parle-t-on pendant le scrum ?

L'équipe se tient devant le tableau d'avancement et chaque équipier répond aux trois questions suivantes : qu'ai-je fait hier, que vais-je fait aujourd'hui et quels sont les problèmes que j'ai rencontré. Chacun répond à ces questions en s'adressant aux autres, pas en s'adressant au scrum master. Le fait de faire le point devant le tableau d'avancement permet aussi de voir les stories qui avancent, c'est très gratifiant !

L'intérêt principal du scrum est que tout le monde soit au courant de ce qu'il se passe et que si une personne travaille sur un sujet potentiellement déjà couvert par une autre personne, elle sache qui aller voir pour se mettre tout de suite dans le bain. C'est un gain de temps significatif pour l'équipe.

Le second intérêt du scrum est la prise de conscience collective, chacun doit être à l'écoute des autres. En soulevant ses problèmes, un équipier lance une invitation à ce que l'on vienne l'aider. À quoi bon perdre du temps à chercher une solution si quelqu'un peut lui donner des pistes pour résoudre son problème ou mieux encore, s'asseoir à ses côtés pour résoudre son problème ensemble.
Si chaque matin une personne indique qu'elle travaille sur le même sujet sans pour autant remonter de problème, il faut se rendre compte qu'il y a un problème. Soit la personne décrit de façon trop macro ses problématiques, soit elle ne se rend pas compte qu'elle n'avance pas et doit demander de l'aide. Il est alors de la responsabilité de l'équipe de s'en rendre compte et de proposer des solutions pour régler cela. De la même façon, si vous ne comprenez pas de quoi vous parle un équipier, prenez 5 minutes avec lui après la réunion pour qu'il vous explique un peu mieux plutôt que de vous désintéresser de son travail.

Gardez à l'esprit que vous devez livrer à la fin du sprint un logiciel fonctionnel avec le maximum de valeur ajoutée. Si des stories n'arrivent pas à être fermées pendant plusieurs jours, rediscutez leur priorité pour savoir s'il ne faudrait pas plutôt se concentrer sur autre chose avec plus de valeur. Il peut être plus sage de sortir les stories du sprint et de les réintégrer plus tard, peut être de façon redécoupée.

Photo d'un paysage de bord de mer.

Et si la conversation doit prendre plus de temps ?

Parfois il vous sera nécessaire d'approfondir les échanges, notamment lorsque vous parlerez des problèmes. Le scrum n'est pas là pour résoudre les problèmes mais pour les faire remonter. Lorsque ce cas de figure se présente : identifiez que vous êtes entrain de débattre d'une piste de résolution ; interrompez la conversation ; donnez vous rendez-vous dans la journée (immédiatement après le scrum par exemple) ; laissez le scrum reprendre son cours. Cela peut s'appliquer à d'autres sujets tels que de l'architecture ou des pistes d'implémentations. Dès qu'un débat se présente, retardez le, ne conviez que les personnes concernées par la discussion (ou volontaires pour apporter leur opinion). Le temps de chacun est précieux, respectez le. Cela évite également que les gens se désintéressent. Mieux encore, si vous vous désintéressez, demandez-vous pourquoi et mettez le sujet sur la table lors de la prochaine rétrospective.

Autres points

Le scrum n'est pas uniquement là pour parler des problèmes, il n'est pas interdit de dire aux autres que l'on a apprécié quelque chose. Au contraire, je vous encourage même à vous forcer à dire régulièrement à vos équipiers ce que vous avez apprécié dans leur travail récent. (NDLR : cela peut aussi s'appliquer à vos amis et votre famille ;-)).

Les clients ne sont en général pas conviés au scrum, il nous est arrivé sur certains projets de les impliquer pour qu'ils soient concernés. Cela permet de suivre leur avancement et de se synchroniser lorsqu'il y a des dépendances sur de la production de contenu par exemple.

Attention à la routine, les scrums ont lieu tous les jours alors soyez originaux de temps à autre. Veillez à ce que les gens ne parlent pas toujours dans le même ordre, changez de pièce à l'occasion, variez l'ordre des questions on ne répondez pas à la première ou seconde à l'occasion. Aléatoirement une personne peut résumer ce que les autres ont fait pour confirmer que tout le monde est attentif.
Bref, gardez le scrum dans un esprit le plus collégial et le plus bon enfant possible, il ne faut pas que ça soit une punition !

Votre commentaire

Le contenu de ce champ sera maintenu privé et ne sera pas affiché publiquement.
Votre adresse servira à afficher un Gravatar et à vous notifier des réponses. Votre commentaire sera anonymisé si ce billet est dépublié pendant plus de 3 mois.

À propos de Julien

Co-fondateur - Scrum master & Expert technique

Utilisateur de Drupal depuis 2008, j’ai fait mes armes comme développeur chez Commerce Guys puis me suis mis à encadrer les nouveaux arrivants avant de donner des formations, participer aux avant ventes et accompagner les équipes au passage à Scrum.

Je suis impliqué dans la communauté française de Drupal depuis 2009, j’ai été tour à tour président puis vice-président de l’association Drupal France et francophonie entre 2011 et 2013.