Connaissez-vous la loi de Little en management de projets Agile et en Management de Portefeuille de projets ?

La loi de Little porte le nom de son inventeur, John Little, qui a établi la théorie des files d’attente dans les années 1950s.

Au départ, la loi avait pour objectif de fournir une formule très simple pour juger de l’efficacité d’un système de gestion de file d’attente.

En 1961, Little a énoncé son théorème :

Le nombre de clients dans une file d’attente est égal au taux d’arrivée moyen des clients multiplié par le temps nécessaire pour les traiter.

Puis, cette loi fut souvent utilisée dans les approches Lean pour réduire les délais. Elle permet de calculer le temps moyen passé dans un système de production entre le début et la fin d’une tâche. L’objectif est bien sûr d’augmenter la capacité de production.

De nos jours, la loi de Little est utilisée dans les approches Agile, en particulier avec Kanban, car elle établit un lien très clair entre le WIP (Work In Progress – Travail en cours), le Lead Time LT (temps moyen pour exécuter une tâche) et le Taux de production T (le débit).

Cette formule est souvent exprimée ainsi :

WIP = T x LT

ou encore

LT = WIP / T

Toute augmentation des travaux en cours WIP augmente automatiquement les délais.

Dans les faits, certaines entreprises ont tendance à faire l’inverse. Elles augmentent les travaux en cours dans l’espoir d’augmenter la production et il en résulte souvent un total désastre en ce qui concerne le respect des délais.

De même, si une entreprise a du mal à exécuter tous les projets en cours, en lancer de nouveau a peu sinon aucune chance d’améliorer la situation. Or, c’est encore trop souvent ce qui se produit.

La loi de Little dans le cadre du management de projet

Nous pouvons utiliser cette loi pour mieux comprendre pourquoi nous avons de meilleures chances de les mener à bien en manageant plus efficacement les projets en cours plutôt qu’en lançant d’autres projets.

Cela correspond comme je l’ai mentionné précédemment aux objectifs recherchés par le management des flux avec Kanban dans les projets Agiles.

Lancer trop de projets engorge les processus, surcharge les horaires de travail des développeurs et allonge considérablement le temps de réalisation.

Prenez un exemple :

• Si, à ressources constantes, vous lancez en parallèle 3 projets d’une durée moyenne de 1 an, il vous faudra 3 ans pour compléter chacun d’entre eux.
• Alors que si vous lancez les projets 1 par 1, vous aurez le premier au bout d’une année, le second au bout de 2 et le troisième de 3.

Avec l’approche « séquentielle », vous pouvez donc commencer à récolter les bénéfices de votre premier projet 2 ans plus tôt qu’avec le lancement de tous les projets en parallèle et les avantages du second une année plus tôt.

Ces bénéfices peuvent être ce qui fera ou défera le succès de votre organisation tant vos capacités d’auto-financement sont de plus en plus importantes.

Bien sûr, tout n’est pas si linéaire…

En fait, si le premier projet est délivré après 12 mois, il vous faudra supporter sa mise en production, corriger les erreurs, écouter les retours des utilisateurs, effectuer quelques ajustements impératifs…

Même avec un plan de mise en production accompagné de ressources additionnelles dédiées au support en sus des développeurs, il y aura probablement des impacts non négligeables sur leur charge de travail.

Donc, en réalité, je ne pense pas que vous terminerez systématiquement le second projet 24 mois après la date de début. Et je suis quasiment certain que le troisième projet ne sera pas fini dans la période cible de 3 ans.

Mais, en revanche, il est certain que vous obtiendrez des bénéfices des projets numéros 1 et 2 beaucoup plus tôt que si vous lancez les 3 en parallèle.

Prenez aussi en compte les dégradations de performance dues au multi-tâches permanent.

Il est clair que plus vos employés ont de projets sur lesquels ils travaillent en parallèle, plus les délais d’exécution de chacun de ces projets seront longs.

Le temps de passage d’un projet à l’autre en cours de journée ou de semaine, le switching time, est à ajouter à vos délais. En effet, cela consomme du temps que de poser votre crayon sur un sujet, vous remettre dans le contexte de votre autre tâche ou projet, puis être à nouveau pleinement productif sur celui-ci. C’est l’une des raisons pour lesquelles le multi-tâches est fortement déconseillé en approche Agile où toute l’équipe doit travailler ensemble.

En limitant le nombre de projets en cours, les ressources nécessaires sont disponibles et davantage focalisées. Le résultat est un achèvement du projet bien plus tôt.

Et pour le management de Portefeuille de Projets (PPM) ?

La loi de Little est un excellent principe à suivre dans le management des portefeuilles de projets (PPM) car elle vous permet de conserver une vue d’ensemble tout en optimisant la mise en œuvre opérationnelle.

Il vous reste cependant (encore et toujours) à bien travailler les business cases pour être certains de choisir le bon ordre de séquencement des projets !

Plus spécifiquement sur les projets Agiles

Que l’approche de développement soit Agile ou prédictive, il est critique dans chaque projet sélectionné de bien travailler sur la liste des fonctionnalités souhaitées et les prioriser en fonction des bénéfices attendus de chacune d’entre elles.

C’est en Agile en grande partie la responsabilité du Product Owner.

Et c’est, selon moi, aussi là qu’un intérêt majeur des approches Agiles va se matérialiser : Savoir quand s’arrêter !

En effet, en plus de livrer au plus tôt les fonctionnalités les plus critiques, en approche Agile vous pouvez et devez décider quand dire stop.

En arrêtant votre projet dès que les bénéfices additionnels ne justifient plus de mobiliser les ressources allouées, vous allez les libérer pour le projet suivant qui apportera davantage de bénéfices à l’entreprise.

Il y a là bien sûr un fort risque de ne jamais terminer un projet à 100% par rapport à son business case originel. Mais ceci est-il réellement un problème ?

J’ai vu dans tous les projets que j’ai suivi des fonctionnalités très prometteuses sur le papier n’être que faiblement voire jamais utilisées alors qu’elles nous avaient coûté un bras. C’était rarement dû à une pauvre qualité du livrable. Il s’agissait plutôt de besoins qui avaient évolués pendant la durée de développement du projet, ou bien dus à des changements dans les processus ou les organisations qui étaient parfois encore plus « Agiles » que nos développeurs.

Quelle est votre expérience de cette Loi de Little ?