Quels sont les différents moyens pour augmenter la productivité dans une équipe agile ?

Retour de discussion avec un Microsoft User Group

Hier, j'étais au MUG (Microsoft User Group) de Lyon et parce que j'aime la bière je suis allé à l'after. Il se trouve que j'y ai entendu une conversation particulièrement intéressante sur l'Agilité et la productivité.

La discussion a débuté autour de la question suivante :
Note : prenez le temps de réfléchir vous-même à la question avant de poursuivre.

La réponse basique est :
Bien sûr la question n'est pas simple. Par exemple, dans le contexte d'une équipe travaillant en Agile, si on augmente le nombre de tâches à faire dans un sprint, l'équipe aura probablement tendance à rechercher des améliorations dans la réalisation des tâches. Cependant, si on réduit la durée d'un sprint, il est probable que celle-ci s’intéresse au coût fixe d'un sprint (réunion de début de sprint et de fin de sprint...).

Conclusion : En changeant l'approche donnée, nous n'obtenons pas les mêmes améliorations.

Je trouve ce point important, mais la conversation ne s'est pas arrêtée là. Par la suite, elle a été orientée vers un peu plus vers le point de vue client par rapport à une équipe « Agile » suite à deux questions :

• Quelle est la durée écoulée entre l'expression du besoin et la mise en production ?
• Si j'avais une baguette magique qui réduit les temps de développement à 0, quel serai le gain par rapport au processus actuel ?

Dans le cadre de notre discussion, il y avait globalement 2 semaines entre l’expression du besoin et l'intégration dans un sprint de deux semaines et une semaine supplémentaire pour la mise en production. Le temps total est donc de 3 ou 5 semaines dans le meilleur de cas.
Si on suppose un temps de développement nul, malgré le gain évident de productivité, il y a un gain de temps si et seulement si le développement dépasse la durée d'un sprint (ce qui en théorie n'est pas possible ).

Du point de vue du client, le délai n'a pas changé. On a potentiellement produit plus, car on a réalisé des story en plus (avec moins de valeurs, car moins prioritaire). Mais le fait est que le client attend exactement le même temps.

Conclusion : Une augmentation de productivité locale ne se répercute pas forcément dans une augmentation de productivité globale. Formuler d'une autre manière :
Note : Il faut bien comprendre que l'idée de ces deux argumentaires est de critiquer les aspects négatifs des méthodes agiles. Cependant, la personne ayant soulevé cet argumentaire en comprends les bénéfices.

J'avoue ne pas être sûr de la conclusion finale. Il est probable qu'on se dirige vers de l'agilité où les sprints sont définit par leur contenu et non par leur durée. Ainsi, à partir du moment où les X story du sprint sont finit, on déclenche une fin de sprint. Mais cela veut aussi dire qu'il y aura probablement plus souvent plusieurs personnes sur la même tâche ce qui, en entreprise, est considéré comme contre-productif. Peut-être à raison, peut-être à cause d'un manque de pratique...

Cela soulève la question des temps « mort », le fameux moment où tu finis une tâche et, au lieu d'enchainer sur la suivante, tu vas discuter 2/3 minutes avec ton collègue pour savoir sur quoi il travail. Apprendre ce qu'il fait, éventuellement l'aider... Est-ce du temps non productif ? Ou un investissement payant ?

Cordialement,
Patrick Kolodziejczyk.

Note : je vais probablement faire un billet sur la conférence en elle-même, mais celle-ci demande un peu plus de temps pour être présenté proprement.

Et vous ?

Qu'en pensez-vous ?