La planification multi-équipes, pratique-clé de l’agilité à l’échelle 

Dans cet article, j’aborderai le sujet de la planification du travail à réaliser. Nous allons notamment aborder la planification à moyen terme (quelques mois). Je partagerai une pratique de planification très intéressante dans un cadre agile multi-équipes, également appelée “agilité à l’échelle”. 

La planification est une pratique que je vois peu mise en œuvre dans les contextes auxquels je contribue. Ces contextes peuvent être agiles ou non, à l’échelle ou non. Il y a plusieurs raisons à cela. 

Pourquoi « zapper » la planification ? 

• Une bonne planification demande du temps. A minima il faut le temps nécessaire pour identifier, même grossièrement, les chantiers qu’on veut visualiser dans son planning. Il faut également voir la valeur ajoutée de chaque chantier, ainsi que l’effort estimé pour le réaliser. De nombreuses équipes ne prennent pas le temps de se prêter à cet exercice. 
• Une bonne planification demande, dans l’idéal, un outil adéquat. Je ne dis pas que c’est un prérequis ; en revanche, c’est un atout non négligeable. Par exemple, faute d’outil adapté, il peut y avoir double saisie entre votre backlog et votre planning. L’exercice devient rapidement peu motivant, ainsi qu’une source d’erreurs. 
• Certaines équipes ne voient pas l’intérêt de planifier. Un planning réalisé à un instant T va bouger en permanence, il ne restera pas figé. La question se pose donc de la pertinence de construire un « livrable » qui sera faux, au moins partiellement, l’instant d’après. Et cela, d’autant plus si l’outil utilisé (voir ci-dessus) rend cela difficile. 
• L’approche agile la plus répandue à ce jour, Scrum, n’impose pas de pratique de planification au sens traditionnel du terme. Elle ne donne pas de conseils sur comment l’instancier. Il y a certes la planification de sprint mais cela reste un exercice de planification à très court terme. Et on n’identifiera pas d’horizons de réalisation différents pour chaque activité engagée dans le sprint. 

Je n’ai pas de problème particulier avec les équipes qui ne réalisent pas de planification à moyen terme. Une vision produit claire, à laquelle on se réfère souvent pour ordonnancer nos travaux, vaut bien un millier de plannings. Notamment, ceux réalisés sans réflexion de fond, et sans concertation avec les parties prenantes ou ceux qui feront le travail. 

Réaliser un planning consomme du temps et de l’énergie. Si cet investissement n’apporte aucune valeur ajoutée, alors, dans une approche d’élimination du superflu (Lean), c’est une pratique qu’il faut soit adapter (afin de la rendre porteuse de valeur), soit éliminer. 

La planification est un exercice riche en enseignements 

Cependant, je trouve que l’exercice est très intéressant, et devrait justement apporter de la valeur, à plus d’un titre. 

• Comme exprimé plus haut, réaliser une planification demande de se poser, même rapidement, plusieurs questions. Tout d’abord, la question du QUOI (quels chantiers). Puis du COMMENT (pour avoir une idée grossière de l’effort) et enfin, du QUAND. Cela incite donc à ne pas naviguer à vue. Mais cela permet d’essayer de garder une vision à moyen, voire à long terme. 

• Par corollaire, une feuille de route claire est un formidable outil pour fédérer ses équipes. Le fait de savoir vers quoi tendre, et à quelle échéance, permet aux collaborateurs de pouvoir rester alignés vers un même objectif, avec les mêmes priorités. 
• C’est aussi un formidable outil pour garder ses clients et utilisateurs engagés. Savoir qu’une fonctionnalité, très attendue, sera livrée au 3^e trimestre 2023, rend l’attente plus acceptable que si nous n’avions aucune information. Cela incite également à communiquer sur des échéances réalistes. Aucun client n’a envie d’être “baladé” pour s’entendre dire chaque mois « finalement, ce sera pour le mois prochain ». 

Donc, lorsque je me rends dans une équipe ou une entreprise qui est capable de donner de la visibilité sur sa feuille de route, à l’instar de ce que font par exemple GitHub (voir la feuille de route publique ici) ou Microsoft (voir la feuille de route Microsoft 365 ici), je trouve cela réellement positif. À condition évidemment que cette feuille de route ne soit pas complètement fantaisiste lorsqu’on y revient a posteriori. 

Les pièges de la planification, dans un mode d’agilité à l’échelle ou pas

Il est toutefois primordial de ne pas tomber dans certains pièges. 

• Planifier peut être une activité complexe. Notamment lorsque nous tâchons de prendre en compte les plannings d’autres personnes, équipes, voire entreprises (éditeurs, sous-traitants…). À ce titre, je ne recommande pas de présenter une planification à moyen terme, voire à court terme, comme un engagement ferme. 
• Même sans avoir de dépendances vers d’autres équipes ou interlocuteurs, il faut bien garder en tête que la planification reste un exercice de prédiction. Comme toute prédiction, elle peut se révéler fausse ! Une absence imprévue, une indisponibilité d’un service, un incident à résoudre avant tout autre chose… Voici que notre planning se retrouve intenable. À nouveau, je ne recommande pas de présenter une planification à moyen terme, voire à court terme, comme un engagement ferme. 
• Planifier trop finement est une perte de temps et n’apporte souvent pas beaucoup d’information utile. Inutile de chercher à planifier l’activité de chaque membre de votre équipe à la demi-journée, voire au quart de journée près. Votre planification sera fausse 95% du temps, et vos indicateurs tout autant (nous en parlions ici dans notre série sur la mesure de l’agilité). Vous passerez autant de temps à la remettre à plat, en raison du grand nombre d’activités et de personnes que vous cherchez à avoir sous contrôle. 
• Planifier trop longtemps à l’avance est aussi une perte de temps. Même une équipe ou une organisation qui a une vision claire et une stratégie claire peut, à un moment donné, choisir de pivoter . C’est d’ailleurs une forme d’agilité, plutôt que s’entêter à suivre une route qui ne va nulle part. Planifier à trois, cinq ou dix ans, dans la plupart des contextes, se révèle difficilement possible et peu utile. 

• Enfin, la planification est un exercice qui doit se réaliser en équipe. Les personnes qui vont réaliser le travail demandé doivent contribuer à la construction de la feuille de route. Elles ne doivent pas simplement se voir imposer un périmètre fixe dans un délai fixe. Il n’est pas possible de demander à une équipe de s’engager sur une planification faite par un nombre restreint de personnes, au mépris de l’avis du groupe. 

Une pratique à expérimenter en mode multi-équipes : la planification « à l’échelle » 

A l’heure où de plus en plus de grandes organisations tentent d’embrasser les concepts agiles, je voudrais mettre en avant une pratique que je trouve excellente en termes de collaboration multi-équipes à des fins de planification. 

Il s’agit de la construction de ce que SAFe appelle le « Planning Board » (ou, jusqu’à récemment, Program Board). Cela correspond en définitive à un grand tableau permettant à différentes équipes collaborant ensemble de réaliser une planification commune. Cela leur permet de visualiser les dépendances entre elles (qui, je le rappelle, devraient être réduites à un strict minimum, notamment par l’organisation en équipes cross-fonctionnelles et autonomes). 

Il s’agit d’une planification à moyen terme (quelques mois), qui est un bon niveau de granularité dans la plupart des contextes que j’ai traversés. Dans la vision SAFe de ce tableau, que je trouve personnellement très pratique et claire, la structuration de l’information est réalisée comme ceci : 

• La première ligne rappelle les jalons principaux à connaître sur les prochains mois. Cela peut être des événements importants d’un point de vue métier (salons, séminaires, date de lancement d’une offre…). Cela peut aussi être technique (date de fin de support…). On peut y ajouter du réglementaire (mise en œuvre d’une nouvelle législation nous concernant, par exemple). Clarifier cette information pour toutes et tous donne à toutes les équipes les moyens de faire des choix en connaissance de cause, notamment en termes d’ordonnancement des activités. 
• Les lignes suivantes correspondent à chaque équipe engagée dans la planification commune. Chaque équipe y placera les travaux qu’elle prévoit de faire sur les mois à venir, échelonnés dans le temps. 
• Les lignes du bas (ici « Needs UX help » et « Needs Sys Arch Help ») correspondent à des intervenants externes qui ne font pas partie des équipes et interviennent ponctuellement. Elles peuvent être concernés par, ou en charge de, certains travaux à réaliser pour permettre aux équipes d’avancer. 

• Chaque colonne correspond à une période fixe (timebox). Cela peut être des sprints pour des équipes qui travaillent en Scrum. Pour des équipes qui ne travaillent pas en Scrum ou en SAFe, cela peut être des mois, des trimestres. Cela dépend du niveau de granularité souhaité. 

À chaque intersection entre une ligne et une colonne, chaque équipe va positionner les sujets qu’elle prévoit de livrer sur la période donnée. Rappelez-vous des pièges énoncés ci-dessus . Le but n’est pas de tomber dans le contrôle fin, mais de donner de la visibilité sur la suite. Il est donc inutile et pas recommandé de découper trop finement ses activités. Elles peuvent rester au niveau « features », si l’on emploie le vocabulaire SAFe. 

Ce sont les rectangles bleus et rouges sur l’image précédente. La différence entre les deux réside dans le fait que les sujets en bleu ne dépendent d’aucun autre sujet. 

En cas de dépendances entre des sujets, celles-ci seront matérialisées sur le tableau. Ce sont les courbes rouges qui relient certains des éléments positionnés précédemment. Cette visualisation permet d’identifier très rapidement les points d’adhérence entre différentes équipes. Elle doit permettre de se poser les bonnes questions. 

Par exemple, est-il vraiment pertinent que l’équipe B planifie son sujet sur le mois d’avril, alors qu’il dépend d’un sujet de l’équipe A, prévu à la livraison au mois d’avril également ?

N’y a-t-il pas un risque à procéder ainsi ? Comment pouvons-nous lever ce risque ?

Cela passe généralement par la communication entre les équipes, Product Owners en tête, afin de résoudre ce casse-tête, notamment en modifiant la priorisation des sujets dans l’une, l’autre, ou les deux équipes. 

Dans un cadre d’agilité à l’échelle, le fait de réaliser cet exercice de planification tous ensemble, avec les acteurs des différentes équipes qui travaillent ensemble, est un gain de temps énorme. Cela permet de prendre des décisions très rapidement, sans échange interminable de courriels ou de messages “instantanés”. Et cela facilite la communication et la collaboration. C’est la pratique dite du “Big Room Planning” (planification dans une grande salle). SAFe l’a renommée par la suite en “PI Planning” (pour Planning Interval Planning, ou, jusqu’à récemment, Program Increment Planning). 

En synthèse 

Planifier est un exercice qui peut paraître délicat, mais qui l’est moins qu’il n’y paraît. À partir du moment où on n’essaie pas de “tomber juste” à tout prix. Planifier est un exercice de prédiction : la prédiction peut être juste, comme elle peut être (plus ou moins) fausse. L’essentiel est d’apprendre à chaque fois et de s’améliorer d’une fois sur l’autre. 

Donner de la visibilité sur la planification peut renforcer le sentiment d’aller dans une direction partagée par tous. Cela contribue à la transparence et la collaboration qui permettent à une équipe agile de fonctionner correctement.  

Dans une logique d’agilité multi-équipes, ou agilité à l’échelle, les risques liés à une absence ou un manque de transparence, de collaboration et de communication sont encore plus forts. Une équipe qui travaille en sous-marin, qui dérape sans que personne ne s’en aperçoive, qui ne communique pas, peut avoir des impacts sur les progrès de plusieurs autres équipes, voire d’une organisation dans son ensemble. 

Construire une feuille de route commune est un excellent exercice pour s’aligner et se comprendre. Le “Planning Board” et le “Big Room Planning” sont des pratiques possibles pour cela. Attention à ne pas tomber dans certains pièges qui peuvent rendre cet exercice impossible ou vide de sens, et ainsi désengager les personnes qui sont amenées à le réaliser. 

Pour aller plus loin sur la planification agile, nous organisons un webinaire le jeudi 22 juin de 11h à 12h : « Agilité à l’échelle, comment bien s’outiller ? Focus sur Jira Align ». Il sera co-présenté par notre collègue Thomas Serre, coach et formateur agile, et Youssri Abdou, consultant Atlassian (entreprise agile Jira Align).

Pour vous inscrire, c’est par ici :

Et si vous n’êtes pas disponible, pas d’inquiétude, inscrivez-vous quand même et nous vous enverrons le replay à l’issue du webinaire.