Méthodes agiles gestion de projet : Scrum, Kanban, Scrumban

Scrum impose des sprints de 2 semaines et des rôles précis

Scrum est le cadre agile le plus utilisé et aussi le plus encadré. Le travail se découpe en sprints de 1 à 4 semaines, avec une préférence nette pour 2 semaines : assez court pour corriger le tir vite, assez long pour livrer quelque chose de montrable. À chaque fin de sprint, l’équipe présente un incrément fonctionnel lors de la revue de sprint, devant les parties prenantes.

Trois rôles organisent le tout. Le Product Owner porte la vision et arbitre les priorités. Le Scrum Master protège l’équipe des interruptions et veille au respect du cadre. L’équipe de développement, de 3 à 9 personnes (en pratique 7 personnes, plus ou moins 2), réalise le travail sans chef hiérarchique interne. Au-delà de 9, les échanges se diluent et la mêlée quotidienne dérape.

Le backlog de produit sert de référence : une liste ordonnée de tout ce qu’il reste à faire, que le Product Owner réorganise en continu. Au début de chaque sprint, l’équipe pioche dans le haut de la pile ce qu’elle estime pouvoir terminer. Chaque jour, une mêlée de 15 minutes pose trois questions : qu’est-ce qui a avancé, qu’est-ce qui est prévu, qu’est-ce qui bloque.

Ce que je constate sur le terrain : Scrum marche bien quand le périmètre peut se découper en livrables réguliers. Il devient pénible quand les urgences pleuvent en cours de sprint, car le principe veut qu’on ne touche pas au contenu une fois le sprint lancé. Autre point souvent oublié : les méthodes agiles séduisent désormais bien au-delà des équipes informatiques, vers les services marketing, RH ou finance. Dans ces contextes, les cérémonies de Scrum demandent souvent un vrai effort d’adaptation.

Kanban visualise le flux de travail sans imposer de sprint

Kanban part d’une idée simple : on gère mal ce qu’on ne voit pas. Le tableau comporte au minimum trois colonnes, À faire, En cours, Terminé et chaque tâche y circule sous forme de carte. Pas de sprint, pas de rôle imposé, pas de cérémonie obligatoire. On démarre avec l’organisation existante et on l’améliore par petites touches.

Ce qui fait la différence dans la méthode, c’est la limite de travail en cours, le WIP (work in progress). Si la colonne « En cours » est plafonnée à 6 cartes, personne n’en démarre une septième tant qu’une autre n’est pas terminée. Ça paraît anodin, mais cela force à finir avant de commencer et fait apparaître les goulots d’étranglement en quelques jours.

Pour aller plus loin : Les clés d’une bonne gestion d’équipe.

Côté pilotage, la mesure centrale est le temps de cycle : le délai écoulé entre le moment où une carte entre en « En cours » et celui où elle passe en « Terminé ». Suivi sur plusieurs semaines, il permet de répondre à un client avec une fourchette réaliste plutôt qu’avec une promesse hasardeuse.

Les principes clés tiennent en quelques lignes :

• Visualiser le travail: chaque tâche a une carte, chaque carte a une colonne, tout le monde voit la même chose.
• Limiter le WIP: un plafond par colonne, discuté et ajusté en équipe.
• Gérer le flux continu: on tire une nouvelle tâche quand une place se libère, sans attendre une date de planification.
• Rendre les règles explicites: critères de passage d’une colonne à l’autre écrits noir sur blanc.
• Améliorer par petits pas: on change une règle, on observe le temps de cycle, on garde ou on revient en arrière.

Quelle méthode choisir entre Scrum, Kanban et Scrumban ?

Aucune des trois n’est meilleure dans l’absolu. Le bon choix dépend de la nature de votre flux de demandes, de la taille de l’équipe et du budget que vous pouvez consacrer à l’accompagnement. Le tableau ci-dessous résume mon évaluation, notes sur 5 à l’appui. Il s’agit de mon appréciation personnelle, pas d’une mesure scientifique.

En bref : Scrum gagne sur la rigueur et la prévisibilité par itération, Kanban sur la souplesse et le coût d’entrée, Scrumban joue les médiateurs. Si vos priorités changent chaque semaine, le tableau penche franchement du côté de Kanban.

Scrumban combine rythme Scrum et souplesse Kanban pour les équipes de maintenance

Scrumban est apparu parce que certaines équipes trouvaient Scrum trop rigide et Kanban trop lâche. On garde le tableau et les limites de WIP sur chaque colonne, on y ajoute un backlog priorisé et des réunions de planification espacées, par exemple toutes les deux ou trois semaines, ou déclenchées quand le backlog passe sous un seuil. Plus de sprint figé, mais un rythme de revue qui limite la dérive.

Le cas d’usage idéal : une équipe support ou maintenance où 30 à 40% des demandes sont imprévues. Dans un sprint Scrum classique, ces urgences font exploser le périmètre et personne ne tient son engagement. Avec Scrumban, on réserve une voie rapide sur le tableau pour les urgences, on plafonne le WIP et le reste continue d’avancer.

Dans la même rubrique : Les clés pour une gestion d’entreprise efficace.

Un exemple chiffré, à titre d’illustration plausible plutôt que de mesure certifiée : une équipe de 6 personnes qui traitait ses tickets avec un temps de cycle moyen de 9 jours peut raisonnablement viser 6 jours après deux mois de WIP limité à 2 tâches par personne et de réunion de replanification toutes les deux semaines. Le gain vient surtout de l’arrêt du multitâche, pas d’un outil miracle.

Le piège classique : cumuler les règles des deux méthodes sans rien retirer. Un Scrumban réussi supprime quelque chose, souvent la mêlée quotidienne longue ou l’estimation en points, au profit d’un point de synchronisation court devant le tableau.

Au démarrage, on est tenté de tout déployer d’un coup : cérémonies, outils, rôles. Les premiers sprints échouent rarement par manque de méthode et bien plus souvent par excès de cérémonial. un cadre complet abandonné au bout de trois.

Les questions fréquentes sur les méthodes agiles déjà tranchées

Faut-il une certification pour appliquer Scrum ?

Non, aucune certification n’est obligatoire. Le Guide Scrum est public et gratuit et rien n’empêche une équipe de l’appliquer seule. Une formation de type Scrum Master coûte autour de 500 à 1 000€ par personne : elle peut aider à poser un vocabulaire commun et à éviter les contresens, mais elle ne garantit pas la qualité de la pratique. Je recommande de former d’abord une ou deux personnes référentes, puis de voir.

Voir également : Améliorer la Communication Interne en Entreprise.

Kanban convient-il à une petite équipe de 3 personnes ?

Oui et c’est même l’un de ses terrains favoris. Avec 3 personnes, les cérémonies de Scrum pèsent proportionnellement lourd : une planification, une revue et une rétrospective par sprint peuvent engloutir une demi-journée par quinzaine. Un tableau Kanban avec un WIP limité à 2 tâches par personne et un point de dix minutes devant le tableau, suffit souvent à mettre de l’ordre dans le travail.

Peut-on passer de Scrum à Kanban en cours de projet ?

Oui, la transition est naturelle. Vous gardez le tableau et le backlog, vous supprimez les sprints à durée fixe, vous introduisez des limites de WIP et vous suivez le temps de cycle. Prévenez les parties prenantes : elles perdent les points de rendez-vous réguliers, il faut donc convenir d’une autre cadence de revue, par exemple toutes les deux semaines, pour garder la visibilité.

Mon avis : Kanban est sous-estimé pour la plupart des équipes

Pour une équipe de moins de 5 personnes dont les demandes varient d’une semaine à l’autre, je choisirais Kanban sans hésiter. Le coût d’entrée est quasi nul : un tableau, une règle de WIP, une heure d’atelier. À l’inverse, Scrum suppose une montée en compétence, souvent 500 à 1 000€ de certification par personne si l’on choisit cette voie, plus du temps de cérémonies chaque quinzaine. Pour une équipe de 4, c’est un investissement disproportionné par rapport au gain.

La cadence joue aussi en faveur de Kanban : un sprint de 2 semaines fige le périmètre pendant dix jours ouvrés, alors que le flux continu absorbe une demande urgente le mardi sans rien casser. Dès que le travail est imprévisible, cette souplesse vaut mieux que la belle discipline d’un sprint constamment perturbé.

Scrum reste pertinent pour un produit livré par itérations fixes, avec un Product Owner identifié et un périmètre découpable. Là, le rythme du sprint crée un engagement et une visibilité que Kanban ne donne pas spontanément. Mais cette situation est plus rare qu’on ne le pense : beaucoup d’équipes adoptent Scrum par mimétisme, puis passent leur temps à contourner le cadre.

Mon conseil : commencez par un tableau et un plafond de WIP. Si, après deux ou trois mois, le besoin de rythme se fait sentir, ajoutez de la cadence. Et si vous avez beaucoup d’imprévus, regardez du côté de Scrumban plutôt que de forcer un sprint qui ne tiendra pas.

Cet article fait partie de notre dossier complet : Gestion de projet efficace : 5 principes qui changent tout.