Pas de volontaire pour les tâches chiantes ?

La question ne se pose pas (trop) dans les équipes Scrum

Je faisais en début de semaine une formation de sensibilisation aux méthodes agiles. Quand j’ai parlé de l’autonomie de l’équipe et que j’ai expliqué que c’est l’équipe qui identifie les tâches et chacun qui les prend, j’ai eu une question : et si des tâches pénibles ne sont prises par personne ?

Hier, Cédric me racontait que lors d’une présentation de Scrum dans sa société de services, il a eu une remarque du même genre :

s’il y a des tâches ingrates (TU, Reporting Excel et autres documentations … ) personne ne les prendra

La question vient probablement de chefs de projet. Il s’inquiètent :

  • parce que, dans leur organisation d’équipe actuelle, ils estiment que s’ils n’intervenaient pas de façon autoritaire, des tâches ne seraient pas faites,
  • ou parce qu’ils ont peur d’être dépossédés de leurs prérogatives si l’organisation passe à Scrum.

En fait, j’ai côtoyé de nombreuses équipes qui passaient à Scrum et je n’ai jamais constaté que la transition vers plus d’autonomie de l’équipe provoquait le problème évoqué des tâches pénibles que personne ne voudrait prendre.

Il y a plusieurs raisons pour que ça ne se produise pas lors de l’application de Scrum :

  • il n’y a pas de tâches chiantes. En effet, le découpage en tâches est fait de façon radicalement différente. Lors de la réunion de planification, les tâches sont identifiées à partir des stories sélectionnées et servent clairement à finir quelque chose. Il n’y a pas de tâches décorrélées de résultats concrets, comme par exemple lorsqu’on demande à quelqu’un d’écrire à la fin du projet des jeux de tests unitaires simplement parce que c’est demandé dans le processus
  • si une tâche est malgré tout considérée comme pénible, elle sera courte. En effet, une tâche dans un sprint représente une journée de travail pour une personne. Cela sera perçu comme beaucoup moins pénible que, par exemple, la tâche d’écriture d’une documentation de conception pendant 10 jours dans une approche traditionnelle.
  • le passage d’un mode autoritaire à un mode autonome responsabilise chacun. Le fait que les tâches soient identifiées en commun pousse à les trouver moins ingrates que si elles sont imposées.
  • l’intérêt d’une tâche pour l’avancement du projet est plus explicite. Cela évite les tâches considérées comme embêtantes et qui, en plus, ne semblent pas utiles du point de vue de celui qui la fait.
  • l’estimation de la charge est faite en commun et, de plus, il n’y a pas de relevé du temps passé sur une tâche : Scrum ne se préoccupe que du reste à faire pour finir la tâche, qui peut être actualisé. Cela a tendance à moins stresser celui qui y travaille que si le délai lui est imposé.
  • l’affectation des tâches aux membres de l’équipe n’est pas faite à l’avance. Les tâches sont prises de façon opportuniste en fonction de l’avancement des travaux. La question de qui va prendre une tâche a une réponse quasi naturelle en fonction de la disponibilité et de la compétence, ce qui évite les tergiversations.

En dernier recours, si une tâche qui devrait l’être n’est pas prise, un bon ScrumMaster s’en apercevra lors d’un scrum meeting et motivera quelqu’un pour la prendre. Cela fait partie de son rôle de facilitateur de résoudre ce genre de problème.

Voir aussi