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 !
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 :-)
Si vous cherchiez "le Kanban en 3 slides", en voilà déjà 2 ;-)
Le décor est planté pour la suite...
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 :
2 choses que je retiens :
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 :
Le Lean nous apporte beaucoup plus de résilience, car :
Le Lean, c'est :
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 :
Et maintenant, toute la SGCIB (j'exagère à peine ;-) vient visiter son plateau pour diffuser les pratiques. Super REX.
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.
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 :-)
——————————————————————————————————————————————
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 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.
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 :
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...) :
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 !