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.

Commentaires

1. Le jeudi 22 mai 2008, 14:00 par Eric

Hm.

Dans mon expérience, on trouve tout de même ce genre de tâches problématiques. Pas les TU, mais plutôt la rédaction des Tests Fonctionnels (nous n'avons pas assez d'analystes fonctionnels pour ce travail, mais de toute façon, il me parait être plutôt utile que mêmes les techos se préoccupent des tests fonctionnels).
Il se passe donc deux choses: 1) les TF sont souvent omis lors du découpage en tâches; 2) même quand ils sont là, ils sont souvent négligés avant la livraison (c-à-d, on fait des livraisons où les TF n'ont pas été rédigés).

On peut se dire que, si c'est un vrai manque, alors les membres de l'équipe vont 'avoir mal' lors des retours de bugs. Mais ça n'est pas aussi simple. D'abord, ils estiment que c'est normal de recevoir des bugs. Ensuite, ça n'est que sur le long terme que les TF rédigés deviennent vraiment utiles, typiquement lors d'une version 2 pour laquelle on veut vérifier la non-régression.

Ma stratégie est donc de répéter régulièrement l'importance des TF, de m'assurer que quelqu'un les prend parfois en charge (généralement notre analyste fonctionnel déjà débordé; les développeurs refusent tout net) et de faire intervenir le Product Owner pour qu'il répète l'intérêt qu'il y voit. En parallèle, je suis transparent avec les stakeholders.

Sur ce point particulier, il est possible que le fond du problème soit que la qualité n'est pas une priorité pour les stakeholders. Mais mon argument reste valable: il est parfois complexe de s'assurer que toutes les tâches sont listées... et réalisées.

En conclusion, il faut parfois rester réaliste et être conscient qu'on ne peut pas transformer un projet ou une équipe rapidement. Parfois, cela ne sera possible que sur le projet suivant, avec la même équipe déjà sensibilisée à de nombreux aspects de l'agilité.

2. Le samedi 24 mai 2008, 12:47 par albar

Très bonne analyse, je devrais te lire plus souvent. Je pense en effet que le but est l'éradication des tâches chiantes.

Nous ne travaillons pas dans les mêmes domaines, je voudrais faire une remarque sur mon travail actuel : l'administration système. Il y a toujours plein de tâches, chiantes a priori parce que répétitives : installation de machines, ouverture de ports de firewall, installation, configuration de logiciels, etc).

Il y a deux manières d'appréhender ces tâches. Celle qui consiste à faire, et refaire perpétuellement la tâche "bêtement", à la main, et celle qui consiste à se fabriquer des outils (ou en adopter/adapter des existants) pour faire cette tâche. La seconde manière est plus lente au départ, plus efficace à l'arrivée, mais surtout beaucoup moins chiante.

Appartée : ce qui ne cesse de m'étonner, c'est le fait que beaucoup d'administrateurs préfèrent, finalement, la voie chiante, moins "prise de tête" à leurs yeux. Chacun son truc...


3. Le vendredi 30 mai 2008, 13:28 par claude aubry

Eric, le problème que tu évoques est surtout un problème de transition à l'agilité qu'on ne peut pas faire en une fois. C'est bien vrai et dans cette phase de transition il peut donc rester des tâches chiantes. Rédiger des tests fonctionnels à la fin, après coup, cela peut être chiant. Cela donne un argument pour pousser à les faire dans chaque sprint plutôt qu'à la fin.

Alain, lis-moi plus souvent comme ça tu feras aussi des commentaires plus souvent. L'exemple que tu donnes est adaptable à l'automatisation des tests. Il faut investir pour ensuite éviter de repasser les tests manuellement à chaque sprint, ce qui est typiquement chiant .

4. Le lundi 02 juin 2008, 11:32 par Rémy Sanlaville

Bonjour,

Même si je n'ai pas une grande expérience de Scrum, je suis un peu étonné par l'argument : "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".

Je suis d'accord sur le fait que Scrum se concentre sur le reste à faire et ce qui est une bonne chose. Par contre, je ne pense pas qu'on puisse se passer du relevé de temps (je l'ai d'ailleurs souvent vu dans le backlog). Cela est utile pour le burdown chart (cf. greenhopper par exemple, www.greenpeppersoftware.c... ) et nécessaire dans la gestion de projets pour pouvoir imputer dans les outils de gestion d'entreprise.

Cela n'est d'ailleurs pas un problème (comme toujours, si ce n'est pas utilisé pour taper sur les doigts) mais cela est aussi utile pour identifier rapidement des problèmes (estimation erronée et/ou le développeur ne s'en sort pas) et donc de trouver des solutions au plus vite.