Planification par les besoins

Pourquoi planifier ? À quel horizon ? Comment les prévisions sont établies ?

Faire des boucles de feedback orientées utilisateurs entraîne une autre façon de planifier.

En réponse à la gestion de projet classique — qui a la vie dure — l’agilité propose une planification par les besoins, adaptée à différents horizons.

Les problèmes avec la planification projet

La division verticale du travail, qui établit une distinction entre la conception et la réalisation, perdure dans bien des projets. Cela conduit à une façon de travailler avec la séparation stricte entre réflexion et exécution, qui se décline avec des phases séquentielles. La première phase sert à concevoir et planifier, la suite n’étant que l’exécution de ce plan avec des contrôles effectués pour garantir sa bonne exécution.

Dans ce cadre, la planification projet consiste à définir le temps accordé aux exécutants pour faire un travail et montrer l’enchaînement des travaux.

Cela entraîne de nombreux problèmes, en voici quelques-uns.

Pas de vision

L’équipe travaille sur ce qu’on lui demande de faire, mais elle ne sait pas vraiment où elle va. Travailler sans savoir à quoi ça sert, ce n’est pas terrible, en particulier dans le domaine de la connaissance.

Depuis bien longtemps, on préconisait déjà d’élaborer une vision commune du résultat à produire au début d’un projet. Ce n’est donc pas une notion qui a émergé avec l’agilité.

Cependant elle a une importance vitale pour une équipe auto-organisée. Il existe différentes façons d’obtenir une vision. Certaines sont trop faites pour des visionnaires qu’on ne rencontre pas souvent. Le mieux est que l’équipe participe à la définition de la vision.

Conseil

Je propose que cela se fasse avec des ateliers, comme ceux présentés dans cet article.

Plan détaillé à l’avance

La planification projet pousse à faire des plans détaillées très tôt. C’est gênant car les besoins des utilisateurs sont impossibles à cerner en détail et en plus ils changent. On s’aperçoit très vite que :

Aucun plan ne résiste au contact avec l’ennemi.

Ce fameux slogan ne vient pas de l’agilité, mais y correspond bien.

L’outil de planification c’est le backlog.

Ensuite, faut-il essayer de prévoir l’avenir ou pas ? Pour quel horizon ? Avec des estimations ou sans ?

Ça dépend. Avec le tag planification, on voit que c’est un sujet que j’ai beaucoup abordé dans les 10 première années de mon blog. Dans mes livres aussi : dans Scrum édition 6, c’est dans le chapitre 20 “Coopérer pour prévoir”.

Occupation à 100%

Avec les plans traditionnels, le plan vise à occuper les personnes à 100%. Ce n’est pas une bonne idée, cela ne leur laisse pas le temps de réfléchir.

Tous les bons enseignements en gestion de projet disent pourtant que :

il faut garder du mou.

Le mou dans les plans est indispensable pour les aléas et la réflexion. Il faut du temps pour :

  • se préparer aux fluctuations inévitables,
  • améliorer les compétences des parties prenantes,
  • explorer de nouvelles idées.
Garder du mou lors de la planification de sprint

Deadline

La planification de projet est souvent utilisée pour définir une date de fin. Communiquée à l’avance elle devient une deadline pour l’équipe.

Cela peut entraîner la mise en service d’un résultat mal fini si on pousse l’équipe à tenir absolument cette deadline ou bien une déception des utilisateurs si on ne leur fournit pas tout ce qui était prévu.

Avec l’agilité, la planification, à partir du backlog, sert à prévoir un contenu pour une date définie à l’avance (sprint, saison) sans que cela devienne un engagement. Ce contenu est sélectionné en fonction de l’objectif pour la période.

Planification par les besoins

La notion de boucles, avec les itérations courtes, est bien différente de la division du temps en phases et jalons de la gestion de projet.

Pour répondre aux problèmes de la planification de projet —une planification détaillée et faite au début en essayant de tout prévoir, suivie d’une pression sur les délais et les coûts— l’agilité adopte une stratégie basée sur l’évaluation régulière des besoins.

Il s’agit de naviguer malgré l’incertitude, en partant des besoins des utilisateurs et en ordonnant les demandes dans le backlog.

Antipatterns

Même avec un backlog priorisé, la planification peut être mal appliquée par des équipes agiles. Voici quelques antipatterns constatés :

  • output vs outcome : on a le nez dans le guidon ; on cherche à produire plus qu’à donner de la valeur,
  • addiction au poker : l’équipe passe trop de temps sur l’estimation,
  • chiffrage exigé en J/h : l’estimation n’est pas faite en points de story, on reste aux heures ou jours.