Quels sont les différents moyens pour augmenter la productivité dans une équipe agile ?
Retour de discussion avec un Microsoft User Group

Le , par kolodz

0PARTAGES

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 :
La productivité étant mesurée en unité de bidule par unité de temps.
Pour augmenter, la productivité, il y a deux moyens :
Produire plus de bidule dans le même temps.
Produire le même nombre de bidules dans un temps plus court.
Quelle est la différence ces deux types d'augmentation de productivité ?
Note : prenez le temps de réfléchir vous-même à la question avant de poursuivre.

La réponse basique est :
Aucune, on produit plus, c'est tout.
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 :
La productivité d'une entreprise n'est pas la somme de la productivité de ses employés.
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 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Traroth2
Membre chevronné https://www.developpez.com
Le 17/09/2015 à 10:37
Comme à chaque fois qu'on met en place des métriques portant sur la production de code, les équipes vont finir par "optimiser" leur fonctionnement de manière à être bien évaluées. La qualité du code va en souffrir (puisqu'on mesure la vitesse), et la granularité des "bidules" produits va diminuer, c'est à dire que des morceaux de code de plus en plus petits et de plus en simples seront considérés comme des "bidules". C'est la manière la plus simple d'augmenter la productivité, telle qu'elle est mesurée. Les gens suivent toujours le chemin de moindre résistance...

Comme dans la politique du chiffre dans la police, chercher à quantifier du qualitatif est une mauvaise idée. Je suis toujours à la recherche d'une exception à ce principe.
Avatar de kolodz
Modérateur https://www.developpez.com
Le 17/09/2015 à 12:10
Citation Envoyé par Traroth2 Voir le message
Comme à chaque fois qu'on met en place des métriques portant sur la production de code, les équipes vont finir par "optimiser" leur fonctionnement de manière à être bien évaluées. La qualité du code va en souffrir (puisqu'on mesure la vitesse), et la granularité des "bidules" produits va diminuer, c'est à dire que des morceaux de code de plus en plus petits et de plus en simples seront considérés comme des "bidules". C'est la manière la plus simple d'augmenter la productivité, telle qu'elle est mesurée. Les gens suivent toujours le chemin de moindre résistance...

Comme dans la politique du chiffre dans la police, chercher à quantifier du qualitatif est une mauvaise idée. Je suis toujours à la recherche d'une exception à ce principe.
Le cœur du sujet n'est pas la productivité en elle-même, mais les axes d'améliorations que va ciblé une équipe en fonction du contexte. D'ailleurs, je ne comprends pas pourquoi tu pars du principe que cette discutions a nécessairement pour bût d’augmenter le nombre de "bidule" produit. C'est d'ailleurs, l'approche de la réduction du temps effectif de mise en production qui est présenté. Or d'après le second point de mon billet (cas où le temps de développement est nul) faire du "chiffre" n'est pas une valeur que peux réellement visualisé le client.

Par exemple, pour la livraison de deux fonctionnalités :
  • Livraison de deux fonctionnalités au bout de deux semaines.
  • Livraison de la premier fonctionnalité au bout d'une semaine, puis livraison de la seconde la semaine suivante.

La productivité effective de l'équipe n'a pas changé, cependant la productivité constaté à bien été amélioré.

Les points qui me semble intéressant et ayant une vraie valeur sont les suivants :
  • La mise en production continue.

Car cela à de la valeur forte pour le métier et implique une maitrise de l'ensemble de la chaine de mise en production. Et donc implique du Dev-OP's
  • La mise en exergue du travail en équipe.

En effet, l'approche proposer est de réduire la durée d'un sprint, mais aussi de réduire le nombre d’élément à traiter dans un sprint. Ce nombre d’éléments à traiter sera nécessairement inférieur au nombre de personne dans l'équipe. (Dès le début ou non.) Ce qui va à l'encontre de beaucoup de pratique actuelle qui considère que le plus productif est d'avoir une seule personne sur une tâche.

Au final, l'idée n'est pas de changer la productivité individuelle de l'équipe et donc de faire du chiffre, mais bien de changer la productivité/vitesse constaté d'un point de vue extérieur. Ceux-ci étant généralement deux choses totalement différentes.

Cordialement,
Patrick Kolodziejczyk.
Avatar de 23JFK
Membre expérimenté https://www.developpez.com
Le 17/09/2015 à 13:01
Quels sont les différents moyens pour augmenter la productivité dans une équipe agile ?
De ne pas être inféodé aux préceptes d'Agile
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web