Encore quelques éléments à peaufiner sur mon site nbphoto.fr et la page Facebook 3 jours après le lancement 😉 #nbphoto.fr #photographepro #enimages #workinprogress #photopro #photosecrets https://www.instagram.com/p/BsoWgmvHqBJ/?utm_source=ig_tumblr_share&igshid=xx5412s5p16r
[EN IMAGES] www.forumculture.ch/derives Les HISTOIRES DE DÉRIVES, c'est terminé ! Retrouvez les photos d'Alexandre Girod sur notre site. #forumculture #leshistoiresdederives #enimages (à Moutier, Switzerland)
Zenika accueillait cette nouvelle réunion mensuelle dans le zLocalHost. Une foule très nombreuse s’y était donné rendez-vous pour cet opus dédié à la formation au Kanban et aux techniques associées.
Un programme très chargé. Peut-être un peu trop, c’est vraiment tout ce que l’on pourrait reprocher à cette remarquable soirée !
Après le mot d’accueil du Sponsor soirée, Couthaier nous donne quelques nouvelles de l’association. Elle est très active il faut bien le dire. D’ailleurs la soirée suivante aura déjà eu lieu quand vous lirez ces lignes. Mais place à l’action.
Et l’action pour commencer, c’est avec Pascal Poussard et les essentiels de Kanban !
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.
L'association organisait aussi en décembre une soirée jeux, je n’ai malheureusement pas pu y participer. J’attends avec impatience l’année prochaine !
Le premier opus du Lean Agile Camp s’était déroulé en novembre dernier, une période peu propice pour moi et j’avais abdiqué. Pas question de rater celle-ci par, contre : programmée début Juillet, il n’y avait guère de conflit de dates à l’horizon.
Quand on veut parler de Lean sérieusement, on a de bonne chance que Régis Médina ou Antoine Contal ne soient pas loin. Nous avons eu la chance de bénéficier de l’expertise des deux !
Au programme de cette journée, des dojo pour aborder 3 sujets :
La compréhension du client
Le management visuel
La résolution de problème
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é
C’est ce que j’appelle une journée bien investie, même prise sur mon week-end ! Une journée pour comprendre, pratiquer et échanger sur 3 pratiques: j’ai hâte de remettre ça !
A mon grand dam, j’ai raté pas moins de 3 rendez-vous du FKUG, j’étais donc heureux de me rendre à celui-ci. D’autant plus heureux qu’il me permettait de m’essayer à l’un des jeux proposé lors d’un meetup précédent. J’avais d’ailleurs arrêté mon choix sur Kanbanzine que je souhaitais comparer au getKanban que je connais bien.
Dans les starting blocks
Nous étions accueillis chez Soat, dans leurs nouveaux locaux du 13ème arrondissement, à deux pas de chez moi ! Beaucoup de place pour s’ébattre, mais nettement moins de participants que prévus : j'imaginais 50 participants sur les 80 inscrits, nous étions un peu moins de 30 au final. Le foot d’un côté et les problèmes de transport de l’autre ont probablement eu raison de la pugnacité des uns et des autres !
On est agile, on s’organise, ou plutôt Gwenael nous aide à nous organiser.
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.
En ce qui me concerne : une soirée réellement instructive, en plus d’être une bonne détente. Un grand merci à Emmanuel pour avoir si brillamment animé ce jeu.
Agile France, c’est un rendez-vous incontournable. Enfin disons : sauf cas de force majeure. Le lieu reste le même et surtout fidèle à lui-même : le chalet de la porte jaune !
En arrivant, on est certain d’y trouver du café, mais surtout des connaissances et des amis. Ca commence bien !
L’organisation se fait aussi un point d’honneur d’être dans le timing. Et ça, ce n’est guère évident ! C’est Damien Thouvenin qui officie comme que maître de cérémonie cette année.
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.
Voilà, ce sera tout pour aujourd’hui. Je vous donne rendez-vous très bientôt pour le déroulement de l’après-midi.
