Dans cet article, je pose une réflexion quant à l'utilité de la planification en product management agile et jusqu'à quel horizon cela peut-il faire sens économiquement ?
Je commencerai par parler de la notion de stabilité d'un système et en quoi cela est important pour le sujet de cet article, avant de conclure sur la question titre de cet article.
Qu'est-ce qu'un système stable ?
Il y a un mythe autour de cette notion de stabilité d'un système, celui qu'il faut que rien ne change pour considérer un état de stabilité.
Or un système stable n'est pas un système qui ne change pas. C'est un système où la variation est contenue dans un espace minimisée et maitrisée.
En d'autres termes un système stable est un système qui se comporte comme on attend qu'il se comporte.
Pour le docteur John Little, un système stable est un système dans lequel les 5 conditions de sa loi n'ont pas été violées sur la période observée. Dans le domaine du product management, au regard de la complexité, cela est presque impossible à réaliser. En tout cas plus la période observée sera longue plus il y aura de probabilité que les conditions de sa loi soient violées. (Vous ne connaissez pas la loi de John Little ? Lisez cet article)
Pour Deming & Shewhart, un système stable est un système où il n'y a pas de "special cause", d'évènements spéciaux (inhabituelles, non rencontrées dans le passé, non quantifiables) mais seulement des "common cause", des évènements communs (des variations habituelles, déjà rencontrés précédemment, quantifiables, des variations maitrisées et qui ne sortent pas grandement d'un historique connu).
Quelles sont les limites de variations acceptables? Chaque contexte étant différent il n'y a pas de réponse absolue. C'est à qualifier, quantifier par rapport à l'environnement dans lequel on se situe.
Que rend possible un système stable ?
Dans un système où il y a trop d'évènements spéciaux qui surviennent, où ce qui pourrait être maitrisé ne l'est pas, par exemple avec un nombre d'éléments en cours variant énormément, ou un âge des éléments du système avec un coefficient de variation élevé, prédire l'avenir relève de la divination.
Dans un système stable, il est par contre possible d'être probabilistiquement prédictible.
La météorologie utilise notamment des techniques probabilistes, car il n'y a aucune démarche déterministe qui peut fonctionner dans ce contexte d'incertitude et de changement fréquent.
La précision des prédictions dans ce domaine est très liée à l'horizon de temps, plus elle est éloignée du moment où a eu lieu la simulation, plus l'incertitude d'être en écart à la prédiction est grand.
Ceci est lié à cette notion de stabilité, de maîtrise de la variabilité.
Sur un laps de temps restreint les prédictions sont assez précises car la variabilité est maîtrisée. Dès que le laps de temps devient plus grand, de nombreux risques non maitrisables entrent en considération et donc la prédictibilité décroit.
Le domaine du product management est lui aussi un domaine complexe avec de nombreuses incertitudes. Est-ce vraiment ce que le client attend? Va-t-on résoudre son problème, ne va-t-il pas changer d'avis? Avons-nous la capacité technique, les compétences pour résoudre cela? Nos experts vont-ils tomber malade, quitter l'entreprise? L'équipe va-t-elle s'entendre et collaborer? Le marché ne va-t-il pas changer? Un concurrent ne va-t-il pas venir le disrupter?
A quel horizon dans ce domaine la planification fait donc-t-elle sens ? Et si on est dans un système instable cela a-t-il du sens de planifier ?
La stabilisation du système ne serait-il pas plus important que la planification?
Si on sort des limites acceptables de variabilité régulièrement, la planification faite à un instant t ne tiendra que très peu de temps. Il faudra réagir face aux nouveaux éléments imprévisibles survenus et ajuster cette planification.
Le plan dans un tel contexte ne pourra pas tenir plus de quelques heures, jours tout au plus…
A quoi bon ? N'est-ce pas gaspiller ce temps ?
On est malheureusement souvent dans un cercle vicieux car trop de personnes ont une vision déterministe du monde, lorsqu'il y a un planning ces personnes pensent que c'est un engagement et que rien d'imprévu ne va survenir. On va donc consommé beaucoup de temps à justifier les écarts par rapport au plan. On va par ailleurs fortement être invité à fournir un nouveau plan, car sans plan, comment pourrions nous avancer ? Comment pourrions nous convenir de continuer ? Il faut rassurer et le plan est le moyen classique.
Sauf que dans un système instable, vous n'allez faire que mentir et petit à petit effriter la confiance (s'il y en avait).
Les heures consommées dans toutes ces discussions et mises à jour du plan ne délivrent pas concrètement de la valeur pour vos clients.
Mais les clients (et d'autres parties prenantes) ont un besoin de savoir quand cela sera finit ? Ou combien de choses pourront être réalisées à une date, période donnée.
Dans un système stabilisé et en pensant de façon probabiliste, il est possible d'obtenir des réponses à ces questions par les données collectées du processus.
En effet avec des techniques probabilistes, il devient possible de prédire qu'on finira X choses dans les Y jours avec une probabilité de Z %. En mettant à jour continuellement ces prédictions, on va pouvoir enclencher des discussions au plus tôt et donc mieux gérer les risques.
En product management agile, même si nous pouvons dire de façon probabiliste avec un bon degré de confiance que l'on va faire 20 éléments ou plus dans les 3 mois prochains, il serait contre-productif de fixer ces 20 éléments. Les fixer serait ne pas considérer que l'on va apprendre en cours de chemin.
En s'ajustant aux changements pour maximiser la valeur du travail de l'équipe, au final au bout des 3 mois, parmi ces 20 éléments ordonnés initialement, se seront peut-être 10 éléments parmi cette liste initiale + 10 autres dont on n'avait pas connaissance au début de la période.
Même dans un système stabilisé, dans le domaine complexe du product management des choses vont changer et un plan donné de façon déterministe sera forcément remis en cause tôt ou tard.
Planifier et y consacrer bien trop de temps au lieu de passer ce temps à produire, à obtenir des feedback, à manager son flux de valeurs… c'est finalement ne pas vouloir apprendre ou prendre conscience que la question principale auquel il faut répondre le plus rapidement possible c'est : " A quel point avons-nous tort ?"
Conclusion
Investir dans des actions pour rendre votre système plus stable, plus robuste et à la fois plus souple pour réagir en continue aux changements fréquents et aux imprévus est une stratégie bien meilleure à mon sens que vous pouvez adopter en lieu et place de la recherche du plan parfait.
Vous souhaitez apprendre et vous faire certifier sur une stratégie qui vous aidera à devenir plus prédictible? Alors inscrivez vous à l'une de mes formations sur la stratégie Kanban.
Ajouter un commentaire
Commentaires