Scrum VS Kanban | La bonne approche pour le bon problème.

En 1986, les auteurs Hirotaka Takeuchi et Ikujiro Nonaka ont publié dans la célèbre Harvard Business Review “The New New Product Development Game”. L’article expose leurs recherches sur le processus de fabrication original de Canon, Honda et Fuji-Xerox. Actives dans trois secteurs différents, ces entreprises avaient une chose en commun : elles étaient meilleures et plus rapides que leurs concurrents pour commercialiser des innovations réussies. Les raisons de leurs succès ont depuis été comprises et compactées dans ce qui est aujourd’hui le framework Agile le plus célèbre, le Scrum. 

Contexte

Grâce à sa simplicité visuelle, Scrum est adopté dans le monde entier par la plupart des équipes de développement qui cherchent à livrer de meilleurs produits en respectant des contraintes. Il s’agit d’une approche structurée conçue autour de cérémonies permettant aux équipes d’inspecter et d’adapter rapidement afin de livrer de petits lots de logiciels fonctionnels. Néanmoins, sous son apparente simplicité se cache un cadre difficile à mettre en œuvre et souvent totalement incompris. On découvre dans cet article l’une des raisons pour lesquelles scrum ne tient pas toujours ses promesses. En effet, si tu tentes d’utiliser scrum pour résoudre des problèmes qu’il n’est pas censé résoudre, dans des contextes pour lesquels il n’a pas été conçu, tu seras conduit inévitablement à la déception. 

Quand Scrum n’est-il pas utile ?   

Voici quelques situations dans lesquelles Scrum pourrait ne peut pas être la bonne méthode à appliquer : 

✖ Quand il y a un problème compliqué, et non complexe. 

Il est crucial de comprendre cette différence si l’on souhaite appliquer la bonne approche aux bons problèmes. Avec des directives, des protocoles, des règles, des listes de contrôle et des processus, tu peux prévoir la résolution d’un problème compliqué. La construction d’une maison est un problème compliqué, par exemple. Si tu souhaites construire une maison, tu sais d’avance qu’il faudra dessiner des plans. De plus, tu peux évaluer la nature et la quantité de matériaux nécessaires à sa construction et planifier à l’avance les compétences qui tu auras besoin pour assembler toutes les pièces. Enfin, tu es en mesure de savoir combien coûtera la construction de cette maison avec une grande précision. C’est peut-être difficile, mais ce n’est pas complexe.

Un problème complexe, en revanche, repose sur le fait que sa résolution va en changer la nature même. Changer une industrie avec un produit de pointe est complexe car tu ne peux pas le planifier à l’avance. Il n’y a pas une seule façon d’y parvenir et cela repose beaucoup sur les essais et les erreurs. Avec ses boucles de feedback courtes permettant des itérations rapides, le cadre de la méthode Scrum convient aux problèmes complexes. Cependant, il ne peut pas être utile pour les problèmes compliqués. 

   

✖ Lorsque la maintenance constitue l’essentiel des tâches d’une équipe. 

Il peut arriver pour des sociétés de services commercialisant des CRM, par exemple, que l’essentiel de leurs demandes entrantes soient purement des tâches de configuration ou de correction de bugs. Scrum est basé sur la livraison d’un incrément fonctionnel à la fin de chaque sprint. Dès lors, Scrum n’est pas utile pour s’attaquer à des tâches qui ne peuvent pas être regroupées dans un logiciel fonctionnel de qualité.

   

✖ Lorsque l’équipe de développement est impliquée dans plusieurs projets simultanément. 

En raison de la rareté des ressources ou simplement de la nature du travail, les développeurs peuvent s’impliquer sur plusieurs projets. Jongler d’un projet à l’autre et s’engager sur plusieurs objectifs de sprint au sein d’un même sprint n’offre pas la concentration ou le temps nécessaire aux équipes pour bénéficier des avantages du cadre Agile. Néanmoins, si l’on devait le mettre en œuvre, il est évident que le nombre des travaux en cours augmente ainsi que la durée de chaque projet.

   

✖ Lorsque l’incertitude prévaut dans le contexte. Typiquement, lorsque les équipes ont peu de contrôle sur le périmètre. 

Pour réaliser un logiciel de valeur et fonctionnel dans la durée du sprint, il faut connaître le contenu et la portée du sprint et le préparer à l’avance. Les équipes doivent avoir une idée de la direction qu’elles prennent. On peut concevoir ou prototyper l’idée, mais il faut qu’elle existe. Dans des contextes de grandes incertitudes où l’objectif du sprint pourrait être régulièrement perturbé par des événements imprévus, la structure donnée du cadre pourrait être trop restrictive et non adaptée.

   

✖ Lorsque les scrum masters ou les product owners manquent de participation active ou de fiabilité. 

L’incapacité à respecter les engagements à plusieurs reprises ou l’incapacité à planifier à l’avance pour une certaine période de temps sont des situations qui peuvent diminuer les avantages du Scrum. Les raisons de ces situations peuvent provenir du manque de soutien que l’équipe de développement reçu de la part du Scrum master ou du Product Owner. Les équipes qui ne sont pas bien protégées ou guidées par une vision claire n’ont pas la concentration ou la capacité de comprendre correctement les exigences. Le cadre Scrum repose sur l’implication totale et fiable de tous les rôles pour fonctionner. Un maillon faible peut saper les avantages de Scrum et causer de nombreuses frustrations. Il est peut-être préférable d’envisager des approches lorsque tu te trouves dans un contexte où tu ne peux pas dérouler correctement la méthode scrum.

Quand il y a peu de contrôle et de certitude sur l’objectif du sprint, la disponibilité de l’équipe pour le projet et le contexte lui-même, une approche plus flexible comme Kanban pourrait être utile pour fournir un minimum de compréhension et de visuel sur le travail à accomplir. 

Kanban est une approche du développement qui met l’accent sur la visualisation pour améliorer les flux en identifiant et en éliminant rapidement les goulots d’étranglement. La méthode a été mise en œuvre pour la première fois par Toyota dans les années 1940 pour permettre un plus grand niveau de personnalisation de ses voitures et identifier rapidement les pénuries de ressources. Elle est aujourd’hui largement adoptée par les équipes informatiques pour suivre le développement. 

En quoi Kanban peut-il être utile ?   

Alors que le Scrum est basé sur des sprints limités dans le temps, Kanban met l’accent sur le flux continu et la limitation du travail en cours. Contrairement au Scrum, Kanban se concentre sur la capacité. Tu recalibres les contraintes imposées au flux en fonction de la taille de l’équipe. Ainsi, tu n’as pas besoin d’estimer les tâches ou de les diviser en petites tâches autonomes. En fait, tu peux les ajouter à tout moment au tableau et les hiérarchiser librement. Kanban offre une plus grande souplesse.

Pour les sociétés de services informatiques qui traitent avec de nombreux clients, une approche comme Kanban devient utile. La priorité passe de la décomposition des tâches et de la mise en place de sprints de durée fixe au déplacement des tâches d’un bout à l’autre du tableau aussi rapidement que possible, quelle que soit la taille de chaque tâche. De même, lorsqu’il y a des chances que l’objectif du sprint soit régulièrement perturbé (dans un contexte où scrum n’est pas approprié), la cadence continue de Kanban peut devenir une excellente solution de repli pour assurer un minimum de structure aux équipes. 

Comment suivre la progression et améliorer le flux sans les pratiques de scrum ?   

Plusieurs mesures simples peuvent aider ton équipe à comprendre comment se déroule le flux de travail et comment l’améliorer.

Le temps de cycle (cycle time en anglais) aide ton équipe à comprendre combien de temps les tâches restent sur le tableau entre le moment où vous les avez prises en charge et celui où vous y avez mis fin. Cette métrique diffère de la mesure du délai d’exécution (lead time en anglais). Elle mesure la durée moyenne pendant laquelle les tâches restent sur le tableau à partir du moment où vous les avez créées et ajoutées au tableau jusqu’au moment où vous y avez mis fin. 

Les histogrammes de temps de cycle sont des outils utiles pour prédire les futurs délais de livraison en fonction de différents niveaux de confiance. Cet outil et la métrique associée remplacent tous ensemble la nécessité de décomposer et d’estimer le temps des tâches. Tu peux donc allouer ce temps au développement ou à d’autres activités à valeur ajoutée. 

   

   

Comme mentionné précédemment, un point important de Kanban est la limitation du travail en cours. La limitation du travail en cours améliore l’efficacité puisque tu termines ce que tu as commencé avant de passer à autre chose. 

Dans l’ensemble, les métriques et les capacités d’optimisation des flux mises en avant par la visualisation inhérente à la méthode Kanban peuvent être utiles aux équipes pour lesquelles la méthode Scrum n’est pas la bonne approche de développement. 

Néanmoins, choisir ce qu’il est bon de prendre dans le cadre du scrum n’est pas une mauvaise idée, vous n’avez pas besoin de tout abandonner complètement. Les réunions quotidiennes, les sessions de refinement ou les rétrospectives d’équipe peuvent être utiles dans n’importe quel contexte en dehors du cadre du Scrum, en fonction des besoins réels de l’équipe. 

Tu souhaites approfondir le sujet de la propriété du produit ? 

   

👉 Obtiens d’autres conseils perspicaces sur notre blog.   

👉 Es-tu un Product Owner à la recherche d’un nouveau défi ? Rejoins notre équipe d’experts 

👉 Ou contacte-nous pour obtenir du soutien sur tes projets : corp_hello@worldofdigits.com 

By Lucas Jako