La gestion de projet agile repose sur des rôles et des rituels concrets, pas sur une philosophie floue. Voici Scrum, Kanban et comment choisir, même dans une équipe de trois personnes.
L’agilité : ce que c’est, et ce que ce n’est pas
L’agilité est souvent résumée à tort par une formule : « on verra au fur et à mesure ». C’est l’idée reçue la plus répandue, et la plus nuisible. Un projet agile n’est pas un projet sans planification. C’est un projet dont la planification est continue, itérative et ajustée à chaque cycle plutôt que figée en amont pour plusieurs mois.
La différence fondamentale avec une approche traditionnelle tient à la façon dont on traite l’incertitude. Plutôt que de prétendre tout savoir au départ et de subir les écarts en silence, une équipe agile accepte que le besoin évolue, organise son travail en cycles courts et ajuste ses priorités à chaque itération. Ce n’est pas de l’improvisation : c’est une discipline de pilotage.
L’agilité s’applique bien au-delà du développement logiciel. Des agences de communication, des cabinets de conseil, des studios créatifs et des équipes commerciales l’utilisent pour piloter leurs projets clients avec plus de réactivité et de transparence.
Le Manifeste Agile et ses quatre valeurs
En 2001, dix-sept développeurs américains ont rédigé le Manifeste Agile, un texte court qui pose les bases philosophiques de toutes les méthodes agiles. Ce manifeste n’impose aucun outil, aucun rôle, aucun rituel. Il formule quatre valeurs, chacune opposant deux priorités, non pour rejeter la seconde mais pour affirmer que la première compte davantage.
| Ce que l’agilité valorise davantage | Ce qu’elle ne rejette pas, mais considère secondaire |
|---|---|
| Les individus et leurs interactions | Les processus et les outils |
| Des logiciels (ou livrables) opérationnels | Une documentation exhaustive |
| La collaboration avec les clients | La négociation contractuelle |
| L’adaptation au changement | Le suivi d’un plan figé |
Ces quatre valeurs expliquent pourquoi une équipe agile préférera une démo fonctionnelle à un rapport de 50 pages, et pourquoi elle organisera une réunion de 15 minutes chaque matin plutôt qu’un comité de pilotage mensuel. Ce ne sont pas des caprices organisationnels : ce sont des choix délibérés pour réduire le temps entre la décision et la livraison de valeur.
Agile vs cycle en V : le tableau comparatif
Avant de choisir une méthode, il est utile de comprendre ce qui sépare concrètement une approche agile d’une approche classique comme le cycle en V ou la cascade. Ces deux familles ne s’opposent pas sur le terrain de la rigueur : elles s’opposent sur la façon de gérer l’incertitude et le changement.
| Critère | Cycle en V / Cascade | Méthodes agiles |
|---|---|---|
| Planification | Définie entièrement en amont | Continue, ajustée à chaque cycle |
| Livraison | En fin de projet | Régulière, à chaque sprint ou en flux continu |
| Gestion du changement | Coûteuse, via avenant | Intégrée au processus |
| Implication du client | Forte au départ, faible ensuite | Continue tout au long du projet |
| Documentation | Exhaustive et formalisée | Allégée, centrée sur la valeur livrée |
| Visibilité sur l’avancement | Par jalons prédéfinis | À chaque fin de sprint ou en temps réel |
| Adapté à | Projets stables, besoins bien définis | Projets évolutifs, besoins incertains |
Le cycle en V reste pertinent pour des projets dont le périmètre est précis et figé dès le départ, comme une migration de données ou un chantier de construction. Dès que le besoin est susceptible d’évoluer, que le client découvre ses attentes en voyant les premiers livrables, ou que le marché peut imposer un changement de cap, une approche agile sera plus adaptée.
Scrum en détail : rôles, événements et artefacts
Scrum est le framework agile le plus utilisé dans les équipes de développement, de produit et de services. Il structure le travail en cycles courts appelés sprints, d’une durée généralement comprise entre une et quatre semaines. À la fin de chaque sprint, l’équipe livre un incrément fonctionnel et exploitable.
Les trois rôles Scrum
Scrum repose sur une équipe réduite, pluridisciplinaire et auto-organisée, articulée autour de trois rôles distincts.
- Le Product Owner porte la vision du produit. Il maintient et priorise le backlog produit, arbitre les compromis entre valeur et effort, et s’assure que l’équipe travaille toujours sur ce qui apporte le plus de valeur au client. Il est le seul à décider de ce qui entre dans le backlog et dans quel ordre.
- Le Scrum Master est le gardien du framework. Il facilite les rituels, protège l’équipe des interruptions extérieures, lève les obstacles qui freinent la livraison et accompagne l’équipe dans l’amélioration continue de ses pratiques. Ce n’est pas un chef de projet : il n’a pas d’autorité hiérarchique sur l’équipe.
- L’équipe de développement regroupe les personnes qui réalisent concrètement le travail. Elle est pluridisciplinaire, auto-organisée et collectivement responsable de la qualité de ce qu’elle livre. Sa taille idéale se situe entre trois et neuf personnes.
Les quatre événements du sprint
- Le sprint planning ouvre chaque sprint. L’équipe sélectionne les éléments du backlog produit qu’elle s’engage à livrer, définit l’objectif du sprint et décompose le travail en tâches concrètes. Sa durée est proportionnelle à la longueur du sprint : deux heures par semaine de sprint est une règle courante.
- Le daily Scrum est une réunion quotidienne de 15 minutes maximum. Chaque membre de l’équipe partage ce qu’il a fait la veille, ce qu’il prévoit de faire aujourd’hui et les obstacles qu’il rencontre. L’objectif n’est pas de faire un rapport à un supérieur : c’est de synchroniser l’équipe et d’identifier rapidement ce qui pourrait empêcher d’atteindre l’objectif du sprint.
- La revue de sprint clôt chaque sprint par une démonstration des fonctionnalités livrées aux parties prenantes. C’est un moment de feedback, pas une présentation commerciale. Les retours recueillis alimentent directement le backlog pour le sprint suivant.
- La rétrospective est le rituel d’amélioration continue. L’équipe s’interroge sur sa façon de travailler : ce qui a bien fonctionné, ce qui a posé problème, et surtout quelles actions concrètes elle s’engage à mettre en place dès le prochain sprint. Une bonne rétrospective produit deux ou trois actions précises, chacune avec un responsable nommé.
Les trois artefacts Scrum
- Le backlog produit est la liste vivante et priorisée de tout ce que le produit doit faire ou devenir. Il est maintenu par le Product Owner et évolue en permanence en fonction des retours clients et des décisions d’équipe.
- Le backlog de sprint est le sous-ensemble du backlog produit que l’équipe s’est engagée à livrer pendant le sprint en cours. Il est la propriété de l’équipe de développement.
- L’incrément est le résultat concret et potentiellement livrable produit à la fin de chaque sprint. Il doit respecter la définition de fini (Definition of Done), un ensemble de critères convenus par l’équipe pour considérer qu’une tâche est réellement terminée.
Kanban en détail : tableau, limite de travail en cours et flux tiré
Kanban est une méthode visuelle issue de l’industrie manufacturière japonaise, adoptée par les équipes de services pour piloter un flux continu de travail. Contrairement à Scrum, Kanban n’impose ni rôles spécifiques, ni sprints, ni cérémonies obligatoires. Il repose sur trois pratiques fondamentales.
Le tableau Kanban
Le tableau Kanban visualise l’état d’avancement de chaque tâche sous forme de colonnes. La configuration minimale comprend trois colonnes : « À faire », « En cours » et « Terminé ». Les équipes plus avancées ajoutent des colonnes intermédiaires qui reflètent leur workflow réel : « En attente de validation », « En test », « En déploiement ». Chaque tâche est représentée par une carte qui avance de colonne en colonne jusqu’à sa livraison.
La limite de travail en cours (WIP)
La règle la plus importante de Kanban est la limite du Work In Progress. Chaque colonne du tableau dispose d’un nombre maximum de tâches autorisées simultanément. Quand une colonne est pleine, l’équipe ne peut pas y ajouter de nouvelle tâche : elle doit d’abord terminer ce qui est en cours. Cette contrainte, qui peut sembler contre-intuitive, est ce qui fluidifie le flux et réduit les temps de cycle. Elle force l’équipe à finir avant de commencer, plutôt que de multiplier les chantiers ouverts en parallèle.
Le flux tiré
Kanban fonctionne sur un principe de flux tiré : une nouvelle tâche n’entre dans le système que lorsqu’une capacité se libère. C’est l’opposé d’un système poussé, où le travail est affecté à l’équipe selon un planning prédéfini. Le flux tiré garantit que l’équipe ne se retrouve jamais submergée et que chaque tâche reçoit l’attention nécessaire pour être bien réalisée.
Les indicateurs clés de Kanban sont le temps de cycle (durée entre le démarrage et la livraison d’une tâche) et le débit (nombre de tâches livrées par unité de temps). Ces métriques permettent de détecter les goulots d’étranglement et d’améliorer le flux en continu.
Scrum, Kanban ou hybride : le tableau de décision
Choisir entre Scrum et Kanban n’est pas une question de mode ou de préférence personnelle. C’est une question de contexte. Voici les critères qui orientent ce choix.
| Situation | Scrum | Kanban | Hybride (Scrumban) |
|---|---|---|---|
| Projet avec roadmap et fonctionnalités à construire | Recommandé | Possible | Possible |
| Flux de demandes continues (support, maintenance) | Peu adapté | Recommandé | Possible |
| Équipe débutante en agilité | Recommandé (cadre structurant) | Possible (plus léger) | Déconseillé au départ |
| Priorités changeantes au quotidien | Peu adapté | Recommandé | Recommandé |
| Besoin de visibilité régulière pour le client | Recommandé (revues de sprint) | Possible | Recommandé |
| Équipe gérant à la fois projets et incidents | Peu adapté | Possible | Recommandé |
L’approche hybride, souvent appelée Scrumban, conserve les rituels structurants de Scrum (sprint planning, rétrospective) tout en adoptant les limites de WIP et le tableau visuel de Kanban. Elle convient particulièrement aux équipes qui doivent à la fois construire un produit sur la durée et absorber des demandes imprévues au quotidien.
Estimer en agile : points de complexité et vélocité
L’estimation est l’un des sujets qui génère le plus d’incompréhensions entre les équipes agiles et leurs clients. En agile, on n’estime pas en heures : on estime en points de complexité, aussi appelés story points.
Qu’est-ce qu’un point de complexité ?
Un story point est une unité de mesure relative. Il ne représente pas une durée : il représente l’effort global d’une tâche, en tenant compte de sa complexité technique, de son degré d’incertitude et du volume de travail qu’elle implique. Une tâche estimée à 8 points est jugée environ deux fois plus complexe qu’une tâche estimée à 4 points, sans que cela ne corresponde à un nombre d’heures précis.
Les équipes utilisent généralement l’échelle de Fibonacci (1, 2, 3, 5, 8, 13, 21) pour attribuer des points. Les grands écarts entre les valeurs sont intentionnels : ils reflètent le fait que plus une tâche est importante, moins on peut en estimer la durée avec précision. La technique du planning poker permet à toute l’équipe de voter simultanément sur l’estimation d’une tâche, de faire émerger les désaccords et d’en discuter.
La vélocité : un outil de planification, pas de performance
La vélocité est la somme des points de complexité livrés par l’équipe à la fin d’un sprint. En calculant sa moyenne sur plusieurs sprints, l’équipe obtient un indicateur fiable pour planifier : si la vélocité moyenne est de 30 points et que le backlog restant représente 150 points, on peut estimer qu’il faudra environ cinq sprints pour terminer le projet.
Deux mises en garde importantes s’imposent. D’abord, la vélocité est propre à chaque équipe : comparer la vélocité de deux équipes différentes n’a aucun sens, car leurs échelles d’estimation ne sont pas les mêmes. Ensuite, la vélocité est un indicateur de planification, pas un objectif de performance. Pousser une équipe à augmenter sa vélocité conduit généralement à gonfler les estimations, pas à livrer plus vite.
Budget et contrat : forfait ou régie pour un projet agile ?
C’est la question qui bloque le plus souvent les discussions commerciales autour des projets agiles. Un client veut un prix ferme. L’équipe sait que le périmètre va évoluer. Comment concilier les deux ?
Pourquoi le forfait classique est inadapté à l’agile
Un contrat à forfait repose sur un périmètre précis et figé. En agile, le périmètre est par définition évolutif : c’est même l’un de ses atouts. Utiliser un forfait sur un projet agile crée une contradiction structurelle : l’équipe travaille en sprints et adapte les priorités, mais le contrat exige une conformité à un cahier des charges rédigé avant le premier sprint. Résultat : des avenants permanents, des tensions sur ce qui est « inclus » ou non, et parfois des litiges.
La régie agile et ses alternatives
La régie (ou Time and Materials) est le modèle le plus cohérent avec l’agilité. Le client paie le temps réellement passé, au tarif convenu. Il garde la maîtrise des priorités et peut réorienter le projet à tout moment. En contrepartie, il porte le risque budgétaire et doit s’impliquer activement dans la priorisation du backlog.
Pour les clients qui ont besoin de visibilité budgétaire, plusieurs modèles intermédiaires existent.
- Le forfait par sprint : un prix fixe est défini pour chaque itération, avec un périmètre variable. Le client sait exactement ce que chaque sprint lui coûte, mais peut ajuster les priorités d’un sprint à l’autre.
- Le budget enveloppe : un plafond global est fixé, et le client arbitre en permanence entre les fonctionnalités à développer en fonction du budget restant.
- Le forfait agile borné : un prix maximum est défini, mais le périmètre peut être ajusté à la baisse si certaines fonctionnalités s’avèrent trop complexes. Si une fonctionnalité est trop coûteuse, elle est remplacée par deux fonctionnalités plus simples de valeur équivalente.
Comment vendre un projet agile à un client qui veut un prix ferme
La clé est de déplacer la conversation du prix total vers le prix par sprint. Plutôt que de promettre un livrable complet pour un montant global, proposez au client de financer un premier lot de sprints (par exemple deux ou trois) pour produire un premier incrément fonctionnel. À l’issue de ce premier lot, le client dispose d’un livrable réel, d’une vélocité mesurée et d’une estimation beaucoup plus fiable du reste du projet. Cette approche réduit le risque pour les deux parties et construit la confiance progressivement.
Adapter l’agilité à une petite équipe de trois ou quatre personnes
Scrum a été conçu pour des équipes de cinq à neuf personnes. Cela ne signifie pas qu’il est inapplicable dans une équipe plus petite, mais certains ajustements s’imposent.
Dans une équipe de trois ou quatre personnes, les rôles Scrum ne peuvent pas toujours être portés par des personnes distinctes. Il est courant qu’un développeur assume également le rôle de Scrum Master, ou que le Product Owner soit aussi membre de l’équipe de développement. Ce n’est pas idéal, car cela crée des conflits d’intérêts potentiels, mais c’est souvent inévitable dans les petites structures. L’essentiel est que chacun comprenne les responsabilités associées à chaque rôle et les assume consciemment.
Les rituels peuvent être allégés sans être supprimés. Un daily de dix minutes suffit dans une petite équipe où tout le monde se parle naturellement. Un sprint planning d’une heure peut remplacer une demi-journée si le backlog est bien préparé. La rétrospective, en revanche, ne doit jamais être sacrifiée : c’est le seul moment dédié à l’amélioration du fonctionnement de l’équipe, et c’est là que se construit la maturité agile.
Kanban est souvent plus naturel pour les très petites équipes qui gèrent des projets variés et des demandes clients en parallèle. Un tableau en trois colonnes, une limite de deux ou trois tâches en cours par personne, et un point hebdomadaire suffisent pour commencer à piloter le flux de façon visible et maîtrisée.
Les erreurs les plus fréquentes en gestion de projet agile
L’agilité mal appliquée peut être pire qu’une approche traditionnelle bien tenue. Voici les erreurs les plus courantes, observées dans les équipes qui débutent ou qui ont perdu le fil de leurs pratiques.
Des rituels vidés de leur sens
Le daily devient un tour de table où chacun récite ce qu’il a fait hier et ce qu’il fera demain, sans que personne ne détecte les obstacles. La rétrospective produit des post-its qui ne donnent lieu à aucune action concrète. La revue de sprint est annulée faute de temps. Ces rituels ont une fonction précise : les pratiquer mécaniquement sans en comprendre l’intention revient à conserver la forme sans la substance. Un daily utile répond à une seule question : qu’est-ce qui pourrait empêcher l’équipe d’atteindre son objectif de sprint aujourd’hui ?
Un backlog jamais priorisé
Un backlog qui n’est pas régulièrement revu et priorisé devient rapidement une liste de souhaits sans ordre logique. L’équipe ne sait plus quoi traiter en premier, le Product Owner n’a pas de vision claire de ce qui apporte le plus de valeur, et les sprints sont planifiés au hasard plutôt qu’en fonction des priorités réelles. Le backlog doit être un document vivant, revu au moins une fois par sprint lors d’une session de refinement.
L’absence de définition de fini
Sans définition de fini (Definition of Done) partagée et écrite, chaque membre de l’équipe a sa propre interprétation de ce que signifie « terminé ». Une fonctionnalité peut être considérée comme livrée par le développeur alors qu’elle n’a pas été testée, documentée ou validée par le Product Owner. La définition de fini est un accord collectif, affiché et consulté à chaque sprint, qui garantit que ce qui est livré est réellement utilisable.
Confondre agilité et absence de rigueur
L’agilité demande plus de discipline qu’une approche traditionnelle, pas moins. Les rituels doivent être tenus, le backlog maintenu, les engagements de sprint respectés. Une équipe qui saute des rétrospectives « pour gagner du temps » ou qui modifie le contenu d’un sprint en cours sans processus clair ne pratique pas l’agilité : elle improvise.
Un tableau ne suffit pas à piloter un projet client
Un tableau Kanban bien tenu et des sprints réguliers permettent de livrer de façon organisée. Mais dans une entreprise de services, livrer bien ne suffit pas : encore faut-il livrer de façon rentable. Or, le tableau agile ne dit rien du temps réellement passé sur chaque tâche, ni du montant facturé au client. Une équipe peut terminer tous ses sprints dans les délais et pourtant perdre de l’argent, simplement parce que le temps consommé dépasse ce qui avait été vendu.
C’est le point aveugle de beaucoup de petites agences et de TPE qui adoptent l’agilité : elles améliorent leur organisation interne sans connecter leur pilotage projet à leur réalité financière. Le projet avance, le client est satisfait, mais la marge fond sprint après sprint sans que personne ne s’en aperçoive avant la facturation finale.
Djaboo relie les tâches d’un projet, les temps saisis par l’équipe et la facturation client dans un même espace de travail. Cela permet de comparer à tout moment l’avancement réel du projet au budget consommé : combien d’heures ont été passées, pour quel montant vendu, et quelle marge reste disponible pour terminer le projet. Cette visibilité financière, mise à jour en continu, permet de prendre des décisions avant qu’il ne soit trop tard, qu’il s’agisse de renégocier le périmètre, d’alerter le client ou de réorganiser les priorités du prochain sprint.
Questions fréquentes
Quelle est la différence entre Scrum et Agile ?
L’agilité est une philosophie de gestion de projet fondée sur quatre valeurs et douze principes formulés dans le Manifeste Agile de 2001. Scrum est un framework concret qui met ces principes en pratique, avec des rôles définis, des événements réguliers et des artefacts précis. Dire qu’on « fait de l’agile » sans préciser le framework utilisé revient à dire qu’on « fait du sport » sans préciser lequel. Scrum est le framework agile le plus répandu, mais il en existe d’autres : Kanban, SAFe, LeSS, ou encore des approches hybrides comme le Scrumban.
Combien de temps dure un sprint ?
Un sprint dure généralement entre une et quatre semaines. La durée la plus courante est de deux semaines, car elle offre un bon équilibre entre la fréquence des livraisons et le temps nécessaire pour produire un incrément significatif. Les sprints d’une semaine conviennent aux équipes très expérimentées ou aux projets à forte incertitude. Les sprints de quatre semaines sont adaptés aux projets dont les fonctionnalités sont complexes et nécessitent plus de temps de développement. Une fois la durée choisie, elle doit rester constante tout au long du projet.
Peut-on modifier le contenu d’un sprint en cours ?
En Scrum, le contenu du sprint est protégé une fois le sprint planning terminé. L’objectif du sprint ne doit pas changer en cours de route, même si de nouvelles demandes urgentes arrivent. Ces nouvelles demandes sont ajoutées au backlog produit et traitées lors du sprint suivant. Si une urgence est réellement bloquante, le Product Owner peut décider d’annuler le sprint, mais c’est une décision exceptionnelle. Cette protection du sprint est ce qui permet à l’équipe de s’engager sur un objectif et de le tenir. En Kanban, en revanche, les priorités peuvent être réordonnées à tout moment, tant que les tâches en cours ne sont pas interrompues.
Comment convaincre un client de travailler en agile ?
La résistance d’un client à l’agilité vient presque toujours de la peur de perdre le contrôle du budget et du périmètre. Pour la lever, il faut montrer que l’agilité donne au client plus de contrôle, pas moins. En agile, le client voit des livrables fonctionnels à chaque sprint, peut ajuster les priorités en cours de route et ne paie que pour ce qui est réellement produit. La clé est de proposer un premier lot de sprints à périmètre limité, avec un livrable concret à l’issue, pour que le client expérimente la méthode avant de s’engager sur un projet complet.
Quelle est la taille idéale d’une équipe Scrum ?
Le Guide Scrum recommande des équipes de trois à neuf personnes. En dessous de trois, l’équipe manque de diversité de compétences et risque de créer des goulots d’étranglement. Au-delà de neuf, la coordination devient plus complexe et les rituels s’alourdissent. Pour les petites structures, une équipe de trois ou quatre personnes peut tout à fait pratiquer Scrum en adaptant la durée des rituels et en acceptant que certains rôles soient portés par les mêmes personnes. L’essentiel est que les responsabilités associées à chaque rôle soient clairement assumées.
Faut-il un outil numérique pour pratiquer l’agilité ?
Non, pas nécessairement au départ. Un tableau blanc, des post-its et un marqueur suffisent pour démarrer avec Kanban ou Scrum dans une petite équipe. L’avantage d’un tableau physique est sa visibilité immédiate et son accessibilité sans formation. Les outils numériques deviennent utiles dès que l’équipe est distribuée géographiquement, que le volume de tâches augmente, ou que l’on a besoin de relier le suivi des tâches à d’autres dimensions du pilotage, comme le temps passé, la facturation ou le reporting client. Dans ce cas, un outil qui centralise ces informations évite de jongler entre plusieurs tableaux de bord déconnectés les uns des autres.
