Limiter l’en-cours
Arrêter de commencer, commencer à finirUn studio qui ouvre ses huit projets en même temps a l’air de tout faire avancer. En réalité, chaque projet attend son tour plus longtemps, et chaque passage d’un dossier à l’autre coûte de l’attention. Gerald Weinberg estimait en 1992 qu’une personne sur deux projets perd environ 20 % de son temps en changements de contexte, et environ 40 % sur trois. Mais un seul projet à la fois n’est pas non plus la solution : quand le client tarde à valider, l’équipe attend. Cherche le bon nombre de projets ouverts.
Le Kanban naît dans une équipe de maintenance de Microsoft
David Anderson reprend une petite équipe de Microsoft chargée de petites évolutions logicielles. Les demandes s’empilent, les délais s’allongent, les clients internes se plaignent. Plutôt que d’embaucher, il limite le nombre de demandes en cours à chaque étape et ne laisse entrer une nouvelle demande que lorsqu’une autre sort. Les délais de livraison chutent nettement et l’équipe livre davantage, sans effectif supplémentaire. Il en tire la méthode Kanban appliquée au travail intellectuel.
À retenir : on accélère un flux en le limitant, pas en le remplissant.
Source : David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business, Blue Hole Press, 2010, chapitre 4.
Une règle simple. Une colonne « en cours » limitée, par exemple à deux projets par personne. Tant qu’elle est pleine, on aide à finir au lieu de commencer.
Le lien avec Little. À débit égal, plus il y a d’en-cours, plus le délai est long : c’est la loi de Little, détaillée dans le chapitre lean.
Travailler en sprints
Montrer tôt, corriger tant que ça coûte peuScrum découpe le travail en sprints d’un mois au plus : on planifie, on produit, on montre le résultat au client lors de la revue, puis l’équipe fait sa rétrospective. Pour un projet client à date fixe, l’agilité ne fait pas disparaître la date. Elle change ce qui bouge : au lieu de tout livrer à la fin et de découvrir les écarts trop tard, on découvre les changements tôt et on arbitre le périmètre. Le client du studio veut un parcours de formation en 12 semaines. Compare trois façons de le mener.
Le FBI sauve Sentinel en passant aux sprints
Après l’abandon d’un premier système de gestion des dossiers en 2005, le FBI lance Sentinel avec un grand intégrateur. En 2010, le projet est en retard et a consommé l’essentiel de son budget. Le FBI le rapatrie en interne et le confie à une petite équipe qui travaille en sprints, avec des démonstrations régulières aux utilisateurs. Le système est mis en service en juillet 2012. Les rapports de l’Inspection générale du ministère de la Justice ont suivi chaque étape.
À retenir : des livraisons courtes et montrées tôt réduisent le risque, surtout quand le besoin est flou.
Source : U.S. Department of Justice, Office of the Inspector General, rapports d’audit sur le projet Sentinel, 2010 à 2012.
Date fixe, périmètre souple. Dans un contrat client, on peut fixer la date et le budget, et classer le périmètre en « indispensable, important, bonus ». Les changements remplacent du bonus au lieu de repousser la date.
La rétrospective est le vrai moteur. Quinze minutes en fin de sprint pour une seule amélioration concrète. Sans elle, Scrum devient une suite de réunions.
Prévoir avec l’historique
Une date avec une probabilité, pas une promesseDemander à une équipe « quand ce sera fini ? » donne une réponse optimiste, celle d’une bonne semaine. Une meilleure méthode : compter combien de tâches l’équipe a réellement terminées chaque semaine, puis rejouer mille fois l’avenir en tirant au hasard dans cet historique. C’est la simulation de Monte-Carlo. Elle donne une date à 50 % de chances et une date à 85 %. L’équipe digitale de Kumo doit livrer 40 tâches pour le nouveau site.
Le manuel scolaire de Kahneman : deux ans prévus, huit réels
Daniel Kahneman dirige une équipe chargée d’écrire un programme et un manuel d’initiation au jugement et à la décision pour les lycées israéliens. Chacun estime le travail à environ deux ans. Il demande alors à un membre expérimenté combien de temps ont pris des équipes comparables : une partie n’a jamais fini, les autres ont mis sept à dix ans. L’équipe continue quand même. Le manuel est terminé huit ans plus tard, et le ministère ne l’utilise jamais.
À retenir : la vue de l’extérieur, ce qu’ont fait des projets semblables, bat l’optimisme de l’équipe. L’historique de vélocité en est la version quotidienne.
Source : Daniel Kahneman, Système 1 / Système 2 (Thinking, Fast and Slow, 2011), chapitre 23, « La vue de l’extérieur ».
Compter des tâches suffit. Pas besoin de points ni d’heures : si les tâches sont découpées à une taille comparable, leur nombre par semaine prévoit aussi bien.
Les biais de planification. Hofstadter, Parkinson et la règle des 90-90 sont dans Murphy et les délais.
Charge contre capacité
Une équipe pleine à 100 % est une équipe en retardRemplir le plan de charge à 100 % paraît rationnel : personne ne reste inactif. Mais le travail n’arrive pas de façon régulière. Les demandes imprévues, les retours clients et les arrêts maladie créent une file d’attente, et la théorie des files d’attente est formelle : quand l’occupation approche 100 %, l’attente ne monte pas un peu, elle explose. Règle le remplissage prévu du studio et regarde ce que deviennent les urgences.
Les hôpitaux et le seuil des 85 %
Des chercheurs britanniques simulent l’occupation des lits d’un hôpital qui reçoit des urgences arrivant au hasard. Au-delà d’environ 85 % d’occupation moyenne, l’hôpital connaît régulièrement des jours sans lit libre pour un patient urgent, et les crises deviennent fréquentes quand on approche des 90 %. Leur étude est devenue une référence pour le pilotage des capacités hospitalières.
À retenir : un système qui reçoit de l’imprévu a besoin de capacité libre. Ce n’est pas du gaspillage, c’est ce qui absorbe la variabilité.
Source : Adrian Bagust, Michael Place et John Posnett, « Dynamics of bed use in accommodating emergency admissions: stochastic simulation model », BMJ, 1999.
Garder 15 à 20 % de marge. On ne planifie pas l’équipe à 100 %. La marge accueille les imprévus, le support et l’amélioration continue.
Mesurer la vraie capacité. Une personne à temps plein ne fait pas cinq jours de projet : réunions, support, gestion. Compte d’abord ce qui reste.
Prioriser par le coût du retard
Ce que coûte chaque semaine d’attenteQuand tout est prioritaire, rien ne l’est. Don Reinertsen propose une question plus utile que « qu’est-ce qui est important ? » : combien coûte chaque semaine de retard de ce projet ? Une subvention perdue, un client qui part, une rentrée scolaire ratée. On divise ensuite ce coût du retard par la durée du projet : c’est le WSJF (weighted shortest job first). Les projets courts et coûteux à retarder passent devant. Ordonne les cinq projets du studio.
Maersk Line chiffre ses demandes informatiques
Chez l’armateur danois Maersk Line, des centaines de demandes informatiques attendent, priorisées par des échelles de type « haute, moyenne, basse ». Joshua Arnold et Özlem Yüce font chiffrer à chaque demandeur ce que coûte une semaine de retard. Le résultat surprend : une petite partie des demandes concentre l’essentiel du coût du retard, et certaines demandes jugées « hautes » pèsent très peu. L’ordre de passage est revu en conséquence.
À retenir : mettre un chiffre, même approximatif, sur le retard change les débats de priorité.
Source : Joshua Arnold et Özlem Yüce, « Black Swan Farming using Cost of Delay », retour d’expérience, conférence Agile 2013.
Un ordre de grandeur suffit. Inutile d’être précis à l’euro près : « 5 k€, 20 k€ ou 100 k€ par semaine » suffit à séparer les projets.
Les échéances dures. Une rentrée scolaire ou une date de dépôt de subvention créent un coût du retard brutal : tout ou rien. Traite-les à part, avec leur date.
Ton plan de charge et tes priorités
Atelier L’outil du lundi matin, à réutiliserÀ toi. Décris l’équipe (personnes, jours par semaine, part du temps hors projets) et les projets (charge estimée en jours, échéance, coût d’une semaine de retard). L’outil calcule le taux de charge, trie par WSJF, simule 500 fois l’avenir avec l’incertitude habituelle des estimations, et donne pour chaque projet une date de fin probable et une date prudente. Il signale les projets à décaler ou à renégocier. Tout est sauvegardé dans ton navigateur.
Ta synthèse
Remplis l’outil ou charge un exemple pour voir le plan.
Moins d’en-cours
Limiter les projets ouverts ; finir avant de commencer.
Montrer tôt
Des sprints courts, une revue avec le client, un périmètre arbitré.
Prévoir avec l’historique
Une date à 85 % pour le client, pas la date optimiste.
Marge et coût du retard
15 à 20 % de capacité libre, et un ordre de passage chiffré.
Pour aller plus loin
- David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business, Blue Hole Press, 2010.
- Gerald M. Weinberg, Quality Software Management, Volume 1: Systems Thinking, Dorset House, 1992.
- Ken Schwaber et Jeff Sutherland, The Scrum Guide, novembre 2020.
- U.S. Department of Justice, Office of the Inspector General, rapports d’audit sur le projet Sentinel du FBI, 2010-2012.
- Daniel Kahneman, Thinking, Fast and Slow, 2011 (trad. Système 1 / Système 2, Flammarion, 2012).
- Daniel S. Vacanti, When Will It Be Done?, 2020.
- Adrian Bagust, Michael Place, John W. Posnett, « Dynamics of bed use in accommodating emergency admissions », BMJ, 1999.
- Donald G. Reinertsen, The Principles of Product Development Flow, Celeritas, 2009.
- Joshua Arnold et Özlem Yüce, « Black Swan Farming using Cost of Delay », Agile 2013.