L’idée est largement répandue. Répétée à l’envie. Y compris au sein de la communauté agile.
Si, pour une équipe isolée, il est possible de travailler sans planning ni estimation, alors, pour des projets complexes impliquant de nombreuses équipes et contraintes, la planification serait la seule manière d’organiser le travail.
Relevons d’abord deux contradictions dans cette affirmation. La première serait qu’un projet complexe serait prévisible. Ce qui est faux. Plus il y a d’acteurs, plus il y a de contraintes, plus il y a d’imprévus. Or, vouloir gérer l’imprévisible en s’appuyant sur des prévisions est un non-sens. A fortiori pour une activité de développement logiciel, où tant du point de vue utilisateur, que développeur, les découvertes sont quotidiennes.
En second lieu, certaines équipes seraient isolées, dans une bulle. Or, une équipe a au moins des utilisateurs. Elle n’est donc pas isolée. De plus, même si une équipe ne fait pas partie d’un ensemble d’équipes, elle travaille pour autant avec des prestataires, partenaires, éditeurs… Les relations, même si elles sont moins visibles, existent bel et bien.
La contagion de la prédictibilité
Certains acteurs savent que les plannings sont faux mais minimisent les conséquences de travailler avec ces outils. Sous prétexte que nous savons qu’ils sont imprécis, alors l’incidence de ces derniers serait nulle.
Or si le choix est fait de synchroniser de multiples équipes à l’aide d’un planning, nous imposons de facto à toutes ces équipes d’organiser leurs travaux en s’appuyant sur des plannings, c’est-à-dire sur un fonctionnement prédictif.
Très loin d’être innocent, le choix de synchroniser des équipes sur une base prédictive va, par contagion, imposer à toutes les équipes synchronisées un fonctionnement prédictif. Le planning appelle les plannings.
Si avant une transformation agile, les équipes travaillent et se synchronisent avec une approche prédictive et qu’après la transformation agile, elles travaillent et se synchronisent avec une approche prédictive, il est légitime d’interroger la nature de la transformation et la réalité de cette agilité.
Une agilité étroite ?
L’agilité, telle qu’elle a émergé à la fin du siècle passé (avec Scrum, XP et le Manifeste Agile notamment), est perçue comme proposant des solutions pour l’organisation d’une équipe mais aurait omis d’évoquer l’organisation d’équipes multiples. Une théorie largement relayée afin de pouvoir vendre ce que nous désignons sous le terme d’agilité à l’échelle.
Or l’agilité n’a de cesse de mettre en avant l’importance des utilisateurs et les interactions entre ces derniers et les développeurs.
Rappelons le premier principe du manifeste agile :
Les individus et leurs interactions
plus que les processus et les outils
Et plus avant :
Les utilisateurs ou leurs représentants et les
développeurs doivent travailler ensemble quotidiennement tout au long du projet.
Très loin de n’avoir évoqué que le fonctionnement d’une équipe, l’agilité apporte des réflexions profondes sur l’interaction entre les équipes et leurs utilisateurs. Or si nous savons comment une équipe fonctionne, et que nous savons comment elle interagit avec les autres, quelle zone d’ombre subsiste-t-il dans notre organisation composée de nombreuse d’équipes ? Aucune.
Synchronisation bilatérale et approche adaptative
De la nécessité d’identifier les utilisateurs
Une confusion a régulièrement lieu. Celle de croire que les utilisateurs ne sont que les utilisateurs finaux du produit. Or dans de grandes organisations, une équipe d’une DSI, souvent très pointue techniquement, peut avoir comme seuls utilisateurs d’autres membres de cette même DSI. Donc cette équipe d’informaticiens a pour utilisateurs d’autres informaticiens. Et dans notre organisation comportant de multiples équipes, certaines fournissent des services à d’autres.
La première étape afin de permettre une synchronisation bilatérale consiste à ce que chaque équipe identifie ses utilisateurs ou équipes utilisatrices. Cela est simple sur le papier, mais nécessite un réel effort dans certains contextes.
Synchronisation bilatérale
L’agilité préconise un dialogue quotidien entre une équipe et ses utilisateurs. Ce qui s’oppose à des échanges moins fréquents : au hasard, des synchronisations trimestrielles.
Sous quelles formes ce dialogue peut-il exister ? Nous pouvons penser à la traditionnelle réunion. Mais des démonstrations fréquentes, notamment si nous prenons en compte les retours, contribuent à ce dialogue quotidien. Des livraisons fréquentes, de quotidiennes à hebdomadaires, vont elles aussi participer à cette synchronisation bilatérale. Nous pouvons aussi ajouter des canaux de messagerie ouverts entre les équipes et leurs utilisateurs. Ou une communauté de bêta-testeurs. Bref, les formes de cette synchronisation bilatérale quotidienne ne manquent pas et dépendent du contexte.
Pour rependre notre exemple de dizaines d’équipes contribuant à un même « grand projet », si toutes les équipes qui doivent se synchroniser sont synchronisées de manière bilatérale en continu, que reste-il à synchroniser ? Rien.
Qu’est-ce que ces équipes pourront échanger d’utile au cours de synchronisations trimestrielles ? Rien.
Est-ce que les synchronisations trimestrielles ne sont utiles que dans des contextes non agiles ?
Backlog versus planning
L’affaire est entendue. Dans une organisation prédictive, dont le fonctionnement est basé sur la prédiction du futur, le backlog comporte des deadlines, des jalons et autres dates de démarrage. Or, si notre backlog comporte ces éléments, il s’agit d’un planning. Un planning vertical, certes, mais un planning. Et nous pouvons espérer qu’une transformation agile soit un peu plus riche qu’un simple rotation orthogonale.
Si le backlog n’est pas un planning vertical, quelle est sa nature ? Si nous considérons que le backlog est indissociable d’une approche adaptative, il ne peut pas représenter une projection du futur, puisque nous avons compris que le futur est imprédictible.
Donc il s’agit d’une liste de tâches priorisée par ordre décroissant d’importance. Quelle est son utilité si cette liste change constamment ? Sa seule utilité, mais elle est d’importance, est de savoir à chaque instant ce sur quoi nous devons travailler, au vu de nos possibilités et des informations que nous avons actuellement en notre possession. Le backlog n’est donc pas une projection du futur, mais un outil orienté vers l’action immédiate.
Dans ce contexte, une tâche qu’il est impossible de démarrer dans l’immédiat, parce qu’un prérequis d’une équipe tierce n’est pas rempli, ne sera pas priorisée. Par conséquent, elle n’entraînera aucune perturbation organisationnelle dans l’équipe, qui se focalisera sur des tâches qu’il est possible de réaliser.
Alors que dans une organisation prédictive, tout retard d’une équipe va se répercuter sur ses équipes utilisatrices qui ont prévu de commencer à une date définie. Et par ricocher, le retard va se propager à toutes les équipes. L’onde désorganisatrice se propage d’équipe en équipe, par l’intermédiaire des plannings.
Dans une approche adaptative, les équipes sont bien plus autonomes. Les adhérences sont moins fortes, l’organisation s’adapte plus facilement à l’imprévu.
Conclusion
Le fait de synchroniser des équipes par la planification impose à toutes les équipes synchronisées d’adopter un fonctionnement prédictif. Ces liaisons fortes entre équipes vont propager toute difficulté d’une équipe à l’ensemble des équipes.
Loin d’être orientée uniquement vers le fonctionnement d’une équipe, l’agilité, telle qu’elle a émergé à la fin du siècle passé, propose une réflexion sur les relations entre les acteurs. Si chaque acteur connaît parfaitement ses utilisateurs et leur parle quotidiennement, la synchronisation est continue. Elle rend caduque des synchronisations à moindre fréquence. De plus si les équipes travaillent à chaque instant, non sur les sujets prévus dans un planning, mais sur les sujets les plus importants, au vu des informations et des possibilités actuelles, l’organisation est résiliente, adaptable, agile.