Arrêter Scrum pour le flux, un début d’expérience

Sophie de Sophia

Suite à ma présentation à Lean Kanban France, j’ai reçu un message de Sophie. Elle accompagne une équipe confrontée à des difficultés avec Scrum qu’elle a aiguillée vers Kanban.

Son expérience est intéressante et elle la raconte bien, alors nous avons décidé de la publier.

Il s’agit donc d’un billet invité, autrement dit de guest blogging.

Voici le message de Sophie de Sophia :


Bonjour Claude,

Je viens de lire ta présentation “Appliquer Kanban sur Scrum”… j’aurais bien aimé y assister ! Cet article m’a fait revenir de fil en aiguille à ton post “Arrêter Scrum pour le flux, mmmmh !”.

Voici un cas concret qui peut alimenter les réflexions : il y a quelques mois, j’ai été sollicitée pour accompagner une équipe vers l’agilité (tout un programme !).

Le contexte

Un acteur industriel avec du cycle en V dans ses chromosomes, du développement embarqué critique sur du hardware spécifique. S’ajoutent à ça des contraintes d’externalisation de certains types d’activités au cours du développement et de nombreuses dépendances externes (tout étant spécifique, quand le hardware ou les bancs de tests sont buggués ou pas prêts à temps, ça coince très vite).

…Votre mission, si vous l’acceptez… j’ai accepté ;-)

Lorsque je suis arrivée, l’équipe avait déjà itéré quelques fois, en Scrum car c’est la méthode qui avait été choisie pour ce projet. Il y avait en fait 2 Scrums cascadés : un pour le développement, l’autre pour la validation, décalés d’un sprint, en théorie (sprints de 3 semaines). Toujours en théorie, il fallait donc 6 semaines à une user story pour traverser toutes les activités de réalisation…

La pratique

Ça c’est la théorie… dans la pratique, le temps de traversée est plutôt plus long, ce qui se traduit par une difficulté systématique à tenir l’engagement du sprint, pas mal de stories “traînant” de sprints en sprints (trop grosses, mais difficulté à les découper plus, pas le même besoin de granularité entre développement et validation, blocages nombreux, etc.)

La première chose qui m’a frappée en arrivant a été le silotage des activités, très difficile à casser, en partie à cause du changement culturel que ça impose à la fois dans les équipes et auprès du management, mais aussi à cause de la réalité du terrain : changer d’activité demande la prise en main d’outils complexes et parfois peu disponibles mais aussi un savoir-faire spécifique. J’ai donc très vite pensé à Kanban, en premier lieu en l’appliquant “par-dessus” les deux Scrums en place, pour tenter de compenser le silotage par une meilleure circulation des stories de silo en silo.

Ça a eu le mérite de fluidifier la coordination entre les deux Scrums (dev et validation), mais ça ne nous a pas permis d’avancer sur deux points fondamentaux :

  1. le temps de traversée à plus de 6 semaines… mais combien au juste ? On a même commencé à voir fleurir des user stories du type “spécifier la fonctionnalité X” pour avoir des éléments de backlog qu’on pouvait réaliser en 3 semaines,
  2. on ne semblait pas non plus se rapprocher de l’objectif de fournir à intervalles réguliers des incréments logiciels “potentiellement livrables”… vu qu’on commençait à se réjouir de livrer des bouts de spécifications en fin de sprint pour dire qu’on avait fini quelque chose, je voyais bien qu’on commençait à diverger sérieusement.
  3. S’ajoute à ça le début de la phase d’externalisation qui renforce le silotage : le prestataire a contractuellement le droit de réaliser certaines activités, mais pas d’autres. Gros point positif néanmoins : client et prestataire tombent très vite d’accord pour rester en “one team” d’une dizaine de personnes des 2 sociétés. Les locaux du prestataire étant à 200m, une petite promenade matinale et hop, un daily scrum co-localisé !

Kanban est arrivé

C’est à ce moment là que le livre de Laurent Morisseau “Kanban pour l’IT” provoque un déclic :

  • ça renforce mon idée que le Kanban semble adapté à la situation, car casser les silos est une trop grosse révolution pour l’instant et je ne suis même pas sure que ça soit totalement possible,
  • les cadences pour vider le bac de sortie me parlent tout de suite. Je lance donc l’idée de passer à du flux tiré plutôt que d’essayer de tenir à tout prix un engagement de sprint (des pistes comme le découpage artificiel des stories ou le rallongement de la durée des sprints à… 8 semaines étant vite écartées).

On commence donc à refaire un seul Kanban pour tous, avec le bac “stories prêtes” en amont, un bac “stories à démontrer” en aval et au milieu, nos colonnes modélisation, développement, tests unitaires, validation. L’équipe élabore également les DoD et des limites de travail en cours par colonne.

ScrumBan

On garde de Scrum :

  • les sprints, qui deviennent la cadence du Kanban. Le dernier bac “stories à démontrer” est vidé après chaque Sprint Review,
  • les rôles de PO et Scrum Master, car tout le monde en a pris l’habitude et commence à trouver sa place,
  • les cérémonies Scrum à l’exception du sprint planning (l’affinage étant fait au besoin une à deux fois par sprint) puisqu’on visualise les stories prêtes dans leur ordre de priorité, il suffit donc de piocher dedans dès que les limites de travail en cours le permettent. Pour résumer, ça ressemble à du ScrumBan, mais on a enlevé l’engagement du sprint planning pour le remplacer par du flux tiré. On s’autorise de fait à ce qu’une story prenne plus d’un sprint à être réalisée, et on se focalise sur la mise en évidence et l’optimisation du temps de traversée.

Le flux

Donc, oui, dans notre cas, on a allègrement zappé le “Shu” du Shu-Ha-Ri (voir l’article Arrêter Scrum pour le flux, mmmmh !). Je suis sincèrement convaincue que c’est pour la bonne cause. Nous appliquons cela depuis une itération et demie, il est encore tôt pour savoir où le chemin emprunté va nous amener :

  • à une analyse fine des blocages et à une meilleure manière de découper nos stories qui nous feront mieux revenir vers Scrum avec des durées de sprints adéquates ?
  • à la conclusion que nos stories sont longues à implémenter et que nous devrons rester sur ce mode ?
  • à une adoption “trop molle” de l’agilité qui ne poussera pas vraiment à l’introspection et à l’envie de travailler plus efficacement ? Est-ce que l’abandon de l’engagement de sprint aura un effet délétère sur la vision de l’avancement avec pour conséquence un inévitable retard ? (je livre ici la peur du management quand nous avons annoncé que nous essayions Kanban et qu’il n’y avait plus “d’engagement” par sprint)

Dans les deux premiers cas, peu m’importe : si à l’arrivée, il s’avère que nous avons pu livrer très souvent des incréments qui ont du sens et qui peuvent être embarqués sur le hardware définitif avec très peu de travail supplémentaire, ce sera une grande victoire !

Dans le dernier cas… eh bien, mauvais chemin !

J’accompagne avec beaucoup de vigilance ce tournant dans notre manière de faire, car effectivement, Kanban bien appliqué requiert beaucoup de discipline et je suis tout à fait en phase avec toi Claude : “Parce que faire vraiment du Kanban, c’est comme pour le vrai Scrum, ça demande de l’investissement”.


Mais qui es tu, Sophie ?

J’ai découvert l’agilité au début des années 2000 en expérimentant l’eXtreme Programming dans une start-up. Ce n’est que bien des années plus tard que j’ai vraiment compris l’étendue du changement de culture auquel invitait l’ensemble des courants agiles. Après une quinzaine d’années d’expérience des projets IT dans divers types de structures, j’ai choisi depuis deux ans de me consacrer à l’accompagnement d’équipes ou d’organisations qui choisissent d’emprunter ce chemin passionnant et riche en aventures.

Je suis également active dans la communauté agile de Sophia Antipolis, au travers de l’organisation de l’Agile Tour Sophia et de l’Agile Playground Sophia.

Sophie Durand (@soph06250, durand.sophie@gmail.com)

Merci Sophie, et à bientôt pour nous dire où ce chemin vous aura conduit.