#fkug

Outil #2 : Project Report

Oui, malgré que l’on soit en mode agile, le management continue à demander des reports comme au bon vieux temps. Là aussi la motivation est de permettre de générer cela en économisant l’énergie à produire ces rapports, car tout comme dans l’outil précédent, les données sont directement issues de TFS.

Pour l’essentiel il s’agit de données agrégées des projets pour permettre d’avoir un indicateur global du projet en un coup d’oeil. Cet appréciation va même jusqu’à l’aspect budgétaire !

Outil #3 : Quality Report

Comme pour le second outil, il s’agit là d’avoir des vues synthétiques d’information. Mais cette fois ce sont des informations sur le code et les builds ! Cet outil semble moins pertinent avec la dernière mouture de TFS, mais son architecture lui permettrait d’être frontal d’autres outils comme Jira, car il est agnostique par rapport au back-end.

Et par rapport aux boards physiques ?

La position prise dépend des équipes. Pour Thomas, la bonne position consiste à utiliser … le board physique autant que possible. Il permet un niveau d’appréhension et de personnalisation que ne permettent pas aujourd’hui les outils électroniques. La plus grande plus-value de ceux-cis se situe à deux niveaux :

La communication entre équipes distantes.

La génération automatique d’indicateurs.

Jira Agile, par Basile Le Plessis

Basile est très à l’aise avec Jira Agile, un outil qu’il déploie très régulièrement dans des équipes. A l’origine, cet outil s’appelait Greenhopper. L’outil permet d’accéder à deux types de boards (qui sont en fait des vues vers les tickets Jira) :

Un board Scrum

Un board Kanban

Ces deux boards ne présentent pas les mêmes fonctions, et c’est en fait le board Scrum qui est le plus riche des deux. Par défaut l’outil proposera un board avec 4 colonnes qui correspondent à autant d’état du workflow Jira. Mais ces colonnes sont évidemment configurables (3 grands types : A faire, en cours, terminé), chaque colonne pouvant d’ailleurs représenter une conjonction d’états ! La flexibilité de cette configuration a un revers : si on se rate, on peut créer des tickets qui ne sont pas visibles sur le board !

Il est également possible d’ajouter des swimlanes, ainsi qu’un ensemble d’ajouts tels que des « filtres rapides » des couleurs associées à des sous-requêtes, etc...

Tout est configurable dans Jira, c’est sa grande force. Mais cela demande une bonne prise en main, car l’ergonomie tourne souvent au cauchemar sur tout ce volet configuration… D’ailleurs si Jira Agile est le successeur de Greenhopper, l'ergonomie semble estimée en retrait par rapport à la première mouture !

En parlant de configuration, il y a quand même quelques contraintes, entre autre sur l’édition de workflow et la réversibilité des migrations (ok, j’en demande beaucoup).

Par contre, l’outil hérite des capacité d’extensibilité de comportements et de modules de Jira. Il est par exemple possible d’associer des comportements aux transitions d’état. Et les modules Jira sont déjà un écosystème très riche !

Agile Bee, par Laurène Vol

Bee, c’est essentiellement un tableau de bord pour les projets menés en Agile, un tableau de bord à même de montrer un portefeuille de projets et d’en donner une vue uniforme. Pourquoi ?

Pour le décideur, pour lui donner de la visibilité sur les livraisons en extrapolant le « quand » on livre.

Pour l’équipe, lui permettre de suivre les indicateurs opérationnels.

De mon point de vue, il semble s’adresser avant tout aux décideurs.

Maintenant, d’un point de vue pratique, comme cela marche-t-il ? Les données doivent être extraites de Jira ou de TFS, etc… en format CSV, puis intégrées dans Bee. C’est assez rustique. La connexion via des APIs devrait arriver dans une version ultérieure. La bête est hébergée sur Heroku, c’est donc avant tout un outil SAS, même s’il peut être déployé chez les clients (avec les difficultés de mise à jour que l’on connait).

L’outil rappelle un peu le « happy board » d’AXA, avec des indicateurs tels que :

Atterrissage du backlog (via des extrapolations calculées sur 3 itérations).

Suivi budgétaire on track / off track ; il permet également de déduire le coût moyen des stories. En pratique, ce suivi s’appuie simplement sur le nombre de stories réalisées dans l’itération et le « coût » d’une itération.

Les Bugs, dont le ratio de bugs et le suivi des bugs ouverts et fermés.

La Productivité (quand je vous disais que cela intéressait avant tout les managers…). Son suivi se base sur le flux et la cadence et son évolution au fil du temps.

Feature matrix : une fonctionnalité permettant l’agrégation de stories par MMF.

Calcul de la prédictibilité, en se basant sur une vision flux.

Le point réellement fort de cet outil est son ergonomie et la qualité de son rendu visuel. Tout est très bien fait jusque dans les moindres détails.

Kantree

C’est l’invité surprise de ce meetup ! Kantree est un  produit est développé par une petite société, le démarrage de ce projet étant surtout guidé par la passion ! L’outil s’inspire profondément de Trello, l’ergonomie respire de cette inspiration (si je puis dire). La grande différence est que Kantree permet une gestion de boards multi-niveaux : chaque carte peut elle-même devenir un board ! Chaque niveau de board peut par ailleurs avoir son propre workflow.

Au-delà des boards multi-niveaux, l’équipe travaille activement à des fonctions se différenciant de Trello : association d’une date à une tâche, synchronisation avec Github et personnalisation des attributs.

Cette sympathique équipe investit beaucoup sur le développement de cet outil dans le but de développer une activité d’éditeur autour. Cela me laisse dubitatif, car même s’il présente des particularités intéressantes, le marché est déjà bien occupé par des éditeurs avec une forte présence. De plus ce type d’outil est exposé à terme à une « comoditisation » et est destiné à perdre de la valeur. Du moins à mon avis.

Autour d’un verre

L’agenda de la soirée était plutôt riche et chargé, un style auquel le FKUG commence à être coutumier. Il est maintenant temps de tailler dans le saucisson et la canette de bière. J’en profite pour échanger avec Thomas Declercq à propos de la question « tableau physique versus tableau électronique ».

Initiation au Kanban avec Pascal Poussard

C’est toujours un plaisir pour moi d’entendre Pascal. Cette fois encore, il nous gratifie d’une session d’initation au Kanban clair et énergique, se concentrant sur les aspect importants de l’approche. On pourra juste lui reprocher de faire des infidélités au Scrum User Group (dont il est l’un des membres éminents du bureau) pour faire une pige au FKUG !

4 objectifs et 2 notions clé

La Kanban, c’est surtout 4 objectifs :

La qualité

Equilibrer le rapport demande / débit

Livrer souvent

Réduire la variabilité

Deux notions clé font de Kanban une approche radicalement différente.

La chaine de valeur : Ici, elle part de l’aval. C’est la demande qui contrôle la mise à disposition, d’où la fameuse notion de « flux tiré ».

Le temps de cycle : On ne parle plus de vélocité ou de capacité. Kanban se focalise sur le délai entre la demande et la mise à disposition au-delà de toute chose. Si cette notion n’est pas importante pour vous, sans doute n’êtes-vous pas un bon candidat au Kanban. Mais réfléchissez bien...

6 principes

Visualiser la chaine de valeur. C’est la première pierre du Kanban. Car visualiser cette chaine de valeur, c’est rendre compte de manière claire de ce qui se passe, créer une adhésion autour de celle-ci et permettre de « casser les silos ».

Limiter le travail encours (WIP limit). Ce principe est à la fois le moteur du flux tiré et de la réduction du temps de cycle.

Gérer le flux. Dans un système, le flux est limité par son goulot d’étranglement (théorie des contraintes). Cette dernière nous dit aussi qu’il y a nécessairement un goulot d’étranglement dans le système, qu’il faut décider (et non subir) où celle-ci se positionne et subordonner le système à cette contrainte.

Rendre les processus explicites. Comme les approches agiles, Kanaban est une école de rigueur : les règles de passages sont clairement définies, ainsi que les procédures exceptionnelles.

Amélioration continue. L’observation et la mesure de ce qui se passe nous permettent de déterminer ce qui peut faire l’objet d’amélioration.

Feedback : Celui-ci vient des mesures et de la voix du client.

Pour quel contexte ?

Si notre flux de travail n’est pas équilibré.

Si notre chaine de travail est surchargée.

Comment commencer ? Avec ce que l’on a, simplement en rendant notre processus explicite. Puis en enclenchant des cycles d’amélioration.

Retrouvez ici la prestation de Pascal.

Ainsi que le support de sa présentation.

Le management visuel et l’Obeya, par Christophe Keromen

Au commencement

On commence fort avec Christophe en se posant la question suivante : pourquoi faire un management visuel ? Pour nous pousser à l’action ! Si celui-ci n’atteint pas ce but, il faut le jeter !

Pourquoi doit-il être visuel ? La Programmation Neuro-Linguistique nous dit que des 5 sens, le VAKOG de la PNL, c’est le sens visuel qui est dominant, car notre cerveau est efficace pour reconnaitre les motifs.

La question suivante sera donc : qu’en fait-on ? On va s’en servir pour rendre visible les problèmes, et rendre aussi visible le lien entre le problème (que l’on refuse souvent de voir) et l’action.

Commençons avec un tableau Scrum...

Celui-ci nous permet de rendre visible la progression. Mais rend-t-il visible le challenge ? Permet-il de voir les « impediments », les boulets qui nous freinent ?

Christophe nous résume ainsi ce que le management visuel rend possible :

Voir ensemble

Agir ensemble

Apprendre ensemble

Pour permettre cela, il faut non seulement faire attention à l’information que l’on montre (et qui conditionnera tout le reste), mais faire en sorte que l’information représentée sur ce tableau soit :

Univoque

Visible

Interactive

Un tableau soigné

Cela commence en soignant ce tableau au niveau du contenu. Ce sont les « 3 U » :

Utile (ce qui n’est pas utile constitue une pollution)

Utilisable

Utilisé (quelle est la dernière chose que vous avez apprise avec le tableau ?)

Cela signifie aussi un tableau soigné du point de vue esthétique. Eh oui je confirme : personne ne va aller voir un tableau moche !

Du manangement visuel à l'Obeya

Que doit montrer d’autre notre management visuel ?

Les objectifs (le challenge)

Les règles

La vision

C’est de tout cela dont on parle quand on évoque l’Obeya. Mais l’Obeya, c’est aussi un espace, l’Obeya Room, à l’agencement très spécifique. Le but ? Se mettre en position de faire du Kaizen !

Retrouvez ici la présentation de Christophe Keromen en vidéo.

Ainsi que les slides de sa présentation.

La résolution de problèmes avec le A3, par Laurene Vol

Le A3, c’était probablement la présentation que j’attendais avec le plus d’impatience. Mais ce fut aussi probablement la présentation la plus faible, hélas. Non pas qu’elle fut mauvaise, mais elle est restée très « by the book ».

Un A3 pour traiter des problèmes

Et ces problèmes, comment sont-ils identifiés ?

De manière spontanée, durant l’itération, quand on tombe dessus !

En rétrospective

Via des indicateurs

Ces problèmes, Laurene nous propose de les collecter au sein d’un tableau, plus précisément dans une matrice de Merill-Covey. Vous connaissez déjà certainement.

A partir de là, des règles nous permettront de déterminer la manière dont nous traiterons ces problèmes. Pour certains d’entre-eux, ce sera le A3 !

Du contexte à l'analyse

Le A3 débute avec une partie « contexte ». Elle répond à la question : Pourquoi en est-on là ?

Vient ensuite le « current state » : un état initial quantifié et si possible illustré avec un schéma. Si des contournements sont déjà mis en oeuvre, ils sont exposés.

L’objectif, c’est l’état final désiré. Il est lui-même quantifié.

La partie délicate, c’est bien l’analyse. On privilégie l’analyse causale à l’aide de différentes techniques : les 5 pourquoi, les diagrammes de cause-effets ou les diagrammes en arêtes de poissons.

Vous avez trouvé mon compte-rendu trop succinct ? Regardez la vidéo de l’intervention de Laurene.

Son support de présentation est également disponible.

Kaizen & PDCA avec Julien Karoubi

Je dois avouer que Julien affronte des challenges que je n’oserai pas, même dans mes jours les plus téméraires.

Ainsi, pour illustrer le principe de l’amélioration continue, Julien a proposé un jeu !

Ce jeu, Julien l’a imaginé spécialement pour cette soirée. Il s’agit d’effectuer des itérations et de consacrer un peu de temps pour trouver des améliorations de fonctionnement, à l’image du Ball Point. Ici, Julien s’évertue également de perturber le système en intervenant au milieu des itérations, histoire de casser de rythme et voir comment l’équipe réagit !

Résultat moyennement concluant. On arrive à la même productivité avec ou sans temps consacré à l’amélioration. Mais on doit pendre en compte que du temps de travail est alors consacré aux rétrospectives. Il faut dire que les tranches de temps sont réellement très courtes, surtout pour les rétrospectives. Voyons en video ce que cela donne.

Il était aussi audacieux de la part de Julien de faire ce jeu dans une configuration de soirée « plénière » : Il y avait 80 personnes dans le showroom Zenika, probablement moins de 10 pouvaient voir et suivre réellement ce qui se passait.

Quoi qu’il en soit, cette cassure était bienvenue dans ce marathon de présentations !

Key Performance Indicators pour Kanban, par Yannick Quennec'hdu

Yannick est très, très affuté (et expérimenté) sur les mises en place de Kanban et les mesures associées dans des contextes multi-équipes. On pouvait s’attendre à une présentation de haute qualité, nous l’avons eu !

Parlons pré-requis

Toutes nos présentations s’articulent bien ensemble, car pour Yannick, un pré-requis important est … la mise en place d’un management visuel ! Bon, il n’y a pas que cela. Il faut aussi que notre Kanban soit « stabilisé » également. Nous ne devons pas non plus perdre de vue notre objectif : rendre factuel notre Kanban !

Les indicateurs

Ils sont classiques, mais ça ne fait pas de mal de les reprendre :

Le Lead Time : combien de temps entre une « commande » et un client servi.

Le temps de cycle : Le temps séparant deux évènements identiques. C’est donc l’inverse de la fréquence et vice-versa.

Le débit : Le nombre d’items livrés dans un laps de temps donné. Là on ne parle plus d’étape du processus, mais de ce qui sort du Kanban !

Le travail en cours : combien d’éléments sont en élaboration aux différentes étapes du processus !

Le diagramme de flux cumulé est l’outil de prédilection permettant de mesurer et voir évaluer la plupart de ces indicateurs. Ca, c’étaient les bases. Et maintenant, voici...

Le grand Mix

Ces indicateurs se combinent pour voir les corrélations entre ces indicateurs.

La loi de Little : Elle indique que le temps pour terminer est inversement proportionnel à l’en cours. Donc réduire l’en-cours augmente le débit !

La prédictibilité : Un indicateur compliqué, basé sur le débit et la taille des tickets.

L’efficience : Pour mesurer dans notre processus, le temps qui ajoute de la valeur au produit. En pratique, on isole les zones tampon et l’on mesure le temps que le ticket y passe.

La qualité : C’est le coût de la non-qualité qui est mesurée, via des « tâches rework », par exemple. Yannick utilise cela pour mesurer la valeur économique de l’accroissement d’une équipe de tests !

Variabilité : Ces variabilités peuvent être locales ou globales. Je vous recommande la vidéo de l’intervention très riche de Yannick

Et aussi, bien sûr, le support de sa présentation.

Mesure de la maturité par Nicolas Lochet

La soirée n’est pas encore tout à fait finie ! Nicolas nous expose à la vitesse de la lumière une grille d’audit de maturité Kanban, basée sur les éléments du livre de Laurent Morrisseau.

Il n’y a pas de support de présentation, car Nicolas nous présentait directement sa feuille Excel (que je n’ai pas non plus). Hélas, nous n’avons pas également de captation vidéo de cette intervention.

Enfin, un petit « preview » ne fera de mal à personne : voilà !

On a soif !

Il est plus que temps d’aller au ravitaillement. Vider le frigo rempli de bières et les petits fours et autres provisions de bouche laissées à disposition, telle était notre dernière tâche !

Ce que j’en ai pensé

Ce Meetup était vraiment très riche. La mission était d’initier le plus grand nombre aux éléments de base de Kanban. Les diverses présentations ont réellement rempli ce rôle. En fait l’agenda était même trop ambitieux. Nous aurions eu de la matière pour deux soirées ici.

Second point, bien que mineur : je n’ai pas compris la nécessité de rendre cette soirée payante. D’autant qu’étant hébergée chez Zenika, tous les coûts étaient assurés par l’hôte ! Cela n’a pas freiné les ardeurs (et la contribution demandée était minime) et cela a certinement alimentée la caisse de l’association.

Le FKUG montre une fois de plus son dynamisme, non seulement à organiser une soirée par mois, mais à varier les formules de ces soirées. Un rythme et une variété que j’avais escomptée pour le Scrum User Group il n’y a pas si longtemps que cela, et qui reste à retrouver.

Apprendre à apprendre pour le 21ème siècle, par Yannick Grenzinger

Cette session, seul Yannick pouvait nous en gratifier ! Sur la dernière année, Yannick a suivi 30 cours en ligne, les fameux MOOCs, il est en quelque sorte un « boulimique du savoir » !

Cette présentation, que Yannick propose par ailleurs au format Brown Bag Lunch s’articule sur 3 niveaux : l’individu, le produit, l’organisation.

Apprendre pour les individus

Ici, Yannick nous propose quelques « hacks » :

Déconstruire pour mieux reconstruire : faire des tranches d’une dizaine de minutes. Cette déconstruction est déjà une étape de l’acquisition de la connaissance !

Des répétitions fréquentes, mais espacées (!)

S’appuyer sur l’utilisation de modèles mentaux et de métaphores. Tiens ? Cela ne vous rappelle-t-il pas XP ?

Eliminer les bloquants.

Utiliser une boucle de feedback rapide. Nous autres agilistes sommes en terrain connu…

Bien sûr, pour faire bonne mesure, Yannick sait aussi nous proposer quelques bonnes lectures :

Moonwalking with Einstein, de Joshua Foer

The 4-hours chef, de Thimothy Ferriss

The First 20 Hours, de Josh Kaufman

L’un des points majeurs est qu’il n’est pas besoin d’avoir une « connaissance parfaite ». Les fameux 80% sont largement suffisants et s’acquièrent comparativement rapidement !

Apprendre sur les produits

Et déjà, sur la construction de produits, quel est l’inverse de l’apprentissage ? Le « cycle en V » bien sûr ! Et bien entendu, notre objectif est bien d’apprendre en permanence. Notre attirail d’agiliste possède ce qu’il faut à ce égard : Rétro, A3, Kaizen, etc…

Apprendre, c’est aussi utiliser le pouvoir de la collaboration et les techniques de co-création.

Enfin, apprendre c’est aussi accepter l’échec et penser à « aller plus vite sur l’échec ». C’est ce que nous enseigne le Lean Startup.

Apprendre en tant qu’organisation

De nouveau la même question : quel est l’inverse de l’apprentissage ? C’est le Taylorisme : un travail codifié devant être exécuté sans reflexion par des executant dont réfléchir n’est pas le rôle !

Apprendre au sein d’organisation, c’est d’abord savoir organiser pour la complexité, plutôt que chercher à la maîtriser ou le réduire à tout prix. Le Stoos Network a pour but de faire progresser ce mode de pensée, bien que force soit de constater qu’il peine à prendre de l’ampleur. Le rôle du management est à repenser dans une organisation apprenante. C’est ce que nous enseigne le Management 3.0, mais aussi les militaires dans le manuel Warfighting !

Ce que j’en ai pensé

Je sors un peu frustré par cette session. De l’aveu même de Yannick, la partie « organisation » nécessite d’être renforcée. Mais c’est surtout sur la partie « individu » que l’on attendait l’orateur, et malheureusement il ne développe pas assez ses « hacks ». Nous aurions aussi aimé une reflexion sur la nature (et l’objectif) différent de l’apprentissage au 21ème siècle, à l’ère de l’information à haute valeur disponible au bout des doigts ! Toutefois, je sors aussi avec quelques pointeurs de lecture (encore). Connaissant Yannick, ils valent sans aucun doute le détour !

Continuous Delivery : A Plug-in for Kanban, par Samuel Retière

Il s’agit en fait d’une présentation qui serait fait à 3 voix au LKF, ici il n’y avait que celle de Samuel. Je ne vais pas paraphraser la présentation de Samuel, car vous pouvez y accéder ici.

Ce que Samuel nous présente ici, ce sont les « patterns de transformation » appliqués à la SGIB et organisé en 3 niveaux. Les thèmes s’articulent beaucoup autour du Kanban Thinking de Karl Scotland : valeur, flux et potentiel

Le niveau 1 n’a peut-être l’air de rien, mais on y parle déjà cycle TDD et flux !

Le second niveau correspond déjà à une maturité acquise par bien peu d’équipe. On y trouve pèle mêle une pensée produit épaulée par du Lean Canvas, du BDD, du Flux « end to end », donc avec du devops à la clé !

Au niveau 3, on trouve des choses bien plus rares telles que la maximisation de la valeur « infrastructure as code ».Et le seul élément que j’ignorais de la présentation : le Black Swan Coaching ! Plus curieusement, on y trouve le DDD que j’aurais mis personnellement au niveau 2 au maximum. Peut-être même au niveau 1 !

Le programme inclut un cocktail de cours, de workshops et de katas. Le tout épaulé par 3 coaches qui permettent de couvrir le spectre de compétences évoqué. Impressionnant !

<

Fin

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.

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.

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…

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 !

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

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.

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.

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…

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

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.

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 !