Le triangle de fer agile. Et les individus dans tout ça ?

Gregory

Ces derniers temps, j’ai observé plusieurs projets valorisés pour leur agilité, à juste titre d’ailleurs : le livrable satisfaisait les utilisateurs, le périmètre avait été retravaillé, le produit avait été livré en un temps record, le budget avait été tenu. Une chose seulement est passée sous le tapis : les acteurs sur ces projets s’écharpaient, courraient après le temps, n’avaient plus le temps de prendre du recul.

J’ai donc pensé qu’on ne regardait pas les bons indicateurs ou tout du moins tous les indicateurs. Et j’ai repensé au triangle de fer.

Triangle représentant le triangle projet périmètre, coût, budget

Nous autres agilistes avons l’habitude de présenter l’agilité au travers de la représentation du triangle de fer, autrement appelé triangle projet ou project management triangle.

En tant qu’agilistes, nous utilisons cette représentation pour expliquer la différence entre un projet “classique” et un projet “agile”.

Cependant et aux vues de mes observations récentes et celles qui me sont revenues en tête, il me semble que cette façon d’expliquer l’agilité masque d’autres variables et nuit à l’agilité.

J’ai donc décidé d’arrêter de parler de triangle de fer et de passer au pentagone de fer.

Le triangle de fer “agile”

Le triangle de fer, pour celles et ceux qui seraient passés à côté est une représentation visuelle permettant de comprendre que la qualité d’un livrable est cadrée par la tenue d’un périmètre, d’un délai et du budget.

La mécanique de ce triangle est telle que lorsque qu’un des sommets augmente, les autres sommets évoluent aussi (ex : lorsque le périmètre augmente, le délai et/ou le coût augmentent aussi).

NB : La notion même de qualité est interprétable. Elle peut signifier aux choix du lecteur : la réponse au besoin client, la qualité intrinsèque, la réponse aux spécifications...

Il existe d’ailleurs d’autres représentations où le terme “qualité” sort du centre pour former un nouvel angle formant ainsi le Diamant du management de projet. 

A diamond with the points labelled cost, quality, scope and time
https://www.prince2.com/eur/blog/project-triangle-constraints

Le PMBOK (Project Management Body of Knowledge) du PMI a fait évoluer la forme vers la Project Management Star. Parmi les modifications, la séparation du périmètre et de la qualité.

A 6-pointed star with the points labelled schedule, risk, scope, quality, budget and resources
https://www.prince2.com/eur/blog/project-triangle-constraints

Mais là encore la notion de qualité peut regrouper plusieurs significations.

Quelle que soit la forme, les observations de projets classiques remontent que la majeure partie du temps le sommet “périmètre” du triangle est difficilement renégociable et diminue rarement.

Aussi, la satisfaction client étant, dans ces systèmes-là, mesurée par le nombre de fonctionnalités qu’on lui livre, la « qualité » est représentée quasiment exclusivement par le “périmètre”.

Le fait est qu’avec l’incertitude de production, la plupart de ces projets font mécaniquement évoluer le délai voir le coût du projet.

L’idée du triangle de fer “agile” est de modifier cette dynamique en assurant ce qui peut être défini dès le départ, c’est-à-dire le coût et le délai et en lâchant prise sur le périmètre.

L’agilité repose dès lors sur un périmètre fluctuant qui, allié à la priorisation, permettra de livrer le maximum de valeur aux clients dans les temps et dans le budget.

Du triangle au carré

Il est déjà largement répandu que la représentation sous forme de triangle masque une variable injustement oubliée, au détriment des clients principalement : la qualité intrinsèque.

La notion de qualité intrinsèque fait référence à la fiabilité des éléments construits ou développés. Ex : Une fonction avec une forte qualité intrinsèque sera exempte d’anomalies, de dysfonctionnements.

Les systèmes basés sur le triangle de fer cherchent donc à maximiser la production de fonctionnalités dans les temps et le budget quitte à rogner sur la qualité intrinsèque.

Le résultat est un succès au niveau projet (sortie de l’attendu dans les temps et les budgets) mais un désastre au niveau produit et pour l’expérience utilisateur quand ce n’est pas également une catastrophe en termes de maintenabilité une fois le livrable en service ».

On observe que tant que la variable de “qualité intrinsèque” n’est pas explicitée elle est minimisée (donc autant dans le triangle de fer que le diamant ou l’étoile). Et paradoxalement, elle est minimisée car on part du principe implicite que tout ce qui est construit est intrinsèquement de qualité (sinon c’est un signe d’incompétence de l’équipe en charge de la construction).

Pour avoir échangé avec de nombreux agilistes, la forme du carré (ou un diamant particulier) semble de plus en plus nécessaire lorsque l’on parle d’agilité avec cette représentation, elle permet d’expliciter la variable pour la traiter à juste titre.

Du carré au pentagone

La première valeur du manifeste agile est : les individus et les interactions plus que les processus et le outils. L’agilité s’appuie principalement (c’est un euphémisme) sur l’énergie et l’intelligence des individus.
Pourtant lorsque l’on représente le triangle de fer que ce soit pour parler des projets classiques ou des projets agiles, nous ne les faisons pas apparaître.

La mécanique est pourtant exactement la même. Pour tenir un périmètre dans les temps, dans les budgets et avec un bon niveau de qualité intrinsèque, il faut des personnes. Et il faut que ces personnes aient le temps, l’énergie, le bien-être nécessaire pour réaliser ces enjeux.

C’est évident, c’est d’ailleurs tellement évident et plein de bon sens que, comme tout ce qui est évident et plein de bon sens, on n’en parle pas, on l’implicite sur le projet. Et à force de maintenir l’implicite et de ne pas en parler, on le perd de vue et on l’oublie.

Et quand on oublie l’humain dans un projet, généralement ce n’est pas le coût, ce n’est pas le délai, ce n’est pas le périmètre qui le paie mais l’humain.

Durant ma carrière de développeur, PO, QA, CdP, coach agile, j’ai vu beaucoup d’équipes agiles qui tiraient la langue, qui couraient après le temps. Des Product Owners et Business Owners qui n’ont plus le temps de discuter avec leurs utilisateurs, de rédiger leurs spécifications, des développeurs qui en reviennent uniquement à produire du code, des architectes qui courent dans tous les sens pour conseiller les équipes dans leur développement tout en travaillant à préparer l’avenir…

Pourquoi en arrivons-nous là ?
Parce que la représentation du triangle de fer comme les autres représentations connues font croire que les seules variables à regarder sont la capacité de livrer le maximum de fonctionnalité (même si on lâche prise) dans les temps et le budget avec la meilleure qualité intrinsèque possible.

De fait, les projets “agiles” qui se congratulent d’avoir réussi à livrer dans les temps, le budget, d’avoir satisfait leurs clients. On estime le projet parfaitement réussi même lorsque les acteurs ont passé leur temps à courir, souffrir, se prendre la tête entre eux. On l’estime d’ailleurs tellement réussi qu’on en fait des modèles à suivre.
Les entreprises devraient arrêter de porter aux nues ces projets et commencer, dans une démarche d’amélioration continue, à analyser comment obtenir le même succès sans créer de la souffrance.

Il est alors de notre devoir d’agents du changement de modifier les représentations.

J’ai donc décidé, à partir de maintenant de ne plus parler du triangle de fer. Ou du moins pour en expliquer les limites. Pour moi l’agilité passera a minima par la forme pentagone.

La représentation de l’humain dans cette formalisation me permettra d’expliquer que lorsqu’on tire sur les autres sommets, on tire sur l’énergie humaine. Et à force de tirer on se met dans l’incapacité de :

  • maintenir un rythme soutenable indéfiniment, base de la santé des équipes
  • réduire la charge des systèmes et donc d’accueillir favorablement les changements
  • se donner du temps de recul pour améliorer le système dans son ensemble

À partir de là et uniquement à partir de là on pourra qualifier les projets d’ »agile”. Par la construction d’un produit qui satisfait ses utilisateurs, ses clients, l’entreprise, les collaborateurs et se donne les moyens de s’améliorer continuellement.

La représentation de l’humain ne doit pas venir après ou à côté de celle des projets de qualité, elle est au cœur de celle-ci au même titre que les autres variables si ce n’est plus.

Bonus : si vous voulez transformer ce pentagone en une jolie métaphore, le voici sous les traits d’une maison

 

Crédit photo couverture : Photo by Daniel von Appen on Unsplash

Comments (2)

  1. Très bon article ! Ça me rappelle effectivement des choses qu’on a perdu De vue

  2. Super article mon ami ! Je l’ai lu et je l’ai trouvé très intéressant. J’aimerais pouvoir appliquer vos enseignements. Merci beaucoup !