Dire 'nous faisons de l'Agile' est la phrase que j'entends le plus souvent chez des clients qui font en réalité des réunions quotidiennes sans aucun changement réel dans la façon de travailler. Agile est une philosophie, pas une méthode. Scrum et Kanban sont des méthodes concrètes qui implémentent cette philosophie de façons très différentes. Les confondre coûte du temps, de l'argent et de la crédibilité à l'équipe projet.
1. Agile : le cadre mental, pas le processus. Agile est l'ensemble des valeurs et principes du Manifeste Agile (2001) : priorité aux personnes sur les processus, au logiciel fonctionnel sur la documentation exhaustive, à la collaboration client sur la négociation contractuelle, à la réponse au changement sur le suivi d'un plan rigide. Il ne dit pas comment organiser les sprints, qui fait quoi, ou comment mesurer l'avancement. C'est pourquoi faire de l'Agile sans choisir une méthode concrète est presque toujours du théâtre organisationnel.
2. Scrum : quand le travail est prévisible et itératif. Scrum fonctionne quand on peut planifier des blocs de travail (sprints de 1-4 semaines) avec un objectif clair et un backlog priorisable. C'est le bon cadre pour le développement produit, les équipes stables avec des rôles définis (Product Owner, Scrum Master, Development Team) et les contextes où le client peut donner du feedback à cadence régulière. Scrum exige de la discipline sur les rôles : si le Product Owner n'a pas d'autorité décisionnelle réelle, ou si le Scrum Master fait aussi office de PM traditionnel, le cadre s'effondre vite.
3. Kanban : quand le flux compte plus que le plan. Kanban fonctionne quand le travail arrive en continu et de manière imprévisible : support client, opérations, équipes de maintenance, ou contextes multi-projets avec priorités changeantes. Pas de sprints : un flux continu avec des limites de work-in-progress (WIP) par colonne. La métrique clé n'est pas la vélocité mais le lead time (temps qu'une tâche met de l'entrée à la sortie).
4. Comment décider en 3 questions. Le travail arrive-t-il en vagues planifiables ou en continu et imprévisible ? Vagues signifie Scrum. Continu signifie Kanban. L'équipe peut-elle s'isoler 1-4 semaines sur un objectif partagé ? Oui signifie Scrum. Non signifie Kanban. Faut-il un changement culturel profond des rôles, ou seulement de la visibilité et du contrôle du flux ? Changement profond signifie Scrum. Visibilité signifie Kanban.
5. Le modèle hybride qui fonctionne en pratique. Beaucoup d'équipes matures utilisent Scrumban : structure en sprints de Scrum pour la planification, tableau Kanban avec limites WIP pour la gestion quotidienne du flux. C'est l'approche que je recommande le plus souvent aux organisations avec équipes mixtes (dev + support) car elle ne force pas toute l'entreprise dans un cadre rigide unique.
FAQ. Peut-on passer de Scrum à Kanban en cours de projet ? Oui, et c'est plus fréquent qu'on ne le pense : le signal est quand les sprints sont constamment interrompus par des demandes externes urgentes. Faut-il se certifier (PSM, CSM) pour appliquer ces cadres ? La certification aide au langage commun et à la crédibilité vis-à-vis des stakeholders, mais ne remplace pas l'expérience pratique d'adaptation au contexte spécifique.
Si votre équipe dit faire de l'Agile mais que quelque chose vous semble ne pas coller, parlons-en : en un appel de 30 minutes je vous aide à comprendre quel cadre correspond vraiment à votre contexte — sans vous vendre une méthodologie préemballée.
