Chaque année, je m’éloigne un peu plus du Scrum traditionnel. J’observe un décalage entre certaines pratiques et les attentes des équipes que j’accompagne. Je me questionne sur certains concepts comme l’estimation, la notion de sprint, la priorisation, etc. J’ai trouvé dans Kanban d’excellentes idées qui ont altéré ma manière de pratiquer Scrum. De plus en plus de personnes se tournent vers Scrumban, une évolution de Scrum, qui combine le meilleur de Scrum et Kanban. Depuis deux ans, j’ai moi aussi franchi le pas et aide des équipes à s’approprier cette approche. Voici comment elles s’essaient à Scrumban.
Vous allez probablement me demander pourquoi ne pas orienter les équipes directement vers Kanban si elles ne s’y retrouvent pas avec Scrum. Ces équipes apprécient le rythme offert par Scrum mais elles ont remarqué que certaines pratiques (estimation du product backlog, la planification de sprint basé sur un périmètre fonctionnel ferme) ne leur apportent pas (ou peu) de valeur dans leur contexte. Kanban apparaît comme une marche assez haute pour les équipes habituées à travailler sur des lots fonctionnels à livrer sur une fréquence de plusieurs semaines. Scrumban donne plus de souplesse aux équipes et offre une transition douce pour celles qui auraient envie d’aller vers Kanban.

L’étincelle de l’amélioration continue

Pour s’essayer à de nouvelles pratiques, il faut que l’équipe s’accorde le temps de regarder en arrière et décider quoi modifier dans son quotidien. Ce temps, indispensable à l’amélioration continue, doit être protégé par l’équipe et son manager. Il peut par exemple s’agir de rendez-vous hebdomadaire d’une demi-heure où l’équipe met à jour son tableau d’amélioration continue. Un tel tableau peut être initié avec un atelier sur le Value Stream Mapping (VSM) comme décrit dans cet article.

Les rôles

J’ai rencontré plusieurs équipes qui souhaitaient aménager certains rôles ou en créer de nouveaux. Par exemple, certains contextes amènent à disposer de plusieurs niveaux d’interlocuteurs client (business analyst, product owner proxy, product owner, sponsors, etc.) ou opération (développeur, DevOps, testeur, support, etc.). Si les rôles existent déjà, un atelier comme « Give and Take Matrix » peut aider à les clarifier. S’ils sont à construire, l’équipe s’attèlera à définir les activités attendues de ces rôles.

Un workflow Kanban pour la préparation des user stories

La préparation d’un item du product backlog suffisamment fin pour être développé s’associe très bien avec un workflow Kanban (y compris en Scrum). En scrum, l’équipe va utiliser ce réservoir d’items prêts pour développement durant un sprint planning pour en définir le lot sur lequel elle est capable de s’engager pour le prochain sprint. En Kanban sur toute la chaîne de valeur, ce réservoir n’est qu’une étape du workflow avec une limite de travail en cours.

Un workflow Scrumban pour la réalisation des user stories

Scrumban, c’est un peu du Scrum sans engagement ferme sur le périmètre du sprint / itération. Il n’y a donc pas besoin de calculer la vélocité du sprint. Est-ce que cela signifie que ce n’est plus la peine d’estimer ? L’estimation va prendre une forme différente et ne servir qu’un seul objectif, celui de valider qu’une user story est suffisamment petite pour entrer dans une itération (en dessous de 4 jours de développement par exemple). Les motivations principales sont de disposer d’un débit cohérent de user stories et d’éviter l’effet tunnel. Les prises de décision qui étaient auparavant liées à la vélocité ou l’estimation n’ont plus lieu d’être. Elles pourront être facilitées par d’autres indicateurs comme le nombre de user stories par sprint / itération.

Les itérations peuvent être découplées de la mise en production. Par exemple, une équipe peut livrer en production toutes les 6 semaines tout en ayant des itérations intermédiaires de 2 semaines. Elle peut ainsi prévoir des tests lourds (non régression, performance, volume, etc.) pour les lots fonctionnels produits à chaque itération.

Un workflow Kanban pour visualiser l’avancement des fonctionnalités

Visualiser l’avancement des items du product backlog ou des user stories n’est pas suffisant pour piloter le développement d’un produit. En effet, ces items ne sont que des morceaux de fonctionnalités qui ne prennent du sens pour l’utilisateur ou le client que lorsqu’elles sont assemblées en MMF (minimum marketable feature) afin d’en percevoir la valeur. Le product owner appréciera donc de mesurer l’avancement des fonctionnalités à l’aide du management visuel. Cela peut prendre la forme d’un tableau où seules les fonctionnalités sont visibles. Chaque fonctionnalité reflètera l’avancement des user stories qui lui sont liées.

Les rendez-vous / cérémonies

La rétrospective reste un must-have.

En Scrumban, les daily stand-ups peuvent mettre le focus sur l’itération / la cadence en cours mais aussi la préparation de la prochaine. Par exemple, si l’équipe n’a en tête que l’itération en cours, elle perdra de vue la préparation de la prochaine itération et n’aura que peu de chose à réaliser sur cette dernière. A l’inverse, si elle passe tout son temps sur la préparation, elle ne livrera rien au terme de l’itération en cours. L’équipe peut donc se donner comme double objectif d’équilibrer la préparation des items du product backlog et la réalisation de l’itération en cours.

Les sessions d’estimation reste intéressantes, même en Scrumban. L’objectif n’est pas ici de produire un nombre qui va être utilisé pour le calcul de la vélocité. Cet atelier a pour but de confronter des points de vue sur la charge de développement (et des activités qui s’y rattachent) d’une user story et de discuter des contrastes. Cette discussion amènera chacun à compléter sa vision personnelle des choses à faire. C’est également l’occasion de valider que la user story est suffisamment petite (inférieure à quatre jours par exemple) pour entrer dans la prochaine itération.

Aller vers Scrumban

Si vous est en Scrum, vous pouvez commencer par rendre visible les activités de préparation dans un tableau Kanban et remplacer le modèle d’estimation par des techniques de découpage fonctionnel afin de disposer systématiquement de petites user stories. L’engagement sur le backlog de sprint n’est qu’approximatif et l’équipe s’habituera à développer plus ou moins ce qui était prévu. Si l’équipe a terminé le développement en avance, elle choisira entre plusieurs options comme la contribution à la préparation de la prochaine itération, l’aide à un collègue pour terminer une user story ou le développement d’une nouvelle user story « Ready for Dev ».

Si vous êtes en Kanban, vous êtes probablement déjà familier au découpage fonctionnel. Il vous faudra simplement ajouter une interface entre les activités de préparation et celles de réalisation. Le tampon « User stories ordonnées » servira à accumuler des user stories « Ready for Dev » qui basculeront en développement à chaque début d’itération.

N’hésitez pas à partager vos témoignages / expérimentations dans les commentaires.

Quelques liens :
– Les slides de ma présentation « Et Si je rythmais mon Kanban » à la conférence CultureKanban
– Les slides de Farfra Couthaïer « REX d’une transformation Kanban sur 6 mois » à la conférence CultureKanban