Planifier Moins Pour Produire Plus

Cette semaine j’ai « carte blanche » dans le 01 informatique, alors je me lache et j’explique, arguments du LEAN à l’appui, qu’il faut charger moins les équipes de production pour obtenir le maximum de productivité … et surtout, faire en sorte d’éviter l’effet BOUCHON.

Pour ceux qui n’aurait pas acheté le journal, voici l’article
Dans le monde du développement logiciel, il est de bon usage de considérer qu’une personne est au maximum de sa productivité lorsqu’elle produit en permanence, et afin d’obtenir ce résultat, de nombreux managers choisissent de charger chaque personne à 100% ou plus. Ils sont honnêtement persuadés que cette pratique leur garantira l’absence de « temps mort » synonyme pour eux de perte de productivité.

Bien que cette approche semble frappée du bon sens, elle est totalement remise en cause par certains principes prouvés du (*)Lean et d’autres principes mathématiques incontestables. Sur la base de ces éléments, il convient donc de mettre fin à cette pratique et de comprendre que pour atteindre l’optimum de productivité il est judicieux de charger moins les personnes ou les équipes de réalisation.

La métaphore que je préfère pour illustrer ce propos est celle de l’autoroute. En effet, demandez à une personne ce qu’il se passe lorsque le nombre de voitures atteint la capacité maximale de l’autoroute, elle vous répondra naturellement : il y a création d’un bouchon !

Ce bouchon n’est rien d’autre que la matérialisation physique d’une productivité faible. Chaque voiture à la capacité de rouler à 130km/h mais dans les faits, elle ne roule qu’à 30km/h.

De même que pour l’autoroute, il est nécessaire de garder des « temps libres » à l’équipe pour garantir une productivité maximale.

Lorsqu’un développeur continue à coder alors que le système de build de son code est en erreur, il ne fait que rajouter de la complexité et des erreurs dans son système. Il sera ensuite beaucoup moins performant car il consommera une grande partie de son temps à corriger ces problèmes complexes. Ce développeur devrait s’arrêter de coder, trouver ce qui pose problème et remettre en état de marche sa plateforme de build.

Pour pouvoir être plus performant, il faut pouvoir prendre le temps d’analyser son environnement et d’identifier des actions d’amélioration. Si l’équipe technique peut régulièrement « lever le nez du guidon », elle trouvera et mettra en œuvre des solutions (outils, processus …) qui amélioreront sa performance sur le moyen et long terme.

Toutes les équipes techniques sont confrontées à des urgences qu’il faut traiter immédiatement. Si aucun « temps libre » n’a été planifié, ces urgences viendront perturber le fonctionnement prévu de l’équipe, qui, pour tenir le délai, ne trouvera pas d’autres solutions que de dégrader les autres activités prévues (réduction de la qualité du code, architecture non robuste, tests non réalisés …). Ces décisions forcées réduiront d’autant la performance ultérieure

Plusieurs études ont également prouvées qu’une équipe technique est très performante lorsqu’elle travaille sur 1 seule activité à la fois. En procédant ainsi, elle évite les changements de contexte qui consomment environ 45 mn à chaque fois. Avec un planning rempli à 100%, voir plus, l’équipe va essayer de tout faire en même temps, et changer de contexte en permanence, pour au final une perte sèche de plusieurs heures de productivité par jour.

Mais que faire pour être plus productif ?

Prendre la décision de migrer vers des approches Lean pour le logiciel (Kanban …) et/ou de méthodes agiles (Scrum, XP …) car elles intègrent structurellement ces pratiques qui sont donc mises en oeuvre sans effort particulier. Et pour les managers qui appliquent des méthodes plus traditionnelles comme le cycle en V, l’alternative de mise en oeuvre consiste à planifier une occupation des équipes à seulement 80% … pour produire plus sur le moyen et long terme !

Quel individu a jamais eu en fin de semaine, et sans savoir vraiment l’expliquer, la sensation de n’avoir pas produit beaucoup alors qu’il avait travaillé beaucoup ?

La réponse est toute simple, il se trouvait dans un bouchon.

(*)Le Lean pour le logiciel est une adaptation du système de production de Toyota, appelé Thinking ou Lean Production System, qui propose une approche différente et souvent contre-intuitive pour la production industrielle.

3 réflexions sur « Planifier Moins Pour Produire Plus »

  1. Je suis bien d’accord avec toi. Toutefois nous avons constaté que les équipes Scrum avaient beaucoup du mal à entendre ces arguments, et il est très difficile de convaincre les équipes de travailler sur un tout petit nombre d’histoires. Les bouchons ont de beaux jours devant eux.

    En ce qui me concerne, il me semble important que la définition de « terminé » contienne le fait que tout les membres de l’équipe aient travaillé sur l’histoire et puissent la maintenir. Ca éviterait trop de travail en parallèle et en silos.

    Une autre piste est que les équipes apprennent à travailler sur le modèle 1 chirurgien / N assistants (pour une histoire donnée – les rôles changent pour l’histoire suivante). Dans ce modèle les assistants peuvent ne rien faire pendant quelque temps (sacrilège!) mais ils sont immédiatement disponibles. Le problème est que tout le monde veut être chirurgien en même temps…

    [Ref pour l’équpe chirurgicale : The mythical man-month, F. Brooks, 1974]

    Bruno

  2. Bonjour,
    Ton article me donne 2 pistes :
    1) Aujourd’hui, on compte 18 JxH par mois, soit 217 JxH à l’année pour modéliser la production d’un Équivalent Temps Plein (ETP). Si je comprends bien, sur un projet en mode agile, il convient de considérer qu’un ETP équivaut à 15 Jours x Homme par mois, soit environ 180 JxH à l’année. Effectivement, on retombe sur des problèmes d’objectifs de productivité fixées aux équipes travaillant dans des usines logicielles…
    2) Ou alors, on peut aussi comprendre qu’un sprint doit être planifié en tenant compte du fait que 20% de l’activité d’un ETP sera consacré à d’autres tâches (correctif urgent, capitalisation, …). Et là, on retombe plutôt sur une exigence de planification plus réaliste du sprint. Normalement, cela doit se retrouver dans la vélocité de l’équipe, c’est bien ça ?
    Cordialement, Fabrice

  3. Mon objectif n’est pas de comparer la productivité d’une équipe agile versus non agile.
    Mon constat est qu’un individu chargé à 100% (ou plus) est moins productif qu’un individu chargé à 80%.
    Celui à 100% va tomber dans un bouchon et sa productivité réelle sera 30% ou 40% et celui à 80% sera lui productif à 80% … voir plus (je l’ai constaté).
    Les méthodes agiles sont basées sur un système de PULL qui fait que les équipes ne seront jamais chargées à 100% et auront donc une productivité supérieure (vélocité). Mais je propose également une solution pour les méthodes traditionnelles … celle de charger les équipes à seulement 80%.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *