“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…

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 !

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