.jpg)
C’est l’une des questions les plus fréquentes que j’entends au sein des équipes Produit que j’accompagne, de près ou de loin. Avant tout, je tiens à préciser que ce qui suit est basé sur mon expérience personnelle et n’a pas vocation à être un dogme. Je vois déjà venir certains puristes !
Un sujet controversé
Pour être honnête, ce sujet m’a souvent agacé. Premièrement, dans la majorité des cas, lorsque les équipes envisagent de passer au Kanban, cela se traduit principalement par l’abandon des rituels Scrum tout en conservant un simple board « Kanban ». Autrement dit, ce n’est pas vraiment « passer en Kanban ». On bascule simplement vers un cadre allégé, centré sur le suivi des tâches.
Le cadre Kanban : plus exigeant qu’il n’y paraît
Pourquoi pas, me direz-vous. Mais pour quelqu’un d’aussi pointilleux que moi, qui est engagé dans une démarche d’amélioration continue et qui vise l’excellence, c’est une pilule difficile à avaler. En réalité, le Kanban est un cadre rigoureux, bien plus exigeant que le Scrum sur plusieurs aspects. Certes, le Kanban est une approche formidable, mais elle est souvent plus adaptée à la gestion de flux qu’au développement de Produits.
L’adéquation du Kanban au développement Produit
Cela dit, il est possible que le Kanban fonctionne bien pour certaines équipes, mais je trouve personnellement que ce cadre est moins approprié pour la plupart des contextes de développement produit. Cette observation m’amène à poser une question essentielle : pourquoi cette envie de changement ?
Le symptôme d’un problème plus profond
C’est là que les choses deviennent intéressantes. Ce débat est souvent le symptôme d’un problème plus profond. Généralement, ce que j’ai pu observer, c’est que l’équipe fonctionne davantage dans une logique de gestion de projet que de Product Management. Elle se concentre sur la livraison d’une roadmap d’initiatives, en enchaînant les cycles, parfois presque en mode « mini-cycle en V ». Dans des cas un peu extrêmes, on peut se retrouver avec un backlog rempli de petits sujets, que chaque développeur traite de manière quasi mécanique, sans fin.
Comparaison entre Kanban et Scrum : 2 cadres aux objectifs distincts
Pour mieux comprendre cette tentation de passer de Scrum à Kanban, il est utile de comparer les deux cadres en profondeur. Scrum repose sur des cycles courts et itératifs appelés sprints, avec des rôles clairement définis et des rituels structurés qui encadrent chaque étape du développement. Ce cadre rigide offre une grande prévisibilité grâce à une planification rigoureuse et des points de contrôle réguliers, permettant ainsi aux équipes de mesurer et d’ajuster leur progression à intervalles réguliers.
Kanban, en revanche, se concentre sur la gestion du flux de travail en continu. Ce cadre est plus flexible, n’impose pas de cycles fixes et permet une adaptation constante en fonction des besoins immédiats de l’équipe. Là où Scrum structure la production avec des sprints réguliers, Kanban permet une plus grande réactivité, particulièrement adaptée aux équipes qui doivent gérer un flux constant de tâches ou de demandes imprévues.
Cependant, cette flexibilité apparente du Kanban ne doit pas être sous-estimée. Pour éviter que le flux de travail ne devienne chaotique, Kanban exige une discipline rigoureuse, notamment en ce qui concerne la limitation du travail en cours (WIP - Work In Progress) et l’optimisation des processus pour prévenir les goulets d’étranglement. En somme, le choix entre Kanban et Scrum dépend du contexte et des besoins spécifiques de l’équipe, chaque cadre ayant ses propres avantages et inconvénients.
Les limites du Scrum dans certains contextes
À la lumière de cette comparaison, il est vrai que dans certains contextes, le Scrum peut devenir difficile à mettre en œuvre. Lorsque les équipes se retrouvent coincées dans une logique de projet au lieu de se concentrer sur la valeur produit, Scrum peut apparaître comme un cadre trop contraignant, voire inadapté. Ce changement de paradigme, qui demande de passer d’une gestion par tâches à une gestion par valeur, peut parfois s’avérer trop radical. On est alors presque dans une approche « bottom-up » en termes de changement culturel, où l'adoption du cadre Scrum devient non seulement difficile mais aussi contre-productive.
Scrum : Un cadre centré sur la valeur Produit
Scrum est conçu pour placer le produit et ses utilisateurs au centre de l’attention. Dans ce cadre, la création de valeur et son impact deviennent les priorités absolues. Cela signifie que l’on se concentre non pas sur la simple réalisation de fonctionnalités, mais sur l’atteinte d’objectifs significatifs qui apportent une véritable valeur ajoutée. Toutefois, dans une culture de projet axée sur la livraison rapide et séquentielle de tâches, Scrum peut perdre de son sens et se transformer en un obstacle plutôt qu’en un atout.
Vers un cadre plus flexible
Alors, soyons pragmatiques, et ne forçons pas les choses. Il est peut-être plus judicieux de trouver un juste milieu, un cadre qui ne s’articule plus autour de cycles de deux semaines, mais de six par exemple. Cela peut paraître radical, mais c’est souvent ce qui se passe dans la réalité : des rétrospectives occasionnelles, des démonstrations sporadiques, et un suivi irrégulier. Autant être transparent dès le départ, pour pouvoir ensuite adapter et améliorer le cadre en fonction des retours.
Une transformation globale nécessaire
Et comme je le sous-entendais précédemment, le Scrum porte intrinsèquement un changement de paradigme qui tire ses racines dans le pilotage opéré par la direction de l’entreprise. Appliquer du Scrum, voire de l’agilité, sans autonomie pour les équipes, mais avec comme ambition de délivrer rapidement des fonctionnalités pour suivre la concurrence, ne permet pas de s’inscrire pleinement dans cette philosophie.
Il est nécessaire d’opérer une transformation globale, où chaque partie de l’organisation avance dans cette direction : une organisation Produit avec au centre les utilisateurs, et non simplement des fonctionnalités.