Formons-nous à Kanban avec le FKUG

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.

image

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 !

image

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.

image

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.

image

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.

image

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 !

image

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 !

image

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 !

image

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.

image

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à !

image

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 !

image

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 !

En route vers un nouveau sondage sur l’adoption de l’agilité

Le Frenchsug s’est déjà par deux fois livré à des sondages sur l’adoption des pratiques agiles. Le dernier en date commence a avoir quelques rides, car il date de 2010 / 2011. De plus, il avait été mené par des membres du bureau. Le bureau du Scrum User Group que nous avons aujourd’hui a décider de mieux procéder : faire participer la communauté à l’élaboration du sondage !

C’est donc à cette fin que nous nous sommes retrouvés entre-nous ce 12 novembre !

image

Mais d’abord : un bâton d’Hélium

On appelle ça un « ice breaker » ! Dans la pratique, c’est un truc beaucoup plus économique que d’abreuver l’assistance d’alcool ! Connaissez-vous le principe ? Un bâton très, très léger repose sur un doigt de chacun des participants. On doit le poser au sol sans en ayant toujours tous les doigts en contact à tout moment. Sinon, on recommence !

image

Résultat des courses : une équipe a réussit, l’autre pas. Il semblerait que l’exercice marche mieux avec un bâton d’Hélium en Fer (le poids de l’Hélium liquide sur Jupiter, j’imagine ?), je me demande bien pourquoi…

Et maintenant, au boulot !

Un backlog, des sujets… mauvaise nouvelle pour moi qui était venu pour mettre les pieds sous la table et causer avec mes potes ! Arnaud (encore lui) nous explique le déroulement de la soirée.

image

Donc nous avons des sujets que nous a concocté le bureau (mais on a le droit d’en choisir / créer d’autres. Toutefois, comme nous avons tous le cerveau plus ou moins lessivé par une journée de travail, nous ne le ferons pas. Le bureau nous a même mis à disposition les supports d’autres sondages à des fins d’inspiration. D’autres apelleront cela « biais cognitifs » !

image

Ah oui, c’est vrai les sujets :

  • Entreprise : tout ce qui concerne l’adoption de l’agilité au niveau de l’organisation, la culture d’entreprise, etc..
  • Projet : Même chose au niveau des projets. Quelles sont les conditions favorables ou défavorables à l’adoption à ce niveau.
  • Localisation : Quelle est l’influence de cet aspect sur le déploiement des principes agiles ? A Paris, hors de Paris, à l’international… Bien sûr en filigrane, il y a la question du near-shore et de l’offshore. Sans compter la répartition dans plusieurs salles, plusieurs étages ou plusieurs bâtiments. Ce qu’Alistair Cockburn appellerait la communication qui se mesure en mètres, portes et escaliers.
  • Personnes : quels profils des répondants, avec quelle expérience dans / hors de l’agilité ? A qui ressemblent les promoteurs de l’agilité dans l’entreprise ?
  • Contrat : Le sujet mal aimé par excellence. Quel type de contrat a un effet positif / contreproductif sur le déroulement en mode agile ? Quelles sont les contraintes par rapport aux achats ?
  • Méthodes et pratiques : XP, Scrum ? Kanban ? Lean ? Qu’adoptent les équipes ? Ou encore : quels mixes ? Même question sur les pratiques telles que story mapping, TDD, BDD/ATDD, pair programming, etc…
  • Impact : Quels sont les gains, les motivations et les enjeux ?
  • Outils : Que ce soit pour suivre le projet ou pour l’executer, quels types d’outils utilisez-vous et avec quelq gains espérés/réel ?

3 itérations étaient prévues, nous en feront 2, parce que hein, quand même…

image

1ère itération

Nous formons rapidement des petits groupes, par affinité de sujets.

image

Je me rapproche du groupe s’interressant aux personnes. Premier obstacle : on a mis à notre disposition un Canvas. Et pour commencer, il nous faut comprendre comment il fonctionne…

image

Plutôt que de recenser directement les questions, nous cherchons plutôt à articuler les thèmes. Caramba, je n’ai pas pris en photo notre Canvas !

Donc plus de détails plus rtard, quand on aura retravaillé la matière. Le temps passe vite, car l’itération n’était prévu que pour 30 minutes ! Il est temps de restituer. Pour notre équipe, c’est Géraldine qui fera la « démo » !

image

Pas le temps de souffler, on remet le couvert !

2nd itération

Peu de changement à notre groupe où règne une bonne entente pour cette seconde itération. Par contre, nous choisissons d’aborder un autre sujet !

Et c’est bien le sujet le moins sexy sur lequel nous allons nous arrêter : le contrat !

Quelle cadre contractuel est appliqué aux projets agiles : forfait classique ou aménagé ? Assistance technique dans un cadrat cadre ou choisie librement ? Quelles sont les conséquences de ces choix…

Pas plus que la première fois, je n’ai conservé les notes. Et déjà il est l’heure de la démo…

image

Et ensuite ?

Nous n’avons fait qu’amorcer le travail. Nos Gentils Organisateurs du SUG se ont fort d’enclencher la suite des groupes de travail. Objectif : des résultats de sondage pour le ScrumDay 2015 !

Retrouvez aussi le compte-rendu (officiel cette fois) de cette soirée sur le site du French SUG.

Agilité et hospitalité Libanaise

J’attendais cela depuis un moment, depuis le milieu de l’été pour être plus précis. Car Pierre Hervouet nous avait invité à venir partager avec la communauté Libanaise pour cette seconde édition de l’Agile Tour Liban ! Nous étions donc 4 Français à nous envoler vers le moyen-orient le vendredi matin pour une conférence qui se déroulerait en week-end.

image

La Suisse du Moyen-Orient offre des rivages cernés de montagnes. Le soleil s’y couche vite. Notre premier contact avec Beyrouth se fait au crépuscule. Qu’il s’agisse de quartiers islamique ou chrétiens, la vie nocturne est intense, mais bel et bien quadrillée de militaires ou de policiers dont l’équipement (étrangement semblable) ne laisse aucune place au doute.

image

L’hospitalité Libanaise est réputée, celle de l’hôte de la conférence est plus encore infaillible. Non seulement avons-nous été pris en charge par Rima, l’épouse de Pierre, dès l’aéroport, mais il nous invite dès le soir même à un diner entre speakers étrangers. Bâtiment ancien (il y en a), petite cours intérieure et large parasols de toile, nous laissons la ville nous imprégner de ses charmes.

Bienvenue à l’Agile Tour Beyrouth !

La conférence accueille cette année 130 personnes. Finalement, tous les billets auront trouvé preneur, même si il aura fallu attendre les deux dernières semaines pour en placer la plus grande partie ! Je dis « preneurs », mais je devrais aussi dire « preneuses », car la conférence affiche à vue d’oeil pas loin de 50% de public féminin ! Un sacré changement par rapport à nos conférences Françaises…

image

Le début est prévu pour 9h30. C’est l’opportunité de faire connaissance avec le concept du « 9h30 inch Allah ». Autant dire que nous n’avons pas du tout commencé à l’heure. Pierre Hervouet ouvre la conférence avec le discours d’accueil.

Outre la présentation de la journée, il met cette journée sous le signe du « Shu Ha Ri » … voilà qui met un peu de pression sur ma propre session, qui porte de facto l’emblème de cette journée !

image

Il est temps de présenter le programme, c’est la moment des pitches des sessions ! Nous sommes 14 speakers, ce qui est peu comparé aux Agile Tours Français. L’agilité est encore très peu développée au Liban, aussi n’y a-t-il que 7 présentateurs locaux. Les « internationaux » présenteront 2 sessions. Pour ma part, il s’agira du « Scrum Shu Ha Ri » le matin, et d’un Carpaccio game l’après-midi. Je ne suivrais donc pas beaucoup de sessions de mon côté.

image

En apéritif de la Keynote d’ouverture, nous avons deux sessions au format Lightning Talk, ou plus exactement de Type Pecha Kucha, donc 20 slides avec 20 secondes pour chacun d’entre eux sur une durée totale d’un peu plus de 6 minutes (si vous faites le calcul).

Pierre ouvre le bal.

Agile the Origin, par Pierre Hervouet

Pierre réussit un petit tour de force : nous présenter en 6 minutes, non seulement un bref historique du mouvement agile, mais aussi sa vision de ce qui est important dans l’agile :

  • Les livraisons fréquentes
  • Le focus sur la valeur métier
  • La communication et la collaboration
  • Le « team empowerment »
  • L’amélioration continue
image

Pour conclure, Pierre nous donne un exemple concret et personnel de la mise en oeuvre de ces valeurs : la construction de sa maison !

La vidéo est courte, n’hésitez pas à la regarder en entier. Voici également le support de sa présentation.

Scrum At a Glance, par Joanna Khoury

Il s’agissait lors de ses deux Pecha Kucha de présenter des fondamentaux de l’agile. Ainsi si Pierre nous a présenté les concepts fondamentaux, il revenait à Joanna de présenter Scrum, l’approche agile emblématique.

image

Pas de fantaisies dans cette présentation de Scrum « by the book ».Mais c’est bien ce qu’il faut pour mettre le pied à l’étrier d’une assistance qui en grande partie découvre l’agilité !

The Best Way to Convey Information, par Kimberly Samaha

Quelle est la valeur d’un face à face par rapport à un échange informatisé ? Mais aussi : l’échange informatisé peut-il apporter une valeur que n’apporte pas le face à face ?

image

J’ai eu un peu de mal à relier les fils du propos de l’oratrice, aussi vais-je en livrer quelques uns de manière déstructurée :

L’importance du contexte et de la perspective : Kimberly fait le rapprochement avec l’art, ou comment une partie du vécu de l’artiste transparait dans ses oeuvres (Velasquez, Francis Bacon). Il en va de même pour nous : il y a des éléments de nos intentions dans nos créations !

Arrêter de penser aux personnes comme à des objets : le contact avec d’autres personnes doit plutôt être perçu comme le déclencheur d’une expérience. La notion d’objectivité en prend un coup. Pour Kimberly Samaha, la vérité n’est d’aucune aide contre les perceptions.

Extreme Ice breaking

Joumana nous avait concocté un petit jeu, ou plutôt un grand jeu permettant à de petits groupes de se rencontrer. Autant dire qu’organiser une telle chose, surtout sur un temps limité était le gage d’un beau bordel ! Jugez-en

A mon grand étonnement (mais aussi avec une belle dépense d’énergie), Joumana est parvenu à mener la chose à bien. Je ne pense pas que j’aurais su en faire autant.

image

Ma propre session commence bientôt. Enfin j’imagine, car j’ai complètement perdu le fil de l’horaire.

Scrum Shu Ha Ri

J’avais déjà donné cette session au Printemps Agile, à Caen. Je l’ai un peu modifiée pour l’occasion, mais surtout traduite en Anglais.

image

Je publierai prochainement la vidéo montée lors du Printemps Agile (donc en Français). En attendant, vous pouvez trouver ici mon support de présentation (toujours en Français) et l’article que j’avais rédigé suite à l’évènement de ce printemps !

Agility for Customer Delight, par Mehmet Yitmen

Je n’ai pas regretté d’être resté dans la salle pour la session de Mehmet. Notre orateur est le chef de file de l’agilité en Turquie.

image

A l’aide d’histoires, Mehmet vient nous partager les enseignements tirés des réussites disruptives d’entreprises : comment Fuji, sur la base de sa réussite dans la production de film photographique est devenu numéro un au Japon des produits cosmétiques. Comment Zara à l’aide d’expérimentation et de cycle de feedback courts est-il parvenu à la réussite que nous connaissons.

Je vous invite à regarder cette intervention très inspirante !

Pause déjeuner

Elle sera assez courte, une heure seulement pour savourer l’excellente cuisine Libanaise. Nous aurons néanmoins l’occasion d’y revenir ce soir !

image

Une petite pause pour dévorer des yeux aussi.

image

La salle ouvre sur un balcon, un oasis de fraicheur.

image

Et voilà, c’est déjà fini ! Je vais rejoindre la session de Fadi Jeanbart.

Improve your Public Speaking Skills, par Fadi Jeanbart

Fadi est chanteur d’opéra. Il nous a d’ailleurs fait une petite démo à la fin : il est vraiment chanteur d’opéra, aucun doute ! C’est à la technique Alexander qu’il va nous initier aujourd’hui. Technique que lui-même applique et enseigne pour le chant.

image

Avoir une conscience aiguë de notre corps et comment celui-ci influe sur notre respiration et par voie de conséquences sur notre capacité à maitriser les sons, voilà l’objectif. Nous arriverons juste à prendre conscience de la difficulté du chemin à parcourir. Mais un chemin commence avec un premier pas.

Carpaccio Game

Le temps file à toute vitesse et voici pour moi la dernière session de l’après-midi. Dernière session, car le Carpaccio Game qui j’anime occupe un double créneau.

image

Il nous fallait de nombreuses machines pour l’atelier le plus « geek » de l’après-midi, car il s’agit bien d’un atelier de programmation. Grace à Pierre et aux bonnes volontés des participants, nous y sommes arrivés. Je vous parlais en début de post de la proportion de femmes à la conférence. Je vous laisse constater ce qu’il en fut à mon atelier.

image

Malheureusement, le timing déjà court s’est trouvé raccourcis par les retards pris et la contrainte de la keynote de cloture qui, elle, ne pouvait être décallée !

Keynote de clôture : Ken Schwabber

C’est via Skype que le co-créateur de Scrum a partagé avec nous cette fin d’Agile Tour. Une liaison Internet hélas pas toujours optimale.

image

Je vous laisse découvrir son propos. Il reste assez classique par rapport à ce qu’il nous a habitué. J’ai noté qu’il écornait SAFe au passage. On sait qu’il n’éprouve pas un grand amour pour le framework de Dean Leffingwell. Il défend plus que jamais son approche non prescriptive en regard des pratiques à adopter. Je ne saurias le lui reprocher, et c’est hélas mal compris par beaucoup de praticiens. Au fond, Scrum c’est un peu l’agilité pour les grandes personnes !

Pierre Neis avait hacké le Lean Kanban France pour saluer l’Agile Tour Beyrouth. L’agile Tour Beyrouth tenait à rendre la politesse à l’Agile Tour Brest qui se déroulait peu après.

image

Vous avais-je parlé du charme des Libanaises ?

En finir avec l’Agile Tour

Quand c’est terminé, ce n’est pas encore tout à fait fini : Pierre avait invité son collège de speakers goûter l’excellente cuisine Libanaise. On commence par se chauffer dans un bar en ville, on se croirait en France !

image

Soirée chaleureuse entre speakers. On échange nos impressions, nos expériences.

image

Comme si cette splendide hospitalité ne suffisait pas, nous avons aussi eu droit à des souvenirs : un petit livre édité par Rima et la série de sous-verres « Shu Ha Ri » ! Et je ne parle même pas du régal pour les yeux et le palais que fut ce dernier repas…

image

En attendant le retour…

Nous étions quelques uns à choisir de rester une journée supplémentaire sur place. Nous n’avions juste pas prévu le marathon de Beyrouth qui se déroulait ce dimanche. Début des hostilités à 5 heures du matin avec la musique à fond ! En regardant par la fenêtre, ça n’a pas l’air de courrir des masses. En fait, on semble plutôt se balader !

image

Pourquoi ne pas y aller dans ces conditions ? Pierre Neis et moi-même nous sommes donc joins à la fête. Fête est le mot approprié : tous les 200 mètres, il y a un podium avec de la musique à fond et des pom-pom girls. En fait, le marathon, c’est juste une autre occasion pour faire la fête.
Je vous laisse admirer vos serviteurs en pleine souffrance dans cet exercice…

image

Amr et Mohamed nous ont accompagnés dans une balade sur la côte offerte par Pierre Hervouet. car vous savez, on est peut-être en Novembre, mais au Liban…

align=“center”image

Une petite ballade dans les grottes de Jeita (avec Marc Cerrone que Pierre Neis a reconnu !). Un dernier diner ensemble. Il est temps de rentrer à la maison. Goodbye Liban, ce fut une conférence et un séjour exceptionnel !

image

La rentrée en open space !

Il n’aura pas fallu attendre longtemps pour voir notre premier rendez-vous agile de la rentrée. C’est d’ailleurs un agenda assez rythmé qui nous attend dans les semaines qui viennent !

Mais en ce 4 Septembre, c’est un open-space auquel Yannick nous a convié dans les locaux de Zenika. Beaucoup d’inscrits, peu de venus (environ une quinzaine), mais comme on dit dans les open spaces : les personnes qui sont là sont les bonnes personnes. Petit avantage : l’achalandage de notre place de marché va plutôt vite. C’est bien car ce sont 3 créneaux qui sont prévus pour ce soir !

image

1er round : où il est question de (non) estimations…

3 sujets sont proposés dans chaque tranche de temps, avec 45 minutes consacrées à chacune q’entre-elle ! Voilà, c’est parti.

image

Chaque groupe prend possession de son espace. J’avoue apprécier d’avantage les petits groupes de 5 comme c’est le cas ici.

Il faut faire des choix, parfois difficiles. Ce groupe a choisi d’aborder la définition de « done », un sujet pour lequel j’éprouve un certain intérêt … 

image

Je me décide finalement à rejoindre le groupe de Dov pour débattre du « no estimates ». Je me suis dit que cela faisait une bonne suite à ma rubrique de l’été : en finir avec les estimations !

image

J’ai été rapidement déçu par la direction qu’a prise la discussion, ou plutôt l’exposé que nous a fait Dov de son contexte. Outre que je suis plus intéressé par la discussion que par écouter une seule personne discourir, il ne nous parlait pas de « no estimates », mais plutôt de « diluate estimate » !

Supprimer les estimations « parce qu’elles font durer le planning meeting trop longtemps » sans changer la logique de travail entre le PO et l’équipe, c’est un peu mettre un sparadra sur un bobo. Certes, cela fait diminuer la pression … mais ce n’est pas du « no estimates ». Où plutôt cela l’est au sens littéral, comme quoi le terme n’est pas bon, du moins à mon avis.

Un avis apparemment partagé par Arturo ! Du coup, nous réorientons la discussion sur le changement de focus : la valeur et la définition de succès, du projet ou du rôle du product owner. Dans le cas du projet de Dov, on parle d’implémenter ce qui est dans le backlog : tant que l’on en est là, il n’y a pas de changement de logique et cesser d’estimer est futile, peut-être même malhonnête par rapport au client ?

J’aurais aimé avoir plus de temps pour creuser la question du changement de logique avec Arturo, mais le gong nous a rattrapé. Nous avons à mon goût passé bien trop de temps dans une direction qui ne m’intéressait pas. Oui, je sais j’aurais dû appliquer la loi des deux pieds. Mais le sujet m’intéressait et je préférais le rediriger dans une voie qui me convenait plus.

2nd round : Trop d’agile tue l’agile ?

Pour faire 3 round, Yannick nous a proposé un timing assez rythmé, pour ne pas dire serré. Ca ne laisse pas beaucoup de temps au partage ni au « slack », c’est un peu dommage.

image

Pour ce second round, je me suis joins à Renaud. Je ne suis pas fan de la manière dont il a exprimé le sujet. Peut-être même pas fan du sujet, d’ailleurs. Mais je me dis qu’au pire, il se prête assez bien au hacking !

Renaud s’étonne d’un certain nombre de sujets abordés dans le cadre de Scrum qui sont justement incompatibles avec Scrum. Sans aucun doute, il a raison. Renaud profite de l’occasion pour nous parler de Shu Ha Ri, cela vous rappelle-t-il quelque chose ?

Je ne vois pas trop où le « trop d’agile » intervient dans cette discussion, car on en arrive à évoquer le « Scrum by the book », ce qui est un peu normal quand on parle de Shu, mais pour le seconde fois de la soirée, je m’aperçois que ce n’est pas une direction de la discussion qui m’intéresse !

image

Le « trop d’agile », c’est pour moi trop se focaliser sur le fait de faire effectivement de l’agile au travers de telle ou telle pratique. Et s’intéresser à l’orthodoxie des pratiques (comme nous le faisons là), c’est se focaliser sur les choses qui sont au final inintéressantes. L’agilité est un moyen, c’est aujourd’hui devenu une fin ! On est d’ailleurs en train de parler « d’audit agile » dans cet ordre d’idée, une perspective que je trouve déplaisante.

Merci une fois encore à Arturo pour m’avoir épaulé pour chercher à explorer cette voie. Une fois encore je me trouve un peu frustré par le gong qui raisonne…

3ème round : Convaincre sur l’agile

Rapide partage avant le dernier round. Trop rapide encore. Hélas encore !

image

Nous commençons à nous dépeupler. Ce dernier round ne comptera que 2 sujets, le 3ème passera à la trappe : c’était le mien ! Mais il semble n’intéresser que peu de monde. Peut-être même personne.

Un débat plus intéressant cette fois autour d’un cas réel : quelle prise pour convaincre un management par ailleurs dans l’échec !

image

On a beaucoup parlé de construire un argumentaire, enquêter, chercher des éléments… Tout cela ne vas pas me convaincre. Plutôt que d’argumenter avec de grands mouvements de manche, pourquoi ne pas faire ? Quelle expérimentation mener pour prouver ? Quel investissement semble assez raisonnable pour essayer quelque chose ? Après tout si la situation actuelle ne marche pas …

image

Conclusions

Ce n’était pas la grande forme pour moi, ce jour-là. Mais je souligne 4 éléments à l’issu de cette soirée.

Un petit groupe pour l’open space et des petits groupes de 5 pour discuter, c’est plus convivial et plus interactif !

Le timing était un peu serré du fait de la contrainte que l’on se donnait sur les 3 tranches de temps. C’est dommage ! Je pense que j’aurais préféré deux créneaux de qualité avec un peu de mou et un temps de partage prolongé.

Un peu frustré par la direction prises par les deux premiers sujets. C’est nécessairement un point de vue personnel, je ne peux escompter que tout le monde partage la direction que j’aimerais faire prendre à la discussion.

Enfin, mon sujet n’a finalement pas été abordé. En soi, cela n’a aucune importance. Mais il s’agissait du seul sujet traitant de conception, de craftmanship. Lors des rendez-vous agiles, j’entends toujours des participants parler du TDD « il n’y a que ça de vrai » … mais traiter vraiment du coeur du sujet, en l’occurrence de la conception émergente, cela finalement n’intéresse personne. Est-ce la différence entre l’intention et la réalité ?

Agile Playground #15

Un conflit d’agenda m’a fait raté le 14ème rendez-vous, c’était donc une bonne surprise de voir un Agile Playground programmé en cette première quinzaine de Juillet, alors que je croyais nos rendez-vous interrompus jusqu’en Septembre !

image

Au programme de cette soirée, un ice-breaker sans prétention mais amusant proposé par Frank Beulé et une traditionnelle expérimentation de jeu.

Change agent

On est là pour expérimenter et Christophe Keromen a bravement défendu cette tradition avec une création vraiment difficile, je dois dire : le « change agent » inspiré du How To Change the World de Jurgen Appelo.

image

Le principe :

  • 4 équipes devant s’approprier 4 des modèles décrits dans le livre de Jurgen Appelo : Dnce with the system (PDCA), ADKAR, la courbe d’adoption de Moore et les 4 « I ».
  • 2 tours de batailles (demi-finales et finales)
  • Un storytelling à monter pour chaque équipe à chaque tour. D’abord un exemple d’échec puis un exemple de succès.
  • A chaque tour, chaque équipe change de modèle.

En plus du modèle, nous disposions de cartes pense-bête dont il fallait montrer l’utilisation au fur et à mesure de l’histoire. Bien entendu, le tout était time-boxé, ce qui rendait l’exercice particulièrement difficile !

image

Entre les 2 tours, nous avons fait une rétrospective éclair pour améliorer le fonctionnement. Ca a marché ! N’occultons cependant pas le principal : c’est mon équipe qui a gagné 😉

image

Ce que j’en ai pensé

Je dois l’avouer : je ne me suis pas amusé durant ce jeu. Est-ce grave, docyeur ? Pas vraiment : l’agile playground est là pour expérimenter et Christophe a fait la tentative la plus audacieuse à laquelle j’ai assisté. Et cela doit être salué !
Nous avons donné (beaucoup) d’éléments à Christophe. Voici de nouveau les miens plus une ou deux choses dont j’ai discuté avec Xavier Galleri :

  • Double difficulté de l’exercice : trouver une histoire et comprendre assez bien le modèle pour l’appliquer à l’histoire. Quand on ajoute la contrainte du temps… Il faudrait proposer des trames d’histoire prêtes à être utilisées.
  • Le setup de la salle : la disposition des tables nous collait contre le mur, ce qui crée un style un peu guindé et une certaine pression psychologique.
  • Durant le story-telling, les autres équipes sont trop passives. On pourrait utiliser les cartes pour les faire participer. Un peu comme un loto…

N’oublions pas le plus important : le story-telling, ça marche ! C’est quand même l’ingrédient principal qu’a voulu utiliser Christophe et les remarques que nous avons faite ne doive pas occulté qu’il a réussi sur ce plan !

Lean Agile Camp, saison 2

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 !

image

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.

image

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.

image

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 !

image

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é.
image

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 ?

image

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.
image

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.

image

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 !

Foot ou ScrumBeer, il faut choisir !

De toute évidence, nous étions un petit nombre a avoir choisi ! Et pour une fois (ceci impliquant cela) nous avons presque atteint la parité hommes-femmes ! Cela dit, en se rendant dans un pub, il restait improbable que nous puissions complètement échapper à une retransmission de la coupe du monde !

image

De nouvelles têtes et des têtes connues, comme d’habitude dirais-je. Je ne vais pas m’étaler sur nos conversations, car contrairement à l’accoutumée, nous nous sommes livrés à quelques activités.

Le noeud humain

Régis nous a convié à l’exercice du noeud humain. D’accord, j’ai déclaré forfait en prétextant mon poignet encore fragile. J’en profite pour prendre des photos (bien entendu) et voir une vue d’ensemble, bien que je n’ai pas suivi les différentes phases !

Bref, on commence par former une chaine « nouée »…

image

Ensuite on doit s’efforcer de se dénouer.

image

Soit en s’auto-organisant, soit sous les directives d’un manager !

Et un marshmallow, un !

Comme nous étions en forme, Arnaud nous a proposé un petit Marshmallow challenge. Deux constructions en compétition. L’une a gagné.

image

L’autre a … moins réussi !

image

Encore une petite dernière ?

Oui, en principe c’est bientôt le break de l’été. S’il fait beau début Juillet (nous n’avons pas tellement de chance de ce côté depuis quelques années), nous pourrons peut-être organiser un petit « Scrum Picnic » pour conclure dignement cette année…