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

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…

Ç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.

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é !

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.

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.

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.

Commentaires

1. Le vendredi 13 novembre 2015, 08:14 par claude

Un avantage d'avoir un billet invité, c'est que je peux faire un commentaire sans me parler à moi-même…

L'argument le plus souvent utilisé pour le choix de Kanban est le flux "subi" en entrée : trop de changements qui empêchent de garder un objectif au sprint. Dans ton cas, ce n'est pas du tout cela, c'est l'impossibilité de casser les silos qui est avancée. Tu ne dis pas pourquoi. Comme il y a la volonté d'avoir une seule équipe, on aimerait en savoir plus. Pour moi le point-clé est la notion d'équipe. Le fait qu'il y ait des compétences très variées dans l'équipe n'est pas bloquant pour faire du Scrum.

J'ai l'impression que le vrai problème est le découpage des stories. J'ai tendance à penser que cela peut-être amélioré par un meilleur affinage.

On aimerait savoir comment les limites ont été posées, ce qu'elles provoquent depuis leur mise en place.

Sinon, pour rester dans les Sophie, le dernier album de la Grande est pas mal du tout, très pop : Nos histoires

2. Le vendredi 13 novembre 2015, 14:13 par laurent morisseau

Merci pour ce guest post sur du Kanban, très intéressant car beaucoup d'obstacles ont déjà été visiblement levés dans un contexte qui n'est pas simple.

A la lecture de ce retour d'expérience, je te rejoins Claude sur ce qui semble être le vrai problème : celui du découpage.
L'intérêt des sprints est de rendre visible ce problème rapidement.
L'intérêt du Kanban est d'avancer avec ce problème en attendant de l'améliorer.

La peur de perdre l'engagement en passant à Kanban est intéressante dans la mesure ou l'équipe n'arrive a priori pas bien à tenir son engagement sur un sprint. Mais c'est un point qui revient très souvent.
L'engagement existe toujours avec Kanban, il ne porte plus sur le périmètre fonctionnelle mais sur la performance. Ici, ce serait le temps de cycle (les 6 à 8 semaines) et le débit (le nombre de stories par semaine par exemple).
En essayant de tenir puis d'améliorer cette performance, on arriverait surement aux mêmes conclusions qu'avec le cadre de Scrum : mieux découper les stories en entrée.

PS : je suis ravi que mon livre est pu déclencher un déclic :o)

3. Le dimanche 15 novembre 2015, 19:31 par Sophie Durand

Merci Claude et Laurent pour vos retours.

Sur la question des silos, ils sont difficilement “cassables” pour l’instant, c’est une question de culture qui sera longue à changer mais aussi la contrainte amenée par l’externalisation : le prestataire est engagé contractuellement à réaliser une partie des tâches (développement, tests unitaires et une première phase de validation fonctionnelle) mais la conception, la modélisation et la validation finale restent en interne. On avait envisagé à un moment de réduire Scrum à l’équipe prestataire avec une sorte de PO intermédiaire pour alimenter cette équipe. Je trouvais ça dommage car on rajoutait dans ce cas des intermédiaires entre ceux qui portent le besoin et ceux qui réalisent la solution, ce qu’on s’efforce d’éviter en agilité...D’où le fonctionnement en “une seule équipe” qui veut dire ici que même si l’équipe est divisée en sous-groupes spécialisés, tout le monde traite les mêmes users stories et participe aux mêmes cérémonies.
Pour le découpages des users stories, vous avez complètement raison : je pense qu’on peut faire beaucoup mieux, découper plus finement...mais s’ajoute à ça un souci encore plus important pour le moment : les blocages dus aux nombreuses dépendances externes comme par exemple les outils, les bancs de tests, les couches logicielles bas niveau qui sont développés par d’autres équipes.
Le premier effet des limites Kanban a été de mettre l’équipe dans la posture de faire circuler les user stories le plus vite possible vers la droite du Kanban : à partir de ce moment là, l’équipe s’est penchée beaucoup plus précisément sur l’identification de ces blocages, ce qui a déjà permis, sinon de les lever, de trouver déjà quelques solutions de contournement efficaces. Grâce à cet inventaire des blocages, je peux moi même mieux cibler des actions du genre aller visiter les autres équipes, leur expliquer comment nous travaillons et imaginer avec eux une meilleure synchronisation.
Pour résumer, je dirais que le premier effet du passage au Kanban a été de permettre à l’équipe de se mettre à réfléchir sur les freins qui entravent leur travail quotidien et donc de booster l’amélioration continue. L’équipe m’a dit à la dernière rétrospective se sentir plus à l’aise avec Kanban car ils ont arrêté de se “prendre la tête” avec la remise en cause incessante de leur processus de développement pour se remettre dans l’action et faire face de manière pragmatique aux nombreux obstacles rencontrés.
J’aime bien tes deux petites phrases Laurent, car elles résument bien ce début de parcours :
L'intérêt des sprints est de rendre visible ce problème rapidement.
L'intérêt du Kanban est d'avancer avec ce problème en attendant de l'améliorer.

4. Le lundi 16 novembre 2015, 09:38 par claude

En ce qui concerne les dépendances externes, il ne sert à rien de commencer le développement d'une story dont on sait qu'elle sera bloquée par une ou plusieurs dépendances. En fait une story qui a des dépendances non "dérisquées" ne devrait pas être considérée comme prête (dérisquée, c'est un des 6D). Comme le découpage (ou la décomposition) des stories, l'examen des dépendances externes est une activité de l'affinage. Une façon simple de procéder est de lister, pour chaque story, toutes ses dépendances vers des experts ou d'autres équipes, et de les examiner avant de déclarer la story prête.