Compte-rendu de la première LeanKanban France

Jeudi et vendredi derniers se tenait la toute première LeanKanban France. J'y étais pour présenter avec Hervé Lourdin notre speech sur l'agilité à grande échelle (un retour d'expérience sur un gros projet).

Une conférence de très bon niveau, internationale, avec des keynotes de haute volée (David Anderson, Stephen Parry, et Don Reinertsen), et des sessions toutes intéressantes. Une centaine de participants, pas le même public que les confs Agile. Il valait mieux être familier avec les concepts de base de Kanban et de Lean, parce qu'on s'est pas embarrassés de redéfinir les concepts, on est rentrés dans le dur !

Keynote de David Anderson : "Understand Agility and how to improve it with Kanban"

Le manifeste agile, c'était il y a 11 ans, certains travaillent sur ces concepts depuis près de 20 ans -> il est temps d'avancer maintenant :-)

• Pour implémenter une vraie agilité : ne pas calquer une méthode by-the-book, agir localement en fonction de votre contexte. Comprendre les principes sous-jacents de l'agilité.
• Les gens vont résister aux changements de process
• Savoir avancer avec une information incomplète
• Promouvoir une forte culture de la confiance (il souligne avec raison que c'est pas le plus facile dans la culture française...)
• Comprendre que le stock de WIP c'est un passif/une dette, et non un actif/de la valeur
• Améliorer le Lead-time pour répondre plus vite
• Comprendre que le travail sur la connaissance est périssable. L'information a une demi-vie qui se compte en jours ou semaines
• Créer des feedback loops pour s'adapter
• Une éthique du craftsmanship, du travail bien fait
• Des améliorations incrémentales, tu ne sais pas a priori quel est le bon process, "there's no target process"
• Kanban : un système pour signaler une capacité de production disponible
• Definitions of Done : pour arbitrer entre vitesse du flux et qualité du produit. Permet aussi d'ajuster la prédictibilité
• CFD (cumulative flow diagram), lead-time : l'important c'est de mesurer la distribution du lead-time (et non pas une moyenne), il y a des choses à comprendre dans les valeurs extrêmes du lead-time
• Classes de services classiques = Expedite, Fixed delivery date, Standard, Intangible (=important mais non urgent, = pas de coût du délai)
• Comprendre que le backlog c'est une wish-list, mais les tickets sur le board = on s'est engagés
• Last Responsible Moment = retarder l'engagement
• Créer des organisations agiles (et pas seulement des projets)

Si vous cherchiez "le Kanban en 3 slides", en voilà déjà 2 ;-)

Le décor est planté pour la suite...

"Emergent Patterns in Kanban systems for IT operations" : Dominica de Grandis (de chez David Anderson & Associates)

Session fort intéressante. Dominica a visité des prods et a repéré les patterns de ceux qui pilotent leur activité "Ops" à l'aide de Kanban. Là où, côté Dev, on va avoir des problèmes de : dette technique, priorités changeantes, objectifs contradictoires, mauvaise communication ; côté Ops, on repère plutôt : des équipes éclatées, des interruptions, des dépendances entres équipes différentes, de la sur-spécialisation des équipiers.

Patterns :

• Pour les équipes éclatées : des kanbans électroniques, partagés, avec des tâches et un workflow simples, et du chat associé au ticket (cf Trello). Et des solutions de collaboration depuis Google Hangout, jusqu'à des solutions haut-de-gamme de présence virtuelle.
• Pour les interruptions : les rendre visibles ! Soit en créant des tickets à chaque (mais c'est un coût de transaction qui est peut-être élevé au regard de la tâche), ou plus simplement en traçant un bâton rouge sur la tâche en cours qui vient d'être interrompue.  Autre pattern, le Goal (dont on avait déjà parlé ici : blog.octo.com/en/devops-tips-and-tricks-on-the-ops-side/).
• Dépendances entre équipes : matérialisez vos vrais process sur le kanban. Si ça passe par d'autres équipes, matérialiser cette dépendance et une zone d'attente correspondante.
• Sur-spécialisation des équipiers (ne maitrisent qu'une seule techno) : Avoir une swim-lane par équipier est plutôt un anti-pattern. Préférer une swim-lane par compétence ou type de tâche, et valoriser ceux qui sont polyvalents et interviennent partout.

2 choses que je retiens :

• matérialisez des flux réalistes, et avec un peu de talent graphique c'est génial :-) pic.twitter.com/7W8f5Uzp
• l'objectif essentiel du kanban chez les ops, c'est afficher les risques.

"Lean Programme Transformation" : Patrick Steyaert

Pas mal. Ca parle Lean, mais présenté d'une façon différente de ce qu'on voit d'habitude.

Son speech débute par une anecdote à propos d'une histoire de stock de pêche près d'une île au Canada, qui est passé d'un seuil bas, problématique sur le plan économique à un seuil très bas, problématique pour la survie même de l'espèce. Et cela a été causé par... un programme censé améliorer la situation. Programme mené avec force analyse scientifique et méthodologie. Bref, en fait un problème de systémique.

De retour à des sujets + IT, Patrick nous recommande d'arrêter de travailler avec des processus focalisé sur l'optimisation, car :

• sont trop centrés sur des problématiques IT, et oublient la problématique business
• considèrent l'environnement comme invariant, et avec des projets aux budgets, périmètres et délais fixés
• se focalisent trop sur le contrôle du budget, ce qui génère toutes sortes de dysfonctionnements
• favorisent des Big-Design-Up-Front et les "one-size-fits-all"

Le Lean nous apporte beaucoup plus de résilience, car :

• a des perspectives plus larges
• intègre le fait que l'environnement change tout le temps
• se focalise sur la mesure du résultat
• prend en compte les spécificités locales

Le Lean, c'est :

• raisonner sur la valeur,
• le système pull (-> Kanban),
• le flux,
• la notion de standard particulière au Lean ("le standard est la meilleure pratique connue à ce jour pour résoudre un problème"),
• le management visuel,
• et votre obstacle sur le chemin sera la résistance au changement.

"Kabanisation In Progress" : Guillaume Anciaux (SGCIB) & Thierry Montulé

Un REX. Guillaume est responsable d'une application utilisée par des traders, qui existe et évolue depuis 10 ans. Il dirige une équipe d'une quinzaine de devs. Là où c'est intéressant, c'est qu'il est dans un contexte que nous autres consultants expérimentons peu, car nous intervenons en général en mode projet. Lui a une dizaine de projets par an, portés par 3 sponsors business différents, des projets internes (budget DSI), de la maintenance. Tout ça sur cette seule application. Et des devs en off-shore (Inde).

Il était déjà en SCRUM, mais avait des douleurs, autour de la visibilité notamment. Il a eu la très bonne idée de se faire accompagner par un coach (Thierry) pour faire évoluer les pratiques.

Il ont mis en oeuvre des outils/pratiques qui ont largement amélioré les choses :

• une StoryMap pour partager la vision de l'étendue fonctionnelle, et faire collaborer les sponsors sur la priorisation. (Anecdote : l'idée de la StoryMap lui est venue suite au petit-déjeuner  OCTO. C'est beau :-)
• un Kanban avec des swimlanes (Expedite, Standard FR, Standard Inde), des WIP limits (sur la colonne DEV-Done, pour ne pas flooder les tests). Le Kanban FR donne une vision globale du projet. Les indiens ont un Kanban local, et envoient un mail après le Stand-Up Meeting pour dire quel ticket bouge où.
• des métriques à chaque release : quel sponsor est servi à quelle hauteur dans la realease, le lead-time par taille de UserStory, le temps passé dans chaque phase. pic.twitter.com/ITsK1hr2
• beaucoup de management visuel

Et maintenant, toute la SGCIB (j'exagère à peine ;-) vient visiter son plateau pour diffuser les pratiques. Super REX.

"Failing Well" : Jabe Bloom

Wow ! Je me suis fait retourner le cerveau, là... Bon, un peu trop de contenu malgré tout, des concepts avancés, donc dur à suivre. Encore plus à résumer ! Mais passionnant, et donne envie d'approfondir.

Le Lean nous dit "Fail Fast". Jabe propose plutôt "Fail Well", car il y a des façons d'échouer qui ne vont rien nous apprendre du tout.

La théorie de l'info nous explique que c'est quand on fait un test qui a une chance sur 2 d'échouer qu'on apprend le plus. En fait, ça dépend de l'objectif :

Jabe nous parle aussi de comment les scientifiques imaginent de nouvelles idées. Pas avec des techniques inductives ou déductives basée sur qu'on voit autour de nous. Parce que c'est le meilleur moyen d'être victime de la théorie du cygne noir ("you'll kill the first black swan you'll see !"). Il faut plutôt utiliser des techniques abductives (WTF ? http://en.wikipedia.org/wiki/Abductive_reasoning).

Pour imaginer des solutions, le brainstorming c'est mal, ça conduit trop vite au consensus. Il nous expose une autre approche, basée sur plusieurs petites expérimentations en parallèle, et basées sur des prédictions au départ.

Bon, je me rends compte que c'est difficile à résumer. Si vous avez envie d'aller plus avant, je vous invite à regarder la vidéo : http://vimeo.com/51685780. Personnellement ça donne envie de creuser, c'est passionnant.

Keynote de Stephen Parry : "Lean & Kanban : What's the purpose"

Malheureusement un peu trop compliqué, avec des slides chargées, en cette fin de (très riche) journée, donc difficile à suivre.

Son idée, c'est de ne pas rester trop focalisé sur la chaine de production avec notre approche Lean, mais de considérer l'ensemble de l'expérience utilisateur. Dans une grande organisation avec des silos fonctionnels, on a tendance à optimiser les silos, au lieu d'optimiser le global. => Optimiser le processus suivi par le client.

Il propose un framework pour établir des métriques :

        ^
        |

End-to-End | | Functional | +------------------> Matters to customer ? NO YES

Parry insiste également sur la dimension "Respect for people", trop souvent oubliée dans les implémentations Lean, ainsi qu'au but ("purpose") que l'on donne à ces initiatives.

Les slides de Stephen sont disponibles ici.

———

Fin de la journée, avec un buffet vin + charcuterie + fromages + bières australiennes sponsorisées par Atlassian :-)

——————————————————————————————————————————————

jour 2

Keynote de Don Reinertsen : "The science of WIP constraint"

Clairement la meilleure keynote. C'était autour des concepts que Reinertsen développe dans ses bouquins, session avec un contenu de haut niveau, mais claire et détaillée.

Son propos, c'est : le Toyota Production System (TPS) avec son PULL-system, c'est bien, ça marche, mais c'est empirique, pratico-pratique, et adapté à la fabrication de voitures. Si tu veux réutiliser ces concepts dans d'autres contextes, t'as plutôt intérêt à avoir une approche plus scientifique pour comprendre ce que tu fais.

Exemple d'un hôpital : si tu mets une WIP-limit sur le service des urgences, que tous les lits sont occupés, et qu'un patient en infarctus arrive, ça ne va pas bien marcher ! => Ici, c'est un problème de coût du délai qui varie beaucoup d'un patient à l'autre (alors que dans le TPS, ça ne change pas en fonction de la voiture).

2° exemple, une boulangerie : si je fais un PULL-system strict, je ne me mets à produire une baguette que lorsqu'un client en commande une. Ca ne va pas bien marcher non plus, car le lead-time cible du client est très éloigné du lead-time de production. De fait, il faut bien avoir du PUSH dans ton système, basé sur une prédiction des ventes. (En fait, c'est la même chose chez Toyota, il y a des frontières pull/push dans le flow).

Il nous explique ensuite la théorie des files d'attente, et pourquoi un système, chargé à 90% de sa capacité de production, avec de la variabilité, et sans contrainte de WIP  va forcément dériver et avoir des files d'attentes ingérables (cet exemple devrait parler à tout chef de projet de développement logiciel...). Un peu de maths : si je cale une WIP limit qui diminue l'utilisation de mes ressources de 1%, j'ai déjà 30% de réduction du cycle-time. Donc : pour commencer à mettre des WIP-limit, commencer haut (oui, oui), et baisser progressivement, on a des résultats très vite, et c'est safe.

Le système pull du Kanban n'est qu'une des méthodes possibles pour contraindre le WIP dans le flux, la limite sur le WIP en est une autre. Et elles-mêmes font partie de méthodes plus larges de contrôle de WIP. D'autres méthodes de contrôle du WIP : grosso-modo jouer sur la demande, la ressource, ou le niveau de qualité attendu sur le WIP. (Bon, en fait c'est un peu ce qu'on fait naturellement sur un projet sans y penser).

Il termine avec un parallèle intéressant avec la gestion des flux internets.

Excellente session encore une fois. Je ne saurai que trop vous conseiller les livres de Reinertsen pour approfondir.

Atelier "Congruent Leadership" : Pierluigi Pugliese

Atelier de management qui nous a présenté la "Congruent Management Theory", basée sur les travaux de Clare Graves. http://www.clarewgraves.com/articles_content/Madden/CG_madden_1.html

5 axes de personnalité : Egocentric -> Saintly/Loyal -> Materialistic ->Personalistic -> Cognitive.

Dans ce modèle, on a un axe dominant, mais les autres peuvent être présents aussi. On progresse (ou régresse...) en suivant la chaîne ci-dessus. Et c'est dépendant du contexte (à la maison, ou au bureau sous stress, je peux me comporter différemment)

Le coach nous a fait échanger les motivateurs qui fonctionnent avec chaque personnalité.

Un outil qui peut aider à passer les résistances au changement qu'on rencontre dans une équipe.

"Agilité à large échelle" : moi-même, avec Hervé Lourdin

C'est la conférence que nous avions joué lors d'un petit-déjeuner OCTO.

Quand on fait de l'agile à grande échelle (9 équipes en parallèle), 2 grands thèmes :

• Il faut travailler sur le flux (mise en place, pilotage) et l'outillage (pour se concentrer sur les tâches à valeur ajoutée). L'amélioration continue est fondamentale.
• Il faut ajuster l'organisation en fonction des contraintes qu'on observe (component-teams, feature-teams...)

"Analyse de la valeur, source essentielle de réduction de coûts en entreprise" : Caroline Braeken

Session très courte de vulgarisation sur les problèmes qu'on rencontre si on se focalise trop sur la réduction des coûts (c'est dans l'air du temps...) :

• On induit de nouveaux coûts (ex : si on se met à l'offshore, on induit de nouveaux coûts de pilotage, et des coûts cachés de non-qualité ou de délai).
• On traite mal les demandes clients, du coup ils nous sollicitent davantage pour des choses qui ne sont pas créatrices de valeur (ex : support...)
• On génère du stress, ce qui génère absentéisme et désengagement actif, sources de coûts gigantesques.

Il faut plutôt se focaliser sur l'expérience utilisateur, écouter ses demandes (cf "Voix du client" en Lean), améliorer le flux pour diminuer les "non-right first time", les gaspillages, les tâches sans valeur ajoutée.

Tellement de bon sens. Si peu appliqué !

————

Fin de la 2° journée.

Vraiment, une excellente conférence. Les débutants en Lean et Kanban sont repartis avec beaucoup de matériel et de nouvelles idées pour leur propres implémentations. Quant aux connaisseurs, ils ont pu échanger avec des experts et avec les plus grandes références actuelles du Lean Software Management.

A suivre dans le futur !