Indicateurs de pilotage : intégrer les risques

Le pilotage de projet en agile s’appuie sur des indicateurs simplifiés : en Scrum, un diagramme d’avancement compilant vélocité de l’équipe et complexité restante à faire. En Lean Software, un diagramme de flux intégrant temps de cycle et encours. Ces indicateurs sont des leurres si vous ne savez pas gérer les risques.

Vous avez déjà entendu les métaphores nautiques “le projet dérive”, “on tient le cap” ? Je vais prendre la métaphore au mot, et vous raconter une anecdote qui m’est arrivée.

Hissez haut !

Au cours de mes années étudiantes, je suis parti pour une semaine de navigation en voilier avec un skipper professionnel et 2 copains.

Très vite, on a vu que notre équipe fonctionnait bien. On s’entendait sans se marcher dessus, aspect fondamental dans ce huis clôt qu’est un habitable de 5,50m. Chacun ayant sa petite expérience de navigation, la coordination se rôdait, on manoeuvrait de plus en plus vite. Un soir, alors qu’on mouillait dans la rade de Port-Blanc, le skipper nous a proposé un défi :

“Demain, vent modéré annoncé. Vous êtes chaud pour les iles anglo-normandes ? Départ de nuit, longue journée de navigation, on doit tout planifier, comme des vrais marins.”
On a dit oui.

Cap vers Jersey

Pour naviguer loin de la côte, sans repère visuel et sur une telle distance, on a que la boussole pour s’orienter, donc il faut se fixer un cap et le suivre. Ce cap demande certains calculs.

Pour commencer, on calcule la dérive. On prend les cartes des courants marins et on additionne tous leurs vecteurs, heure par heure, tout au long du trajet, pour avoir la dérive totale. Disons que d’après ce vecteur on arriverait à 10 miles au sud par rapport à la destination théorique.

(corrupted image)

Donc on prend notre trajectoire par défaut, la ligne droite entre nous et Jersey, et on la compense, comme si l’île était en fait 10 miles au nord. Le cap (angle par rapport au nord) est mesuré pour suivre cette nouvelle ligne.

Dans notre cas, la précision comptait parce qu’au bout de 12H de navigation, on finirait fatigués. Tout retard puiserait dans nos forces, et ce serait que le début : selon l’heure et la position, on subirait des courants et des vents qu’on aurait pas intégrés, ça pourrait devenir une vraie galère. Les GPS ont beau éliminer le danger de se perdre, la mer est dangereuse, surtout pour un équipage épuisé et tendu sur un petit habitable de 5,50m. Donc chacun a recoupé les calculs pour être certains du vecteur de dérive et de l’angle de cap résultant. Avec nos bacs scientifiques fraîchement fêtés, on était quand même en confiance.

Le principe ensuite, c’est de lever l’ancre à l’heure prévue, suivre le cap à la boussole, et, déviés par le courant, on arrive à l’île. Fort de notre plan de navigation, nous nous sommes couchés pour un départ de nuit.

4H du mat, on me réveille.

“En fait y’a pas un pet de vent, on laisse tomber, on va suivre la côte jusqu’à Bréhat.”

Adieu Jersey.

On a accosté sur Bréhat dans la matinée sous un grand soleil. On s’y est reposé et baladé avant de reprendre la mer, c’était une journée magnifique.

Du “projet qui dérive” à “l’avarie dans le projet”

Je reviens sur le pilotage de projet en agile.
Planifier nécessite l’hypothèse d’une progression simplifiée, linéaire. Les écarts que tolère cette hypothèse sont de simples dérives. Mais ce plan a un effet pernicieux : avec le temps que l’on investit dans nos calculs de prédiction, à sommer des éléments, prendre des marges, on tend à prendre l’hypothèse pour une réalité.
Hors la réalité n’est pas linéaire. Un imprévu peut faire exploser votre prévision.
C’est ce que je reproche aux courbes de vélocité et aux diagrammes de progression : ils incitent à penser que les imprévus provoqueront des dérives linéaires, des écarts de cap compensables. Je suis tombé dans cet écueil, et pas seulement à mes débuts en agile.
Je pense ne pas être le seul.
J’évoquai les métaphores nautiques, “projet qui dérive”, “tenir le cap”, etc. Mais on entend jamais “le vent est tombé”, “avarie dans le projet” ou “canot de sauvetage”. Les imprévus, les vrais, ceux qui comptent, ne font pas dériver la courbe. Ils la rendent caduque. Bien sûr, vous vous en rendrez compte, mais souvent ça prendra du temps, attachés que vous étiez à vos formules excel, et ce sera trop tard.

Quand le vent tombe, on jette ses calculs de courant, et on oublie Jersey. C’est un événement de rupture.

Comment intégrer dans le pilotage de projet un indicateur de progression qui donne le cap en conditions normales, tout en restant attentif à ces événements de ruptures, afin de lâcher le plan et prendre à temps les décisions qui s’imposent ?
Je croie en un pilotage schizophrène utilisant à valeur égale :

1. un diagramme de progression, burnup chart ou burn down chart, qui prédit “qu’est ce qu’on va finir quand”
2. une fiche de risques, récapitulant “ce qui ferait que ce diagramme n’a plus de sens”

Cette fiche de risques est une pratique classique de pilotage projet, je ne réinvente pas la roue. Cependant, je la trouve trop peu mentionnée dans le milieu de l’agile, et souvent oubliée par les équipes qui démarrent, donc j’insiste : elle doit être inclue et à jour dans vos documents de pilotage. Allons plus loin :

ce n’est pas qu’un élément d’information,
c’est un antidote contre la croyance en une progression linéaire.

Concrètement, j’en tire un principe pour les feuilles de route, diagrammes d’avancement, ou toute forme de projection qui vous sert à piloter :

on ne présente jamais un planning sans les risques à côté

Au mur, affichez la fiche de risque à côté de la roadmap. Dans vos excels, écrivez les risques sous le diagramme de progression, et pas dans un onglet séparé. En un seul regard schizophrène, vous aurez un oeil sur les indicateurs, l’autre sur les risques.

À venir : construire une matrice de risques (simplifiée)

Tags: Agile Management, Contrôle, Dérive, Matrice de risques, Pilotage, Project Management, Risks, Risques, Vélocité