LPA #35 Qu’est-ce que la vélocité, et comment l’utiliser dans vos équipes ?

Le Podcast Agile, épisode 35 – Qu’est-ce que la vélocité, et comment l’utiliser dans vos équipes ?

Sources :

3 réflexions sur « LPA #35 Qu’est-ce que la vélocité, et comment l’utiliser dans vos équipes ? »

  1. Bonjour,

    Je fais actuellement partie d’un projet Agile, mais la vélocité de l’équipe est inscrite dans le contrat client : on doit livrer un certain nombre de point minimum X par version, peu importe la capacité.

    Notre PO calcule la vélocité comme suit : Temps passé sur les US / (Nombre de point * temps fixe estimé par point)
    Elle doit contractuellement toujours être égale à 1.
    Plus on travail (en heures passées), plus l’indicateur est faible, et plus on se fait challenger par notre management.

    Je trouve que cela va à l’encontre de la méthode Agile.

    Côté client on peut s’engager sur un nombre de point par version, avec un indicateur de vélocité qui serait = Nombre de points livrés dans la verison / nombre de points prévus au contrat.
    Et en interne, on pourrait à la limite mettre en place un indicateur de productivité (calcul actuel de la « vélocité »)

    Qu’en pensez-vous?

    Merci d’avance pour votre réponse…

    Bien cordialement

    1. Bonjour Clémence, merci pour votre question !

      Ah honnêtement ça me fait mal au coeur de vous lire, c’est exactement pour ça que j’ai produis cet épisode sur la vélocité.

      Avant tout, ce n’est pas facile pour moi de répondre sans avoir plus de contexte. Vous décrivez bien la situation mais c’est sûr qu’un échange plus long me permettrait de mieux comprendre, donc prenez mes retours avec des pincettes 🙂

      J’identifie plusieurs points :
      * Le calcul de la vélocité : tout ce qui n’est pas « ce qui est terminé pendant un Sprint » n’est pas la vélocité. Point. C’est malheureusement souvent mélangé avec la productivité (notion dangereuse dans le monde complexe !). Mélanger le terminé avec le temps passé, c’est extrêmement dangereux. J’y vois un lien direct avec la souffrance des équipiers et l’accumulation de dette technique (qui sera payée un jour ou l’autre) (et bien plus chère plus c’est tard).
      Bref vous avez tout à fait raison, ça va totalement à l’encontre de l’agile. J’ajouterais même que ça détruit de fait beaucoup de ses bienfaits.
      Revenir à la vraie vélocité, enlever le temps de l’équation et se concentrer sur la valeur pourrait être une piste ? (long chemin on est d’accords)

      * La vélocité inscrite au contrat : en la fixant à 1, le fournisseur ne peut pas gagner et donc son client non plus. Cela fait reposer la complexité exclusivement sur les épaules du fournisseur, et ça devient une relation perdante perdante (donc pour le client aussi).
      Ce que vous proposez avec l’engagement (mot dangereux, personne ne peut s’engager à tout terminer dans un Sprint, on s’engage sur notre attitude quotidienne : http://leodavesne.net/2017/11/01/lpa-38-pourquoi-est-ce-qu-on-ne-devrait-jamais-s-engager-sur-une-date-mais-sur-notre-attitude-quotidienne/) d’histoires terminées c’est déjà mieux, je l’ai vu aussi, et forcément ça arrivera plus souvent que tout ne soit pas terminé. Donc il faudra donner toute latitude à l’Équipe Scrum de prendre moins d’histoires dans le Sprint. Forcer l’équipe à en prendre plus ce serait condamner l’ensemble. Mais il faudra communiquer clairement partout sur ce qu’est la vélocité (pas que en interne, transparence !).
      Pour résumé, j’ai l’impression que vous êtes coincés avec des contrats de l’ancien monde, pas agiles du tout et de fait cela limite la création de valeur et encourage à la non-qualité, qui sera payée bien plus plus tard. Expliquer tout ça ne sera pas facile ! (mais si c’était facile, ça ne serait pas intéressant non ?)

      * Le management qui challenge : que vient faire le management là-dedans ? Vous avez un beau challenge devant vous pour expliquer que clairement ici le management détruit et n’aide pas, bien au contraire. L’Équipe Scrum a toute latitude, et si ce n’est pas le cas, eh bien ce n’est pas Scrum. Et ça limite de fait bien des bienfaits de Scrum. Pareil, il semblerait que vous soyez toujours dans une transition, les managers doivent comprendre qu’ils sont là pour supporter, aider, devenir des leaders et faire confiance, leur faire écouter Pablo Pernot ? https://www.youtube.com/watch?v=pjH0x21pYA0 Honnêtement c’est un chemin encore plus long, peut-être qu’un acteur externe débloquerait la situation (très difficile d’adresser ça de l’interne).

      N’hésitez pas à me corriger si j’ai mal compris, j’ai peut-être répondu à côté (sans doute en fait) (et désolé pour le pavé).

      En tout cas ça me donne beaucoup d’idées d’épisodes (les contrats agiles, la productivité dans le monde complexe, les relations clients-fournisseurs, etc.), merci infiniment (les brouillons sont lancés) !!

      Bon courage, priorisez vos batailles, limitez le nombre de transformations en cours, répétez réexpliquez différemment encore et encore, montrez l’exemple, essayez de proposer des essais timeboxés peut-être, prenez soin les uns des autres, et tenez-moi au courant de vos avancées. Vous n’êtes pas seule et vous pouvez y arriver, petit à petit 🙂

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. Apprenez comment les données de vos commentaires sont utilisées.