Scrum ou Kanban
Afin de pouvoir s’adapter à des marchés toujours plus concurrentiels et évolutifs, de plus en plus d’équipes de développement appliquent des méthodes Agiles pour la réalisation de logiciels. Nous allons nous intéresser particulièrement à deux d’entre elles : ‘Scrum’ et Kanban
Lors du démarrage d’un nouveau projet, les équipes se demandent souvent comment les mettre en œuvre : Scrum, Kanban ou un peu des deux (le ‘Scrumban’)
Dans cet article, je vais essayer de vous présenter les différences et dans quel cas les utiliser.
Commençons par quelques rappels :
Scrum (mêlée en français) est un cadre de travail décrivant une organisation d’équipe qui s’appuie sur le découpage d’un projet en ‘timebox’ nommé sprint. Scrum repose sur 3 piliers :
- la transparence : le fait d’avoir un langage commun au sein de l’équipe favorise les échanges et permet d’obtenir une meilleure visibilité sur le projet
- des points réguliers : ces points permettent d’assurer un suivi de l’état d’avancement du projet et de lever les éventuels obstacles rencontrés
- l’adaptation : si lors des points réguliers, des problèmes sont constatés, alors des modifications sur le projet peuvent être mises en place afin de ne pas bloquer celui-ci.
De plus Scrum prescrit un certain nombre de cérémonies et de rôles permettant d’organiser ces sprints.
Kanban (terme signifiant ‘panneau’ en japonnais) est moins normatif que Scrum car cette méthode est basée sur seulement deux principes fondamentaux :
- la visualisation : l’objectif principal du kanban est de pouvoir visualiser rapidement la totalité des tâches en cours et leur statut
- limiter les encours : en limitant le nombre de tâches de chaque colonne, nous nous obligeons à réduire une liste de tâches interminables en une liste de tâches plus courte et cohérente. Cette décomposition du travail en tâches réduites favorise leur accomplissement.
Ces deux méthodes appliquent la méthode “Kaizen” (fusion des deux mots japonais kai et zen signifiant “changement” et “meilleur”) invitant tous les membres de l’équipe à analyser et à contribuer à l’amélioration continue des processus de développement.
Quelles différences entre les deux :
- Kanban est plus souple que Scrum : en effet Scrum impose une organisation bien particulière ce qui n’est pas le cas de Kanban.
- Scrum limite les tâches par sprint alors que Kanban les limite dans le workflow (par état).
- Kanban n’impose pas de découpage du backlog par sprint contrairement à Scrum.
- Scrum mesure la vélocité par sprint alors que Kanban mesure le temps de cycle des tâches (temps moyen effectif pour traiter une demande). Cependant, certaines équipes conservent la mesure des demandes en vélocité afin de continuer à pouvoir estimer leur complexité.
Comment choisir ?
Le premier facteur à prendre en compte est le niveau de pratique des méthodes Agiles de l’équipe. Si vous démarrez dans une équipe habituée à un cycle en V, Scrum peut être une bonne approche pour débuter.
En effet, son caractère normatif permet une transition facilitée car encadrée par les sprints. Une répartition des rôles au sein de l’équipe ainsi que des cérémonies incitant à l’échange, à la transparence et à l’amélioration aide à la montée en compétence.
Le caractère ouvert de Kanban (les seules contraintes sont la visualisation et la limite des encours) peut être intimidant au départ car il implique une certaine auto-gestion de l’équipe. Mais comme Scrum, Kanban est empirique, par conséquent, une équipe qui adhère au principe de l’amélioration continue, arrivera à surmonter ces difficultés.
Pour les personnes rompues à l’agilité, le choix de Scrum ou Kanban dépendra plutôt des spécificités du projet.
Si votre cycle de livraison est supérieur ou égale à la durée d’un sprint alors Scrum est une bonne solution car elle vous permet de découper vos livrables en conséquence. Ainsi l’équipe apporte de la valeur au produit à chaque sprint. Cet élément est un grand facteur de motivation et de cohésion.
Pour un produit qui nécessite des livraisons sur un intervalle inférieur ou égale à la moitié de la durée d’un sprint (sprint inférieur à 3 semaines), Scrum peut être perçu comme un frein. Dans ce cas l’exécution du processus de livraison plusieurs fois durant le sprint ainsi que les cérémonies commencent à avoir un impact important sur la capacité de l’équipe à délivrer de la valeur au produit (l’automatisation et un ‘timeboxing’ rigoureux des cérémonies peut aussi aider à surmonter ces problématiques).
Dans ce cas, la souplesse de Kanban peut apporter beaucoup de fluidité et d’adaptabilité à l’équipe car il permet de lever la contrainte de temps induite par le sprint. Ici, la valeur peut être délivrée sans grande planification car la contrainte est appliquée au nombre de tâches en cours et non sur la durée d’un sprint.
Scrumban…
Beaucoup d’équipes matures ne font pas vraiment de choix et piochent les bonnes pratiques dans les deux méthodes. En effet, une équipe qui livre et déploie tous les jours ou à la demande peut utiliser Kanban pour visualiser les tâches en cours, leur état, ainsi qu’appliquer la contrainte sur leur nombre. Mais elle peut aussi appliquer les cérémonies de Scrum qui ont le mérite de favoriser les échanges et l’amélioration. Ainsi elle conserve les bonnes pratiques des deux en les adaptant à son environnement.
J’espère, à travers ce billet, avoir pu vous éclairer un peu sur ces deux pratiques qui ont le vent en poupe au sein des équipes de développements.
Dans un prochain article, je vous présenterai leur application au sein de l’équipe de développement Web du site ViaMichelin.
