Après avoir étudié comment nous pouvions synchroniser des équipes de développement logiciel sans s’appuyer sur des plannings, penchons-nous sur le cas de la deadline, ou limite mortelle, dans le contexte du développement logiciel.
Nous pouvons distinguer deux types de dates butoirs. D’une part, les deadlines arbitraires qui sont créées afin de mettre la pression sur les personnes. L’idée sous‑jacente est simple : les personnes n’aiment pas travailler. En leur mettant la pression pour finir des travaux à une date dite, elles s’impliquent. Plus nous mettons de pression, plus il y aura de travail pour le même prix. La rentabilité va s’accroitre. Il s’agit là de management par la peur. Et le fait d’imposer une deadline ou d’imposer à une équipe de s’imposer elle‑même une deadline est du management par la peur.
La seconde option a la réputation d’être plus fiable. Les développeurs auraient la capacité à prédire les durées de développement (postulat qui mériterait d’être validé par de la mesure). Elle est aussi beaucoup plus perverse. Elle veut faire croire aux développeurs qu’ils ont une relative autonomie, alors qu’elle les maintient toujours dans le règne de la défiance et dans l’irréalité de la prédictibilité. C’est un piège qui est tendu et qui va se retourner contre eux dès que l’on s’apercevra que le futur prévu n’est pas celui qui advient.
D’autre part, il existe des échéances que nous pourrions qualifier de naturelles ou d’externes. Ce sont des échéances qui ne sont pas créées afin de mettre la pression sur les personnes, mais qui s’imposent à une organisation. Le cas d’école est une évolution règlementaire qui entrera en application à une date donnée. Un salon professionnel est un autre exemple d’échéance externe. Si un concurrent annonce qu’il fermera un service à une certaine date, et que nous avons la possibilité de récupérer ses utilisateurs en développant une fonctionnalité d’import avant cette date, il s’agit là aussi d’une échéance externe. Même si ces échéances externes ne sont pas fréquentes, il convient de savoir les gérer.
Prenons un exemple : le service juridique sonne le tocsin. Un décret d’application d’une loi vient d’être publié. Dans quatre mois au plus tard, notre produit devra être mis en conformité sous peine de lourdes amendes.
Premier réflexe face à cette deadline d’importance ? Faire un planning ou estimer la charge. Or, en procédant ainsi, nous augmentons le risque — drastiquement.
L’illusion de la maîtrise du futur
Dans un contexte complexe et incertain, comme celui du développement logiciel, les plannings ne font pas les délais. Il est illusoire de croire qu’un trait horizontal sur un diaporama, agrémenté de quelques dates, influencera le futur. C’est une grande naïveté, voire un orgueil démesuré, de penser que nous pouvons dessiner l’avenir comme de grands architectes du devenir. Le futur n’a cure de nos plannings : il advient, toujours surprenant, jamais là où l’on l’attend. Le planning n’est en rien protecteur ; 100 % des projets en retard ont fait l’objet d’un planning.
Qu’est‑ce qui influence le délai ? Le travail.
À savoir : comprendre les besoins, développer, tester, livrer.
Le risque est inversement proportionnel au temps résiduel
Toutes choses étant égales par ailleurs, si nous disposons de cinq ans pour réaliser une action, la probabilité qu’elle se concrétise est bien supérieure à celle d’une tâche à accomplir en deux jours. Ainsi, l’écoulement du temps augmente le risque. Passer du temps à établir des plannings et des estimations retarde le démarrage effectif des travaux ; ces activités accroissent donc le risque.
De plus, dans une culture prédictive, les acteurs sont constamment empêtrés dans les engagements et les plannings passés. Pour entamer de nouveaux sujets, il faut soit honorer les engagements antérieurs, soit s’en libérer — dans les deux cas, cela consomme du temps, anéantit la réactivité et augmente sensiblement le risque.
Réaliser des plannings pousse naturellement les équipes à chercher à les fiabiliser : on ajoute une phase d’étude, on rédige des spécifications verbeuses, on impose une Definition of Ready aussi indigeste que les pires des formulaires CERFA de notre chère l’administration. Tout cela est vain : dans des contextes imprévisibles, les plannings sont systématiquement erronés. Mais l’énergie investie dans ces activités est elle bien dépensée. En pure perte.
Dans un fonctionnement prédictif, il faut d’abord solder les engagements passés, puis réaliser les actions préalables à la planification avant même d’entamer les estimations ou le planning proprement dit. À ce stade, rien de concret n’a encore été fait. Le temps s’est écoulé, le risque a augmenté. Dans le meilleur des cas, une grande partie du temps disponible a été gaspillée à prédire le futur ; dans le pire, la totalité du temps a été consommée ainsi.
Après quatre mois, aucune fonctionnalité n’est livrée. Le risque n’est pas seulement de ne pas atteindre l’objectif : le risque maximal est de ne rien livrer du tout. Les plannings et les estimations ne font que focaliser l’attention sur la prédiction du futur, au détriment de sa construction.
Comment agir ?
- Prioriser immédiatement le sujet
Prioriser, c’est dé‑prioriser les autres tâches. Un élément est prioritaire par rapport à d’autres éléments. La priorité à droite indique que les véhicules qui viennent de droite sont prioritaires vis-à-vis de ceux qui viennent de gauche. Dans un mode de fonctionnement adaptatif, sans planning ni projection de futur, les acteurs restent libres de tout engagement. La priorisation devient instantanée, car la dé-priorisation ne remet en cause aucun plan. Dès que le service juridique sonne l’alerte, on se met immédiatement sur le sujet, réduisant ainsi considérablement le risque. - Atténuer le problème plutôt que viser la perfection
Supposons que la contrainte légale porte sur la traçabilité. On a tendance à penser en termes binaires : la traçabilité existe ou n’existe pas. En y regardant de plus près, nous découvrons souvent (systématiquement ?) qu’il y a plusieurs manières de répondre à un problème. Et que certaines solutions sont découpables. Par exemple, que s’il est complexe, voire impossible, de tracer toutes les informations exigées par la législation dans un premier temps, il est aisé de tracer ne serait-ce qu’une information. Alors nous développons cela et le livrons sans délai. Chaque livraison va non seulement atténuer le problème mais aussi nous faire gagner en expérience, facilitant la résolution du problème. - Livrer (très) fréquemment
La fréquence de livraison d’une équipe est généralement stable. C’est un travail sur le long terme de l’accroitre. Une équipe livrant une fois par an ne peut pas du jour au lendemain se mettre à livrer quotidiennement. Ni sa culture, ni ses process, ni sa manière de tester ou de livrer ne sont prêts pour cela. C’est un peu comme si une personne depuis longtemps sédentaire se décidait à courir le marathon du jour au lendemain sans entrainement préalable. En revanche, une équipe coutumière de livraison hebdomadaire, avec une deadline de quatre mois, fournira seize versions ; chacune atténuera le problème un peu plus.
Nous ne savons pas ce que contiendrons ces versions – et ne cherchons pas à le savoir. Nous n’avons aucune garantie que ces 16 versions vont nous permettre de répondre complètement à la contrainte règlementaire. Mais les plannings n’apportent aucune garantie non plus. Ils ne sont que la projection de nos désirs.
Conclusion
Lorsque la deadline est forte (et moins forte aussi d’ailleurs), l’écoulement du temps entraine l’accroissement du risque. En s’adonnant à des activités prédictives (plannings, estimations, études…), le temps est gaspillé à spéculer sur le futur plutôt qu’à le bâtir. Donc le risque s’accroit fortement.
Pour minimiser le risque, nous pouvons :
Prioriser le sujet immédiatement, en dé‑priorisant tout le reste.
Viser l’atténuation progressive du problème plutôt que la solution parfaite dès le départ.
Livrer de petits incréments fonctionnels dès que possible, afin de réduire le risque à chaque livraison. Puis itérer, en utilisant la totalité du temps dont nous disposons. Donc en réduisant au maximum le risque compte tenu de nos moyens.