Aller vers des membres d’équipes pluridisciplinaires

Après une discussion intéressante en commentaire, je me suis dit qu’un petit article sur le sujet pourrait intéresser. Comment aller vers des membres d’équipes pluridisciplinaires ?

Problèmes rencontrés

Il n’est pas rare de voir des équipes scrum qui ont des membres aux compétences diversifiées où chaque membre est expert dans une technologie particulière.

Il est vrai que le fait d’avoir des expertises dédiées sur des technologies peut amener son lot de problèmes au sein des projets réalisés en scrum.

Prenons l’exemple d’une équipe type que nous rencontrons régulièrement aujourd’hui :

• 2 développeur front
• 2 développeurs back
• 1 dba

Soucis de répartition des charges

Chaque user story (format d’item le plus fréquemment utilisé en scrum) ne demandera pas le même effort en front, en back et en base de données. Pourtant, nous estimons toujours la user-story de façon générale.

Comment faire pour assurer un travail sur un sprint pour l’ensemble des membres de l’équipe ?

Difficulté de prédictibilité

Ce soucis d’estimation générale sans la prise en compte des technologies pose un vrai soucis de priorisation pour les Product Owner qui cherche à prioriser par la valeur. Ce type de Product Owner sont encore rares mais c’est la façon la plus agile de prioriser.

Article intéressant : Livrer rapidement et régulièrement des fonctionnalités à grande valeur ajoutée

Comment peut-on prioriser par la valeur si nous ne pouvons pas connaitre la répartition des charges selon les technos ?

Chaque maladie et congé est un risque

En effet, dès qu’un des membres de l’équipe s’absente, le Product Owner se retrouve dans une situation qui peut s’avérer inconfortable. Il doit revoir ses priorisations qui ne seront plus du tout basées sur la valeur mais basées sur la capacité.

Comment se prémunir de ces situations à risque ?

Solutions envisageables

Concept « d’équipes pluridisciplinaires »

Quand chaque membre de l’équipe est totalement dédié à une technologie particulière, il est intéressant d’amener peu à peu les membres de l’équipe à aller peu à peu vers de la pluridisciplinarité. Cependant cela ne se fera pas en un jour.

Il faudra comme le rappelle Eric Siber que le contexte n’aille pas en contradiction avec ce type de pratique. Cette pratique amène un minimum d’investissement pas toujours accepté par les directions.

Pour commencer le travail, je vous conseille de sonder les différents profils, de leur expliquer votre vision à long terme et de voir le ressenti de ceux-ci avec ce concept « d’équipes pluridisciplinaires ». Il sera très compliqué d’amener ce type d’approche si les membres de l’équipe n’y adhèrent pas.

Pour avoir une bonne vision du travail qui sera à effectuer pour peu à peu migrer des profils techniques dédiées à des profils pluridisciplinaires, il est très intéressant de remplir une matrice de compétences avec l’équipe.

Voici un exemple :

Pour comprendre cette matrice, le code couleur est très simple :

• vert : je maîtrise, c’est mon expertise
• jaune : je connais mais je suis junior sur le sujet
• rouge : je n’ai aucun connaissance sur ce sujet

Dans les attendus, nous mettrons au minimum une personne qui maitrise et un backup junior afin d’assurer une meilleure continuité en cas d’absence. Cette matrice est simple mais permet de visualiser simplement les manques de l’équipe.

Article : La matrice de compétences

A partir de cette matrice de compétences, les équipes devront mettre en place des concepts de passation de connaissances : développement à deux sur un poste le temps de monter en compétence, workshop/dojo, e-learning… Si cette stratégie sera payante, il faudra accepter qu’elle mette quelques temps pour arriver à avoir des membres de l’équipe pluridisciplinaires.

Le temps d’attente pour évoluer

Cette deuxième solution est peut être moins évidente à mettre en place surtout dans les milieux où la prestation est très forte. Quand l’estimation ne prend pas en compte la charge, ce qui est fortement déconseillé, il arrive que certains membres se retrouvent avec du temps libre.

Nous laisserons alors les membres profiter de ce temps libre pour :

• monter en compétence sur leurs technos
• apprendre les technos autres
• faire du refactoring technique du déjà fait

Certaines directions ont un peu de mal à accepter ce type de choix et pourtant amener de l’excellence technique au produit permettra de limiter au maximum l’obsolescence d’arriver et d’avoir des individus de plus en plus productifs.

Maintenant c’est au scrum master et/ou au coach agile d’amener cette pratique et de sensibiliser les plus réfractaires (internes ou externes de l’équipe) à y adhérer.

Solutions à éviter

Bien que certains contextes imposent au scrum master ou autres profils à aller vers ces solutions, il faut toujours essayer même si la tâche est complexe d’aller peu à peu vers des solutions plus viables.

Les estimations par technologie

Bien que certains contextes amènent plus facilement à aller vers cette pratique, je recommande d’éviter de faire une estimation des user-stories par technologies.

Exemple qui suit l’équipe imaginée précédemment :

« En tant que client, je souhaite ajouter un produit dans mon panier ».
Back : 8 points d’effort – Front : 3 points d’effort – BDD : 5 points d’effort

Cette façon de faire qui au premier abord semble répondre à une problématique de profils en silo par technologie, elle va amener d’autres problèmes encore plus complexes à gérer :

• devoir faire de la prédictibilité pour chaque profil
• devoir synchroniser les différentes prédictibilités

Avec autant d’éléments, il deviendra très compliqué pour le Product Owner de prioriser par la valeur ; il sera contraint de prioriser par la capacité de l’équipe. Mais comme en agile, le scope est variable, ce type de priorisation contraignante va faire perdre un peu d’agilité à l’équipe.

Des user-stories par technologie

Cette pratique est encore plus dangereuse mais je l’ai déjà vu en oeuvre. Quand les user-stories sont écrites par technologie (le terme user-stories est même erroné), on se retrouve rapidement avec des décalage entre les livraisons des développeurs.

Si la notion d’indépendance est totalement perdue dans ce cadre, le décalage des développements peut amener à de réels soucis de livraisons et des continuels retours sur des anciennes user-stories réalisées.

En effet, une user-story dans une techno 1 qui doit se plugguer dans une techno 2 vont peut-être être incompatible et imposer du rework.

Conclusion équipes pluridisciplinaires

Pas toujours possible malgré de nombreuses tentatives infructueuses, il faudra toujours essayer d’aller vers des membres d’équipes pluridisciplinaires. J’espère que cet article vous aidera si vous rencontrez ce problème lors de vos missions.