Dans le domaine de la gestion de projet, l’agilité a largement pris le dessus sur les méthodes plus classiques dites ‘cycle en V’ avec des apports indéniables et visibles par toutes les parties prenantes.
En cycle en V, la livraison du produit s’effectue lorsque toutes les fonctionnalités sont développées avec, bien souvent, un produit final qui, soit ne correspond pas totalement au produit imaginé, soit n’est plus aligné sur les besoins qui ont évolué entre le lancement du projet et la fin de celui-ci. En gestion agile, les besoins sont priorisés, puis développés et testés sans attendre le développement complet de la fonctionnalité, avec les réajustements nécessaires en fonction des feed-backs client et l’ajustement aux évolutions de l’activité.
Plus qu’une méthodologie de gestion de projet, l’agilité est un état d’esprit à adopter avec, pour principal objectif d’optimiser l’alignement des équipes et d’éviter l’effet tunnel. Il a aussi un effet motivateur en engageant les développeurs et les responsables de produits sur des objectifs communs.
Il n’y a pas qu’une manière de mettre en œuvre l’agilité, les deux approches agiles les plus répandues sont Scrum et Kanban.
Scrum
Le terme apparait pour la 1ère fois en 1986 pour décrire une approche plus flexible de développement de produits en référence à la mêlée du Rugby et ait devenu la référence lorsque l’on parle d’agilité. Pour autant, il s’agit plus d’un cadre qui favorise l’agilité qu’une méthode à proprement parler.
L’idée est de former des petites équipes par projet rassemblant toutes les compétences afin d’assurer
- La qualité des livrables : gestion de projet réactive, livraisons régulières et volonté d’amélioration continue
- La pertinence des livrables : implication de toutes les parties prenantes pour garantir un produit au plus proche des besoins
En s’appuyant sur Scrum et ses cérémoniaux, l’équipe de développement découpe son projet en tâches atteignables, réduit la complexité et rythme les itérations. Plus agile, l’équipe peut réagir et répondre rapidement aux imprévus.
Très axé sur le calendrier, Scrum rythme les développements avec à la clé vélocité et amélioration continue.
Avantage
Très structurée c’est un excellent moyen de mettre en pratique de l’agilité auprès d’équipes novices
Inconvénient
Un changement de périmètre ne peut se faire, à priori, qu’une fois un sprint terminé.
Kanban
La méthode Kanban a été inventée par l’ingénieur japonais à qui l’on doit également le système de production de Toyota : méthode de gestion des stocks dite « à flux tendu » permettant de minimiser les stocks, et donc de diminuer les coûts et le gaspillage. C’est le besoin qui dicte la production. Zéro déchet, zéro stock.
Appliquée à la gestion de projet, en diminuant le nombre de kanbans en circulation, on diminue l’en-cours, on augmente la concentration des équipes, donc la qualité du livrable, mais on livre également plus rapidement et plus régulièrement.
L’objectif principal de la mise en œuvre de Kanban est d’identifier les goulots d’étranglement potentiels dans le processus et de les corriger.
Kanban propose un processus à suivre :
- Visualiser le travail grâce à un modèle visuel et déplacement des tâches dans les colonnes du tableau au fur et à mesure de leur avancement
- Limiter le travail en cours et réduire le temps entre le début et la fin d’une tâche
- Se concentrer sur le flux pour améliorer la fluidité du travail
- S’améliorer en continu et aider l’équipe à prendre conscience de son efficacité en analysant le flux de suivi des tâches
Avantage
Méthode très simple à mettre en place
Inconvénient
Reste une méthode très sommaire, il peut s’avérer utile de la mixer avec d’autres méthodes pour permettre une plus grande agilité encore.
Qu’est-ce que Scrum et Kanban ont en commun ?
- L’amélioration continue
- Découpage des demandes complexes en tâches simples matérialisées visuellement sur un tableau pour fluidifier les flux dans le processus
Quelles sont leurs principales différences ?
Le rythme
Scrum est plus rythmé que Kanban : le rythme du sprint doit être constant et soutenable par tous les intervenants du projet et doit permettre de livrer les tâches sélectionnées par l’équipe lors du sprint planning, en fonction de l’estimation de leur complexité, les estimations s’affinent itération après itération. Ce n’est que lorsque le sprint est terminé que les nouvelles tâches peuvent être intégrées dans le nouveau sprint.
Kanban en revanche n’inclut pas de période délimitée dans le temps. Tout est en flux continu : la production, l’amélioration continue, la priorisation des nouvelles demandes. Nul besoin d’attendre la fin d’un Sprint pour prioriser un nouveau sujet, de nouvelles tâches peuvent être ajoutées en permanence.
Les outils visuels
La différence de cadence entre Scrum et Kanban est visible sur les tableaux respectifs : pour Scrum, le flux de travail est entièrement décrit, depuis l’étape « À faire » jusqu’à celle du « Réalisé », pour toutes les tâches réalisées en fin de Sprint. Les tâches restantes seront reportées sur le Sprint d’après, ainsi que les nouvelles demandes.
Le tableau de Kanban comporte également des colonnes, mais chacune a une limite stricte de tâches qu’elle peut accueillir. L’en-cours plus faible permet de répondre au besoin en temps réel. Chaque tâche suit son cours et les nouvelles demandes sont ajoutées au fil de l’eau.
Les rôles
Dans Scrum, il y a un ensemble de rôles à implémenter
- Le product owner est en charge du backlog
- Le scrum master est facilitateur et garant de la durée des cérémonies
- Les développeurs traitent le travail convenu et planifié lors du sprint
Kanban permet de conserver la même structure. Le responsable d’équipe est chargé de veiller à ce que le flux soit en continu et qu’il n’y ait pas d’embouteillages parmi les tâches
L’important est d’identifier toutes les tâches, de les hiérarchiser et de les estimer selon la valeur qu’elles apportent au produit.
Les équipes
Scrum : Un backlog de sprint n’appartient qu’à une seule équipe à la fois. Scrum encourage les équipes multifonctionnelles. Chaque équipe possède toutes les compétences nécessaires pour réussir toutes les tâches pendant le sprint.
Kanban : En comparaison, les tableaux Kanban peuvent être partagés par plusieurs équipes. Chacun est dédié à ses propres tâches.
Quand utiliser Kanban plutôt que Scrum ? Retour d’expérience
Mieux visualiser l’ensemble des sujets ouverts, se focaliser sur moins de sujets à plus forte valeur ajoutée
Comme le souligne Maxime, Ingénieur R&D de la filiale SoftFluent Software et de RowShare
Avec Scrum, on avait un peu de mal à faire ça car le « backlog », la liste de tous les trucs à faire, est un peu laissé de côté. A chaque sprint planning, s’il y a un sujet un peu chaud qu’on veut à tout prix traiter, on l’ajoute au contenu du sprint, et les tâches restantes de certains sujets démarrés lors du sprint précédent sont remises dans le backlog, pour plus tard. Avec Kanban, comme il n’y a plus de sprint, on utilise à la place directement le backlog, qui doit être tout le temps priorisé. Donc quand on décide de passer un sujet « chaud » en haut des priorités, on voit automatiquement ce qui est dépriorisé, et si on dépriorise plusieurs fois la même chose, on s’en rend compte. Et comme on utilise dans ce cas la grille Kanban qui organise les tâches dans des colonnes en fonction de leur état, on peut avoir l’information visuellement quand une tâche est restée ‘in progress’ trop longtemps.
Apporter de la souplesse : moins souffrir de l’impact d’un imprévu à traiter en urgence qui fait perdre du sens au rythme du sprint et démotive ou à l’inverse éprouver une frustration à devoir attendre la fin d’un sprint pour démarrer un développement urgent, comme l’exprime Maxime.
Avec Kanban, comme il n’y a plus de deadlines toutes les deux semaines, on peut traiter des sujets urgents presque immédiatement si l’exercice de priorisation les a mis en tête, et ça, sans avoir l’impression d’avoir « raté » notre sprint.
Lorsque la roadmap est plutôt moyen-long terme et que la majorité des sujets dépasse la durée d’un sprint
Selon Maxime,
Kanban permet aussi sur ces sujets plus longs de décider quoi faire quand une tâche nous prend plus de temps que prévu : on sait à chaque instant toutes les tâches qui sont prévues pour la suite, et donc on peut reprioriser l’élément difficile.
Soit il est essentiel est on continue dessus, mais en ayant une vision claire des autres points qui seront retardés, soit son coût le rend moins prioritaire que d’autres sujets et en le redescendant dans la liste des priorités, on sait approximativement à quel moment on pourra recommencer à travailler dessus.
Une autre alternative est de faire du SCRUMBAN, c’est-à-dire de combiner le meilleur des deux approches.
Scrumban
Le ScrumBan regroupe les avantages de l’approche Scrum et Kanban, il est structuré comme peut l’être la méthode Scrum avec des itérations de développement et permet de gérer des projets en flux continu et de prioriser des tâches grâce à l’approche Kanban.
La méthode s’appuie également sur une planification basée sur la demande, les équipes ne prévoient plus des tâches pour un sprint complet mais doivent désormais les prioriser au fur et à mesure de l’avancement du projet.
Quelle méthode choisir ?
La méthode agile que vous choisirez doit répondre aux besoins de l’équipe en charge de développement du projet en fonction des critères suivants :
- La disponibilité du client ou de l’utilisateur
- Les fonctionnalités du produit
- Le besoin du client
- Le calendrier de développement du produit
- L’expérience de l’équipe dans les projets agiles
- La taille de l’équipe
Dans tous les cas, aucune méthode n’est par nature meilleure qu’une autre. Les valeurs et les principes énoncés dans le manifeste agile sont bien plus essentiels que l’application plus ou moins stricte de telle ou telle méthodologie.
A lire également, l’agilité à l’échelle et SAFe
