Cet article est le deuxième de la série présentant une façon de passer de Scrum à Scrumban ainsi que ses avantages. Dans le précédent article, vous avez adapté le management visuel, celui-ci concerne la notion de flux en Scrumban.

La logique d’itération en scrum

Un objectif d’itération “figé”

Une des règles les plus importantes dans Scrum est de bloquer le périmètre de l’itération après le rituel du Sprint Planning.

Le premier jour de l’itération, on remplit les US du Sprint dans la colonne “à faire”.

Et l’objectif sur la période de l’itération est de passer l’ensemble du périmètre au statut “Terminé”. En fin d’itération, le board idéal ressemble à ça :

Le périmètre est “figé”, c’est-à-dire que l’équipe décide de refuser en cours d’itération toute US non prévue. La règle est de re-prioriser les nouvelles demandes dans des sprints ultérieurs.

Cette pratique a la vertu de protéger l’équipe des perturbations extérieures.

De façon générale, la méthode Scrum pousse à garder le focus de l’équipe sur l’engagement défini en début d’itération et l’aide donc à ne pas s’éparpiller. Le management visuel doit rendre visible les activités de l’équipe en cours de sprint, et tout travail non prévu est considéré comme “pirate”.

Les douleurs

La “course” à l’objectif

Le focus sur le périmètre de l’itération permet d’agir efficacement sans se disperser. En revanche, l’engagement peut inciter les équipes à cristalliser les objectifs de l’itération et à oublier le projet sur son long terme.

Cette tendance s’observe lorsqu’on entend par exemple : “on doit finir la fonctionnalité x pour la démo”.

A l’approche du moment de la démo, l’équipe de développement est concentrée sur “finir le sprint”. On retrouve par ailleurs, le phénomène de “course aux points” où l’équipe se focalise sur un nombre de points d’effort à terminer d’ici la fin de l’itération.

Des biais découlent souvent de ces tendances : il arrive que l’équipe décide de privilégier le court terme sur le long terme et livrer les fonctionnalités “promises” - ou le nombre de “points” prévus - en rognant sur la qualité. Cela peut se traduire par mettre de coté des tests unitaires qui prennent du temps à écrire ou par laisser passer certaines anomalies qui ne se verront pas lors de la démo. Cela peut engendrer aussi de la dette technique qu’il faudra rattraper dans les itérations suivantes ou la payer plus tard dans le projet

Il arrive également de voir l’équipe gonfler l’estimation des tâches qu’elle doit réaliser. C’est une façon de se rassurer en prévoyant de la “marge”. Gonfler les estimations permet en effet de se dire “chouette, on a fait x points sur ce sprint”, mais comme cette hausse est artificielle, elle se traduit aussi par une hausse du périmètre à réaliser. On mesure donc qu’on est allés plus vite, mais comme c’est sur un volume artificiellement plus élevé de choses à faire, ça ne change pas la date de fin. C’est donc un choix qui permet de se donner bonne conscience mais qui n’a pas d’effet réel. Il peut même avoir des conséquences néfastes car il biaise l'échelle d'estimation de l'équipe dont la stabilité conditionne sa capacité à prévoir dans la durée.

Ces travers se produisent parce que l’équipe est “pressée” par un objectif qu’elle s’est elle-même fixée. Ne pas montrer ce qu’on avait prévu en démo ou ne pas réussir à terminer suffisamment de points est par ailleurs perçu comme un échec par l’équipe.

À contrario, il arrive que l’équipe ait terminé ses tâches plus tôt que prévu. Elle pourrait aussi tomber dans un autre biais en se servant des indicateurs d’avancement du sprint pour se dire “j’ai le temps” et baisser de rythme.

Comme rien n’est ajouté en cours de sprint, on peut voir un effet de “relâchement” dû à la pénurie de tâches au statut “à faire”.

Il peut aussi arriver de voir l’équipe hésiter à commencer de nouvelles US à l’approche de la fin du sprint car, comme on sait qu’on ne la finira pas, elle ne sera pas intégrée dans les “points de vélocité” de l’itération en cours.

Tout ceci se produit lorsqu’on privilégie ce qui est “visible” à l’extérieur de l’équipe. Mais ces “choix” se font au détriment à long terme de son efficacité et du niveau de qualité qu’elle cherche à maintenir.

L’engagement d’itération, la transparence sur le travail en cours et les indicateurs de mesure servent en premier lieu à l’équipe pour s’organiser efficacement - en détectant au plus tôt si quelque chose ne va pas pour pouvoir prendre des décisions au moment où celles-ci ont encore un effet. Lorsque ces outils deviennent un facteur de pression - mis à soi-même ou par les autres - ils desservent les intérêts de l’équipe.

Le manque de souplesse

Dans la “vraie vie”, il arrive souvent d’avoir des imprévus pendant le sprint (nouvelle dépendance, blocage, incertitude fonctionnelle, incidents prioritaires en production, indisponibilité des environnements de recettes,...), et l’équipe a besoin de souplesse pour s’adapter pendant le sprint et se permettre dans certains cas de redécouper, re-prioriser ou rechallenger des US.

Et la plupart du temps, en Scrum, on se l’interdit parce que le sprint est figé.

Un rythme saccadé

Le plat de début de sprint

Une autre composante importante dans le scrum, c’est la notion de rythme d’itération.

L’outil de burndown permet de suivre l’évolution de la vélocité de l’équipe (nombre de points d’effort terminés) pendant le sprint.

Voici un exemple de burndown en début de sprint :

L’équipe s’est donné un “objectif” de 40 points. Il y a 10 jours ouvrés dans un sprint; logiquement, l’équipe sait qu’elle doit valider environ 4 points par jour pour finir convenablement le sprint.

Et en fin d’itération, on obtient souvent quelque chose comme ça :

Ici, on constate qu’il y a un “plat” sur les trois premiers jours. La cause vient de la méthode qui implique que suite au sprint planning, au premier jour du sprint, tous les développeurs commencent en même temps leur US. Et les premiers “points” commencent à tomber au bout de quelques jours.

L’équipe voit qu’elle doit maintenant faire plutôt 7 points par jour et donc qu’elle est obligée d’accélérer. Cette situation - provoquée par la nature du rythme itératif - amplifie le phénomène de “course aux points”.

La pioche

Au final, avec la logique d’objectifs de sprint et de rythme saccadé, l’équipe finit la plupart du temps soit “trop vite” soit “pas assez vite”. Une des façons de remédier à ça est de tordre un peu le principe du sprint figé en imaginant un système de pioche. L’équipe prévoit quelques US supplémentaires dans un espace en dessous du backlog d’itération dans lequel elle peut “piocher” lorsque toutes les US du sprint ont été commencées.

Et en Scrumban ?

De l’itération à la logique de flux

L’idée derrière le Scrumban est de garder la plupart des principes de Scrum mais en adoptant la logique de flux que préconise la méthode Kanban. Cela permet de répondre aux douleurs que nous venons de décrire.

Dans une approche par  flux, on peut imaginer le board comme un tuyau, et les tickets y transitent dedans comme de l’eau.

Dans une logique Scrum pure, le tuyau est rempli en début de sprint et vidé en fin de sprint, ce qui crée ce rythme saccadé.

En Scrumban, on va fluidifier ce rythme en ajoutant dans la colonne “À faire” du sprint quelques nouvelles US chaque fois qu’elle se vide. Cela a plusieurs effets :

En créant dans le tuyau une “pression d'entrée” constante, on n’a jamais de situation de pénurie. Tout le monde a toujours quelque chose à faire, et l’ensemble de l’équipe est calée sur un rythme de développement quotidien. A l’inverse, le fonctionnement itératif et les accélérations momentanées induisent des à coups - à l’instar du "coup de bélier" dans une tuyauterie - rendant difficile la création d’un rythme fluide.

Garder toujours quelques US au statut “À faire” et les rendre visibles a aussi une autre vertu : les développeurs peuvent trouver des optimisations en re-priorisant finement l’ordre des tickets. Un développeur peut prendre par exemple l’initiative de “choisir” plusieurs tickets qui ont plus de sens d’être traités par la même personne.

Par ailleurs, en fin de sprint, il reste toujours un en-cours d’US non terminées. On évite donc l'effet "plat de début de sprint" sur l’itération suivante, car des US se finissent dès les premiers jours.

En fin de sprint, on se retrouve donc avec un board de ce genre là :

On voit qu’un certain nombre d’US ont été ajoutées pendant le sprint, et certaines d’entre elles ont été commencées. On constate aussi que le sprint se termine avec un en-cours, il démarre donc avec un “tuyau plein”.

On peut voir un exemple de répartition dans le temps avec ce burndown chart :

On observe qu’il y a tous les jours au moins quelques US au statut “À faire”. La colonne a été réalimentée au fur et à mesure qu’elle se vidait (à partir du jour 5).

Le “plat” de début de sprint a aussi disparu. Comme il y avait un en-cours au sprint précédent (visible par les deux parties jaunes de l’histogramme), les premiers “points” ont mis peu de temps à tomber. On s’aperçoit d’ailleurs que le “tuyau est plein” presque tous les jours.

Ce diagramme est un peu plus élaboré que les burndown charts classiques (représenté ici par la courbe rouge et les pointillés gris). Nous avons ajouté l’équivalent d’un CFD (“cumulative flow diagram” utilisé dans la méthode Kanban pour visualiser l’évolution du flux) sur la période de l’itération. Il est important de noter que, traditionnellement, l’échelle utilisée en CFD est le “nombre de tickets”, tandis qu’ici on utilise les “points de vélocité” pour pouvoir le superposer au “burndown chart”.

Le CFD est particulièrement utile dans une approche Scrumban car le pilotage du flux est l’apport majeur vis à vis de Scrum.

Du coup, on supprime les sprints ?

Rythmer le temps en sprints offre beaucoup d’avantages, qu’on choisira en Scrumban de conserver.

Définir des périodes récurrentes est très utile pour cadencer les rituels et synchroniser les différents acteurs sur un rythme commun en prévoyant des “rendez-vous” réguliers. La démonstration reste particulièrement utile pour recueillir le feedback des personnes extérieures de l’équipe.

Mais ce rythme ne devient plus une raison de se forcer à créer des accélérations momentanées ayant pour seul objectif : avoir toutes les fonctionnalités “promises” visibles lors de la démonstration. En scrumban, l’équipe décide d’employer ce rituel comme un rendez-vous pendant lequel elle montre ce qu’elle a terminé pendant la période, et c’est tout.

De même, la vélocité n’est plus utilisée comme un “objectif” mais comme une “mesure” prise sur un intervalle d’un sprint des US qui passent l’état “À démontrer”. Cette mesure nous permet - comme toutes les autres mesures qu’on prend en agile - de voir si quelque chose se passe bien ou mal au cours du projet et servir de base factuelle pour trouver des améliorations éventuelles.

L’approche Scrumban pose également un autre changement : le passage à une logique de flux modifie fondamentalement le rythme de travail du PO qui est obligé d’alimenter le sprint en US au même rythme que le développement.

Et le “Sprint Planning” alors ?

Une des douleurs qu’on a en scrum est la durée du Sprint planning, et son intérêt pour l’équipe. Surtout s’il s’agit d’un découpage à la tâche près, cela peut rendre ces réunions parfois très longues pour présenter et discuter du périmètre fonctionnel de tout un sprint.

Nous attachons toutefois de l’intérêt à échanger sur les US, aligner l'équipe et surtout challenger les fonctionnalités si nécessaire. Libérer la parole de chacun permet d’impliquer, de motiver, fédérer toute l’équipe sur ce même sujet et indirectement améliorer la qualité du produit.

En Scrumban, on va choisir de garder les avantages du sprint planning, sans en avoir les inconvénients. Dans une logique de flux, comme on réalimente la colonne “À faire” régulièrement, il n’y pas de sprint planning à chaque début d’itération. L’équipe organise régulièrement et fréquemment (par exemple, autour de 3 fois par semaine selon le rythme, ou alors au fur et à mesure que les US sont prises en compte par les développeurs) des “ateliers de présentation” des US qui sont des “mini sprint-plannings” et qui du coup durent beaucoup moins longtemps. Cela offre l’avantage de pouvoir s'attarder plus longtemps sur chaque US et d'éviter par la suite de nombreux aller/retour entre l'équipe technique et fonctionnelle.

Le PO doit être néanmoins conscient que ce surcroît de liberté vient avec la responsabilité d’être vigilant à ne pas changer constamment les priorités pour que l’équipe ne s’éparpille pas.

Conclusion

Ajouter la logique de flux à une équipe qui fonctionne en Scrum apporte de nombreux avantages en terme de sérénité, prise de recul, stabilité du rythme de production et prédictibilité. Une fois ces améliorations intégrées, l’équipe est passée au Scrumban.

Il est important de noter en revanche que c’est une pratique “avancée” et qui peut être difficile à appliquer par une équipe pas encore à l’aise avec les rudiments de Scrum.

Le Scrumban semble un bon compromis qui apporte des avantages par rapport Scrum, et, si l’équipe se sent à l’aise, le scrumban peut être une bonne étape d’intermédiaire pour passer à du flux pur en arrêtant complètement les itérations.