Scrum et Kanban sont des cadres de travail déployés très largement dans les entreprises même s’ils montrent certaines limites.
Par exemple, les itérations figées de Scrum peuvent sembler contraignantes. À l’inverse, Kanban est parfois considéré comme un cadre trop léger.
Scrumban est la contraction de Scrum et de Kanban. Il s’agit d’une approche hybride qui répond aux limites de Scrum et de Kanban.
l est donc important de maîtriser Scrumban pour le proposer à vos équipes afin d’améliorer leurs performances.
Dans un premier temps, nous analyserons les différences fondamentales entre Scrum et Kanban.
Ensuite, nous exposerons les limites de Scrum et de Kanban avant d’aborder les 5 éléments clefs qui vont vous permettre de maîtriser Scrumban.
Différences entre Scrum et Kanban
Avant de découvrir Scrumban, il est important de bien comprendre les différences entre Scrum et Kanban :
Scrum | Kanban |
|---|---|
Les itérations sont à durée fixe (2 à 3 semaines en général) | Pas d’itérations |
Événements imposés | Pas d’événements imposés |
L’engagement porte sur un périmètre pour une itération | L’engagement porte sur le temps de cycle (temps de traversée moyen des éléments dans le kanban) |
Utilisation de la vélocité constatée sur les itérations précédentes pour planifier | Utilisation du temps de cycle constaté pour planifier |
Équipe pluridisciplinaire | Équipe de spécialistes autorisée |
Les éléments du backlog sont taillés pour être faisables dans une itération | Aucune taille n’est imposée, mais Kanban préconise des éléments petits et de même taille. |
Mesure de l’avancement grâce au burndown chart (reste à faire en points de complexité en fonction du temps) | Mesure de l’avancement grâce au diagramme de flux cumulé (nombre d’éléments dans chaque colonne du kanban en fonction du temps) |
Limitation du travail à faire par itération | Limitation du travail à faire par étape du workflow. Le travail en cours est limité pour garantir un flux tiré. |
Estimation imposée. Les estimations se font en points de complexité. | Estimation optionnelle. Kanban préfère se baser sur le nombre d’éléments. |
Pas de nouveaux éléments embarqués en cours d’itération | Possibilité d’ajouter des nouveaux éléments n’importe quand à condition que la capacité le permette |
3 rôles (Product Owner, Scrum Master, Dev) | Aucun rôle imposé |
Le tableau Scrum est réinitialisé à chaque début d’itération | Le tableau Kanban est persistant |
En savoir plus sur la différence entre les frameworks Scrum et Kanban.
L’approche Scrum est particulièrement bien adaptée au mode « build », autrement dit lorsque l’équipe a des priorités claires et une bonne visibilité sur les travaux à faire pour l’itération à venir (2 à 3 semaines).
L’approche Kanban est efficace pour le mode « run », car elle permet de gérer des changements rapides et non prévus associés à un produit déjà déployé en production.
Nous conseillons aux équipes d’adopter le mode « build & run », car nous pensons que ceux qui construisent les applications doivent aussi être responsables de les maintenir.
Pour cela, une capacité à faire est dédiée au « build », en mode Scrum et une capacité à faire est dédiée au « run », en mode Kanban.
Autrement dit, il est tout à fait possible de mixer les deux approches.
Pourquoi Scrumban ?
Scrumban a été créé par Corey Ladas, un passionné de méthodologie de développement de logiciels, pour faciliter le passage de Scrum vers Kanban ou de Kanban vers Scrum.
La cadre Scrumban tente également de répondre aux limites observées de Scrum et Kanban, que nous allons détailler maintenant.
1) Limites de Scrum
Voici quelques limites observées sur le terrain avec la méthode Scrum :
- Les équipes considèrent qu’aucun changement de périmètre n’est permis pendant l’itération, ce qui nécessite d’attendre l’itération suivante pour embarquer une nouvelle fonctionnalité. Mais en théorie, Scrum autorise les changements en cours d’itération à condition de ne pas dénaturer l’objectif de sprint. Cette première limite est donc plutôt une limite que s’imposent elles-mêmes les équipes, faute d’une bonne connaissance de Scrum.
- Le cadre Scrum a été pensé pour une équipe d’une dizaine de personnes. Au-delà, il est très difficile de garantir l’efficacité des événements agiles.
- Pour définir le périmètre à embarquer dans une itération, les équipes Scrum estiment la complexité du travail à faire. Cet exercice est toujours périlleux, particulièrement pour les équipes composées de membres peu expérimentés ou qui subissent un turn-over important.
Scrum fonctionne mieux lorsque l’équipe est auto-dirigée et auto-organisée, mais dans les faits, le management est souvent contrôlant et intrusif.
2) Limites de Kanban
Voici quelques limites observées sur le terrain avec la méthode Kanban :
- Un manque de rigueur est souvent constaté dans la mise à jour du tableau Kanban, particulièrement chez les équipes qui ne pratiquent pas de réunions quotidiennes.
- Le tableau Kanban peut vite devenir ingérable lorsqu’il contient trop d’éléments. Limiter le nombre d’éléments dans les colonnes en cours permet d’accélérer le flux de travail à condition que les limites soient suffisamment basses pour être efficaces.
- Trop d’éléments sans échéances rendent difficile la priorisation.
- Un manque de visibilité sur les travaux à venir peut conduire à des mauvais choix de conceptions ou d’implémentations.
- Une disparité dans la taille des éléments a pour conséquence un manque de prédictibilité.
Si votre équipe fait face à plusieurs de ces limites Scrum ou Kanban, il est peut-être temps d’essayer Scrumban !
Découvrons ensemble quelles sont ses caractéristiques.
Qu’est-ce que Scrumban ?
Tout d’abord, sachez qu’une confusion est très souvent faite concernant Scrumban.
Beaucoup considèrent que Scrumban est avant tout du Scrum auquel des pratiques Kanban ont été ajoutées, notamment des limites sur les travaux en cours.
En réalité, c’est l’inverse !
Scrumban est avant tout du Kanban auquel des pratiques Scrum ont été ajoutées !
Sachez également que la communauté agile est très divisée sur Scrumban.
Soit une équipe est en Scrum et embarque également des pratiques Kanban, soit elle est en Kanban et embarque également des pratiques Scrum.
Mais il n’est sans doute pas nécessaire d’ajouter au vocabulaire agile ce terme « Scrumban » qui finalement apporte de la confusion.
Quoi qu’il en soit, l’intention de Scrumban est de proposer un cadre flexible au service de la performance des équipes.
Les 5 éléments issus de Scrum et ajoutés à Kanban sont clefs pour bien maîtriser Scrumban :
- Rôles Scrum optionnels
- Planification à la demande
- Réunions quotidiennes
- Démonstration à la demande optionnelle
- Rétrospectives régulières
1) Rôles Scrum optionnels
Scrumban n’impose aucun rôle, mais par expérience, il est préférable d’installer un rôle de Scrum Master et un rôle de Product Owner, particulièrement si votre équipe débute en agilité.
Votre Scrum Master aura pour mission de former votre équipe au cadre Scrumban, animer les évènements agiles et s’assurer que le cadre Scrumban est respecté et compris par tous.
Scrumban nécessite de maintenir à jour un Product Backlog pour alimenter l’équipe lors des planifications à la demande.
Le rôle de Product Owner est donc très important pour prioriser le backlog en permanence et avoir suffisamment d’éléments prêts pour la prochaine planification.
Sans Product Owner, vous devrez à minima trouver une personne capable de trancher, de rédiger les User Story et de les prioriser.
Pour clarifier vos rôles, vous pouvez utiliser la technique du Delegation Poker.
N’oubliez pas que le manque de définition des rôles est une erreur fréquente de la phase préparatoire d’un projet agile.
2) Planification à la demande
La planification à la demande est déclenchée par un événement défini par l’équipe. Cela fait partie de son mode de fonctionnement.
Par exemple, une planification peut être déclenchée lorsqu’il reste moins de 2 stories à faire.
Pour limiter les travaux en cours, nous avons l’habitude de fixer une limite maximale de User Story pour une colonne donnée.
Ici, il s’agit plutôt de fixer une limite minimale sur la colonne « À FAIRE » pour que l’équipe soit toujours alimentée correctement.
Les limites hautes et basses font référence à un nombre de User Story et non à des points de complexité.
Par conséquent, pour que ces limites aient un sens, nous vous conseillons d’avoir des User Story de même taille.
Dans l’exemple ci-dessus, un développeur tire la User Story #5 dans la colonne « DEV EN COURS ».
Il libère une place dans la colonne « À FAIRE », si bien que le nombre de User Story restantes dans la colonne passe sous le seuil de la limite minimale définie à 2.
Une planification à la demande est donc déclenchée. Elle permet de donner de la visibilité à l’équipe sur les travaux à venir et évite que l’équipe se retrouve sans travail à faire.
Lors de la planification à la demande, le Product Owner présente les User Story les plus prioritaires de son backlog.
L’équipe charge la colonne à faire avec des User Story prêtes jusqu’à atteindre la taille maximale, fixée à 4 dans notre exemple.
Pour cela, vous pouvez utiliser des techniques de découpage.
3) Réunions quotidiennes
En tant que Scrum Master, vous savez que visualiser et limiter le travail en cours est la clef pour établir un flux tiré et accélérer le flux de travail.
Pour maintenir une attention constante de votre équipe sur son flux de travail, vous animez des réunions quotidiennes de 15 minutes maximum.
Plutôt que de demander à chacun ce qu’il a fait la veille, ce qu’il va faire aujourd’hui et quels sont les obstacles qu’il rencontre, vous mettez le focus sur l’avancement des travaux.
Vous remontez le flux des User Story de la droite vers la gauche en interrogeant chaque porteur sur les obstacles qu’il rencontre et ce qu’il reste à faire pour faire avancer le sujet.
Garant du flux, vous limitez le nombre maximal de User Story en cours afin d’établir un flux tiré plutôt qu’un flux poussé.
Par conséquent, vous encouragez les membres de votre équipe à s’entraider pour terminer des User Story avant d’en commencer des nouvelles.
Vous favorisez ainsi le travail collaboratif et renforcez l’esprit d’équipe.
Dans l’exemple ci-dessus, pour faire un état des lieux des User Story des colonnes en cours en commençant par la droite du tableau, le parcours logique est #3 puis #4 puis #5.
La réunion quotidienne est aussi le bon moment pour :
- détecter les éventuels goulets d’étranglements
- décider s’il faut déclencher une planification à la demande
- décider s’il faut déclencher une démonstration à la demande
Puisque Scrumban est avant tout du Kanban, le temps de cycle moyen des User Story est calculé fréquemment pour permettre à l’équipe d’être prédictive sur son delivery.
4) Démonstration à la demande optionnelle
À l’instar de la planification à la demande qui permet de faire entrer de nouveaux éléments, la démonstration à la demande permet de valider des éléments du tableau Kanban.
La démonstration à la demande est déclenchée par un événement à définir par l’équipe.
Par exemple, une démonstration peut être déclenchée lorsque 4 stories sont à démontrer.
Dans l’exemple ci-dessus, 4 User Story sont présentes dans la colonne « À DÉMONTRER ».
Par conséquent, une démonstration à la demande est déclenchée.
Votre Product Owner doit être suffisamment disponible et réactif pour assister aux démonstrations à la demande afin qu’il ne devienne pas un goulot d’étranglement.
Dans l’exemple ci-dessus, le Product Owner a accepté les 4 User Story qui ont été présentées en démonstration. Elles sont donc considérées comme terminées.
L’équipe va maintenant mettre le focus sur les User Story #5, #6, #7 et #8.
Pour améliorer votre flux de travail, l’idéal est de démontrer au fil de l’eau. Cela signifie qu’une User Story est démontrée dès qu’elle arrive dans la colonne « À DÉMONTRER ».
En démontrant au plus tôt, l’équipe reçoit du feedback au plus tôt et peut corriger le cas échéant au plus tôt, ce qui permet de limiter les coûts de correction.
Au final, la démonstration à la demande est une pratique qui pallie au manque de disponibilité du Product Owner. Elle reste optionnelle.
5) Rétrospectives régulières
Nous vous conseillons d’effectuer une rétrospective régulière une fois par mois au minimum.
Elle sert plusieurs objectifs :
- Faire un point sur l’état d’avancement des axes d’améliorations de la rétrospective précédente
- Questionner l’évènement déclencheur de la planification à la demande
- Avoir un regard objectif sur la qualité et la taille des User Story qui entrent dans le système
- Questionner les limites hautes et basses sur le travail en cours
- Mesurer la prédictibilité de l’équipe et trouver des leviers pour améliorer le flux de travail
- Analyser les métriques de qualité de code et de dette technique
- Questionner l’évènement déclencheur de la démonstration à la demande
Contentez-vous de quelques axes d’améliorations que votre équipe s’engage à traiter dans le mois à venir, plutôt que d’en avoir beaucoup et de n’en traiter aucun.
Conclusion
Scrumban tente de répondre aux limites observées dans Scrum et Kanban en proposant une approche hybride qui rassemble le meilleur des deux mondes.
La planification à la demande permet d’alimenter votre équipe juste à temps avec des éléments prioritaires les plus à jour possibles.
La démonstration à la demande permet de capter du feedback au plus tôt pour rectifier le tir au plus tôt si besoin.
Au final, la planification et la démonstration à la demande libèrent les équipes des itérations figées proposées par Scrum et apportent davantage de souplesse pour améliorer la performance de vos équipes.
