Notez cette article

Scrum, Kanban, les deux méthodes de management de projet se valent-elles ? En réalité, elles sont complémentaires. Pourquoi ? Quelle est la différence entre Scrum et Kanban ?

Pourquoi choisir Scrum ?

Scrum aide les gens à améliorer leur façon de travailler.

Scrum s’applique en particulier au développement de produits (ou de services ou d’applications ou de systèmes) :

  • Les gens travaillent en équipe, bien définie.
  • Le développement est rythmé par une série d’itérations courtes qui sont appelées des sprints.
  • Les fonctions du produit sont collectées dans le backlog.
  • Le contenu d’un sprint est défini à partir du backlog, en tenant compte des priorités et de la capacité de l’équipe. À partir de ce contenu, l’équipe identifie les travaux nécessaires et s’engage sur l’objectif du sprint.
  • Pendant un sprint, des points de synchronisation sont effectués tous les jours. Cette inspection quotidienne permet d’appliquer, en équipe, des ajustements pour assurer le succès du sprint.
  • À la fin de chaque sprint, l’équipe présente l’incrément qu’elle a ajouté au produit pendant le sprint. Son évaluation et le feedback récolté permettent de faire évoluer la définition du produit en cours de réalisation. L’amélioration porte aussi sur la façon de travailler en équipe.

Quelle est l’origine de Scrum ?

Scrum n’est pas un acronyme. Le mot Scrum vient du rugby : en anglais, scrum signifie mêlée.

C’est pourquoi on n’écrit pas SCRUM. C’est pourquoi on prononce « screum », et non « scrume » ni « scroum ». Il suffit de regarder un match de rugby avec un arbitre anglophone pour l’entendre.

Au rugby, une mêlée est sifflée par l’arbitre quand une règle n’a pas été respectée. Par exemple :

  • une équipe a fait un en-avant,
  • le ballon est parti directement en touche sur un renvoi.

La mêlée permet de repartir sur des bases solides, avec une poussée synchronisée de tout le pack. C’est la quintessence de l’effort collectif que Scrum prend comme exemple de la meilleure façon d’attaquer la complexité.

citation auetru dlivre « Scrum utilise les valeurs et l’esprit du rugby et les adapte aux projets de développement. Comme le pack lors d’une mêlée au rugby, l’équipe chargée du développement travaille de façon collective, soudée vers un objectif précis. Comme un demi de mêlée, le ScrumMaster aiguillonne les membres de l’équipe, les repositionne dans la bonne direction et donne le tempo pour assurer la réussite du projet.

En quoi Scrum est-il fondamentalement différent ?

Scrum se différencie nettement des approches traditionnelles. Voici, à mon avis, les six nouveautés fondamentales.

Approche empirique

Scrum a son origine dans la théorie du contrôle empirique des systèmes complexes.

Dans les domaines complexes, il n’est pas possible de prévoir à l’avance ce qui sera réellement obtenu à la fin : les spécifications détaillées, les plans détaillés faits à l’avance sont donc inadaptés. L’approche empirique s’appuie sur des cycles courts avec des rétroactions fréquentes pour avancer vers une solution inconnue au départ. L’empirisme dans Scrum est appelé « inspection & adaptation ».

Rythme

Scrum utilise des blocs de temps fixes pour créer de la régularité. Le cœur du rythme de Scrum est le sprint. La nouveauté est que la fin du sprint n’est pas décidée quand un travail est achevé, mais fixée à l’avance et jamais repoussée.

Priorité
Pendant un sprint, le travail de l’équipe porte sur les choses qui apportent le plus de valeur. On évite de perdre du temps sur des choses sans valeur immédiate. On évite de commencer plein de travaux en même temps. « Arrêter de commencer, commencer à finir. »

Autogestion
L’équipe a le pouvoir et l’autorité pour organiser son travail en fonction de l’objectif. Cela donne plus de responsabilité aux personnes impliquées et leur permet de mieux s’épanouir dans le travail.

Transparence
Le suivi est fait par l’équipe elle-même ; il est visible et reste simple afin qu’il soit facilement compréhensible par tout le monde. Un bon moyen pour y parvenir est de pratiquer systématiquement le management visuel.

Émergence
On laisse du temps à l’équipe pour favoriser l’émergence de nouvelles idées pour le
produit, pour la conception et aussi pour améliorer la façon de travailler ensemble.

Comment faire la méthodologie Scrum pour stimuler la productivité de votre équipe (en 6 étapes)

L’approche Scrum de la gestion de projet permet aux équipes de développement de hiérarchiser leur travail et de rationaliser les opérations. Voyons les six étapes que vous pouvez suivre pour appliquer cette méthodologie, afin d’améliorer la productivité et les performances de votre propre équipe.

Étape 1 : Se familiariser avec les guides Scrum

La première chose à faire avant d’adopter la méthodologie Scrum est d’acquérir une compréhension de ses éléments et événements essentiels. Il existe une abondance de documents en ligne qui offrent des conseils sur le cadre Scrum. Nous vous recommandons de commencer par le Guide officiel de Scrum :

Ce guide complet peut être téléchargé au format PDF, ou vous pouvez ajouter la version web à vos favoris pour vous y référer si nécessaire. Il a été créé par les initiateurs de la méthodologie Scrum : Ken Schwaber et Jeff Sutherland.

Une fois que vous aurez compris les bases du Guide Scrum, vous serez mieux préparé à appliquer le cadre à vos propres projets de développement. Cela vous aidera également à comprendre les prochaines étapes du processus.

Étape 2 : Attribuer des rôles à l’équipe Scrum

Pour mettre en œuvre la méthodologie Scrum, vous devez former une « équipe Scrum ». Celle-ci sera composée de :

1 . Un propriétaire de produit. Cette personne est une partie prenante, qui facilite la communication et les priorités au sein de l’équipe de développement. Elle est chargée de maximiser la valeur du produit et sert essentiellement de représentant ou de mandataire du client.

2 . Le Scrum Master. Le Scrum Master s’assure que l’équipe de développement reste créative et productive, en faisant la liaison entre l’équipe et le Product Owner. En revanche, il ne gère pas l’équipe.

3. L’équipe de développement. L’équipe de développement est généralement composée d’environ sept personnes et comprend un mélange d’ingénieurs, de programmeurs, de testeurs et de concepteurs d’interface utilisateur. Chaque personne s’autogère et est chargée de déterminer comment accomplir le travail qui lui est confié.

Lors du choix de ces rôles, il est important de se souvenir de la fonction spécifique et des tâches à accomplir. Par exemple, le Product Owner doit être une personne qui se sent à l’aise pour parler au nom des meilleurs intérêts des clients.

Étape 3 : créer un backlog de produit

En termes simples, le Backlog de produit est une liste permanente du travail à effectuer. Ce document décrit chaque exigence, caractéristique et fonction nécessaire à un produit ou à un autre projet.

Les éléments inclus dans cette liste sont classés par le Product Owner en termes d’importance et de valeur commerciale. Au fur et à mesure que le projet se développe et que de nouvelles exigences ou corrections sont révélées, le Backlog est mis à jour.

Il est crucial d’avoir une vision claire à ce stade du processus de mise en œuvre. Pour créer une hiérarchie visuelle, il est utile d’élaborer un Scrum Board. Pour ce faire, vous pouvez utiliser un outil de management de projet tel que Trello :

Scrum
Scrum ou Kanban : comment fonctionnent-ils ? 1

Trello est gratuit et permet aux équipes Scrum de s’organiser sur les tâches critiques. Le propriétaire du produit, que ce soit vous ou quelqu’un d’autre, peut assigner des tâches pour chaque élément du Backlog. Les cartes de tâches peuvent ensuite être utilisées par les développeurs pour la planification de leur sprint (que nous aborderons plus tard).

Étape 4 : Réaliser la planification du sprint – sprint planning – et les réunions quotidiennes de mise au point

Une fois que vous avez créé votre backlog, il est temps de planifier le sprint. Il s’agit pour l’équipe de développement de prendre les éléments les plus prioritaires et de déterminer comment les atteindre.

Une partie importante de cette étape consiste à déterminer le temps nécessaire à la réalisation de chaque objectif. En général, la durée d’un sprint est comprise entre deux et quatre semaines.

La planification du sprint doit être relativement brève, car la majeure partie du travail doit être consacrée à la réalisation des objectifs choisis pour ce sprint. Il incombe au Scrum Master de veiller à ce que ces événements limités dans le temps soient réduits au minimum.

Par exemple, disons que votre équipe dispose d’un Sprint de trois semaines. Au début de chaque semaine, vous ne devriez pas consacrer plus de deux heures à la planification de la réalisation de vos objectifs.

Il est bon de prévoir également de brèves réunions quotidiennes de « standup » avec votre équipe Scrum. Ces réunions ne doivent pas durer plus de 15 minutes et permettent de se tenir au courant des progrès et des tâches de chaque membre.

Étape 5 : Définir quand un Sprint est considéré comme terminé

Le Scrum Master doit s’assurer que tous les membres de l’équipe de Scrum sont sur la même longueur d’onde quant à la fin d’un sprint. Les sprints ne sont terminés que lorsque le produit ou le projet est prêt à être livré ou examiné par les parties prenantes.

Cela signifie qu’il a complètement passé le contrôle de qualité et qu’il n’est pas nécessaire de procéder à des modifications ou à des révisions supplémentaires. Les critères pour qu’un élément du backlog soit considéré comme terminé varient d’une équipe de développement à l’autre. Toutefois, ce qui importe, c’est que les attentes soient clairement communiquées à tous les membres de l’équipe.

Étape 6 : Révision, réflexion et répétition

À la fin de chaque sprint, vous voudrez planifier une réunion de révision du sprint avec votre équipe. Cet événement sera l’occasion pour votre équipe de présenter ou de démontrer son travail terminé.

Lors de cette revue, le Product Owner doit évaluer le travail par rapport aux critères prédéterminés de « réalisation ». Les parties prenantes peuvent donner leur avis et décider d’accepter ou de refuser le travail. La phase de révision est également un bon moment pour le Product Owner pour revoir le Backlog, afin de préparer la prochaine session de planification du Sprint.

Vient ensuite la réunion de rétrospective du sprint. C’est là que votre équipe et le Scrum Master vont réfléchir sur le Sprint, pour discuter et documenter ce qui a fonctionné et ce qui n’a pas fonctionné. Lors de ces réunions, il est utile de se concentrer moins sur ce qui n’a pas marché et plus sur les domaines qui pourraient être améliorés pour la prochaine fois.

Une fois la revue de sprint terminée, il est temps de recommencer. Votre équipe peut s’inspirer de ce qu’elle a appris au cours du Sprint précédent et l’utiliser pour améliorer ses processus pour le prochain élément du Backlog.

Scrum VS Kanban : Quand utiliser Scrum ou quand utiliser Kanban ?

Tout comme « brunch » et « motel », « scrumban » est un mélange de deux mots qui, mis ensemble, créent quelque chose de nouveau. Dans ce cas, les deux mots sont « Scrum » et « Kanban ».

Scrum et Kanban sont deux types différents de méthodologie agile, qui côtoient l’Extreme Programming (XP), le Feature Driven Development (FDD), le Lean Software Development, l’Agile Unified Process (AUP), Crystal et la Dynamic Systems Development Method (DSDM).

Elles sont toutes fondamentalement similaires (chacune se concentre sur la planification, l’amélioration et la livraison), avec toutefois quelques différences subtiles. Dans la plupart des cas, les équipes utilisent un mélange des deux, en fonction du type de projet sur lequel elles travaillent.

Scrum et Kanban sont tous deux des pratiques/cadres agiles. Ils ont évolué au fil des ans pour relever des défis spécifiques en matière d’organisation du travail.

De nombreuses équipes et organisations ont souvent utilisé une combinaison de pratiques issues de Scrum et de Kanban, parfois à leur avantage, parfois moins. Des questions se posent donc souvent : qu’est-ce que scrum et kanban et quand faut-il utiliser l’un ou l’autre ? Scrum et le kanban peuvent-ils être utilisés indifféremment pour tous les projets ? Ou existe-t-il des pratiques complémentaires dans les deux méthodes qui peuvent être combinées ?

Tout d’abord, si nous combinons des pratiques de scrum et de kanban sans appliquer l’ensemble du cadre, nous ne faisons ni du scrum ni du kanban. Nous faisons quelque chose, mais ce n’est ni l’un ni l’autre. Nous pouvons également tirer certains avantages des pratiques, mais pas ce que nous obtiendrons de la mise en œuvre complète de scrum ou de kanban.

Cela dit, comparons scrum et kanban en fonction de divers attributs pour comprendre les types de projets dans lesquels chacun peut être utilisé. Le tableau de la page suivante résume les attributs de la méthode scrum et du kanban et met en évidence les types de projets dans lesquels ils peuvent être utilisés en fonction de ces attributs.

AttributScrumKanban
1Cycle de travailItérations. Scrum comporte des sprints au sein desquels l’équipe suit le cycle planifier-faire-vérifier-agir (PCDA).
Les travaux complexes et itératifs, comme le développement de nouveaux produits ou de nouvelles fonctionnalités, peuvent être mieux réalisés avec Scrum.
Flux continu. Dans un cycle de travail kanban, dès qu’une tâche est terminée, l’équipe en reprend une autre.
Kanban est mieux adapté au travail en flux continu, comme le support et les services.
2WIP – Work In Progress (travail en cours)Les limites du WIP sont fixées par l’équipe scrum pour chaque sprint, et les nouveaux travaux ne sont repris qu’une fois tous les travaux terminés.
Si les équipes ont besoin d’un sentiment d’accomplissement, d’achèvement et de clôture, utilisez la méthode scrum.
La limite des travaux en cours est permanente. Dès qu’un travail est terminé, on en reprend un autre.
Si les équipes continuent à travailler sur une chose après l’autre, utilisez le Kanban.
3Inspecter-Adapter (Empirisme)Chaque sprint est une occasion d’inspecter et d’adapter. Le travail passe par plusieurs sprints pour permettre l’improvisation, si nécessaire.
Si le travail évolue en permanence et nécessite une improvisation, utilisez la méthode scrum.
Pas de mécanisme spécifique pour inspecter et adapter. Le travail circule dans une seule direction.
Si le travail est un effort unique, et ne nécessite pas d’inspection et d’adaptation, utilisez le Kanban.
4Transparence (Empirisme)Les artefacts dans scrum comprennent le backlog de produit, le backlog de sprint, un incrément. Ils assurent respectivement la transparence des exigences, de la mise en œuvre et des livrables.
Si les exigences doivent être suivies séparément du suivi des travaux en cours, utilisez scrum.
Pas d’artefacts spécifiques pour la transparence. Le tableau Kanban offre une certaine transparence. De nombreuses équipes utilisent le backlog du produit (de Scrum) en combinaison avec les tableaux Kanban.
Si seule la mise en œuvre doit être suivie, utilisez le kanban.
5PlanningÉvénements spécifiques pour la planification du sprint et de la journée – planification du sprint et scrum quotidienne.
Utilisez la méthode scrum si une planification disciplinée à intervalles réguliers est nécessaire.
Aucune disposition pour la planification du travail. Les équipes adoptent leur propre cadence et leur propre approche de la planification.
La planification du Kanban de l’utilisateur peut être intermittente ou au fur et à mesure des besoins.
6ResponsabilitéLes responsabilités dans scrum développent la focalisation des responsabilités, par exemple, le propriétaire du produit pour les affaires, les développeurs pour le domaine et le maître de scrum pour les obstacles.
Si les équipes ont besoin d’individus concentrés sur ces responsabilités, utilisez la scrum.
Il n’y a pas de responsabilités comme le propriétaire du produit, les développeurs, etc. dans le kanban. Il suppose un groupe d’individus travaillant sur des tâches.
Si l’équipe est simplement un groupe d’individus ayant une certaine expertise, utilisez le Kanban.
7Parties prenantes/clientsScrum implique la participation active des parties prenantes et des clients – au moins une fois par sprint lors d’un événement de revue de sprint.
Si le travail est innovant, créatif ou nouveau et qu’il nécessite un retour d’information ou un engagement de la part des parties prenantes et des clients, utilisez Scrum.
Kanban ne permet pas d’impliquer les parties prenantes ou les clients. De nombreuses équipes adoptent une approche de  » revue de sprint  » une fois par mois.
Si le travail est essentiellement quotidien et ne nécessite pas d’implication fréquente des parties prenantes, utilisez Kanban.

Les deux sont Lean et Agile

Scrum et Kanban reposent tous les deux sur les mêmes valeurs et principes. Par exemple :

  • Scrum et Kanban sont orientés Juste à temps (JIT = Just In Time) qui est un principe Lean. Cela signifie que l’équipe choisit le moment et la quantité de travail sur laquelle s’engager, et “tire” le travail quand elle est prête, plutôt que de voir ce travail “poussé” de l’extérieur. Exactement comme une imprimante qui tire la page suivante uniquement au moment où elle est prête à l’imprimer (même s’il n’y a qu’un petit stock limité de papier qu’elle peut utiliser).
  • Scrum et Kanban sont basés sur une optimisation continue et empirique des processus, qui correspond au principe Kaizen du Lean.
  • Scrum et Kanban mettent l’accent sur la réactivité aux changements plutôt qu’au suivi d’un planning (même si Kanban donne en général une réponse plus rapide que Scrum), l’une des quatre valeurs du Manifeste Agile.

. … et plus encore. D’un autre côté, Scrum n’est pas aussi Lean que cela, car il prévoit de grouper la réalisation des éléments dans des itérations à durée fixe. Mais cela dépend de la durée de votre sprint et de ce que vous comparez. Par rapport à un processus traditionnel où l’on intègre et livre 2 à 4 fois par an, une équipe Scrum développant un produit potentiellement livrable toutes les 2 semaines est très Lean. Si vous continuez avec des sprints de plus en plus courts, vous vous rapprochez de Kanban. Lorsque vous commencez à parler de durée inférieure à 1 semaine, vous pouvez envisager de laisser entièrement tomber le principe de l’itération à durée fixe.

Quels sont les différences entre la méthode kanban agile et la méthode scrum ?

Scrum est un processus agile qui nous permet de nous concentrer sur la livraison de la valeur commerciale dans les plus brefs délais. Kanban est un système visuel de gestion du travail de développement de logiciels. La méthode Kanban favorise l’amélioration continue, la productivité et l’efficacité sont susceptibles d’augmenter.

Comparaison des méthodologies de management de projet : Agile, Scrum et Kanban :

Agile est un terme générique utilisé pour décrire une méthodologie de management de projet qui décompose les grands projets complexes en petits morceaux plus faciles à gérer. La gestion de projet agile est utilisée depuis de nombreuses années dans le développement de logiciels pour accélérer l’achèvement des projets. Cependant, le monde change et il n’est pas nécessaire d’être un développeur pour être exposé à l’idée d’Agile et de Scrum.

Aujourd’hui, nous commençons à voir ces pratiques appliquées dans une multitude de secteurs. Nicholas Carrier, partenaire associé chez Prophet, explique : « Agile est un ensemble de principes directeurs élaborés en 2001 et publiés sous le nom de Manifeste Agile. Scrum et Kanban, quant à eux, sont deux cadres de travail considérés comme agiles. Ou, pour le dire autrement : Si vous devez travailler de manière agile, Scrum et Kanban sont deux façons de le faire. »

Scrum et Kanban sont tous deux deux systèmes de management de projet Agile différents, avec des différences subtiles. Si vous adhérez au Manifeste Agile, vous voudrez probablement adopter l’un de ces cadres. Mais Carrier a noté comment ils partagent tous deux des similitudes. « Les deux méthodes utilisent un tableau physique, ou la réplique numérique d’un tableau, où les gens déplacent le travail entre environ trois catégories : 1) le travail [qui doit être fait], 2) le travail en cours et 3) le travail achevé. »

Qu’est-ce qu’un tableau Kanban – Kanban Board ?

Un tableau Kanban est un outil de visualisation du flux de travail et l’un des éléments clés de la méthode Kanban.

La visualisation de votre flux de travail et de vos tâches sur un tableau Kanban vous aide à mieux comprendre vos processus et à obtenir une vue d’ensemble de votre charge de travail. Grâce à ce nouveau niveau de transparence, vous identifierez rapidement les étapes de travail problématiques et, en les améliorant, votre équipe travaillera bientôt plus efficacement.

Dans ce guide, nous allons expliquer ce qu’est un tableau Kanban, discuter des principes de base et clarifier les détails importants que vous devez comprendre, surtout si vous êtes un débutant.

Tableau Kanban
Tableau Kanban

Le tableau Kanban expliqué

Le tableau Kanban a connu un long parcours pour devenir ce qu’il est aujourd’hui. Kanban (en anglais : signboard) a commencé comme un système d’ordonnancement visuel, faisant partie du système de production Toyota.

Quelques décennies plus tard (2007), David Anderson a développé l’idée de la méthode Kanban et a introduit le tableau Kanban. En effet, c’est Darren Davis (le collègue d’Anderson) qui a suggéré que le flux de travail soit visualisé sur un tableau blanc. C’est ainsi qu’est né le tableau Kanban, tel que nous le connaissons aujourd’hui, pour devenir l’un des outils de management de projet agile les plus utiles pour le travail de connaissance. Aujourd’hui, son utilisation par les équipes agiles est si répandue que l’on entend souvent parler des tableaux Kanban comme de tableaux de tâches agiles.

Principaux composants du tableau Kanban

Scrum ou Kanban : comment fonctionnent-ils ?

Les tableaux Kanban utilisent des cartes, des colonnes, des swimlanes et des limites d’encours pour permettre aux équipes de visualiser et de gérer efficacement leurs flux de travail. Laissez-nous vous présenter de plus près les principaux composants :

Cartes Kanban – Il s’agit de la représentation visuelle des tâches. Chaque carte contient des informations sur la tâche et son statut, telles que la date limite, le destinataire, la description, etc.

Colonnes Kanban – Chaque colonne du tableau représente une étape différente de votre flux de travail. Les cartes parcourent le flux de travail jusqu’à leur achèvement complet.

Limites du travail en cours – Elles restreignent la quantité maximale de tâches dans les différentes étapes du flux de travail. La limitation du travail en cours vous permet de terminer les éléments de travail plus rapidement en aidant votre équipe à se concentrer uniquement sur les tâches en cours.

Swimlanes Kanban – Il s’agit de couloirs horizontaux que vous pouvez utiliser pour séparer les différentes activités, équipes, classes de service, etc.

Si vous êtes novice dans cette méthode, vous pouvez commencer par une structure de base de tableau Kanban et la diviser en trois sections principales qui montrent les différentes étapes du flux de travail.

Tableau Kanban de base
Tableau Kanban de base

La méthode Agile

Scrum et Extreme Programming (XP) existaient bien avant le Manifeste. Dès la publication de celui-ci, on les considéra comme des méthodes agiles, avec d’autres maintenant marginales. Depuis peu, Kanban fait partie du lot des méthodes qui comptent.

Dans les enquêtes qui montrent leur diffusion et leur utilisation, année après année, c’est Scrum qui reste la plus populaire. Au point que Scrum et agile soient des mots qu’on utilise l’un pour l’autre ou qu’on accole : des offres d’emploi ou des articles parlent d’Agile Scrum.

On a vu que Scrum n’était pas vraiment une méthode mais un cadre. Kanban n’est pas non plus une méthode agile, c’est une méthode d’amélioration de processus ou une méthode de gestion de flux. Finalement, il n’y a que XP qui devrait être qualifié de méthode.

C’est de plus en plus rare, mais cela arrive encore que des entreprises mettent au point leur propre méthode. Pourquoi pas, mais la méthode ainsi créée n’est pas Scrum. Il y a aussi celles qui disent passer au « mode agile » pour certains développements, pour signifier plus de flexibilité. Bien sûr, Scrum ne rentre pas dans ce mode agile. Et faire du Scrum pour être à la « mode agile », ce n’est pas mieux… Scrum est donc considéré comme une méthode agile. Et quand on parle de méthode agile, le domaine concerné reste généralement celui du développement de logiciel.

L’agilité

Au-delà de l’informatique

En fédérant les méthodes agiles, le Manifeste agile constitue l’acte de naissance du mouvement de l’agilité qui a pris de l’ampleur depuis quelques années. Scrum est maintenant diffusé dans de très nombreuses organisations : après les pionniers et les premiers adeptes, c’est la majorité des développeurs qui s’y intéresse.

Parti du développement, Scrum implique les gens des « métiers » et irrigue même au-delà de l’informatique :

  • On trouve des utilisations de Scrum pour le marketing ou pour le commerce.
  • Dans le domaine du numérique, des organisations complètes y passent.
  • Des expériences ont lieu pour développer du matériel (hardware) et des systèmes incluant matériel et logiciel.

Comme Scrum n’est pas lié à un domaine particulier, on se dit qu’il peut être utile pour développer des produits de tout type.

Le management agile

Le management est en plein changement ; les nouvelles approches [Denning, Radical Management] sont totalement en phase avec les principes de l’agilité. Les approches des « entreprises libérées » présentent aussi de nombreuses similitudes avec le mouvement agile

Cependant, toutes les initiatives se réclamant « management agile » ne sont pas issues du mouvement impulsé par le Manifeste, leurs points de convergence avec Scrum ne sont pas toujours évidents

Une définition de l’agilité

Jim Highsmith, un des signataires du Manifeste, définit l’agilité par rapport au changement :

« L’agilité est la capacité à favoriser le changement et à y répondre en vue de s’adapter au mieux à un environnement turbulent. »

Il me paraît intéressant d’ajouter une dimension vers le client final, l’utilisateur, celui qui est impacté par le résultat. Voici ma définition :

« L’agilité est la capacité d’une organisation à fournir tôt et souvent des services impactant ses utilisateurs, tout en s’adaptant à temps aux changements dans son environnement. »

La culture agile

Les valeurs et les principes de l’agilité peuvent présenter un caractère indéniablement subversif pour certaines organisations (mais on sait aussi que les valeurs sont assez vite récupérées). Il importe de tenir compte des aspects culturels dans la formation et la transition à Scrum : on ne change pas si facilement de culture. Au-delà des idées, l’agilité, en particulier avec Scrum, véhicule un vocabulaire nouveau. En quelque sorte, le vocabulaire contribue à renforcer l’idée du changement de culture.

Qu’est-ce que Scrumban ?

Scrum + Kanban = Scrumban, qui combine les meilleures caractéristiques des deux.

Elle a été initialement introduite comme un moyen de faire passer les équipes de l’une à l’autre, mais elle est depuis devenue une méthodologie à part entière.

Avec Scrumban, la planification des itérations de Scrum est combinée avec le système de traction de Kanban.

Elle utilise la structure d’itération de Scrum (bien qu’il s’agisse d’une version plus souple). Utilise le processus d’amélioration continue de Kanban.

Plutôt que d’organiser des réunions de révision quotidiennes et d’estimer l’étendue du travail pour chaque itération, les équipes doivent simplement s’assurer que le backlog est limité à une taille fixe qui peut être réduite à zéro avant le début de la prochaine étape de planification.

Un backlog est une liste qui classe par ordre de priorité toutes les fonctionnalités qui composent un produit ou un projet. Il comprend également des éléments tels que les corrections de bogues (dans le développement de logiciels) et les modifications de fonctionnalités.

La planification des itérations peut se faire à intervalles réguliers, mais contrairement à Scrum, ces intervalles peuvent être flexibles. L’objectif est de réaliser les tâches disponibles au fur et à mesure qu’elles sont prêtes, plutôt que de déterminer le nombre de tâches avant le début du travail. Cela permet de lisser le processus de charge de travail et de réduire le temps consacré à la planification des itérations, ce qui laisse plus de temps disponible pour le contrôle de la qualité.

Et si un travail est marqué comme « terminé », mais n’est pas de haute qualité, cette tâche unique peut être renvoyée à nouveau jusqu’à ce qu’elle soit prête. (Un diagramme de cause à effet peut s’avérer utile ici si les problèmes se répètent).

Quels sont les avantages de Scrumban ?

Une méthode de travail plus souple et « juste à temps » pour ceux qui utilisaient auparavant Scrum.
Plus de structure pour ceux qui utilisaient auparavant Kanban
Un délai d’exécution plus court
Une amélioration continue et une réduction des déchets
Moins de temps passé en réunions (pour ceux qui utilisaient auparavant Scrum)

Scrum vs Kanban vs Scrumban : laquelle utiliser ?

Comme toute méthodologie, Scrumban fonctionne mieux avec certains projets qu’avec d’autres.
Si vous travaillez dans une entreprise où les clients jouent un rôle dans le processus de développement et où les délais sont importants, alors Scrum est la méthode qu’il vous faut. Si vous travaillez principalement dans un environnement de maintenance, où les tâches sont continues et où le développement ne joue pas un rôle clé dans votre production, alors choisissez Kanban.

Pour ceux qui connaissent des changements de priorité fréquents, qui trouvent Scrum trop contraignant, qui veulent ajouter des fonctionnalités d’extraction ou qui ne parviennent pas à respecter les contraintes de temps en raison d’un manque de ressources, alors Scrumban est une bonne option.

Réflexions finales

Le choix de la méthodologie dépend en fin de compte du type de projet et de la façon dont votre équipe travaille. Quelle que soit la méthode que vous choisissez, il est important de suivre les meilleures pratiques pour avoir les meilleures chances de succès.

Une communication régulière entre les membres de l’équipe est essentielle à cet égard. Investir dans un outil de management de projet en ligne est une bonne option pour aider les équipes et les parties prenantes à collaborer, car les individus peuvent vérifier l’état d’avancement des projets où qu’ils soient. Les membres de l’équipe peuvent stocker toutes leurs notes en un seul endroit, tandis que les managers de projet peuvent configurer des notifications automatiques pour les informer de l’achèvement d’une tâche ou de son retard.

Backlog – notre propre outil de management de projet – peut être utilisé pour ces trois approches. Les fonctions de suivi des bogues et des problèmes facilitent le contrôle de la qualité et des améliorations, tandis que les diagrammes de Gantt, les diagrammes d’épuisement et les tableaux de style Kanban vous permettent de voir quelles tâches sont en cours et lesquelles ont été achevées. Il comprend également des fonctions de tâches conçues pour vous aider à créer, hiérarchiser et attribuer des tâches, ce qui rend l’ensemble du projet un peu plus collaboratif, que vous travailliez via Scrum, Kanban ou un mélange des deux.

Laisser un commentaire

Scrum ou Kanban : comment fonctionnent-ils ?

laghouati

Laghouati Mohame El Amine Ingénieur chargé de la communication