Agile et chaîne critique : gardez vos sprints, tenez enfin vos délais

La rétrospective du sprint 6 se passe bien. L'équipe a livré ce qu'elle avait promis, la démo a plu, l'ambiance est bonne. Puis le directeur de projet pose une question simple : « Et la mise en production du 15 mars, on la tient ? »

Personne ne sait répondre. Les sprints sont tenus, un par un. Mais le backlog a grossi, deux développeurs ont été appelés sur un autre projet pendant une semaine, et la recette n'a toujours pas de date réaliste. Chaque sprint est à l'heure, et pourtant le projet glisse.

Ce n'est pas un échec de Scrum. C'est une question à laquelle Scrum n'a pas été conçu pour répondre seul : comment protéger une date de livraison quand le contenu du travail évolue sprint après sprint ?

Ce que Scrum fait très bien, et ce qu'il ne promet pas

Les méthodes agiles ont profondément amélioré la conduite des projets logiciels. Le CHAOS Report 2015 du Standish Group, qui analyse des milliers de projets informatiques menés entre 2011 et 2015, compte 39 % de projets agiles réussis contre 11 % pour les projets en cycle en V (« waterfall »).

Scrum, le cadre agile le plus répandu, repose sur quelques principes simples, décrits dans le Scrum Guide de Ken Schwaber et Jeff Sutherland (édition 2020) :

• le travail est découpé en sprints, des périodes de durée fixe d'un mois au maximum ;
• chaque sprint poursuit un objectif (le Sprint Goal) ;
• la date de fin du sprint ne bouge pas : c'est la quantité de travail accompli qui varie ;
• la démarche est empirique : on regarde ce qui s'est réellement passé, puis on adapte.

Un rythme régulier

Des sprints courts et fixes donnent une cadence claire à l'équipe et au client.

Des retours fréquents

Chaque fin de sprint montre un résultat concret et permet d'ajuster la suite.

Une équipe autonome

L'équipe s'organise elle-même pour atteindre l'objectif du sprint.

Là où Scrum s'arrête

Scrum protège la durée du sprint. Il ne prévoit pas de mécanisme pour protéger la date finale d'un projet, ni pour arbitrer entre plusieurs projets qui se disputent les mêmes personnes.

Marris Consulting, cabinet français spécialiste de la chaîne critique, résume bien la situation dans sa présentation consacrée aux projets informatiques : l'agilité apporte la réactivité et l'autonomie des équipes, mais elle ne garantit pas la maîtrise des dépendances du planning ni de la charge des équipes.

Or c'est exactement ce que demandent la plupart des projets IT dans une PME ou un bureau d'études : une date de mise en service promise au client, une recette à caler avec ses équipes, une migration de données qui dépend d'un prestataire, et des développeurs qui travaillent aussi sur d'autres projets.

Ce que la chaîne critique apporte : protéger la date, pas chaque tâche

La méthode de la chaîne critique (Critical Chain Project Management, ou CCPM) a été présentée par Eliyahu Goldratt dans Critical Chain (1997). Elle part d'un constat : les marges de sécurité cachées dans chaque estimation ne protègent pas le projet. Elles se perdent localement, tâche par tâche.

La CCPM propose donc :

• des estimations nettes, sans marge cachée ;
• un seul buffer placé en fin de projet, qui protège la date de livraison ;
• un suivi par le reste à faire : « combien de temps de travail reste-t-il à partir de maintenant ? », plutôt qu'un pourcentage d'avancement déclaré ;
• une lecture de la santé du projet sur le fever chart, qui compare l'avancement à la consommation du buffer.

Si ces notions sont nouvelles pour vous, notre guide complet sur la CCPM les présente pas à pas, et l'article sur les marges de sécurité cachées dans les plannings explique pourquoi elles disparaissent si vite.

Deux méthodes, un point de rencontre

À première vue, Scrum et la chaîne critique ne parlent pas de la même chose. L'une organise le travail d'une équipe. L'autre protège la date d'un projet. C'est justement pour cela qu'elles se complètent.

La dernière ligne du tableau montre le manque de Scrum. La ligne « moment de réévaluation » montre le point commun : à la fin d'un sprint, l'équipe regarde honnêtement ce qui s'est passé. La chaîne critique a besoin précisément de cette information, le reste à faire, pour mesurer la consommation du buffer.

Autrement dit, il ne s'agit pas de choisir entre deux méthodes parallèles. La chaîne critique pilote le projet et le portefeuille ; Scrum s'emboîte à l'intérieur, au niveau d'un lot de travail. Notre article Excel, Gantt, Jira… et toujours en retard montre ce changement de niveau du point de vue du portefeuille. Ce guide montre comment il fonctionne concrètement, sprint après sprint.

Dans quels projets combiner Agile et chaîne critique ?

La combinaison est utile dès qu'une partie du projet a un contenu qui évolue et que le projet entier a une date à tenir.

Développement logiciel

Un portail client, une application métier, une nouvelle version de SaaS : les fonctionnalités se précisent au fil des démos.

Intégration et paramétrage

ERP, CRM, outil de GMAO : le paramétrage se fait par itérations avec les utilisateurs, mais la bascule a une date.

Projets mixtes

Un bureau d'études ou une agence qui livre un ouvrage ou un site, avec un lot logiciel au milieu de tâches classiques.

À l'inverse, la combinaison n'apporte pas grand-chose dans deux cas :

Le mode Agile dans KairoProject, en quatre notions

KairoProject n'ajoute pas une deuxième méthode à côté de la chaîne critique. Il permet de réaliser une tâche du planning en sprints. Le moteur de planification, le buffer et le fever chart restent ceux de la chaîne critique, sans modification.

Workpackage

Une tâche dont la case « Agile » est cochée dans sa fiche. Le mode se règle tâche par tâche : un même projet peut mélanger tâches classiques et workpackages.

Sprint

Une période de travail de 1 à 4 semaines, numérotée, avec un objectif. Ce n'est pas une tâche : il n'a ni dépendance, ni ressource, ni durée de travail propre.

Item

Une sous-tâche du workpackage, devenue une simple ligne de suivi que l'on coche. Elle n'influence ni la durée ni le reste à faire : aucun double comptage.

Reste à faire

Le nombre d'heures de travail qu'il reste pour terminer le workpackage, estimé par l'équipe. C'est la seule valeur que lit le moteur de planification.

Pourquoi ce choix ? Parce que c'est la seule façon de respecter les deux méthodes à la fois. Le sprint garde sa durée fixe, comme le veut Scrum. La date du projet reste protégée par le buffer, comme le veut la chaîne critique. Et l'estimation initiale n'est jamais recalculée : on met à jour uniquement ce qui reste à faire, ce qui est le principe même du suivi en chaîne critique.

En pratique : un projet IT, sprint par sprint

Prenons une équipe de six personnes qui développe un portail client pour un industriel. La mise en production est promise pour le 15 mars. Le projet comprend :

• un cadrage et des maquettes, bien connus : ce sont des tâches classiques ;
• le développement des fonctionnalités, dont le contenu va se préciser au fil des démos : c'est un workpackage Agile, estimé à 120 heures de travail ;
• une recette et une mise en production, à nouveau des tâches classiques ;
• le buffer de projet, qui protège la date du 15 mars.

1. 1

   Dans la fiche de la tâche « Développement des fonctionnalités », cochez la case « Agile ». La durée et le reste à faire gardent leur valeur actuelle. Les items déjà présents sont conservés, mais on n'en ajoute plus ensuite : le backlog détaillé vit dans l'outil de l'équipe.

2. 2

   Dans la section « Sprints », saisissez l'objectif (« Authentification et tableau de bord client ») puis cliquez sur « Créer le sprint ». Il dure une semaine par défaut, réglable de 1 à 4 semaines. Il est Prévisionnel : ses dates sont calculées automatiquement et suivent le workpackage s'il est décalé.

3. 3

   Le jour J, cliquez sur « Démarrer le sprint ». Le champ « Début réel » est prérempli avec le moment présent ; vous pouvez le reculer en cas de démarrage tardif. Les dates sont alors figées. Un seul sprint peut être démarré à la fois.

4. 4

   Pendant le sprint, rien ne change pour l'équipe : rituels, backlog, outils habituels. Si la date de fin est dépassée sans clôture, un badge violet « sprint échu » s'affiche avec le nombre de jours de retard (« + 2 j »). Un clic ouvre le formulaire de clôture.

5. 5

   C'est le moment clé, détaillé ci-dessous : l'équipe répond à trois questions et confirme son reste à faire. Le planning se recalcule à partir de cette valeur.

6. 6

   Créez le sprint suivant depuis la fiche de la tâche. Quand le livrable est terminé, la dernière clôture le déclare : le workpackage se termine et la recette peut démarrer.

La clôture du sprint : le moment où les deux méthodes se rencontrent

La clôture est le seul moment où un sprint agit sur le planning. Le formulaire « Clôturer le sprint » pose trois questions, dans cet ordre.

1. Objectif atteint ?

Oui, Partiellement ou Non. Réponse obligatoire, rien n'est présélectionné : l'équipe doit choisir.

2. Livrable terminé ?

Oui : le reste à faire passe à 0 et le workpackage est terminé. Non : l'équipe confirme le reste à faire, forcément supérieur à 0.

3. Pourquoi l'écart ?

Facultatif, proposé si le reste à faire dépasse la valeur attendue : estimation trop optimiste, aléa ou blocage, ajout de périmètre.

L'exemple chiffré

Revenons au portail client. Le calendrier de la tâche compte 5 jours de 8 heures. Avant le sprint 1, le reste à faire du développement est de 120 heures.

La valeur attendue n'est jamais imposée : c'est un repère. KairoProject ne fait aucune soustraction automatique, ni de la durée du sprint, ni des items cochés. Seule compte l'estimation honnête de l'équipe.

Ce que fait la clôture, précisément

1. 1

   Le sprint passe à l'état Clos. Sa fiche garde l'historique : objectif atteint ou non, reste à faire avant, après et attendu, cause et commentaire.

2. 2

   Le reste à faire du workpackage devient exactement la valeur saisie : 110 heures dans notre exemple.

3. 3

   Le moteur de la chaîne critique recalcule le planning à partir de ce nouveau reste à faire. La recette et la mise en production se décalent, et le buffer absorbe ce décalage.

4. 4

   Si la consommation du buffer augmente de plus que le seuil du portefeuille (3 points par défaut, réglable), l'événement est enregistré avec la cause choisie à la clôture. La question n'est pas reposée.

Ce que voit le responsable du portefeuille

C'est là que la combinaison prend toute sa valeur. Le directeur de projet qui demandait « on tient le 15 mars ? » n'a plus besoin d'attendre la rétrospective.

• Sur le fever chart, le portail client se déplace après chaque clôture : l'avancement du projet est comparé à la consommation de son buffer. Une zone verte, jaune ou rouge dit immédiatement si la date est menacée.
• Dans l'analyse des causes de retard du portefeuille, les trois causes de sprint sont des catégories à part entière. Après quelques mois, on sait si les écarts viennent surtout d'estimations optimistes, de blocages ou d'ajouts de périmètre. Ce n'est pas la même conversation avec le client.
• Le tableau de bord continue de désigner le projet prioritaire, la raison et l'action recommandée, en tenant compte du nouveau planning.

Ce lien régulier entre sprint et buffer a un autre effet : il réduit la tentation de répartir les développeurs sur trois projets en même temps. Quand chaque sprint montre son effet sur la date, la priorité devient visible, et le multitâche entre projets se discute sur des faits.

Ce que le mode Agile ne fait pas, et pourquoi c'est voulu

KairoProject ne cherche pas à remplacer Jira, Azure DevOps ou le tableau de votre équipe. Son rôle est de relier le résultat des sprints au planning et au portefeuille. Certaines fonctions restent donc, volontairement, dans l'outil d'exécution de l'équipe.

Quelques règles complètent ce partage des rôles :

• pas de création automatique du sprint suivant : chaque sprint est un engagement que l'équipe crée elle-même ;
• un sprint clos ne se modifie plus : il devient l'historique fiable du projet ;
• un workpackage ne peut pas être terminé tant qu'un sprint est en cours : on clôture d'abord ;
• dans l'API publique et les outils MCP, les sprints sont accessibles en lecture (liste, sprints échus, aperçu de clôture), ce qui permet par exemple à un assistant IA de vous signaler les sprints à clôturer.

Questions fréquentes

Essayez sur votre prochain projet

Vous n'avez pas besoin de changer la façon dont votre équipe travaille. Choisissez un projet avec une date à tenir, passez son lot de développement en mode Agile, et clôturez le premier sprint avec un reste à faire honnête. Le fever chart vous dira, dès la première semaine, si la date est en danger.

Sources et lectures complémentaires

• Ken Schwaber et Jeff Sutherland, The Scrum Guide (édition 2020) : la définition officielle des sprints, de l'objectif de sprint et de la démarche empirique. Lire le Scrum Guide (PDF)
• Eliyahu Goldratt, Critical Chain (1997) : l'ouvrage fondateur de la méthode de la chaîne critique. Disponible sur Google Books
• Marris Consulting, accélérer les projets informatiques en combinant Agile et chaîne critique. Lire la présentation (PDF)
• Wolfram Müller, A Practical Guide: How to Integrate Agile into CCPM or Vice Versa, conférence TOCICO 2020. Voir la présentation

À lire ensuite

• CCPM : la méthode qui explique pourquoi vos projets dérivent : les fondations de la chaîne critique.
• Le fever chart de la CCPM : lire en un coup d'œil l'effet de chaque clôture de sprint sur la date.
• Excel, Gantt, Jira… et toujours en retard : piloter un portefeuille IT par priorités, au-dessus de Jira.
• Réduire le multitâche dans les équipes projet : pourquoi un développeur sur trois projets ralentit les trois.