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.