L’effet « banlieue »

Publié par Louis-Philippe Carignan le mardi 1 novembre 2011 à 07:15

Lors de transitions Agile, il m'arrive de rencontrer des équipes de développement où les membres de l'équipe de réalisation sont habitués à travailler individuellement. Mes affaires. Mes tâches. Mon travail. Ma réussite pour ma négociation salariale annuelle. C'est ce que j'appelle l'effet "banlieue". Chaque membre de l'équipe a sa maison, son terrain, sa piscine, ses choses. Bien qu'il envoie la main à son voisin lorsqu'ils se croisent en revenant du travail, disons que les canaux de communication n'encouragent pas une interaction fluide et spontanée entre voisins. J'exagère (à peine).

image_banlieu

Bien que le guide Scrum ne stipule pas explicitement que les membres de l'équipe de réalisation doivent travailler en équipe, ce dernier laisse sous-entendre la force du travail d'équipe. Entre autres, la page 6 du Guide Scrum spécifie quelques caractéristiques de l'équipe de réalisation :

  • They are self-organizing.
  • Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole;
  • Development Teams do not contain sub-teams dedicated to particular domains like testing or business analysis.

En tant que Scrum Master, il est de votre responsabilité à faire travailler les membres de l'équipe de réalisation en ... équipe. Lorsque vous arrivez dans une équipe qui débute avec Scrum, que pouvez-vous faire pour articuler cette vision auprès d'une équipe qui n'est pas habituée de travailler ensemble? Que ce soit un comportement acquis par expérience ou simplement par l'application du gros bon sens dans le passé, n'y aurait-il pas une façon de contrer l'effet « banlieue »? N'y a-t-il pas une façon de travailler en équipe dans l'intérêt du client?

Selon mon expérience, la planification du sprint représente un bon moment pour briser cet effet. Je remarque souvent que les demandes insérées dans le carnet de sprint se séparent en deux catégories.

Demande connue

Lorsqu'il est temps de découper une demande en tâches, il y a probablement un membre de l'équipe qui est plus à l'aise pour prendre en charge cette demande du carnet de produit. J'appelle souvent cette personne le coordonnateur de la demande. Au lieu de le laisser réaliser cette demande de A à Z (effet banlieue en plein action), suggérer, en tant que Scrum Master, au coordonnateur si d'autres personnes peuvent se joindre à lui. Par exemple, est-il possible d'intégrer un autre membre de l'équipe qui n'a pas vu cette partie du code?

Une autre façon d'enclencher le travailler d'équipe est de suggérer au coordonnateur de travailler avec un nouveau membre de l'équipe pour faciliter son intégration. Par exemple, Mathieu a écrit une bonne partie du module de visualisation. Dave vient de s'ajouter à l'équipe. Lors de la planification de sprint, il y a une nouvelle demande reliée au module de visualisation. Mathieu invite Dave à découper cette nouvelle demande en tâches tout en lui expliquant le travail à faire. Cette initiative enchaînera alors un travail d'équipe entre ces deux personnes pour le bien du projet.

Recherche et exploration

Lorsqu'une demande de recherche et d'exploration est ajoutée au carnet du sprint, il il se peut qu'aucune personne ne puisse être le coordonnateur puisque l'équipe doit débroussailler une nouvelle technologie. Lors de la planification du sprint, le Scrum Master peut suggérer à quelques personnes comment elles peuvent attaquer une telle demande et corroborer leurs trouvailles plusieurs fois au cours du sprint. Le Scrum Master peut même leur suggérer de faire le point avec le propriétaire de produit pour forcer l'interaction continuelle entre ces deux rôles.

Pour conclure, ce travail d'équipe peut sembler contre-intuitif à prime à bord puisque les membres de l'équipe de réalisation perdent du temps en collaborant et en échangeant entre eux. Ne devrait-il pas tout simplement devenir des experts dans une section du code pour ainsi prendre toutes les demandes en charge pour cette section? Oui si on veut optimiser chaque ressource mais d'un point de vue système, toute l'équipe et le client y gagne à long terme. Et vous, êtes-vous témoin de l'effet « banlieue » dans votre équipe?

Mots-Clés :
blog comments powered by Disqus

0 Comments:

Post a comment

Comments have been closed for this post.