Anti-patterns Agile : Le Chef de Projet ajoute de lui-même un ticket sur le board [FRENCH]

Dans cette série d’articles, je vais présenter des anti-patterns rencontrés lors de mes missions d’agilisation d’équipes. Qu’est-ce qu’un anti-pattern ? C’est quelque chose qui semble de prime abord être une bonne idée, mais qui au final se trouve être une mauvaise idée.

Le premier anti-pattern que je vais aborder aujourd’hui concerne le contenu du board.

Lors du Daily Stand-up, il m’arrive parfois que des personnes extérieures à l’équipe ajoutent des tickets sur le board, à l’emplacement qui leurs conviennent. Cela arrive lorsque typiquement le Chef de Projet (et oui, notre équipe a encore un Chef de Projet, mais ça c’est un autre sujet d’article :) ) estime qu’un sujet très important ne figure pas sur le board. Suivant les principes du “management traditionnel” selon lesquels le Chef de Projet est dans une logique de micro-management et de contrôle continu, il explique à l’équipe comment elle doit s’organiser. Par conséquent, il se dit que son travail est d’ajouter un ticket sur le board à tel endroit avant d’oublier et parce que peut-être qu’il pense que l’équipe va oublier de traiter ce sujet. Cela peut sembler une bonne idée. Et pourtant …

Ce que l’on recherche dans une équipe Agile, c’est qu’elle s’auto-organise. Pas simple lors de la mise en place de l’Agile : dans la plupart des organisations, les décisions sont prises top-down : le Chef de Projet - tout comme le management - prend les décisions et les impose à l’équipe. C’est sûr que ça n’incite pas l’équipe à prendre des initiatives, encore moins à s’organiser. Faire soi-même ne fait que maintenir cette situation que l’on souhaite changer.

Donc, concrètement, il m’est arrivé plusieurs fois de retirer immédiatement un ticket qui est ajouté par le Chef de Projet par exemple (qui n’est pas - en théorie - intervenir lors du Daily Stand-up puisque ne faisant pas partie de l’équipe de dev) pour au contraire demander à l’équipe comment elle souhaite gérer ce sujet : ajout d’un ticket dans tel flux, l’ajouter à la liste des points de blocages, créer un flux de tickets spécial pour ce genre de sujet, lancer une discussion après le Daily Stand-up pour creuser le sujet, confirmer que c’est un sujet d’actualité, etc … Je suis là simplement pour m’assurer que l’équipe a bien pris en main le sujet et qu’elle s’organise ainsi pour le traiter.

Le micro-management empêche l’équipe de s’auto-organiser. Bien sûr, le Chef de Projet et le management pourront répondre qu’ils manquent de confiance. Mais c’est une relation qui se construit avec le temps. Le Scrum Master est là pour s’assurer que l’équipe arrive à s’auto-organiser. Et si parfois la manière dont l’équipe s’auto-organise conduit au non traitement du sujet, il est là pour aider l’équipe à prendre conscience de ce problème et pour l’inciter à trouver une solution. Au final, le Chef de Projet et le management pourront occuper leur temps et dépenser leur énergie sur d’autres sujets plus générateurs de valeur. L’équipe, elle, sera reconnaissante de ne plus avoir l’impression d’être surveillée, d’être infantilisée et pourra souvent trouver des solutions plus pertinentes que celles imaginées par le Chef de Projet ou le management.

J’ai rencontré ce type de problème dans le cadre de la mise en place de l’Agile dans des équipes qui travaillaient en Waterfall ou ayant déjà tenté plusieurs fois de devenir Agile sans succès et dans un contexte de management traditionnel qui ne se prête pas à Agile. Ceci explique en partie le fait qu’il y ait toujours un Chef de Projet, pour faire des plannings, un reporting traditionnel et gérer les ressources. Malheureusement, c’est aussi lui qu’on félicite si le projet tient les délais ou c’est lui qu’on réprimande s’il y a des retards. Mais ça, ça pourrait faire l’objet d’un autre article. :)

Comments

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×