Article original : Kanban VS Scrum - How to be Agile

Par Niall Maher

Scrum et Kanban sont les deux techniques de gestion de projet les plus populaires aujourd'hui dans le monde des affaires. En tant que développeur, je pense qu'il est important de comprendre ces processus, car vous serez probablement très impliqué dans ceux-ci si vous faites partie d'une équipe. En comprenant ces méthodes, nous pouvons rester concentrés sur la résolution de problèmes et ne pas être trop effrayés par certains des termes à la mode.

Je suis développeur de métier, mais mon dernier rôle salarié était dans la gestion de produit. J'ai essayé ces deux méthodologies pour améliorer la productivité et l'efficacité dans la livraison de produits et services de la meilleure manière possible. Elles aident également les organisations à s'adapter rapidement aux changements de demande pour leurs produits/services.

Qu'est-ce que Scrum ?

Scrum est une méthodologie de gestion de projet conçue pour des équipes pluridisciplinaires de moins de 10 membres travaillant sur des projets complexes. Son objectif principal est d'utiliser les diverses compétences des membres de l'équipe pour créer une solution/produit pour le client/utilisateur final.

Le mot Scrum est dérivé du jeu de rugby où les joueurs des deux équipes s'interpénètrent et tentent de prendre possession du ballon en tant qu'unité fonctionnelle.

Scrum repose sur trois piliers majeurs : la transparence, l'inspection et l'adaptation. Cette méthodologie est basée sur le principe que le client/utilisateur final pourrait changer d'avis sur ce qu'il veut ou qu'il pourrait y avoir des changements qu'une approche planifiée ne peut pas gérer.

Le projet est généralement démarré avec les informations disponibles. Ensuite, des changements ou des ajustements peuvent être effectués chaque fois que nécessaire tout en suivant le processus de développement.

Le projet est divisé en actions distinctes appelées sprints qui doivent être complétées dans un délai fixe ou des itérations. La durée moyenne des sprints est généralement de deux semaines à un mois.

Les progrès sont suivis grâce à des scrums quotidiens, qui sont des réunions debout fixes de 15 minutes. Cela encourage une interaction et une communication étroites entre les membres de l'équipe plutôt que l'approche séquentielle traditionnelle.

Qu'est-ce que Kanban ?

Kanban est un cadre de gestion de projet visuel qui a été créé à partir du processus de développement logiciel lean et utilisé dans la gestion de projet Agile. Le mot Kanban est un mot japonais signifiant panneau d'affichage et a été dérivé des méthodes de fabrication lean pionnières du fabricant de véhicules Toyota au Japon.

Il visualise le processus et les progrès du travail grâce aux tableaux Kanban. Il est utilisé pour des produits/solutions qui nécessitent une livraison continue et vise à équilibrer la demande avec la capacité disponible (système de tirage) plutôt que de pousser les produits sur le marché (système de poussée).

L'objectif de l'utilisation de Kanban est de supprimer les goulots d'étranglement pendant le processus de production afin que le projet puisse se dérouler en douceur et rester dans le budget. Il est généralement utilisé en combinaison avec d'autres méthodologies agiles comme Scrum.

Histoire

L'évolution de Scrum

La méthodologie Scrum a été mentionnée pour la première fois dans un article de la Harvard Business Review de 1986 intitulé 'The New New Product Development Game' par Hirotaka Takeuchi et Ikujiro Nonaka.

Les auteurs ont décrit ce processus qu'ils ont initialement appelé l'approche holistique ou rugby comme un nouveau processus de développement qui augmenterait la vitesse et la flexibilité avec lesquelles les produits commerciaux étaient mis sur le marché. Ils le voyaient comme "bon pour apporter une innovation en continu, de manière incrémentale et spirale".

En 1993, Jeff Sutherland a utilisé pour la première fois cette méthodologie avec John Scumniotales et Jeff Mckenna chez Easel Corporation. Deux ans plus tard, Sutherland et Ken Schwaber ont co-présenté un article décrivant la méthodologie Scrum lors de la conférence Object-Oriented Programming, Systems, Languages and Applications '95 (OOPSLA) à Austin, au Texas.

Schwaber a également écrit le premier texte sur Scrum en 2001 avec Mike Beedle intitulé Agile Software Development with Scrum. La même année a vu les deux auteurs, avec Sutherland et 14 autres experts de Scrum, rédiger le Manifeste Agile dans l'Utah, qui spécifiait les principes, les caractéristiques et les valeurs de cette méthodologie.

La Scrum Alliance a été créée en 2002 par Schwaber pour fournir un organe de gouvernance pour la méthodologie Scrum ainsi qu'une certification formelle par le programme CSM (Certified ScrumMaster). Schwaber a ensuite quitté l'alliance en 2009 pour créer Scrum.org qui est responsable de la série d'accréditation Professional Scrum.

Depuis 2010, un document appelé Scrum Guide fournit des directives pour la méthodologie Scrum et a été révisé régulièrement, la dernière version étant publiée en novembre 2017.

Évolution de Kanban

Kanban a commencé comme une méthodologie de fabrication promue sur les chaînes de production de Toyota par Taiichi Ohno, connu comme le père du Toyota Production System.

Ohno cherchait un moyen d'augmenter la productivité et de réduire les inefficacités pendant le processus de fabrication des voitures tout en évitant de produire des véhicules qui ne pourraient pas être vendus et qui feraient perdre de l'argent à l'entreprise.

Dans une quête pour trouver une solution, Ohno tomberait dessus lors d'une visite dans un supermarché de Tokyo en 1943. Là, il remarqua que les produits en vente n'étaient réapprovisionnés que lorsqu'ils étaient presque épuisés selon la demande des clients, plutôt que par des approvisionnements réguliers du fournisseur. Cela garantissait que le supermarché avait très peu de stocks excédentaires et fonctionnait efficacement.

Ohno apporterait cette technique à Toyota, bien qu'il faudrait 10 ans pour qu'elle soit pleinement opérationnelle. Une grande partie de ce processus serait le système de communication qui utilisait des cartes visuelles appelées Kanban qui illustraient aux travailleurs à chaque étape du processus de fabrication des véhicules ce qui devait être fait et les matériaux nécessaires, en termes clairs.

Il ajustait également le nombre de véhicules fabriqués à la demande du public au lieu d'utiliser la pleine capacité productive. Ce processus était également connu sous le nom de fabrication lean ou de production "Just in Time".

Cela a aidé à standardiser le processus de production, à éliminer les inefficacités et à rendre Toyota agile et flexible en évitant l'accumulation de produits excédentaires qui ne pouvaient pas être vendus. C'était un problème que les fabricants automobiles américains rencontraient également.

Cela a transformé Toyota en un géant automobile mondial. Après son adoption dans l'industrie automobile, la philosophie Kanban s'est répandue dans le monde entier et dans différentes industries.

Kanban deviendrait populaire dans les industries de services/connaissances grâce au travail de David J. Anderson. Il était un admirateur du processus de fabrication lean qui a appliqué un système de développement de tirage influencé par la philosophie Kanban d'Ohno tout en travaillant avec un groupe Microsoft XIT Sustaining Engineering en 2004.

Les années suivantes verraient Anderson et certains de ses collègues façonner les caractéristiques et les principes de la méthodologie Kanban. La méthodologie Kanban s'est répandue grâce à des conférences et des discours de gestion, et davantage d'entreprises ont commencé à l'adopter.

Anderson a compilé ses expériences avec Kanban dans un livre publié en 2010 'Successful Evolutionary Change for your Technology Business' qui est considéré comme la définition la plus complète de la méthodologie Kanban pour les travailleurs du savoir.

Les principes/valeurs de Scrum

Les tableaux Scrum sont aussi des "tableaux Kanban", c'est déroutant, n'est-ce pas ?

La méthodologie de gestion de projet Scrum est devenue une partie des approches de développement Agile qui se sont répandues à la fin des années 1990 et au début des années 2000. Celles-ci étaient un effort pour trouver une solution au taux d'échec élevé dans le développement logiciel.

L'approche de développement en cascade utilisée principalement avant ce point dans l'industrie du logiciel était rigide et inflexible - le développement de produit devait suivre des procédures et une documentation rigides.

Scrum a permis aux développeurs de logiciels la flexibilité et la liberté de répondre aux changements dans le développement. Il appelait également à l'implication du client dans le processus de développement plutôt que d'être un simple spectateur.

Cette méthodologie s'est ensuite répandue dans d'autres industries. Scrum est devenu la méthodologie de gestion de projet agile la plus utilisée - des recherches indiquent qu'elle est utilisée dans 66 % de tous les projets incorporant des méthodes de développement agile.

Scrum est facile à comprendre et à suivre car il évite les instructions et procédures rigides. Avec Scrum, les organisations peuvent faire ce qui est nécessaire pour mener à bien le projet, en s'adaptant aux circonstances qui pourraient soudainement survenir. Cette flexibilité est l'une des raisons pour lesquelles Eric Naiburg, vice-président marketing chez scrum.org, appelle Scrum l'opposé d'une liste de tâches.

La division des projets en sprints le rend adapté aux entreprises complexes tandis que l'implication du client dans le processus de développement améliore la transparence.

Le Manifeste Agile

Le Manifeste Agile visait à répondre aux frustrations des développeurs de projets logiciels en 2001 et a abouti à quatre principes. Aujourd'hui, ces principes sont le fondement de la philosophie de gestion de projet Scrum et se sont répandus au-delà de l'industrie du logiciel. Ils stipulent que les projets doivent valoriser :

Les individus et les interactions plutôt que les processus et les outils.
Les produits/solutions fonctionnels plutôt que la documentation exhaustive.
La collaboration avec le client plutôt que la négociation contractuelle.
La réponse au changement plutôt que le suivi d'un plan.

Les meilleures pratiques de Scrum

Il existe certaines meilleures pratiques qui sous-tendent la méthodologie Scrum.
Nous assurons la satisfaction du client grâce à une livraison précoce et continue du produit.
Tester et incorporer les commentaires du propriétaire du produit quotidiennement.
Accueillir et répondre aux exigences changeantes, même tard dans le processus de développement.
Travailler ensemble avec le client sur le processus de développement.
Fournir le soutien et l'environnement nécessaires pour que les individus motivés puissent accomplir le travail.
Insister sur la communication en face à face au sein de l'équipe et avec celle-ci.
Mesurer les progrès grâce à une solution/produit fonctionnel.
Promouvoir le développement à un rythme durable.
Améliorer l'agilité en s'engageant envers l'excellence technique et le bon design.
Les équipes auto-organisées étant le meilleur moyen d'obtenir la meilleure architecture, les meilleures exigences et les meilleurs designs.
Avoir des réflexions régulières sur l'amélioration de l'efficacité grâce aux revues de sprint et ajuster les actions pour s'adapter à celles-ci.
Respecter l'équilibre entre la vie professionnelle et la vie privée des membres de l'équipe pour garder le stress à un minimum.

Avantages de Scrum

La méthodologie Scrum est la méthodologie de gestion de projet agile la plus largement utilisée pour les raisons suivantes.

Liberté d'initiative — Les professionnels qui aiment la liberté de prendre des initiatives adorent le processus Scrum en raison de son éthique d'auto-organisation. Cela tend à booster le moral de l'équipe.

Produits/services de haute qualité — Les produits et services produits en utilisant le processus Scrum tendent à être de haute qualité en raison des diverses itérations et améliorations qu'ils ont dû subir ainsi que de l'implication du client dans le développement.

Délais de livraison plus courts — Cela résulte du processus de développement incrémental qui réduit le délai de livraison de 30 % à 40 %. L'implication du client dans le développement est également un facteur ici.

Meilleur retour sur investissement — Cela résulte des délais de livraison plus courts, de la meilleure qualité des produits/services et de moins de défauts grâce aux commentaires continus et aux tests précoces.

Flexibilité — Les équipes sont capables de réagir rapidement aux changements soudains du marché et de les refléter dans le développement du produit/service.

Inconvénients de Scrum

Comme tout le reste, le processus Scrum a ses limites. En voici quelques-unes.

Besoin d'expertise — Scrum nécessite des professionnels ayant une expertise et une formation sur la méthodologie Scrum. Cela nécessite un investissement initial par l'organisation.

Dérive des objectifs — Le client pourrait demander trop de modifications sur le produit/projet, qui pourraient s'avérer inutiles.

Coûteux — Le besoin d'une expertise élevée pendant le processus Scrum ainsi que les événements constants rendent le processus Scrum coûteux à exploiter.

Le processus Scrum

Équipes Scrum

Le processus commence par la formation d'une équipe Scrum pour travailler sur une solution/projet prédéfinie. Ces équipes sont généralement auto-organisées et pluridisciplinaires. Selon les principes Scrum, les équipes auto-organisées sont le meilleur moyen de garantir des performances optimales sur un projet, car elles peuvent influencer la manière dont le travail sera accompli plutôt que de suivre des directives externes.

La pluridisciplinarité fait référence aux différentes compétences parmi les membres de l'équipe, ce qui permet à l'équipe Scrum d'avoir tout ce dont elle a besoin pour accomplir le projet et élimine le besoin d'aide externe.

Une équipe Scrum idéale ne devrait pas avoir plus de 9 membres pour améliorer l'esprit d'équipe, la proximité et l'efficacité. Il est également important que les membres de l'équipe soient au même endroit physique ou au moins en ligne constamment s'ils travaillent à distance.

Les équipes Scrum livrent des solutions par incréments, en incorporant les vues du propriétaire du produit à chaque itération du produit. Cela garantit la disponibilité constante d'un produit fonctionnel. Il y a 5 valeurs ou principes que chaque équipe Scrum doit respecter pour être efficace.

Engagement — Travailler vers les objectifs de l'équipe à chaque sprint.
Courage — Être capable de faire ce qui est juste malgré les conflits et les défis.
Concentration — Se concentrer exclusivement sur les objectifs de l'équipe et le backlog du sprint.
Ouverture — Être transparent les uns avec les autres sur le travail et ses défis.
Respect — Respecter chaque membre de l'équipe.

Rôles Scrum

Il y a trois rôles distincts dans toute équipe Scrum : le propriétaire du produit, le Scrum Master et l'équipe de développement.

Propriétaire du produit — Cette personne représente le client dans l'équipe Scrum et a la responsabilité de s'assurer que l'équipe livre le projet/solution/produit selon les spécifications du client/utilisateur final. Ils doivent communiquer les exigences du produit de l'utilisateur final ainsi que les commentaires du client à chaque itération du produit. Ils gèrent également le backlog du produit qui identifie les fonctionnalités du produit à travailler.

Scrum Master — Cet individu s'assure que l'équipe suit les principes et les directives de Scrum. Ils s'assurent que tout ce qui est nécessaire pour le projet est disponible et prennent soin de tout obstacle qui l'entrave. Ils facilitent également les événements d'équipe et assurent une communication appropriée.

Équipe de développement — Cela comprend le reste de l'équipe Scrum. Ils doivent travailler ensemble pour fournir un produit/projet en utilisant leurs diverses compétences. Ils s'organisent eux-mêmes et choisissent leur propre chemin pour livrer le produit.

Événements Scrum

La communication est vitale dans le cadre Scrum. Cela est ancré dans les cinq événements ou réunions où les informations sur le processus de développement sont échangées régulièrement.

Affinement du backlog — Le propriétaire du produit examine régulièrement le backlog du produit qui fait référence à la liste des fonctionnalités du produit, au travail à faire et à la séquence de livraison. Ils s'assurent que le backlog est correctement préparé de manière à communiquer aux membres de l'équipe ce qui doit être fait à chaque sprint.

Parfois, l'ordre du travail doit être modifié en raison des commentaires des clients ou des revues de l'équipe de développement. La revue du backlog, qui est effectuée entre la conclusion d'un sprint et avant le début d'un nouveau, priorise les fonctionnalités en fonction de facteurs tels que la valeur commerciale, le risque et la date à laquelle les fonctionnalités sont nécessaires. Cette revue fournit généralement le contenu pour le prochain sprint.

Planification du sprint — Cela se fait au début d'un sprint pour planifier ce sur quoi l'équipe Scrum doit travailler. Les petites parties dans lesquelles un projet est divisé sont appelées sprints. Ils peuvent durer d'une semaine à un mois.

La réunion de sprint, qui dure généralement en moyenne quatre heures pour un sprint de 2 semaines, voit l'équipe choisir les éléments du backlog qui peuvent être complétés pendant le sprint, comment ils seront travaillés et l'objectif du sprint. Tout cela est inclus dans un backlog de sprint.

Scrum quotidien/stand up — Il s'agit d'une réunion debout quotidienne rapide qui dure au maximum 15 minutes. Le travail de la veille est examiné et les défis sont identifiés par l'équipe ainsi que par les membres individuels.

Un individu est chargé de trouver des solutions à tout défi identifié et tout travail non terminé de la veille est mis en évidence par le Scrum Master sur le tableau Scrum.

Les discussions détaillées ne sont pas autorisées pendant les réunions Scrum. La stratégie à utiliser pour le travail de la journée est également convenue.

Revue de sprint — Cette réunion, qui se tient à la fin du sprint, est utilisée pour examiner la performance de l'équipe. Si le travail du jour est terminé, l'itération du produit est démontrée puis présentée au client/utilisateur final avec le backlog du sprint contenant les éléments "terminés" pour leurs commentaires.

Le propriétaire du produit peut également apporter des ajustements au backlog du produit à ce stade.

La durée recommandée pour la réunion est généralement d'un maximum de quatre heures.

Rétrospective de sprint — C'est une opportunité pour l'équipe Scrum de réfléchir à leur efficacité et à ce qui pourrait être amélioré pour une meilleure productivité la prochaine fois.

Artéfacts Scrum

Cela fait référence aux outils couramment utilisés dans le processus Scrum. Voici trois d'entre eux utilisés pour enregistrer les progrès de l'équipe Scrum ainsi que les détails du projet.

Backlog du produit — Il s'agit d'une liste de travail qui doit être effectuée sur le projet par l'équipe Scrum. Il contient les exigences du produit, les fonctionnalités à travailler et les bugs qui doivent être corrigés. Il est supervisé par le propriétaire du produit et sert de guide à l'équipe. Il est généralement examiné avant d'être intégré au backlog du sprint.

Backlog du sprint — Cette liste, supervisée par l'équipe de développement, fait référence à la liste des fonctionnalités du produit du backlog du produit qui doivent être travaillées pendant le sprint actuel.

Les membres de l'équipe s'inscrivent pour gérer les tâches qu'ils peuvent gérer en fonction de leurs compétences dans l'esprit de l'auto-organisation et de l'engagement.

Les backlogs de sprint peuvent être modifiés pendant un sprint, mais l'objectif final reste constant.

Incréments de produit — Il s'agit du résultat final du travail accompli pendant un sprint. Il est généralement ajouté au travail terminé des sprints précédents.

Cela est généralement conforme à ce que l'équipe Scrum définit et accepte comme statut "Terminé". La plupart du temps, cela signifie que le produit est fonctionnel à un niveau optimal et prêt à être livré au client/utilisateur final.

Les principes et pratiques de Kanban

Les principes de Kanban

Il y a quatre principes fondamentaux qui forment la base d'une mise en œuvre réussie de la méthodologie Kanban.

Commencez avec le système actuel — La méthodologie Kanban insiste sur la nécessité d'éviter un choc culturel en introduisant un nouveau système du jour au lendemain. Au lieu de cela, elle peut être introduite dans une organisation et appliquée parallèlement aux techniques existantes.

Cela rend Kanban facile à mettre en œuvre et non perturbateur. Les changements peuvent ensuite être mis en œuvre à un rythme que tout le monde accepte pendant une longue période de gestation, tandis que des informations sur le flux de travail actuel et ses inefficacités sont collectées et analysées.

Effectuez des changements de manière incrémentale — La méthodologie Kanban met l'accent sur des changements graduels et petits par rapport au statu quo. Cela permettra une meilleure adhésion des membres de l'organisation qui seront affectés par le processus, réduira l'incertitude et l'inquiétude, et permettra à l'organisation d'être transformée pour le mieux, car les preuves des changements incrémentaux précédents sont apparentes.

Respectez les processus et rôles actuels du flux de travail — Le processus de travail existant, les fonctions et les personnes responsables de celles-ci ne sont pas immédiatement supprimés lorsque la méthodologie Kanban est mise en œuvre.

L'équipe décidera quels rôles doivent être modifiés, quels changements doivent être introduits et le bon moment pour les faire. Cela vise à faciliter la transition organisationnelle parmi les membres et à rendre les changements incrémentaux acceptables parmi eux.

Encouragez le leadership à tous les niveaux — Kanban reconnaît que les qualités de leadership peuvent émerger de n'importe qui, quel que soit le niveau auquel il se trouve dans une organisation. C'est pourquoi les membres de l'équipe sont encouragés à agir lorsqu'il y a un besoin de changements ou à lancer des initiatives au lieu d'attendre que la direction supérieure ou senior les ordonne.

Ce principe favorise la confiance et l'amélioration continue (Kaizen) parmi les membres de l'équipe, les aidant à atteindre leurs niveaux de performance optimaux, ce qui augmentera la productivité organisationnelle à long terme.

Pratiques Kanban

Pour que la mise en œuvre de Kanban soit efficace, il y a six pratiques Kanban que les équipes doivent mettre en action.

Visualisez le processus de flux de travail — Il s'agit de la première étape lors de l'utilisation de la méthodologie Kanban. Le processus utilisé pour livrer les produits/services par l'organisation ainsi que son flux doivent être illustrés sur un tableau Kanban qui peut être physique ou électronique.

Chaque étape du flux de travail est représentée par une colonne sur le tableau. Les différents éléments de travail sont désignés par des cartes Kanban de différentes couleurs. Une collection d'éléments de travail liés peut être regroupée à l'aide de voies Kanban.

L'objectif principal de celles-ci est que toutes les parties comprennent le fonctionnement du processus de flux de travail, de la demande du client à la livraison finale du produit/service, ainsi que d'améliorer la communication et la collaboration. Avec cela, différentes zones du processus de travail peuvent être suivies et analysées pour identifier les éventuels obstacles qui peuvent être travaillés.

Limitez le travail en cours (WIP) — Avec Kanban, un nombre gérable d'éléments de travail doit être travaillé à la fois avec une limite placée sur le travail en cours qui peut être géré. Le travail en cours doit être terminé avant de passer à une nouvelle tâche à "tirer".

Kanban décourage le multitâche car il conduit au gaspillage et aux inefficacités. Les limites de WIP dans les tableaux de colonnes soulignent l'importance de choisir soigneusement le travail que l'équipe doit faire à ce moment-là, car il y a une capacité limitée qui doit être utilisée efficacement.

La concentration sur le WIP aide également à réduire les temps de cycle (la durée de la demande du client à la livraison finale) pour un produit/service particulier.

Gérez le flux de travail — Avec la méthodologie Kanban, les différentes étapes du flux de travail et les progrès du travail dans chacune d'elles sont mis en évidence sur le tableau Kanban.

Kanban met l'accent sur la gestion du processus de flux de travail au lieu de la micro-gestion des personnes, l'objectif principal de sa mise en œuvre étant le flux de travail fluide à des niveaux optimaux.

Cela permet à l'équipe d'analyser le processus de flux de travail en mesurant la productivité/l'efficacité avec des métriques comme le temps de cycle et les temps de traitement. Cela facilite l'identification de toute obstruction dans le processus de flux de travail.

La plupart du temps, ces obstructions se trouvent dans les étapes intermédiaires d'attente où le travail doit changer de mains, mais parfois d'autres facteurs comme l'efficacité des travailleurs ont un rôle à jouer.

Où qu'elles soient présentes, des ajustements sont apportés dans le processus de travail pour les éliminer et améliorer le flux de travail. Cela permettra de réduire les temps de cycle pour le produit ou le service, assurant un retour plus rapide et la livraison d'une meilleure valeur aux clients.

Communiquez clairement les politiques du processus — Une grande partie de Kanban est la communication des politiques et des règles du processus sur la manière dont le travail est conduit explicitement à toutes les parties concernées afin qu'il y ait une compréhension claire de ce qui est attendu de chaque personne. Cela aide à fournir une norme contre laquelle la performance peut être mesurée et garantit une cohérence de qualité dans le produit/service livré.

Il doit y avoir des règles et des directives de processus de travail pour chaque colonne, comme qui tire quoi, les critères d'entrée et de sortie pour la colonne, quand une tâche est terminée, etc., qui doivent être visualisés sur le tableau Kanban. Cela maintient tout le monde avec une référence visuelle dans l'organisation alors qu'ils travaillent vers un objectif commun.

Obtenez des commentaires régulièrement et mettez-les en œuvre — Les commentaires sont très importants pour la méthodologie Kanban. L'examen et l'analyse des étapes du flux de travail sur le tableau Kanban lors des réunions debout quotidiennes sont une bonne opportunité pour cela. Chacun des différents aspects du flux de travail comme la livraison et les opérations doit également être examiné individuellement pour suivre leurs progrès.

Les membres de l'équipe doivent également commenter leurs observations individuelles de la veille. Ces réunions quotidiennes doivent être courtes et aller droit au but. Des plans doivent être mis en mouvement pour travailler sur tous les commentaires reçus. Obtenir tous ces commentaires tôt dans le processus permet de faire des améliorations rapidement afin d'améliorer les temps de cycle et la productivité organisationnelle.

Expérimentez et améliorez toujours — Le modèle de changement évolutif de Kanban permet l'utilisation de la méthode d'investigation scientifique qui implique de former une théorie, de la tester et de la modifier pour l'améliorer.

Le processus de flux de travail doit être évalué et amélioré en continu. De nouvelles techniques peuvent être introduites de manière incrémentale dans le processus de flux de travail et observées, puis une décision doit être prise pour les conserver ou les supprimer en fonction de l'amélioration qu'elles apportent au processus en évaluant la mesure des métriques.

Parfois, ces techniques ont juste besoin d'une modification pour fonctionner de manière optimale. L'amélioration continue est la pierre angulaire de la méthodologie Kanban.

Le processus Kanban

Kanban est une méthodologie qui cherche à améliorer l'efficacité d'une organisation en appliquant la visualisation au processus de travail. Elle est basée sur la notion éprouvée que le cerveau traite les images plus facilement que les mots. Avec la visualisation, les zones d'inefficacité deviennent apparentes.

Kanban vise à améliorer le processus de flux de travail progressivement et de manière incrémentale plutôt que rapidement. Cela réduit le risque pour l'organisation. Il vise également à faire en sorte que le processus de travail se déroule plus rapidement.

Le tableau Kanban

Le tableau Kanban est l'outil principal pour la représentation visuelle du processus de flux de travail. Il permet une communication plus claire entre toutes les parties impliquées, la manière dont les informations sur le projet/le processus de développement sont mises en évidence à travers des images.

Les tableaux Kanban peuvent être sous forme physique ou sous forme numérique/électronique, utilisée pour les équipes avec des membres à distance. Le tableau Kanban comprend généralement trois colonnes principales :

À faire — Les tâches qui n'ont pas été commencées sont listées ici.
En cours — Les tâches en cours de traitement sont listées ici.
Terminé — Cela consiste en des tâches qui ont été complétées.

Les tâches sont représentées par des notes ou des cartes collantes colorées. En représentant le processus de flux de travail avec des images sur le tableau Kanban, l'efficacité du processus de flux de travail peut être mesurée, surtout avec l'aide de logiciels Kanban spécialisés.

Là où l'efficacité est inférieure à ce qui est attendu, les obstacles peuvent être traqués et ensuite traités. Cela permet une efficacité de production plus élevée et des temps de cycle de produit plus courts ainsi que des améliorations dans la qualité du produit/service.

Avantages de Kanban

Kanban est rapidement adopté par des organisations dans différentes industries à travers le monde. Certaines des raisons de cela incluent les suivantes.

Communication claire et transparence - La visualisation du flux de travail sur les tableaux Kanban permet une communication claire et permet à chacun de savoir ce qui est attendu de lui. Il est facile de suivre les progrès du travail, ce qui facilite la connaissance de l'action nécessaire.
Repérer rapidement les obstacles — L'encombrement de certaines des colonnes peut facilement mettre en évidence où le processus de travail est ralenti, nécessitant ainsi des ajustements.
Flexibilité — La capacité d'utiliser Kanban dans n'importe quel système ou industrie et sa philosophie de changement incrémental en font un favori parmi de nombreuses organisations désirant des améliorations continues de l'efficacité. Il est généralement combiné avec des techniques de gestion de projet agile pour les rendre plus efficaces.
Réactif à la demande — Kanban permet d'ajuster la capacité pour correspondre aux demandes des clients, évitant ainsi le gaspillage inutile ainsi que la capacité de répondre rapidement aux changements.
Concentration et collaboration — Le travail en cours limité force les équipes à se concentrer sur le WIP au lieu du multitâche, améliorant ainsi la productivité. La collaboration est également améliorée car les membres de l'organisation s'entraident pour surmonter les défis dans l'exécution de leurs tâches.

Inconvénients de Kanban

La méthodologie Kanban a ses limites —

Mal adapté aux grands projets — Kanban peut être difficile à utiliser dans une situation à grande échelle.
Mauvaise utilisation du tableau Kanban — La mauvaise utilisation ou la surcomplication du tableau Kanban peut envoyer de mauvais signaux sur le processus de flux de travail, ce qui pourrait entraîner des erreurs coûteuses.
Fluctuations sauvages de la demande — Des demandes de produits irrégulières pourraient perturber la méthodologie Kanban, car de mauvais signaux pourraient être envoyés en conséquence.
Erreurs de qualité — La méthodologie Kanban réduit les niveaux de stock à presque zéro dans le but de réduire le gaspillage. Mais lorsqu'il y a un problème de qualité avec le produit ou le service final, il pourrait être difficile pour l'organisation de réagir rapidement en raison de l'absence de tampon de stock.

Similarités et différences entre Scrum et Kanban

Scrum et Kanban sont les outils d'amélioration de la productivité les plus adoptés au monde, mais ils ne sont pas vraiment des alternatives directes l'un à l'autre comme le croient la plupart des gens. Ils ont quelques similarités, mais il y a aussi des différences entre les deux.

Similarités

Scrum et Kanban sont tous deux des outils pour améliorer la productivité et l'efficacité ainsi que minimiser le gaspillage.

Ils sont tous deux basés sur la technique de gestion de projet agile qui met l'accent sur la flexibilité et la capacité à s'adapter aux changements.

Ils fonctionnent également selon la technique de planification "pull".

Ils voient tous deux les améliorations de la qualité des produits ou services et des délais de livraison comme la pierre angulaire des deux techniques.

Ils sont tous deux basés sur l'éthique de l'auto-organisation avec les membres de l'équipe prenant leurs propres initiatives et actions, chaque membre étant égal aux autres et aucun ordre ne venant de l'extérieur.

Les tâches complexes sont généralement divisées en parties plus petites et gérables.

Scrumban

Dans de nombreuses organisations aujourd'hui, Scrum et Kanban sont utilisés et combinés dans ce que l'on appelle Scrumban. Cela a été initialement créé pour les équipes passant de Scrum à Kanban, mais est devenu une méthodologie de gestion de projet à part entière. Sous cette méthodologie, le processus Scrum est utilisé, mais il est vu à travers le prisme du système d'amélioration Kanban.

Un tableau similaire à un tableau Kanban avec des cartes colorées est utilisé. Le travail est divisé en itérations. Les limites de WIP sont utilisées ici tandis que les membres de l'équipe choisissent les tâches sur lesquelles ils travailleront, puisqu'ils sont auto-organisés.

La planification à la demande est une caractéristique de Scrumban. Il s'agit de l'application de techniques de planification lorsque de nouvelles tâches sont disponibles plutôt que sur une base quotidienne. La priorisation des tâches est effectuée afin que les membres de l'équipe sachent quelles tâches sont importantes.

Différences

Il existe de nombreuses différences entre Scrum et Kanban. Cela inclut :

Définition — Scrum est un cadre avec des règles et des techniques spécifiques, tandis que Kanban est un outil de visualisation du flux de travail utilisé parallèlement à un système existant.

Formation et gestion — Scrum nécessite beaucoup d'éducation et de formation, ainsi que de gestion et de professionnels experts. Kanban, en revanche, peut être facilement compris par tout le monde, ce qui le rend moins coûteux à gérer.

Processus de changement — Kanban encourage le changement incrémental et est adapté aux organisations avec des structures de flux de travail stables et solides, tandis que les organisations qui ont besoin d'un changement complet rapidement devraient opter pour Scrum.

Utilisation — Kanban est généralement utilisé pour des projets plus petits, tandis que Scrum est plus bénéfique pour des projets plus grands et plus complexes.

Rôles — Scrum a trois rôles définis : Scrum Master, propriétaire du produit et équipes de développement. Kanban n'a pas de rôles définis, car chaque membre de l'équipe peut prendre les tâches disponibles.

Durée — Le processus Scrum dure pour la durée du projet/développement et est relancé avec une nouvelle entreprise, tandis que Kanban est un effort continu, car il est fait avec des produits/services qui doivent être livrés en continu.

Équipes — Scrum prône les équipes pluridisciplinaires, tandis que les équipes spécialisées sont la norme dans Kanban.

Nouvelles tâches/Itérations — Dans Scrum, de nouveaux éléments ne peuvent pas être ajoutés en dehors des tâches préplanifiées pour le sprint, même lorsque l'équipe a la capacité pour de telles additions. Dans Kanban, de nouvelles tâches peuvent être travaillées tant que la capacité est disponible.

Propriété — Le backlog du sprint dans le processus Scrum est possédé par une équipe Scrum, tandis que le tableau Kanban peut être partagé par autant d'équipes que possible.

Mesure de la productivité — Kanban mesure la productivité en utilisant le temps de cycle d'un produit/service, tandis que Scrum mesure cela en utilisant la vélocité à travers les sprints.

Objectifs de l'équipe — Dans Scrum, les équipes se concentrent sur la collaboration et l'achèvement d'une tâche prédéfinie, tandis que les équipes Kanban se concentrent sur la définition d'objectifs et la réduction des temps de cycle.

Conclusion

Cet article ne vise pas à prouver lequel est le meilleur entre Scrum et Kanban, car ce sont tous deux des outils de productivité visant à améliorer l'efficacité. Il vise plutôt à fournir une compréhension des deux outils afin que vous puissiez prendre une bonne décision si vous choisissez entre eux — ou vous pouvez décider d'utiliser les deux.

Je préfère personnellement Kanban. Mais je pense que c'est parce qu'un mentor m'a donné une copie de 'Kanban: Successful Evolutionary Change for your Technology Business' qui m'a vraiment aidé lorsque j'ai commencé à avoir besoin de rendre mes équipes productives. C'est définitivement un livre qui devrait être dans chaque bureau.

Si vous avez des commentaires ou si vous souhaitez entrer en contact, trouvez-moi sur Twitter @nialljoemaher.