Vous entendrez souvent la question: « Quel est le meilleur? Kanban ou Scrum? »Ou des variations de cet éternel match à mort entre deux des méthodologies agiles les plus établies.

Les gens perdent de l’énergie à se battre pour savoir quelle méthodologie l’emporte sur une autre. Si vous êtes une organisation agile, vous devriez placer le principe au-dessus de la pratique.

Il est très logique de poser des questions comme «pourquoi pourrais-je vouloir utiliser Kanban sur Scrum?», Et il y a beaucoup de différences entre les deux. Mais fondamentalement, ce sont deux méthodologies agiles, et le principe derrière lequel vous voudrez peut-être utiliser les deux peut être aligné.

Vous pouvez même constater qu’ils peuvent bien fonctionner ensemble, dans le cadre d’une stratégie unifiée. Vous devez considérer quelle approche fonctionnera le mieux pour votre équipe.

Mon objectif avec cet article est d’aborder la question de «Kanban vs Scrum» en présentant clairement les deux approches en termes de quand, comment et pourquoi vous pourriez choisir d’utiliser l’une ou l’autre.

Voici une ventilation de la façon dont nous aborderons la comparaison de «Kanban vs Scrum»:

Qu’est-ce qui rend une équipe agile? Qu’est-ce que Kanban? Qu’est-ce que Scrum? Différences entre Kanban et Scrum Similitudes entre Kanban et Scrum À quoi sert Kanban? Quand utiliser KanbanKanban À quoi sert Scrum? Quand utiliser ScrumScrum processus

Commençons par une introduction de base sur ce que signifie être agile.

Agile 101: Qu’est-ce qui rend une équipe agile?

Vous ne pouvez pas simplement adopter une «méthodologie agile» et vous attendre à être agile. Votre équipe doit adopter une mentalité agile.

Cela va au-delà des simples outils («faire» agile); il s’agit d’adopter les principes qui permettront un succès agile («être» agile).

Kanban et Scrum sont deux façons de «faire» de l’agile.

Vous verrez parfois «agile» désigné au même niveau que Kanban ou Scrum, par exemple «Kanban vs Scrum vs Agile vs Waterfall». Cette présentation de l’agile comme une approche alternative comme Kanban ou Scrum peut être trompeuse.

En réalité, à toutes fins utiles, Kanban et Scrum s’inscrivent tous deux dans le cadre d’une approche agile. Méfiez-vous des faux agiles.

Alors, qu’est-ce qui rend une équipe agile? Pour commencer, adopter les principes agiles et faciliter un environnement de travail où les membres individuels de l’équipe sont encouragés à développer leurs propres valeurs agiles.

Il y aura toujours des processus et des procédures que vous pourrez remettre à votre équipe, tout en leur disant «allez faire agile», mais il y a des caractéristiques plus profondes qui favorisent le bon type d’habitudes qui mèneront à un succès agile.

Environnement d’équipe collaboratif

Le travail d’équipe est l’épine dorsale de toute approche agile. Votre équipe doit réussir à travailler ensemble dans un environnement collaboratif.

Les équipes non agiles délaissent généralement des tâches spécifiques aux membres individuels de l’équipe et travaillent, pour la plupart, de manière isolée. Peut-être se réunissent-ils une fois par semaine et discutent-ils des progrès. Ce n’est pas la façon de faire de l’agilité.

Les équipes agiles qui réussissent travaillent ensemble, écoutent les commentaires des autres et observent le travail effectué en tant qu’unité d’équipe entière. Au fur et à mesure que l’équipe collabore sur des fonctionnalités, une plus grande transparence du travail effectué ainsi qu’une main-d’œuvre combinée de résolution de problèmes signifie qu’il y aura moins de risques de déséquilibre entre le travail commencé et le travail terminé.

Prêter une attention particulière aux commentaires

La rétroaction est cruciale pour un succès agile. Obtenir des commentaires fait partie du travail avec les itérations – les équipes peuvent donc se concentrer sur le fonctionnement d’une petite fonctionnalité ou une mise à jour, puis obtenir de précieux commentaires à ce sujet.

Les clients, les testeurs et même d’autres développeurs devraient avoir la possibilité de fournir des commentaires à chaque itération. Les commentaires sont plus précieux lorsqu’ils sont pris à petites doses, il n’y a donc pas de risque qu’une grande quantité de travail soit effectuée, puis rendue inutile ou invalide par les commentaires.

Les petites étapes itératives où les fonctionnalités sont surveillées de près, puis peaufinées en fonction de commentaires en retour, sont l’un des comportements des équipes agiles performantes.

Être robuste et adaptatif

Vous ne pouvez pas toujours prédire les conditions d’un projet, agile ou non. Certains objets ne peuvent tout simplement pas être surmontés et certaines spécifications sont appelées à changer. Mais, le travail doit être fait. La différence entre les équipes agiles et non agiles est que les équipes agiles sont adaptatives face à n’importe quel défi.

Les équipes agiles sont exploratoires et les membres de l’équipe doivent être prêts à aller au-delà de leur domaine d’expertise. Cela ne signifie pas sortir de votre profondeur; aborder une tâche ou un problème dont vous n’avez absolument aucune idée n’est pas ce qu’est l’agilité. Les directeurs commerciaux ne devraient pas être obligés de jouer le rôle de chef de produit, par exemple.

Il s’agit davantage de passer à l’action par défaut et de ne pas avoir peur de s’écarter d’un processus défini. S’il est clair que vous pouvez ajouter de la valeur à un processus ou à un travail en cours, cela devrait être encouragé.

Agir comme un propriétaire

Cette valeur est parfois définie comme «étant intrépide», et elle représente l’un des éléments les plus importants du succès agile.

Il représente un environnement de travail où les individus sont sur un pied d’égalité, où chacun s’efforce d’atteindre une norme de propriété collective et individuelle du travail.

Cela signifie que les membres de l’équipe n’ont pas peur de se défier les uns les autres et qu’il n’y a pas de filtre sur la communication. Des valeurs comme «le dire tel qu’il est» sont défendues dans l’intérêt de la transparence et d’une communication claire.

Mais ce n’est pas que du macho paradant. Tout aussi importante est la capacité d’écouter et de reconnaître la contribution de tous les membres de l’équipe de manière égale. Savoir quand concéder; quand dire « je ne sais pas », et admettre que vous aviez tort sur quelque chose. Cela implique également de ne pas être trop fier ou embarrassé pour demander de l’aide.

Tout cela se conjugue pour aboutir à des équipes hautement auto-organisées et hautement performantes, avec une grande concentration sur l’amélioration continue collective.

Qu’est-ce que Kanban?

Le terme «kanban» (k en minuscules) est un type de système de fabrication allégée pour communiquer ce qui, quand et quelle quantité de quelque chose est nécessaire pour être produit; cela peut inclure des outils tels que des tableaux Kanban et des cartes de tâches. C’est une méthode pour améliorer l’efficacité de la fabrication.

Le nom vient de Taiichi Ohno, ingénieur industriel chez Toyota au Japon au début des années 40. Également orthographié «kamban» en japonais, il se traduit approximativement par «panneau d’affichage» et a été initialement choisi pour représenter la «capacité disponible (pour travailler)».

Ce système original de planification de la production a été développé par David J. Anderson principalement dans son livre de 2010 Kanban: Successful Evolutionary Change for Your Technology Business.

C’est dans le travail d’Anderson que le principe a été appliqué pour la première fois au développement de logiciels. Sa méthodologie se différencie souvent de la méthode Toyota d’origine en capitalisant le «K» dans «Kanban».

Kanban est défini comme un système d’amélioration continue. Anderson prend soin de préciser que Kanban seul n’est pas simplement une méthodologie de développement logiciel; c’est plutôt un système fondamental d’amélioration des processus à appliquer aux processus de développement de logiciels existants.

Kanban n’est pas une méthodologie de cycle de vie de développement logiciel ou une approche de gestion de projet. Cela nécessite qu’un processus soit déjà en place afin que Kanban puisse être appliqué pour modifier progressivement le processus sous-jacent. – David J. Anderson

Le type de Kanban que je développerai est la méthodologie d’Anderson, qui est généralement associée à l’utilisation de tableaux Kanban visuels et de fiches de tâches, et largement appliquée comme méthode de développement de logiciels et de gestion de projet allégée.

Ainsi, les principales caractéristiques du système Kanban d’Anderson sont définies comme suit:

Utilisation des workflows visuelsFinition de ce que vous avez commencé (et limitation des travaux en cours) Gestion du workflowFocalisation sur le processusPriorité de la rétroactionAmélioration continueLe tableau Kanban

Flux de travail Kanban

Kanban est basé sur le principe de l’amélioration continue, où les équipes sont censées être agiles et prêtes à changer les priorités en fonction des demandes et des exigences en constante évolution.

Une grande partie du flux de travail Kanban est le tableau Kanban – où le travail est organisé en colonnes représentant des étapes telles que «À faire», «En cours», «Prêt pour révision» et «Terminé».

Plus important encore, Kanban encourage les équipes à personnaliser cette vue Kanban pour l’adapter au fonctionnement de votre équipe.

Chez Process Street, l’équipe de contenu utilise une version modifiée d’un tableau Kanban dans Airtable pour suivre les tâches. Nos colonnes principales sont:

IdeaInboxUpcomingDoingReviewingDoneMove

Rôles Kanban

Les équipes Kanban sont plus horizontales; il y a moins de concentration sur la gestion, et tout le monde est encouragé à intensifier et à posséder le conseil d’administration.

Il est courant de voir des équipes enrôler des «entraîneurs agiles», mais il n’existe pas de «maître Kanban» semblable au Scrum Master.

En bref, il est de la responsabilité conjointe de toute l’équipe de s’assurer que les tâches au tableau sont exécutées.

Mesures clés

Les équipes Kanban devraient se concentrer sur:

Délai d’exécutionTemps de cycleCombien de travaux en cours à tout moment

La source

Le délai d’exécution est le temps qui s’écoule entre la création d’une carte de travail et sa fin.

Le temps de cycle est le temps qui s’écoule entre le début du travail et sa fin.

Le raccourcissement du temps de cycle peut être un bon indicateur d’une équipe Kanban réussie.

Une autre mesure à examiner est la quantité de travail en cours à un moment donné. Étant donné que Kanban consiste à réduire les travaux en cours, il peut être pertinent de définir des limites sur le nombre de tâches pouvant être actives à un moment donné dans un système Kanban.

Une fois ces limites atteintes, généralement dans une colonne donnée, il deviendra clair où le travail doit se concentrer, et l’équipe peut fourmiller ces éléments pour les déplacer vers la fin.

Soyez prêt pour le changement

Les workflows Kanban sont conçus pour évoluer et changer constamment. Les équipes doivent s’en rendre compte et embrasser la nature changeante des workflows Kanban.

Par exemple, de nouveaux éléments sont constamment ajoutés en fonction des besoins et du contexte du projet, et les tâches existantes peuvent être bloquées ou supprimées pour toutes sortes de raisons.

Kanban, en tant que méthodologie agile, consiste à être prêt à s’adapter aux exigences changeantes.

Qu’est-ce que Scrum?

Scrum a été inventé pour la première fois dans l’article de 1986 The New New Product Development Game par Hirotaka Takeuchi et Ikujiro Nonaka. Le nom vient du sport du rugby, destiné à accorder de l’importance au travail en équipe dans des environnements complexes et compétitifs.

À l’origine, comme le suggère le document, l’accent était mis sur le développement de produits en général, et pas seulement sur le développement de logiciels, car le terme est devenu largement associé.

Le document proposait que des niveaux de performance plus élevés soient atteints lorsque les équipes remplissaient les critères suivants:

Équipes plus petites et ciblées Niveaux élevés d’auto-organisation Orienté objectif, par opposition à orienté tâche Les équipes ont la capacité de concevoir leur propre approche afin d’atteindre des objectifs communs

Deux rôles clés dans la méthodologie Scrum incluent le Scrum Master et le Product Owner.

La source

Scrum Master

Le Scrum Master est responsable de s’assurer que l’équipe est «agile», ainsi que de suivre toutes les politiques et procédures qui ont été convenues.

Les principales responsabilités du Scrum Master incluent:

Résolution de problèmes et élimination des obstacles sur le chemin de la Scrum et «être agile» Superviser et maintenir un environnement de travail sain et productif Faciliter de bonnes relations entre l’équipe et le propriétaire du produit, ainsi qu’avec les parties prenantes externes

Propriétaire du produit

Le Product Owner est la personne responsable de s’assurer que le résultat souhaité d’un produit est conforme à la vision de l’équipe de développement et à toute autre exigence clé.

Leurs principales responsabilités comprennent:

S’assurer que tout le monde dans l’équipe comprend clairement la vision partagée de l’équipe de développement Prendre des décisions basées sur la tâche, la fonctionnalité et la priorité du produit, dans le meilleur intérêt de maintenir un produit de haute valeur, tout en minimisant la production Déterminer si le travail est satisfaisant ou non, en termes de Spécifications des caractéristiques du produit Assurez-vous que l’équipe et le flux de travail sont transparents

Différences entre Kanban et Scrum

Travail d’équipe et rôles

Scrum: Les équipes Scrum sont composées d’un Scrum Master, d’un Product Owner et de membres de l’équipe.

Kanban: Il n’y a pas de rôles définis. L’équipe est plus horizontale et la responsabilité est partagée à travers l’équipe. Personne ne devrait être interfonctionnel.

Flux de travail et visualisation

Scrum: Le travail est organisé en termes de tâches, utilisant souvent un tableau de travail (Scrum board). Les catégories peuvent inclure: Démarré, Pour examen et Terminé, et refléteront les différentes étapes du flux de travail spécifique d’une équipe.

Kanban: Focus similaire sur différents états de workflow (Doing, Waiting, Done) avec un accent supplémentaire sur la quantité de travaux en cours (WIP), qui représente un indicateur de performance clé pour les équipes Kanban.

Cadence et planification

Scrum: Il y a un calendrier clair, avec un accent sur les étapes clés ou «points d’histoire» pour la livraison des fonctionnalités importantes. L’accent est mis sur le progrès itératif, où chaque itération est clairement commercialisée par un build fonctionnel.

Kanban: Pas d’horaire fixe ou nombre d’itérations défini. Cependant, les équipes Kanban fonctionnent de manière itérative; l’accent est tout simplement moins mis sur un calendrier strict pour l’achèvement des travaux.

Similitudes entre Kanban et Scrum

Voici quelques similitudes immédiates qui méritent d’être reconnues entre Kanban et Scrum:

Ils sont tous les deux capables de décomposer des tâches et des processus volumineux et complexes en tâches plus petites et plus faciles à gérer pour être exécutés plus efficacement. très transparent et tenir tous les membres de l’équipe au courant des travaux en cours, ainsi que des travaux à venir.

Kanban: À quoi ça sert?

Kanban fonctionne très bien si votre équipe sait qu’il y aura un grand nombre de tâches entrantes (tickets, demandes ou tout type de tâche modulaire) qui varient en priorité et en taille.

Contrairement à Scrum, qui dépend d’une portée de projet plus clairement définie (mais toujours flexible), Kanban est meilleur si la portée sera moins claire, et il est nécessaire de suivre le flux.

En un mot, Kanban est idéal pour trouver un équilibre continu entre le travail et la capacité des travailleurs de l’équipe, si ce n’est pas quelque chose qui est immédiatement clair.

Quand utiliser Kanban

Kanban est une méthode d’amélioration continue. Cela implique qu’il existe des processus existants sur lesquels s’appuyer. Si vous faites tout type de développement au sein de votre équipe et que vous souhaitez trouver un moyen de resserrer le vaisseau, Kanban est peut-être pour vous.

N’oubliez pas, Kanban est idéal pour garder toute votre équipe sur la même page. Peut-être plus que Scrum, cela dépend d’une équipe plus auto-organisée, car il n’y a pas de «Kanban Manager» clair.

Le facteur le plus important de Kanban est peut-être le travail en cours (WIP). Pour réussir, la méthode Kanban requiert que des limites strictes soient placées sur la quantité de travaux en cours à un moment donné, dans une colonne donnée, et qu’aucun nouveau travail ne puisse entrer dans une colonne qui a atteint cette limite.

Cela est utile si vous rencontrez des goulots d’étranglement et que vous souhaitez essayer de comprendre comment améliorer cette situation, car cela encourage les individus à envahir les zones de débordement des travaux en cours.

Le but ultime de Kanban est d’améliorer vos processus existants. Les équipes utiliseront le tableau Kanban pour guider la discussion et les changements de processus, se réunissant généralement pour des réunions régulières pour discuter des développements récents et analyser les processus existants.

Scrum: À quoi ça sert?

Scrum est une approche de gestion des processus de grande envergure; toute entreprise peut l’adopter et en bénéficier. Scrum est bon pour faciliter la flexibilité et permettre aux équipes de répondre à un changement soudain et inattendu.

Il est également bien adapté pour améliorer la transparence au sein des équipes, ce qui contribue à éviter certains des écueils qui se posent dans les environnements de travail où l’évolution des exigences est la norme.

Quand utiliser Scrum

Chaque fois que des exigences évoluent rapidement. Pour les équipes hautement interfonctionnelles et auto-organisées, Scrum fonctionne également très bien.

Scrum dépend d’une portée plus bien définie que Kanban, au moins dans la définition des jalons spécifiques du projet. Cependant, en ce qui concerne les spécifications du projet, Scrum ne nécessite qu’une définition de très bas niveau des exigences pour fonctionner correctement; les équipes qui s’attendent à un degré élevé de changement des exigences de processus, de produit et de haut niveau devraient envisager Scrum.

Processus Scrum

Il existe un certain nombre de processus pertinents pour le framework Scrum. Ils sont tous conçus pour encourager les membres de l’équipe à évaluer ce qui fonctionne et ce qui ne fonctionne pas – réunissant toute l’équipe, ainsi que le propriétaire du produit et Scrum Master, et ayant une conversation ouverte sur l’état du projet.

Vous pouvez trouver quelques modèles de processus Scrum ci-dessous, tous utilisant des modèles Process Street personnalisés pour rationaliser les choses pour vous.

Processus de réunion quotidienne Scrum / standup

Les mêlées bénéficient souvent d’une réunion de standup quotidienne. Ils se produisent généralement à la même heure chaque jour, et l’équipe examinera généralement le travail effectué au cours des jours précédents, puis planifie les 24 heures suivantes.

Processus de planification de sprint

Les sprints sont un moyen de diviser le temps, généralement de 7, 14 ou 30 jours, pendant lequel le travail doit être terminé.

Dans ce modèle de planification de sprint, toute l’équipe doit être impliquée pour aider à définir les buts et objectifs du prochain sprint.

À la fin de chaque sprint, idéalement, une version logicielle devrait être produite.

Processus rétrospectif de sprint

En contrepartie de la planification du sprint, une rétrospective du sprint a lieu à la fin d’un sprint.

Lors d’un sprint rétro, l’équipe réfléchit à ce qui s’est passé pendant le sprint; ce qui a mal tourné, ce qui a fonctionné et quels changements doivent être apportés.

L’objectif principal d’une rétrospective de sprint est l’amélioration continue.

Processus Kanban

Pour Kanban, le processus est conçu pour faciliter l’amélioration continue. Il existe un certain ensemble de principes que la méthode Kanban suit, conçus pour faciliter l’amélioration continue.

Les quatre principes du Kanban sont les suivants:

Visualisez les flux de travail Limitez le travail en cours Concentrez-vous sur le flux (en réduisant les tâches manuelles fastidieuses et le temps perdu entre les travaux importants) Amélioration continue

En prenant ces quatre principes et en reconnaissant que Kanban est au cœur d’un système d’amélioration continue, vous pouvez utiliser un modèle comme ce processus pour optimiser un processus pour augmenter votre infrastructure Kanban.

Votre équipe est-elle vraiment agile? Comment faites-vous? Kanban, Scrum ou autre chose? Faites le nous savoir dans les commentaires! Nous aimons entendre chacun de vous.