Affectation des tâches dans un projet scrum

Rapidement, une bafouille sur l’affectation des tâches dans une équipe Scrum. J’observe trop souvent des tâches avec des noms dessus. C’est une mauvaise pratique (dans ma compréhension et proposition concernant Scrum). Une équipe de dev Scrum (ne pas limiter “dev” à production de code, mais à développeur de tout ce qui est utile pour parvenir à “fini”), donc une équipe de dev Scrum est auto-organisée. Il faut l’appréhender comme un système global, comme un collectif. Et de fait ne pas affecter, assigner les tâches à une personne. L’équipe est auto-organisée car c’est ainsi que l’on obtiendra de sa part la meilleure performance.

L’assignation existe, mais elle doit rester tacite, au sein de l’équipe. L’équipe sait qui prend quoi, mais elle ne l’affiche pas.

Pourquoi garder l’assignaton de façon tacite, sous-entendue et non pas explicite ?

Car je ne souhaite entendre en tant qu’élément externe à l’équipe : “nous n’avons pas abouti sur cette user story parce que X ou Y n’a pas achevée sa tâche”. Sous-entendu : moi j’ai fait mon boulot, pas mon équipier. La réponse adéquate à mes yeux -et c’est très important- c’est “vous êtes une équipe, je ne comprends pas un discours autre que collectif ; l’équipe n’a pas réussie (pour de bonnes ou mauvaises raisons) d’achever la user story”. (Rappelez vous les stades forming,norming,etc.. des équipes).

Postulat : l’équipe s’est engagée ou a eu l’intention en tant que collectif de travailler sur ces user stories. Il n’est pas compréhensible que ce collectif se déchire plus tard.

Effet : l’équipe doit apprendre à travailler ensemble. L’équipe doit comprendre qu’elle est auto-organisée. Cela brise les silos invisibles qui pouvaient garder chacun dans son pré carré, et va libérer cette dynamique d’associations inattendues, d’engagement, qui va porter innovation et productivité.

D’ailleurs, à quoi sert-il de mettre des noms sur des post-its de tâches ?

Si ce n’est pour blâmer ?

Quelle autre raison justifie-t-il cela ? Je n’en vois pas. Donc il faut donc drastiquement l’éviter.

Si vous avez une raison valable envoyez-la moi, je la publierai, mais attention j’en ai entendu beaucoup, aucune n’a été justifiée à ce jour.

Quelques craintes infondées

C’est faux on sait pertinent quels travaux sont en cours, et c’est bien cela l’essentiel. Si on souhaite savoir qui travaille sur quoi pour de bonnes raisons il suffit d’assister au daily scrum ou de demander à l’équipe, tout simplement. Au sein de l’équipe, pas de souci, tout le monde sait qui bosse sur quoi.

Le cumul du temps si on vous le demande se déroule habituellement dans un système parallèle. J’ai passé X% de mon temps sur le projet Y. Vouloir suivre très finement le temps passé sur chaque tâche est aussi illusoire (si ce n’est encore pour blâmer) et aussi une vraie perte de temps. Ne venez pas m’expliquer que c’est pour avoir une réponse toute faite si la situation se reproduit. Depuis que j’entends cet argument je ne l’ai jamais vraiment croisé, c’est le Dahu. Les contextes changent, un contexte totalement identique c’est une illusion. Et pire, sachant que son activité est tracée à la tâche le comportement de l’équipier va changer pour respecter cette traçabilité et non plus le bienfait du projet, de l’équipe. A proscrire donc !

Les tableaux physique Scrum de management visuel remplissent très efficacement ce rôle : on connait les tâches en cours, à faire, finies, les daily scrum journaliers parachèvent le partage de cette information.

Parfait cela va les pousser à plus communiquer.

Cela ne veut pas dire

Outil électronique

PS : on peut aussi décider de ne pas laisser l’équipe s’auto-organiser, affecter les tâches, prendre l’engagement pour l’équipe, blâmer, et ainsi rester bien tranquille. C’est tellement reposant, mais dangereusement inefficace pour la création de valeur de l’organisation.