Devenu ultra populaire, le Scrumban également appelé Agile kanban est une méthodologie agile qui permet de bénéficier :
- des itérations du Scrum
- du concept de flux tirés du kanban
Si cette dernière phrase n’est pas clair, pas de panique, je vais expliquer tout cela dans cet article dédié à scrumban.
Les origines du Scrumban
Le Scrumban avait initialement été créé en 2009 pour proposer une méthodologie de transition de Scrum vers Kanban et Lean comme je l’expliquais dans un précédent article.
Aujourd’hui, le Scrumban est devenu un framework agile à part entière ; il permet souvent d’aider les équipes à combler certains soucis rencontrés par les équipes Scrum. Et son adoption depuis quelques temps est assez fulgurante.
Itératif et incrémental
Le Scrumban bénéficie des piliers des méthodes agiles qui marquaient de grandes différences par rapport aux méthodes traditionnelles.
Comme le montre le schéma ci-dessous, quand nous imaginions un produit « A » en méthode traditionnelle (Cycle en V par exemple), nous attendions 6 mois après à voir le produit « A » livré. Cependant comme les utilisateurs clés n’étaient pas sollicités dans le courant du développement, ils n’étaient pas forcément content du résultat.
Il fallait potentiellement rajouter 6 mois de développement pour faire le produit « A+ » ; en effet, il était indispensable de rajouter du temps et du budget pour prendre en compte les feedbacks des utilisateurs qui voyaient le produit pour la première fois qu’au bout de 6 mois. Il fallait encore avoir la chance d’avoir le budget supplémentaire nécessaire pour entamer une nouvelle phase de développement.
En Scrum (et autres méthodes agiles), nous faisons des itérations courtes pour obtenir à la fin de chaque itération les feedback des utilisateurs clés ; nous nous retrouvons ainsi 6 mois après avec un produit « A' » qui diffère un peu du produit imaginé au lancement. Et ceci grâce à la prise en compte de ces feedbacks. Cette façon de faire plait réellement aux utilisateurs clés. Ce produit contiendra une partie du scope initial, de nouvelles évolutions non imaginées en début de projet et des parties non développées.
L’agile ne permet pas de développer plus mais permet de développer réellement ce qu’attend nos utilisateurs clés.
Scumban aussi adaptatif !
Le Scrumban bénéficie également d’un pilier essentiel de l’agilité : l’adaptation. Si nous pouvons parler d’adaptation du scope comme nous venons de le voir dans le point précédent, nous devons aussi rappeler que les méthodes agiles imposent cette notion « d’amélioration continue ».
Comme le montre l’image ci-dessous, l’équipe améliorera constamment son cadre et son fonctionnement en arrêtant les pratiques obsolètes et en testant de nouvelles pratiques.
Le Scrumban bénéficie des rôles et des cérémonies Scrum
Le Scrumban propose des itérations classiques venant tout droit du Scrum comme le présente le dessin ci-dessous afin de mettre en place ces concepts itératifs, incrémentals et adaptatifs.
Voici un article pour en savoir plus sur le scrum afin de bien comprendre ce que le Scrumban reprend du Scrum (cérémonies, rôles) :
Article : Le scrum : les premiers pas
En scrumban plus de flux poussé mais du flux tiré comme en kanban !
Contrairement à une application classique du Scrum, le Scrumban va rechercher à faire du flux tiré et non plus du flux poussé. Pour faire simple, les équipes ne prévoiront plus du travail pour un sprint complet mais prioriseront le travail au fur et à mesure.
Article : Comprenons la différence entre le flux poussé et le flux tiré
Cela change en effet la « Sprint Planning » qui deviendra plutôt une « sprint objective » ; le product owner proposera à l’équipe de développement les objectifs qu’il aimerait que cette équipe atteigne en fin de sprint. La notion de périmètre (contenu d’un sprint sous forme d’items) n’existe plus en scrumban.
Le product owner proposera alors une nouvelle user-story (ou nouvel item) aux développeurs quand ceux-ci en termineront une. Il proposera le travail au fur et à mesure du temps. Vous comprendrez ainsi que les développeurs feront ainsi le découpage des user-stories (ou autre items) au fur et à mesure du sprint.
Board kanban et indicateurs kanban en scrumban
En scrumban, nous allons utiliser les indicateurs kanban qui sont plus adaptés à un flux tiré. Nous utiliserons :
- le lead time
- le cycle time
- le diagramme de flux cumulé
Article : Allons plus loin avec les indicateurs kanban
Pour le board de l’équipe scrumban, l’équipe pourra profiter des boards kanban qui proposent de nombreuses notions de qualité. N’hésitez pas à lire l’article suivant pour en savoir plus :
Article : Faire son tableau kanban
Pourquoi faire du Scrumban ?
Le Scrumban permet de bénéficier du Scrum dans des contextes où nous ne pouvons pas vraiment prédire le travail sur les semaines à venir. Par exemple, nous pourrions parler d’équipe support, d’équipe de Data Scientists…
De plus en plus d’équipes viennent d’ailleurs à utiliser le Scrumban ; en .effet, elles aiment bénéficier des avantages des deux concepts. Si vous semblez avoir des difficultés pour stabiliser un sprint ou que les indicateurs kanban vous intéressent, testez le Scrumban.
Lien utile : Scrumban ceremonies (english)
Comment évaluer le Scrumban qui n’est ni du Scrum ni du Kanban ? qu’est ce qui arrive souvent comme pbs lorsque le scrumban est mis en place ?
Le scrumban est un scrum où l’on priorise en temps réel pour simplifier. On profite des cérémonies du scrum pour avoir de l’amélioration continue, pour avoir des review régulières… Cependant on profite du flux tiré du Kanban.
Les problèmes que j’ai pu voir pour ma part est cette notion de priorisation en temps réelle où les équipes en oublie des roadmap estimatives sur le temps ; cela pose souvent souvent au management qui a besoin d’avoir une vision un peu plus générale. Cependant le scrumban est souvent mis en place pour faire suite à un scrum donc amène des réponses à des problématiques de priorisation sur deux semaines. Donc il est plutôt bien apprécié lors de sa mise en place car il vient amélioration la situation.