#enimages

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.

1er atelier : le « job to be done »

Cet atelier est destiné à confronter nos hypothèses à la réalité. Pour ce faire, nous avons choisi une application (l’application Meetup mobile dans notre cas) et avons cherché à en établir les cas d’utilisation, structuré de la manière suivante :

Contexte d’utilisation

Job

Attributs

Dis comme ça, c’est un peu abstrait. Voyons plutôt le résultat que nous avons obtenu.

Dans une seconde étape, nous avons consolidé le travail fait avec nos hypothèses en allant rechercher des feedbacks utilisateurs. On le craignait, mais bien sûr hélas, la réalité du terrain nous donne un tout autre son de cloche : les propriétés que nous avions jugées importantes ne semblent pas les bonnes. Par exemple, la question de la confiance dans les groupes ou les membres semble récurrente (nous avons croisé plusieurs sites et forums utilisateurs).

Bref, on découvre de nouveaux « job to be done », de nouvelles propriétés et en éliminons certaines qui ne sont pas recoupées par nos sources d’information.

A la fin de l’exercice, nous partageaons nos trouvailles entre groupes.

Le « misfit » entre nos hypothèses et la réalité est un point commun entre nos deux groupes !

Le FIAP Jean Monnet qui nous hébergeait propose des facilités pour déjeuner. Grâce à cela nous pouvons limiter nous pause déjeuner à 1 heure. D’autant que la zone restauration est carrément vide en ce premier week-end de Juillet !

Retour aux choses sérieuses avec notre second kata !

2nd atelier : le management visuel

Cette fois, nous allons partir d’une situation existante, un cas existant dans l’un de nos contexte et proposer des visualisations adaptées. Il pourra s’agir d’une visualisation ex-nihilo ou l’amélioration d’une visualisation existante. Les clés que nous proposent nos deux coaches Lean sont :

S’inspirer des jeux video : être clair sur les scores !

Donner un contexte stratégique, mais un focus opérationnel !

Visualiser le challenge !

Attention, le challenge peut être anxiogène, le mieux est d’être capable de montrer les progrès au jour le jour, car la motivation vient du succès ! Nous avons choisi deux contextes issus de notre groupe :

Un centre de service, qui cherche encore quel est son objectif de succès !

Un grand projet qui a un objectif de périmètre pour une date donnée et doit motiver celles-cis afin d’atteindre ce but alors que les mesures montrent un état courant en-dessous de ce qui est escompté.

Certes, le management visuel n’était nouveau pour aucun de nous. Et pourtant ! Pourtant, grâce à ces quelques lignes directrices et aux interactions du groupe, nous avons abouti à des résultats inespérés !

3ème atelier : la résolution de problème avec le PISCAR

La résolution de problème, c’est un peu l’épicentre du Lean (avec l’amélioration continue). Et qui dit amélioration continue, dit PDCA, n’est-ce pas ?

Nous allons nous concentrer sur la partie « problème » du PDCA et utiliser une heuristique proposée par Régis Médina : le PISCAR que nous allons donc expérimenter sur nos études de cas :

P : Le Problème ; il doit être énoncé sans essayer de camper un contexte ! On définit un problème comme un écart quantifié.

I : L’impact ; Il doit être chiffré. Il nous permet de répondre à la question : Est-ce le bon problème.

S : Standard ; la partie la moins évidente de l’exercice. L’idée est de comparer la situation à problème au cas normal.

C : Causes ; que l’on obtient par exemple avec les « 5 pourquoi ». Mais surtout on cherche les racines. Les 5 pourquoi, ça fait un peu tarte à la crème…

A : Action ; une action qui doit être le plus rapide et le plus simple (donc la moins coûteuse) possible. Donc, une expérimentation.

R : Résultats attendus ; ils sont à mettre en rapport avec l’impact.

Nous effectuons l’exercice de manière itérative, car c’est probablement le plus difficile de la journée. Corina s’est proposée pour exposer le sien pour clore ce 3ème volet.

Ce que j’en ai pensé

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.

Avant de laisser place à la Keynote de Régis Médina, je voudrais souligner la formidable présence de Romain Couturier pour animer un scribing en continu lors de cet Agile France. Il a également initié plusieurs groupes à son art, qui se sont aussi jeté à l’eau pour capturer les sessions de l’open-space !

Le produit, prochaine frontière de l’agilité

Le Product Management, c’est un sujet plutôt « trendy » en ce moment. Régis va l’évoquer pour nous avec sa sensibilité Lean.

Le bon vieux temps

Autrefois, avant l’agile, on produisait les logiciels en phase. Arrivait la phase de tests. En fait, le moment où commençait vraiment le projet. Parfois, tout était purement et simplement jeté à la poubelle. mais on sait maîtriser cela désormais. Hélas, la récompense pour un problème résolu, c’est un nouveau problème !

Le nouveau problème, c’est que nos utilisateurs veulent plus et plus vite : ils ont des services en ligne accessibles depuis partout, des applications mobiles … Ils ne sont plus dupes ! Le niveau monte, il n’y a plus le choix : il faut produire un SUPER logiciel !

Obtenir le whaou effect !

Et déjà, deux trucs pour ne pas l’obtenir:

« design par comitee ». Ici les Product Owner ne servent que d’aiguillage entre des besoins plus ou moins divergents.

Fonctionner en flux à l’extrême. Le revers du flux, ce de ne porter son attention sue sur des petits bouts.

Alors quelle solution ?

Le Lean Startup offre une partie de la solution, mais il n’offre pas de réponse aux points de vue antagonistes, ni à la résolution des contraintes. Régis préfère orienter son regard vers le Lean Engineering, où un chef d’orchestre (et un seul) porte la vision du client (vous avez dit « product owner » ?). Bien. Mais quels caractéristiques, quelles aptitudes doit posséder ce chef d’orchestre.

Si l’on regarde les grands chief engineers, on voit que l’une de leur caractéristique commune est leur capacité à dire « non ». Mais comme on s’en doute, cela ne suffit pas. L’orateur évoque pour nous trois compétences clé.

Trois compétences

Positionner le challenge : c’est le chief engineer qui donne la direction et place la barre. S’il ne le fait pas, les personnes de l’équipe se trouveront individuellement leur propres challenges ! Positionner le challenge, c’est aussi identifier les paramètres clé, ceux que l’on aura déterminés en allant voir sur le terrain.

Cultiver le désaccord : Lister les options s’offrant à nous de manière crédibles et les attaquer de front (set based design).

Dénicher les erreurs : En ayant un niveau d’exigence élevé, obligeant à voir et revoir sans cesse les solutions adoptées. La voie empruntée ici est celle de la résolution des problèmes.

Ce que j’en ai pensé

C’est toujours un plaisir d’écouter Régis. Et ses interventions sont toujours d’excellente qualité. Je ne peux qu’abonder dans le sens qu’il évoque, même si je trouverais certains autres points à appuyer, comme l’importance du feedback (bien couvert par le Lean Startup dans ce cas).

Cela ne révolutionne pas non plus mon image du product management, j’y trouve les éléments que j’avais déjà, à l’exception sans doute du « cultiver le désaccord » qui donne un peu à réfléchir. Curieusement ce point sera aussi abordé dans une autre session ! Mais c’est aussi un aspect que l’on retrouve aussi dans le design thinking…

Le mot de l’organisation

Avant d’aborder la suite du programmes, nous avons droit aux pitches de la première journée : 30 secondes par orateur, c’est vraiment court ! On a aussi le mot de l’association, par la voix de son président, Emmanuel Gaillot.

L’an dernier, Emmanuel nous avait gratifié d’une tirade pour le moins asez sèche, assis sur une chaise. Pas terrible. Je ne sais s’il a lu mon compte-rendu, mais cette année c’est débout qu’il s’est exprimé, avec un verbe moins acerbe et nettement teinté d’humour, et avec le même message. Ca change tout ! Kudo, Emmanuel !

Il est temps de rejoindre la session suivante. Moi, je ne change pas de salle car Pascal Van Cauwenberghe fait son talk avec Jacques Couvreur dans celle-ci.

La simplicité : Pas facile !

Je ne savais pas à quoi m’attendre pour cette session (dont je n’avais même pas pris la peine de lire le résumé). La simplicité, ce n’est effectivement pas facile, car elle nécessite avant tout de définir ce qu’est la simplicité !

Pour nous aider dans notre quête, Pascal et Jacques vont plonger dans la substance proposée dans deux ouvrages.

The Laws of simplicity

Le livre de John Maeda nous propose 10 lois que nous passons revue.

1 - La réduction : Ne laisser apparents que la fonction et le message.C’est donner une apparence de simplicité.

2 - Organisation : Ranger les éléments pour donner une impression de simplicité.

3 - Lutter contre les temps d’attente : l’attente donne une impression de complexité. Exhiber un élément dynamique comme une barre de progression atténue cela.

4 - L’apprentissage : Elle couvre deux niveaux :

L’apprentissage immédiat : c’est permettre la découverte.

La maîtrise, qui intègre une notion de dynamique.

5 - La différence (Jacques est resté sec là dessus)

6 - Le contexte : un concept difficile à saisir, mais qui tempère d’un « ni trop, ni trop peu » cette notion de simplicité.

7 - L’émotion : La simplicité est aussi un facteur non rationnel.

8 - La confiance : C’est offrir un contexte sécurisé, permettant de faire et défaire sans crainte.

9 - L’Echec : Parfois, on ne peut pas tout simplifier. Mais essayer permet d’apprendre.

10 - La loi cardinale : Moins d’évidence et plus de sens.

Bon, je reste un peu sur a fin avec cet énoncé de concepts. Certains éléments de la liste me parlent un peu, mais cela manque de substance. Passons au second opus.

The Laws of Substraction

Le livre de Matthew E. May livre à son tour 6 règles.

1 - Ce qui n’est pas là est parfois plus important que ce qui est là. Pascal rapproche ce point de la loi de Conway. Améliorer l’environnement (en éliminant des barrière) peut améliorer le produit.

2 - Les règles simples produisent les expériences les plus productives. Pascal nous propose deux choses à essayer en ce sens :

Quelles règles (qui protègent) peut-on supprimer ?

« abandonner » l’application aux utilisateurs.

4 - Ajouter des contraintes. Pour déclencher de nouveaux comportements, on peut par exemple : réduire la durée des itérations, réduire la durée entre 2 commits, etc..

5 - Parfois, il faut casser pour percer. Ne pas avoir peur des crises…

6 - Parfois, ne rien faire c’est mieux !

Je sais, il me manque l'item numéro 3 : désolé !

Ce que j’en ai pensé

Je suis un fan des présentations de Pascal. Cette fois, je suis resté sur ma faim. Mais néanmoins, je serais bien là aux prochaines présentations de Jacques et Pascal !

Le prochain créneau nous propose des lightning talks. Mon choix est fait depuis longtemps !

Tim Gallwey ou comment le coaching a commencé

Christophe Keromen nous a proposé une session une session de 20 minutes passionnante commençant par un échec : celui de Tim Gallwey, alors champion de tennis, ratant la balle de match d’une demi-finale de championnat (et le match par la même occasion). Ainsi commence le constat : nous sommes tous nos propres saboteurs ! Nous avons du potentiel, mais nous faisons moins que ce que nous sommes capables de réellement faire. D’où l’équation :

Performance = potentiel - interférences

Quand « self 1 » gêne « self 2 »

Nous interférons avec nous-même.

Notre « self 1 » représente l’égo, le moi rationnel, tandis que « self 2 » représente le corps et l’inconscient. Lorsque nous laissons « self 1 » interagir, nous provoquons un ralentissement, une diminution de notre probabilité de réussir. Ce point est appuyé par les neuroscience qui affirment que la quasi-totalité des informations dont nous disposons est inconsciente.

A quoi cela peut-il me servir ?

Christophe nous propose deux axes.

L’apprentissage. Les images sont supérieures aux mots. On apprend mieux par mimétisme sans chercher à décrire ou à rationaliser ce que nous faisons (sinon nous rappelons « self 1 »).

Les habitudes. Nous créons des habitudes pour répondre à un contexte qui est souvent la marque du passé, bien que répondant à une intension positive. Il faut remplacer ces habitudes par de nouvelles, répondant aux mêmes intentions, mais adaptées au contexte présent.

Ce que j’en ai pense

Christophe a superbement abordé le sujet. Me voici avec encore un sujet à potasser. Je retiens dans l’immédiat la prédominance de l’exemple sur la formulation littéraire.

Pas la peine de bouger de place pour la prochaine présentation qui se déroulera dans la même salle. Tant mieux pour moi, car ça se bouscule !

La rétrospective continue

C’est en duo et dans une salle comble que Régis Médina et Antoine Contal nous ont proposé leur session. Toutes les places sont prises et une partie du public est debout !

Evidemment, comme on peu s’y attendre, Antoine et Regis nous parleront de Lean. La clé des retrospectives réussies, celles qui progressent au lieu de s’enliser se situe hors des rétrospectives : c’est créer un environnement où l’équipe progresse. Continuellement.

Dans ce cadre, le rôle du coach devient celui du coach sportif : il aide à poser le challenge.

Le challenge !

Forcément, sur un projet, le challenge est un concept plus flou que pour un sportif. Mais c’est posible en prenant en compte ce qui est important pour le projet. Il n’y a pas de recette miracle.

Le sourire du client

Le lien avec l’argent. Le flouze, quoi !

La stratégie

Pour un manager, les dimensions à prendre en compte pourront être :

Qualité du code.

Délai de livraison.

Productivité (même si ce facteur est à prendre avec prudence).

Finalement, il faut trouver le moyen de rendre ce challenge visuel (indicateur, progression…).

Un apprentissage individuel

Une fois posé le challenge, il faut le décliner en petits exercices d’amélioration individuel : chaque action d’amélioration doit avoir son porteur. Ce porteur devient expert du sujet, et il profite ensuite des rétrospectives pour partager son savoir !

Chaque action d’amélioration se décline en expérimentations suivant le cycle PDCA : ce sont des Katas.

Finalement une bonne nouvelle, mais…

La bonne nouvelle, c’est que l’on peut garder les rétrospectives. Elles deviennent un lieu d’échange des nouvelles pratiques. Il y a aussi un prix à payer :

Ecouter les managers

Ecouter la réalité plutôt que ses envies

Persévérer

Les bénéfices en contrepartie :

On peut avoir un impact

Quand ça marche, le comportement des personnes change.

Enfin, Antoine et Régis nous proposes des exercices à faire en rentrant

Aller voir et écouter le client

Construire le modèle économique du produit

Questionner un directeur sur les objectifs stratégiques

Mettre en place un indicateur

Commencer avec un problème dont nous (en tant que coach) connaissons la réponse.

Ce que j’en ai pensé

Comme d’habitude, avec Antoine et Régis, c’est du lourd comme disent les jeunes. On prend cher au passage aussi : leur sessions sont aussi intéressantes que déprimantes. Mais ça tombe bien, les actions d’amélioration sont au centre de ce que j’ai à faire en ce moment !

Pause déjeuner

Je ne reviens pas sur la qualité de la la restauration d’Agile France, j’en ai déjà longuement parlé l’an dernier !

Le déjeuner, c’est surtout l’occasion d’échanger avec les personnes que l’on apprécie (il y en a beaucoup !). Ce midi, ce sera avec Nathaliel Richand et Jean-Luc Lambert. Bien sûr, nous évoquons un peu le Printemps Agile, mais nous parlons surtout enseignement : Nathaniel voudrait développer des MOOCs agile, ce qui est dans les tendances du moment, mais peu compatible avec un enseignement de plus en plus par le jeux et « from the back of the room »…

Sans doute il y a-t-il complémentarité entre les deux modes, en utilisant les MOOCs pour des sujets plus étroits, pour lesquels il serait difficile d’organiser des sessions, donc plus avancés.