[French SUG] – Scrum, Kanban et Lab Days

La dernière soirée du French Scrum User Group (French SUG) s’est déroulée le jeudi 18 novembre 2010, avec deux parcours en parallèle proposés : « Retours d’Expérience Agile » et un atelier dédié à une technique de facilitation, la « Focused Conversation Method ». Je vous propose de voir plus en détail la présentation du rythme agile chez PriceMinister, réalisée par Martin Sudmann, où comment l’agilité a été mise en place dans sa société en mêlant Scrum, Kanban et Lab Days.

Le rythme agile chez Priceminister

Martin Sudmann, Scrum Master chez PriceMinister, nous a fait un retour de son expérience agile au sein de sa société, sur le déroulement du processus de mise en place de l’agilité, ainsi que sur les pratiques qui ont été un succès et celles qui ont échouées.

Tout d’abord parlons du contexte de la société. Les développements, produits en Java, sont réalisés par 4 équipes de développement, divisées par secteur métier. Chaque équipe est composée de 2 à 4 développeurs, 1 Scrum Master et 1 Product Owner. A cela s’ajoute une équipe dédiée à la QA (Quality Assurance). L’agilité est arrivée chez PriceMinister petit à petit, il y a environ 2 ans et demi, introduite par l’équipe de développement, pas par un coach. Au tout début, la motivation est venue d’un chef de projet technique qui a commencé à introduire l’agilité par des pratiques de Scrum, en mode « sous-marin » (caché) sans que son chef de projet s’en aperçoive. L’histoire a commencé par un mur de post-its en premier et une orientation progressive de la définition du besoin en user stories. Puis les pratiques sont devenues plus officielles par la suite et ont été généralisées progressivement aux différentes équipes de développement.

Contexte agile

Les sprints sont d’une durée de 2 semaines, correspondant à la fréquence de sortie d’une nouvelle version du site. En fait chaque équipe livre à tout de rôle, au bout de 8 semaines, découpés en 4 sprints, 3 sprints de développements et 1 sprint spécial dédié à la livraison.

La maintenance est quant à elle réalisée en continue, ce qui baisse la vélocité de l’équipe. Les pratiques de Pair Programming et de TDD (Test Driven Development) ont bien essayé d’être adoptées, mais elles sont très difficiles à mettre en place.

Sprint Wall

Le mur de sprint (où sont accrochés les tâches du sprint par post-its), contient en plus des classiques « à faire », « en cours » « fait », une colonne « à tester » où sont déposés les tâches de la colonne « fait » de l’ancien sprint. N’ayant pas d’intégration continue, les tâches réalisées sont testées dans le sprint suivant.

Enfin, une autre colonne est ajoutée au mur (Sprint Wall) : « A venir ». Dans cette colonne sont affichées des tâches supplémentaires au cas où toutes les tâches« à faire » seraient terminées.

Sprint Livraison

Ce sprint un peu spécial est dédié à la livraison en production, avec un travail collaboratif entre une équipe de développement et l’équipement QA. Finalement ce sprint est là pour faire la jonction entre la phase de recette de la gestion de projet classique de l’équipe QA et la correction des retours de bugs en agilité de l’équipe de développement.

Toutefois le traitement des retours de la recette a posé un véritable souci. Le but était de ne pas dédier un sprint complet à attendre le retour des bugs, mais à continuer à développer en parallèle des user stories, la difficulté étant l’imprévisibilité des retours.

Plusieurs solutions ont été envisagées pour traiter les retours de bugs :

–          Baisser la vélocité en estimant un retour de bug moyen de 40% par exemple

–          Créer des items de livraison

–          Créer des items fantômes de retours de bugs (avec des points arbitraires), revenant finalement à baisser la vélocité

En parallèle des retours de la recette étaient ajoutés des items de conception technique, les « design spikes ».

Aucune de ces solutions n’a été satisfaisante et finalement la solution vint à Martin de combiner Scrum et Kanban.

Kanban

Le Kanban (terme japonais qui signifie « étiquette ») est une information qui accompagne un container de pièces (composants ou produits finis).

Le système Kanban est une méthode d’approvisionnement en flux tiré. Cela signifie que l’on va remplacer ce que le client consomme exclusivement.   Pour ce faire, la fiche fait la navette entre l’amont et l’aval d’un poste de production pour indiquer si le poste de production situé en amont doit fabriquer une nouvelle série de pièces ou pas. Le principe permet de limiter l’en-cours de stock et donc le gaspillage en cas de défaut détecté en aval de la chaine de fabrication.

La création du Kanban comme méthode de développement est née du besoin de certaines équipes de pouvoir réduire le time to market, c’est à dire le temps passé entre l’idée d’une fonctionnalité émise par le métier et sa mise à disposition pour l’utilisateur final.

La mise en place du flux tiré, qui correspond à minimiser le time to market, c’est-à-dire à développer que ce dont on a besoin en limitant au maximum l’en-cours de fonctionnalités à réaliser, est un concept Lean. Mais ce n’est pas le seul mis en œuvre avec Kanban : Le stop the line.

Lorsque sur une chaine de production un opérateur constate une erreur, ou lorsqu’une machine se débraye, on arrête toute la chaine et on s’attèle à résoudre le problème plutôt que de continuer à produire coute que coute. Appliqué au développement, lors d’un problème de livraison, toute l’équipe va se concentrer sur la résolution du problème pour relancer le flux, plutôt que de continuer la correction des bugs. Ce système, pas forcément de bon sens à première vue, participe toutefois à éviter la propagation de non qualité.

Avant de voir la solution adaptée par Martin, détaillons un peu le worflow Kanban :

On remarque que les 2 différences fondamentales sont que le nombre d’items « En cours » est limité et que la liste des items « à faire » n’est pas figée, contrairement au workflow Scrum.

Martin décida donc d’appliquer Kanban au sprint de livraison, ce qui avait pour avantage

–          de gérer les nombreuses petites tâches exigeant un « time to market » très court (à livrer rapidement)

–          de ne pas s’engager sur le périmètre

–          de faire la conception technique en parallèle

Mur de livraison Kanban

Durant ce sprint spécial voici un schéma représentant le mur de livraison utilisant Kanban. Il est composé de 4 colonnes, avec 2 lignes de flux Kanban, une pour les retours de la recette et l’autre pour des tâches de fond liées au développement. La différence essentielle avec le mur de sprint étant que le nombre d’items « En cours » est limitée à 1 par développeur, par ligne Kanban.

Toutes les tâches, de conception technique ou de retour de bug, démarrent à gauche sur le tableau/mur de livraison et le traversent rapidement à l’image de l’étiquette Kanban.

Et dès la fin de la livraison et la conception technique, l’équipe de développement revient à un Scrum plus classique.

Lab Days

Aujourd’hui l’équipe a un taux de temps de travail très intense, de l’ordre de 75%. La recette/livraison n’est pas une phase de repos pour les développeurs. Martin Sudmann a donc réfléchi à comment remotiver le groupe, le faire souffler tout en soudant l’équipe.

C’est à ce moment-là qu’ont été introduits les Lab Days. Martin a eu l’accord total de la hiérarchie pour que son équipe profite d’une ½ journée par sprint d’un temps de travail libre d’expérimentation. Ce temps « libre » peut être dédié à des auto-formations, à de la méthodologie, à de l’exploration d’architecture. L’essentiel est que ca vienne de l’équipe et que le travail soit fait en groupe.

Les équipes de développement ont eu la bonne pratique de communiquer en toute transparence avec le reste de la société, notamment via des affiches et posters à la machine à café, avec le contenu de leur travail, le contenu du sprint. Cela a instauré une relation de confiance avec la hiérarchie et a permis que ces lab days soient totalement acceptés par l’entreprise. Le contenu et résultat de ces lab days sont également communiqués par posters, à la cafet. D’ailleurs c’est grâce aux lab days que le pair programming testé durant une ½ journée a été adopté ensuite dans une des 4 équipes de développement.

Conclusion

Chez PriceMinister, la transformation Agile se fit en apportant  progressivement des pratiques agiles, en s’inspirant grandement de Scrum. Certaines ont été un succès (travail en sprint, découpage en user stories, contenu de sprint transparent sous forme d’affiches à la cafet) tandis que d’autres ont partiellement ou totalement échouées. (Pair Programming déployé que partiellement, TDD trop difficile à mettre en place, échec des items de livraison).

Toutefois devant l’échec des sprints de livraison, Martin a su s’adapter en tirant parti du système Kanban. Enfin, grâce aux Lab Days, l’équipe conserve sa motivation et son rythme de travail soutenu et soutenable. Personnellement j’ai apprécié cette présentation, de voir l’alliance réussie entre Scrum et Kanban, ainsi que la démarche d’amélioration continue, en cherchant des solutions ailleurs que dans Scrum.

Références

Site du French Scrum User Group : http://www.frenchsug.org/

L’Agenda Agile : http://www.agenda-agile.org/

Source de la photo du workflow Kanban  http://blog.outsystems.com/aboutagility/2010/11/scrum-vs-kanban.html


Nombre de vue : 116

AJOUTER UN COMMENTAIRE