Parlons outils pour Kanban !

Eh oui, malgré que le manifeste nous assène que « les hommes sont plus importants que les outils », cela ne nous empêche pas de faire le plein à une soirée exclusivement consacrée aux outils ! D’ailleurs j’en étais, mais je suis arrivé un peu en retard… Essayons de rattraper celui-ci !

Thomas Declercq, ou comment étendre TFS

Thomas est manager chez AXA, à Lille plus exactement. Ici, on utilise les outils Microsoft, donc TFS pour faire du développement en .NET ; rien que de très logique. Les grands comptes sont rarement sur les dernières versions des outils, on vient donc tout juste de passer de TFS 2010 à TFS 2013. Et l’outil montre ses limites pour suivre des métriques. Alors si l’on a pu fort logiquement commencer avec des exports de données puis du bricolage sous Excel, l’équipe a fini par se lasser de ce travail et a envisagé des outils se branchant sur les API de TFS. On parle ici de 3 outils internes.

Outil #1 : Le Kanban board

Il n’est pas beau, il a été développé entre la poire et le fromage, car l’équipe en avait besoin mais personne ne voulait payer pour … et il est très utilisé ! Ils en avaient besoin, car la solution initiale, c’était des extracts CSV de TFS injectés ensuite dans Excel. Un travail à la longue très fastidieux.

Lire la suite

Publicités

Jouez en Kanban, re-tentez votre chance !

A mon grand dam, j’ai raté pas moins de 3 rendez-vous du FKUG, j’étais donc heureux de me rendre à celui-ci. D’autant plus heureux qu’il me permettait de m’essayer à l’un des jeux proposé lors d’un meetup précédent. J’avais d’ailleurs arrêté mon choix sur Kanbanzine que je souhaitais comparer au getKanban que je connais bien.

Dans les starting blocks

Nous étions accueillis chez Soat, dans leurs nouveaux locaux du 13ème arrondissement, à deux pas de chez moi ! Beaucoup de place pour s’ébattre, mais nettement moins de participants que prévus : j’imaginais 50 participants sur les 80 inscrits, nous étions un peu moins de 30 au final. Le foot d’un côté et les problèmes de transport de l’autre ont probablement eu raison de la pugnacité des uns et des autres !

On est agile, on s’organise, ou plutôt Gwenael nous aide à nous organiser.

image

Tout d’abord, les jeux proposés pour cette soirée :

  • Le getKanban, nous est proposé par Renaud Chevalier
  • Le Lean Lego Game va être animé par un Yannick Quenec’hdu remonté à bloc.
  • Un Kaizen game, créé par Olivier Le Lan et quelques uns de ses collègues sera orchestré par lui-même.
  • Le Kanbanzine est prévu pour se dérouler sous la houlette de Sebastien Ménétrier
  • Enfin, le Beer Game nous est proposé par Emmanuel Sciara

Pas sûr que nos effectifs nous permettent de mettre en oeuvre tout ce qui est proposé : un rapide vote le confirme. Damnation : c’est justement le Kanbanzine qui est sur la sellette. Je me rabat sur le Beer Game. Mais ce sera sans le regretter !

Le Beer Distribution Game

Ce jeu n’est pas vraiment un truc tout neuf, car il a été créé au MIT dans les années 60 ! Emmanuel, qui va être notre meneur de jeu va utiliser la version commerciale de la System Dynamics Society.

image

Le principe

Le but est d’imiter une chaine de distribution en 4 étapes, allant de la fabrication à la distribution de bières. Chaque maillon de la chaine reçoit des commandes, passe des ordres de rapprovisionnement en fonction du stock (ou du backlog) et des commandes reçues, mais n’a pas de visibilité sur ce qui se passe chez ses voisins. En fait, on n’a même pas le droit de se parler entre nous.

On fait de nombreux tours de jeux, 40 dans notre cas. Et nous voyons nos stock varier et même passer dans le négatif en tentant d’ajuster ces fluctuations à l’aide de volumes d’ordres que nous pensons adaptés.
Le meneur compte les coût de stock (0,50 € par item en stock) ou les demandes en souffrance (1 € par commande non satisfaites).

La dynamique du jeu, surtout vue de l’extérieur, est assez curieuse. Nous ressemblons à des sortes de galériens silencieux qui n’ont pas tellement l’air de s’amuser ! Parfait !

Ce qui se passe

Assez rapidement, on a l’impression de ne plus avoir la situation sous contrôle : les stocks varient et les arrivages ne sont pas du tout en ligne avec la compensation de ces variations, alors on tente de sur-compenser cela par des ordres adaptés. Mais cela semble vain.

image

En fait, nos stratégies sont effectivement vaines. Elles sont même contre-productives : chaque tentative de correction se trouve amplifiée par l’élément suivant de la chaine, accroissant le niveau de chaos des arrivages !

On se sent à la fois aigris et pour le moins dépité par « ce que nous font subir » nos voisins. C’est une sensation vraiment curieuse !

Les enseignements

Si la situation semble se stabiliser vers les tours 30 ou 40, on arrive vite à la conclusion qu’il n’y a pas de corrélation directe et simple entre nos ordres et les arrivages. Les comptes nous montrent même que mes tentatives pour « apaiser » le système ont de manière paradoxale fait de moi le maillon le plus coûteux de la chaine : incroyable !

Cet effet est connu dans les milieux autorisés sous le doux nom de Bullwhip effect.

Les facteurs favorisant cet effet sont :

  • Le manque de communication entre les maillons de la chaine, ce qui ne nous permet pas de donner un bon feedback, d’éclairer nos intentions et favorise l’interprétation erronée.
  • Le manque de vision global sur l’état du système.

On voit donc que ce que nous mettons en avant dans nos principes agiles (transparence, communication) sont une vrai réponse à un problème démontrable plutôt ancien !

Emmanuel a par ailleurs publié un post sur ce jeu.

Lego Game

Pendant que nous nous livrions à nos activités avec une austérité digne des plus grandes heures de l’Union Soviétique, il n’en allait pas de même chez nos camarades Legoistes justes à côté !

C’est un Yannick visiblement sous l’emprise de substances illicites qui animait avec dynamisme un session que je serait bien en peine de décrire, émaillée non seulement de sautillements de l’animateur, mais aussi de grands brassages de Lego…

image

On trie les l’égo, on les renverse par terre, puis bien sûr on les ramasse. Finalement, ce n’est pas si mal comme spectacle pour égayer notre boulot de galérien !

image

Kaisen Game

Olivier Le Lan avait déjà animé ce jeu lors de la journée Open-Space du ScrumDay. Déjà je l’avais raté à ce moment là (mais il s’agissait d’une version 40 minutes, pas vraiment satisfaisante aux dires d’Olivier).

image

Hélas, ce n’est pas encore ce soir que je pourrais l’expérimenter. Il fallait bien faire des choix !

getKanban

C’est un grand classique pour l’apprentissage du Kanban. S’il manque le côté décalé d’un Kanbanzine ou d’un Pizza Kanban, c’est un jeu très complet sur tous les aspects du Kanban dont le fonctionnement a été très bien mis au point. Il mérite un post à lui tout seul.

image

Renaud avait disposé 2 plateaux de jeux « fait maison ». Il est vrai que le jeu officiel est preque hors de prix !

Pizzas time !

Les activités qui étaient planifiées occupaient chacune un peu plus de 90 minutes. C’est donc pratiquement à 22 heures que nous avons pu calmer nos appétits avant de regagner nos pénates.

image

En ce qui me concerne : une soirée réellement instructive, en plus d’être une bonne détente. Un grand merci à Emmanuel pour avoir si brillamment animé ce jeu.

FKUG #3 avec Laurent Morisseau

Laurent n’est pas un inconnu pour nous, car il a fait partie du French SUG avant de s’orienter nettement vers le Kanban, en créant tout d’abord l’association Lean Kanban France qui organise la conférence du même nom et dont il est président, et en écrivant un livre sur le Kanban, le seul en Français à ce jour si l’on excepte la traduction du livre de David J. Anderson.

D’ailleurs la seconde édition de ce livre vient de sortir, elle évoque quelques nouveautés, des avancées dans la communauté Kanban. C’est pour les évoquer que Laurent est venu au FKUG la veille du ScrumDay.

C’est aussi hélas parce que c’était la veille du ScrumDay et que j’avais quelques petites choses à terminer pour l’atelier que j’animais que je n’ai pu venir de nouveau.

Fort heureusement cette soirée a été entièrement filmée (la vidéo est donc très longue) et nous pouvons profiter de cette soirée en différé comme si nous y avions été.

Enjoy !

Un meetup sur les jeux Kanban avec le FKUG

Retenu à Caen par le printemps agile, je n’étais hélas pas là pour ce second meetup du FKUG consacré aux jeux Kanban, et hébergé chez Criteo. Cette vidéo vous donnera un bref apperçu de ce qui s’est passé durant ce meetup. Grand merci à Gwenael Bonhommeau pour son excellent travail !

Mon CR du premier meetup est ici.

Venez comme vous êtes au FKUG !

“venez comme vous êtes”, c’était le thème de cette première rencontre des affiionados de Kanban ! Au programme : 2 présentations chez “un grand de l’assurance dont le nom commence par A” et “l’acteur majeur des paris hyppiques en France”. Couthaïere Farfra, à l’origine de ce groupe, assurera la première présentation, ainsi qu’une rapide et efficace présentation du groupe, de ses objectifs et de son organisation.

A force de trainer mes guêtres dans diverses réunions agiles, on fini par connaitre du monde. C’est mon cas, et débarquer en connaissant déjà une bonne moitié de l’audience est plutôt agréable, on se sent en famille. Cela a aussi son petit côté jubilatoire quand ceux que vous ne connaissez pas vous voient aborder tout le monde comme s’il s’agissait de vieux amis (c’est d’ailleurs le cas pour certains). On s’amuse comme on peut, n’est-ce pas ?

Kanban à grande échelle chez un grand de l’assurance.

Couthaïer nous fait ici un retour sur la mise en place, les pratiques et les impacts d’une mise en place sur un grand plateau de développement impliquant un grand nombre d’équipes, en mode distribué qui plus est : les product owner étant sur un autre site. Cette transition vers Kanban s’est opéré à partir d’un processus “Scrum”. Je mets des guillemets car à la description, il me semble qu’il s’agissait là d’un Scrum “Canada Dry”, customisé pour les besoins du client comme on dit. Chaque fois que j’entends cela, je sais que je ne dois pas m’attendre au meilleurs…

image

Quoi qu’il en soit, cette mise en place a commencé par un pilote : 2 équipes totalisant 30 personnes (tout compris). L’accompagnement a pris une allure standardisée : 8 semaines à temps plein par coach et par équipe. Chaque coach ne s’occupe que d’une équipe ! Au niveau de a portée du suivi, sont exclus :

  • La partie amont : identification et spécification du besoin
  • La partie aval, dévolue à la partie “devops” !

Les objectifs sont également clairs :

  • La satisfaction du client
  • Améliorer la qualité
  • Tenir les promesses (!)

La mise en place du Kanban reflète le backlog, avec des passages d’état : MMF >> Acceptée >> Critère d’acceptante >> BDD >> INVEST >> Dévelopment >> Tests

A cela se rajoutent bien sûr la mise en place de limites, qui doivent à terme nous permettre de connaitre la véritable capacité de notre système. La maitrise de cette capacité est en bonne partie subordonnée au fait que les stories entrant dans le système sont relativement homogènes en terme de taille. Dans la pratique, elles sont estimées au stade “INVEST”.

Au Kanban lui-même s’ajoute la mise en place de KPI : ici c’est le “cockpit”. Tout cela est bien beau, mais prends beaucoup de place. En fait, le plus gros problème est là : trouver des murs pour afficher ces Kanbans !

Supprimer les gaspillages

Ils sont subordonnés aux obstacles. Et les obstacles, il faut les surmonter. Ils sont de deux types: les petits obstacles et les gros obstacles.

Pour les petits obstacles, on passe par des fiches Kaisen. La revue des obstacles s’effectue lors du stand-up sur le tableau de suivi des obstacles.
Pour les gros obstacles, on passe par des A3 et des Kata.

Réduire les anomalies

Le pair testing est une activité clé ici, dans le cas présente entre un développeur et un testeur. Les anomalies sont considérées comme critiques : on les traitent sans attendre. Au bout du compte, un ratio d’anomalies très réduit, de l’ordre de 0,7 anomalies par User Stories.

La délocalisation : c’est tellement mieux de se compliquer la vie…

Comme je l’ai évoqué, le “avant”, c’était du Scrum pas vraiment “by the book”. En fait, un mixte qui me semble un peu contre nature entre Scrum (au moins le vocable), CMMi et le near shore. C’est une des difficultés de la chose.

La réponse mise en oeuvre est un Kanban miroir sur le site délocalisé, synchronisé au début du stand-up commun aux différents sites. Cet aspect de synchronisation est un des aspects difficiles. Les outils électroniques n’ont pas ce problème mais leur lacune en terme de visualisation limitée pose d’autres questions…

Tenir les promesses

Le CFD (cumulated flow diagram) est l’outil utilisé à priori pour suivre la machine Kanban. Il donne des indications sur :

  • Le débit
  • Les goulots d’étranglement
  • Les en cours

Cela dit, il n’est pas facile à lire… Le CFD montre verticalement le débit, il peut permettre d’extrapoler une date d’atterrissage et montre aussi les perturbations, là où la monotonie de la courbe est rompue. L’axe horizontal montre les temps de cycle, du moins une approximation de ceux-ci. On peut comparer les deux approches, mais c’est un poil compliqué.

Le suivi du Kanban, c’est aual le suivi d’indicateurs issus de son évolution. Ici ils sont mis à jour hebdomadairement. Un point crucial est que la pertinence des informations reste très subordonnée à l’homogénéité des items qui figurent sur ce Kanban !

Pause éclair

Guère beaucoup de temps pour se dégourdir les jambes, on a à peine 5 minutes pour cela. J’aimerais bien échanger avec certaines personnes. Ce sera pour après, peut-être…

image

Renaud Chevalier : La conception d’un Kanban en suivant la méthode Morrisseau

Laurent serait fier de son disciple : Renaud va nous faire suivre la mise en place de son Kanban en suivant sa méthode. Il l’apprécie et elle marche. Démonstration.

Cette mise en place a été effectuée chez “l’acteur national majeur des paris hippiques”. Si vous n’avez pas compris,cherchez encore. Il nous faut remonter à Septembre 2012 pour comprendre l’origine de cette mise en place. A l’époque, le projet fait face à deux inquiétudes majeures :

  • Un problème de “qualité” de backlog, qui ne donne que 2 sprints de visibilité. En tout cas, c’est rangé dans les problèmes par le management.
  • Un risque technologique lié aux choix opérés : Du Java en back-end exposant des services ReST, un front-end en backbone.js et une gestion de contenu accédée en ReST ; c’est du Drupal. Ce n’est pas la mort, mais bon on est chez … af ! C’est vrai… on ne peut pas le dire !

La dessus, la vision macro de ce qui reste à réaliser annonce 1 an de retard ! Branle-bas de combat ! Audit !!

image

Les propositions issues de l’audit proposent entre autre la mise en place d’un grand Kanban transverse, voilà qui est intéressant ! En plus, ça ne parait pas si difficile, un Kanban. Il est rapidement mis sur pied.

Hélas, trois fois hélas : au bout de 2 semaines seulement, ce Kanban ne vit plus ! Que s’est-il passé ? Renaud décide de reprendre les choses à la base, donc de suivre la démarche de Laurent Morrisseau.

image

La portée et les objectifs

Justement, on met directement le doigt là où ça a pêché : une portée trop importante de ce Kanban initial ! La portée du Kanban doit être celle où l’équipe est propriétaire du processus. Ce n’était pas le cas du Kanban précédent, remontant trop en amont (dans l’élaboration du besoin) et en aval (dans la partie production / exploitation).

De plus, inutile également de produire un Kanban correspondant à un processus cible. Il faut commencer là où l’on est, avec le processus courant.

Pour matérialiser les objectifs, il faut identifier ceux-ci ainsi que les insatisfactions actuelles. Cela s’est fait sous forme d’interviews.

La nature de la demande

Pour la connaitre, il faut identifier ce qui arrive à l’équipe, ce qui l’alimente. Dans le cas présent, on a :

  • Les anomalies en provenance de la QA
  • Les demandes du marketing
  • Les “stories techniques”
  • La dette technique

La question subsidiaire est celle de la taille de ces demandes. Comme on l’a vu précédemment, la qualité du Kanban est subordonné à l’homogéneité des items. Ici, Renaud va utiliser les tailles T-Shirt pour évaluer ces items (S, M, L, XL).

Enfin, pour se faire une idée de la situation actuelle, on procède à 3 analyses:

  • Débit par Sprint et par type de demandes
  • Débit par sprint et par taille T-Shirt
  • Débit par catégorie d’anomalies

Le flux de travail et carte Kanban

Au départ, il faut identifier le workflow spécifique à chaque type de demande. En l’occurrence, chacune des 4 catégories a son propre cycle, seules les demandes marketing rentrant dans les sprints !

4 catégories de demandes, cela veut dire 4 cartes Kanban. Elles diffèrent légèrement en contenu en fonction de leur type, mais les éléments de même nature se retrouvent au même endroit : la rigueur d’organisation est un facteur clé d’efficacité. On affectera aussi une couleur spécifique à chaque type de demande. Nous verrons que cela s’avère très important au niveau du tableau.

Le tableau

Justement, le tableau nous y sommes ! Et l’on commence par déterminer les règles de priorités des demandes, quel que soit leur type. C’est intéressant, car on a coutume de subordonner la priorité au type. Or ici on va utiliser l’évaluation du “cout du délais”. C’est une bonne façon d’éviter de se faire hacker le système en transformant une demande en anomalie, par exemple !

Donc, sur ce tableau, on commence par alimenter le système par type de demande, et le premier triage consiste à réalimenter la suite du tableau par classe de service en utilisant ce facteur de cout du délais. Comme chaque classe de service peut théoriquement contenir n’importe quel type de demande, il est opportun de pouvoir facilement distinguer facilement ces différents types : d’où les couleurs !

Règles, règles…

C’est là que l’on rentre dans le volet pas très “agile mind set” du Kanban. Cela couvre 3 volets :

  • Les règles aux interfaces : Quelle règle pour réalimenter le système ? Quel règle pour déclencher la sortie des items ? C’est aussi (surtout) une question diplomatique avec les équipes avec lesquelles on collabore…
  • Les règles internes. Elles sont de plusieurs types. La principale est la “definition of done” qui permet à une carte de passer à l’étape suivante. Les autres règles traitent des exceptions (escalade, changement de priorité, annulation, etc.)
  • Enfin, la grande question : qui s’occupe du respect des règles. La réponse est : le process manager ! Oui, vous avez bien lu, on a un process manager, comme il y a 20 ans !

La capacité du système

Le système en place, il s’agit maintenant de le monitorer et le “tuner”. Au départ, il faut fixer des limites hautes et basses, de manière plus ou moins empirique au départ. Un point particulier concerne la gestion de la dette technique : on en garde toujours une en cours. C’est un tâche de faible prioité qui peut être interrompue pour répondre à une classe de service de niveau le plus élevé.

Le juste à temps et la cadence

Travailler en mode Kanaban ne signifie pas abandonner complètement les rituels réguliers. En fait chaque rituel a sa propre cadence, et ce n’est pas calé de manière global sur une fin d’itération. En fonction du type de cérémonie, on trouvera des rythmes :

  • Journaliers
  • Hebdomadaires
  • Pluri-hebdomadaires

</FKUG #1>

Si j’ai trouvé la seconde session particulière instructive et bien présentée, je dois dire que globalement le contenu de ce premier rendez-vous valait largement le coup. En fait, il était même mieux que ce à quoi je m’attendais !

Expérience réussie, donc. J’ai hâte d’être au second rendez-vous !