Scrum est la méthode de référence lorsqu’il s’agit d’apporter un cadre à un projet en agile. Comme c’est un standard répandu, elle permet à l’équipe de ne pas trop se poser de questions sur leur organisation au lancement du projet.

Une fois que l’équipe est rodée à la méthode, nous avons :

• un backlog priorisé
• une équipe engagée sur un objectif récurrent (par exemple deux semaines)
• des rituels pour que l’équipe communique
• un processus d’amélioration continue

Et traditionnellement, les équipes utilisant Scrum, ont aussi :

• du management visuel
• un suivi de la vélocité de l’équipe

Nous utilisons cette méthode dans nos projets à OCTO, mais plusieurs choses nous gênent dans son application “by the book”. Et nous avons fini, avec l’expérience, par adapter nos usages en intégrant plusieurs principes issues de la méthode “Kanban” et tirer parti des qualités des deux démarches : nous passons à ce qui est communément appelé “Scrumban”.

Nous proposons une série d’articles présentant une façon de passer de Scrum à Scrumban et les avantages que ça peut apporter.

Cet article est le premier de la série et s’articule autour de l’adaptation du management visuel.

D'abord, sortir de la logique par “tâches”

En terme de management visuel, même s’il ne fait pas partie initialement du framework Scrum, on retrouve généralement un tableau - appelé communément “board visuel” ou “scrum-board”.

Ce board visuel est constitué de trois colonnes, dans lesquelles chaque tâche va circuler :

• A faire : ce qu’il reste à faire dans l’itération. Rempli à chaque début d’itération pendant le rituel du Sprint Planning (backlog)
• En cours : les tâches en cours, une tâche en cours à la fois par personne
• Fini : les tâches terminées.

Ce tableau est utile pour visualiser l’activité de l’équipe et prendre des décisions facilement. Il s’accompagne généralement d’indicateurs visuels (burn-down chart, déroulement du stand-up par exemple).

Ce tableau c’est la base, le minimum qui permet de suivre par une représentation visuelle ce qu’il y a à faire, ce que nous sommes en train de faire, et ce qui est terminé.

Une pratique courante est de suivre une logique par tâches : chaque User Story est découpée en “sous-tâches” ou “tâches techniques” pour représenter l’ensemble du travail qu’il faut réaliser pour terminer l’US.

Par exemple : développer l’IHM de tel écran, intégrer les règles de gestion, la partie gestion des données, ajouter les tests unitaires, etc.

L’objectif est qu’à la fin du Sprint, toutes les tâches aient été vidées dans la colonne “Fini”.

La première étape pour passer au Scrumban sera de passer d’une logique par tâches à une logique de flux.

La principale différence est que seules les US transitent du début à la fin du board, et on ne rend pas visible leurs check lists de tâches internes. L’intérêt est de ne pas ajouter des détails spécifiques à l’US qui nuiraient à la clarté nécessaire pour que l’équipe prenne des décisions efficaces au quotidien.

1. La première conséquence est de suivre un état par US. Donc au lieu de se dire “J’ai effectué 70% de l’US” ou “j’ai fait 7 taches sur 10”, on ne s’attarde que sur la colonne dans laquelle il est, ou s’il présente des points de blocage. L’équipe a ainsi une vision plus synthétique de l’évolution de la fonctionnalité.
2. La deuxième conséquence est que les estimations - en temps, en taille de t-shirt ou en point de complexité - sont définies à un niveau de granularité “US” et non pas par tâches.
3. Enfin, les développeurs sont responsabilisés sur l’ensemble du périmètre fonctionnel de l’US et pas uniquement sur l’un de ses aspects techniques. (Ex: IHM uniquement, Back uniquement ...)

Dès lors, le process de l’équipe est modélisé de façon générale - et non spécifique par ticket - en définissant chaque colonne par laquelle l’US devra transiter obligatoirement.

Puis, ajouter des colonnes !

Ajouter des colonnes dans le board visuel c’est formaliser visuellement les étapes réelles du processus par lesquelles les user stories passent.

Une colonne correspond idéalement à un type d’activité qu’un collaborateur peut effectuer seul ; le passage d’une colonne à une autre formalise le fait que l’US passe à un autre état et est prise en charge par une autre personne. Cette transition répond à une règle, un contrat formalisé et accepté par l’équipe, appelée “Definition of Done” (ou DoD).

Tous les projets sont différents, et à fortiori le process et donc les colonnes du board sont généralement spécifique à chaque équipe projet. Néanmoins, voici les colonnes qu’on a l’habitude de voir lorsque l’équipe étend le traditionnel “Todo - Doing - Done”

La revue de code

Avec les bonnes pratiques de développement (“craftsmanship”), la première colonne qu’on va vouloir ajouter, c’est la revue de code.

Lorsqu’un développeur a fini son développement, le code peut être revu par d'autres membres de l'équipe. Cette revue peut être réalisée en revue collective, ou plus simplement en revue par un pair (en synchrone, c'est à dire à deux devant l'écran, ou asynchrone, en utilisant un outil adapté).

Le bout de code de la fonctionnalité est développé dans un premier temps en local sur une seule machine. Puis, ce fragment est diffusé sur une base de code partagée avec les autres membres de l’équipe. De là nous pouvons constater que le bout de code fonctionne sur plusieurs machines.

C’est généralement une des DoD - “Definition of Done”, c’est-à-dire les règles qu’on se donne collectivement pour autoriser un ticket à passer d’une colonne à une autre, et qu’on affiche sur le board - pour passer dans la colonne “EN REVUE”, la fonctionnalité, ce bout de code, est maintenant partagé et visible de “tous”.

Il y a plusieurs objectifs dans cette démarche, la revue de code permet de :

• Identifier les éventuels défauts de qualité (code mal écrit) au plus tôt
• Transmettre une culture de la qualité logicielle, faire évoluer les standards de code de l’équipe
• Partager la connaissance sur cette fonctionnalité. Si un développeur part en vacances par exemple, un autre peut reprendre la suite.
• Renforcer la propriété collective du code
• Faciliter l’apprentissage
• Améliorer l'esprit de d’équipe et la qualité des échanges.

La recette PO

En Scrumban, nous intégrons un maximum de choses au fil de l’eau. Et, comme pour la revue de code, plus un défaut est détecté tôt, plus il est rapide à corriger.

Donc la deuxième colonne qu’on va vouloir ajouter c’est la recette du PO au cours de l’itération. Là où la revue de code servira à détecter les défauts techniques, la recette PO permettra d’identifier les bugs fonctionnels sur l’US.

Le PO va donc valider les tests d’acceptances des différentes US dès que les développements et revues de codes seront terminés et que la fonctionnalité sera déployée sur la plateforme prévue à cet effet.

Si le PO détecte un bug pendant sa recette, il bloque le ticket, signalant à l’équipe qu’il y a une correction à faire en priorité. S’il s’agit d’un cas de test oublié lors de la rédaction de l’US, généralement la pratique est de créer un autre ticket qui sera priorisé par le PO.

Recetter au fil de l’eau apporte un énorme avantage en terme de réactivité.

D’une part, le développeur corrige plus facilement un bug si le contexte est encore frais dans sa tête. Par ailleurs, si la recette n’est faite que toutes les deux semaines, cela allonge le délai de correction des bugs pouvant aller jusqu'à plusieurs itérations (pour imager à IT N : détection du bug, IT N+1 : Correction du bug, IT N+2 : Recette de la correction).

Enfin, dézoomer !

En Scrum, le board est dédié à ce qui se passe pendant l’itération. L’intention est de se concentrer sur le coeur du développement.

Le cycle de vie des User Stories en amont de l’itération (“en cours de rédaction”, “prêt à développer” etc) est donc géré par le PO et n’est pas visible par le reste de l’équipe.

• Pour les développeurs en particulier, ne pas voir les fonctionnalités prévues pour les jours qui viennent, c’est comme conduire dans le brouillard, et donc sans voir suffisamment bien devant soi. L'équipe a besoin d’avoir une visibilité sur les US qui vont arriver dans les prochains Sprints car il peut y avoir un impact sur la manière de développer le sprint en cours.
• C'est également très important de définir un workflow de conception adapté dans lequel nous pouvons avoir bien plus d'acteurs que le PO (responsable métier ou marketing, UX, designer si besoin etc ...).
• Cela permet aussi d'avoir une réelle visibilité en terme de pilotage sur le niveau de préparation de la suite du projet.

Voici un exemple simple de board Scrumban :

Généralement, nous avons :

La phase de conception

Cette - appelée aussi “Cadrage” dans certaines équipes - phase rend visible le processus de conception des itérations à venir et ainsi le stock d’US prêtes à rentrer dans la phase de développement.

L’ensemble des critères sur lesquels l’équipe s’accorde pour décider qu’une US est prête s’appelle le DoR, ou “Definition of Ready”.

En sortie de phase de conception, par exemple de mise en pratique, les US sont :

• Découpées
• Rédigées
• Relues par un ou plusieurs acteurs de l’équipe
• Estimées par les développeurs

Les colonnes de la phase de conception vont formaliser les étapes nécessaires pour satisfaire le DOR. L’état d’avancement est visible pour toute l’équipe.

Toutes les équipes ont leur propre façon de fonctionner. On peut trouver des étapes variées selon les équipes car les contextes de projet sont différents et elles ont chacune leur façon de travailler. Ce workflow peut parfois être complexe.

La phase de développement

Ici, “En développement”, “à revoir” et “à tester”, soit :

• la phase en cours de développement
• la phase de revue de  code
• la phase de test PO, la recette au fil de l’eau des US avec la validation (ou pas) de chacun des futurs incréments du package de la prochaine itération à livrer.

La phase de recette externe

Lorsque l’US sort du Sprint, il peut arriver qu’on fasse une recette externe indépendante du rythme des sprints. Une fois validée et terminée nous pouvons procéder au déploiement en production de l’application.

Il est sans doute important de préciser ici que si l’un des incréments du sprint terminé est “défectueux” il coûtera plus cher à être corrigé que pendant la recette PO au fil de l’eau.

L’essentiel sur la façon de construire un board est qu’il correspond à la façon de faire de l’équipe, que tous les membres soient d’accord sur le processus et surtout sur les conditions pour passer d’une étape à la suivante. Si l’équipe qui change le board est susceptible de changer, si l’équipe évolue, le board est susceptible d’évoluer également.

La suite ?

Vous êtes sorti de la logique par tâches pour visualiser plus simplement le flux des User Story. Puis vous avez enrichi le classique "Todo-Doing-Done" pour détailler votre process. Enfin, vous avez élargi le board pour rendre visible les activités en dehors de l'itération.

L'équipe a ainsi réalisé les premières étapes pour passer de Scrum au Scrumban en adaptant le management visuel.

Ensuite ? Scrum propose un rythme itératif très précis et cadré. Le prochain article abordera cette thématique et les ajustements possibles avec Scrumban.