Laissez vos développeurs choisir leur capacité !

Une question qui perturbe certains Product Owner mérite un petit article : comment prédire au mieux la capacité d’une équipe ? Je vais tenter de vous donner quelques indices dès maintenant.

Comment définir la capacité ?

J’avais moi même fait un article pour proposer une astuce sur le sujet mais il s’avère qu’elle est perturbante et parfois trop pris au mot. Oubliez la tout simplement !

Donc comment définir la capacité de faire d’une équipe de développeur ?

La base du sujet passe par la négociation

N’oublions jamais les interactions humaines qui sont une des bases de l’agilité. L’équipe de développement doit négocier avec le Product Owner pour définir la capacité.

Cela signifie que le calcul en croix pour définir une capacité ne doit qu’être une aide de préparation pour le Product Owner mais en aucun cas un indicateur stricte.

Exemple

Voici un exemple de pratiques que je vois encore de temps en temps.

Les niveaux disparates des développeurs

On a ici deux développeurs qui sont en vacance sur les 4 développeurs sur le prochain sprint de 2 semaines.

Cependant faire un produit en croix pour calculer n’a pas forcément de sens. Imaginons que les deux développeurs en vacance sont des seniors qui connaissent parfaitement l’environnement et que les deux développeurs présents sur le prochain sprint viennent seulement d’arriver au sein de la structure. Croyez-vous vraiment que le produit en croix serait cohérent ?

Ajouter des développeurs, c’est baisser la capacité de l’équipe

On entend encore parfois : « on va ajouter 5 devs, ça va bien faire avancer le projet ».

Ce n’est malheureusement pas vrai. Ajouter un développeurs qui découvrent le projet et l’équipe va avoir des conséquences à court terme bien différentes.

1/ Le nouveau développeur devra apprendre à connaitre l’environnement (technique, fonctionnement équipe voire entreprise) avant de devenir productif. Qui va l’aider ?

2/ Les développeurs présents vont devoir aider le nouveau développeur sur les différents sujets cités ci-dessus et seront donc moins productifs lors des prochains sprint.

3/ Les développeurs devront eux-mêmes s’habituer au nouveau développeur. Peut-être même que certaines nouvelles interactions seront négatives sur le fonctionnement de l’équipe.

L’ajout de développeur implique de bien comprendre les impacts à court terme. Si cela pourra (même pas certain) augmenter la productivité de l’équipe à long terme, ce ne sera pas le cas à court terme.

Donc le plus simple est de laisser l’équipe de développement entière de choisir sa capacité de faire. Aucun calcul magique ne viendra résoudre toutes ces problématiques.

Estimation base de l’incertitude

N’oublions jamais que l’estimation est par défaut bonne mais une définition fausse de la charge réelle. Trop d’éléments peuvent interférer lors de la réalisation pour arriver à l’objectif « done » par rapport à l’estimation.

La meilleure estimation est donc celle que les développeurs feront eux-mêmes en équipe lors de la sprint planning.

Cela pose des soucis dans certains contextes ?

Dans certains contextes, cette façon de faire va poser des soucis car on attend de livrer sans vraiment se l’avouer un « scope fixe » à une date T. Malheureusement peu importe la méthode de gestion de projet qu’on utilise, ce cas est impossible.

Voici un petit rappel de l’Iron triangle pour comprendre l’obligation d’avoir un élément variable :

Article à lire : Qu’est-ce que l’agile iron triangle ?

Il faudra alors sensibiliser et tenter de faire comprendre aux managers qui ont ce type d’attente, de la nécessité de comprendre l’intérêt du scope variable et du concept de l’estimation.

Ce n’est pas forcément ce qu’il y a de plus simple mais les scrum master ou les coachs agiles (souvent mandatés pour) pourront aider à amener les mentalités à changer.

On planifie le sprint par la négociation

Donc pour résumer, en général ce qui fonctionne le mieux est de laisser l’équipe négocier le contenu du sprint quite à revoir l’objectif du sprint en plein sprint planning.

Si la méthode du produit en croix peut se fiabiliser sur le long terme car l’équipe se stabilise, les Product Owner rencontreront souvent des situations plus complexes qu’une simple probabilité ne pourra résoudre.

N’oublions jamais que l’équipe ne s’engage pas à faire X points d’effort ; elle s’engage à faire au mieux.