Catégorie : Compte-rendu

Meetup Evernote entre amis

Le par addinquydans Compte-renduLaisser un commentaire

Pierre Journel n’organise plus aussi souvent les Meetup Evernote qu’il en avait l’habitude. Il faut dire que sa nouvelle aventure, faire de La Chaine Guitare une startup l’occupe énormément. Dans ce contexte, nous devons lui être reconnaissant de parvenir à distraire du temps pour organiser épisodiquement ces rencontres.

Cette rencontre-ci ciblait plutôt les nouveaux venus à la plateforme de prise de notes, donc pas des gens comme moi en principe. Mais outre le plaisir que j’ai à me rendre à ces rencontres, j’y découvre invariablement de nouvelles choses.

image

Le tour de l’application desktop

Tout d’abord le tour de l’application Evernote Mac pour les débutants. On s’arrête un peu sur la nouvelle fonction diaporama, ou la possibilité de créer une table des matières par simple multi-selection de notes ! S’en suit un nouveau round de l’éternelle question : tags ou carnets ?

En ce qui me concerne, j’avoue utiliser les tags avec moins de conviction qu’hier et utiliser un peu plus de carnets. En fait, j’ai l’impression que Pierre fait comme moi sur un point : il créé un carnet quand il s’aperçoit qu’il finit par écrire beaucoup de notes sous le même thème. De toute façon, c’est clairement la recherche full text qui nous sert le plus à retrouver nos notes ! Le retour des participants sur les tags est :

  • Une grande discipline dans leurs usages : toujours les utiliser, sans les multiplier à priori.
  • Concevoir le système de tags selon l’usage que l’on en aura dans 2 ans ! J’avoue que ce dernier point me pose problème : c’est typiquement le genre de question que je ne prétenderais jamais être capable de répondre !

En parlant de recherches, Pierre nous montre une fonctionnalité que j’ignorais : la possibilité de faire des recherches full text, mais spécifiques :

  • Sur des tags : “tag:xxx”
  • Sur des carnets : “notebook:xxx”
  • Dans les titres : “intitle:xxx”

Pierre nous montre aussi la création de raccourcis dans la partie gauche. Je n’ai jamais pensé à utiliser cela, pas sûr que je m’y mettre… Nous voyons aussi l’interfaçage avec skitch pour modifier les images : ça il faudra que j’essaie !

Je découvre aussi en passant la fonction de lecture orale du texte avec Evernote Clearly (dont je me sers beaucoup pour récupérer poprement des posts qui m’intéressent).

L’actualité Evernote

Pas de grandes nouveautés aujourd’hui dans les fonctionnalités coeur. Evernote semble très occupé avec du cleanup de code. Nous avons évoqué le post de Jason Kincaid auquel à fait suite une réponse de Phil Libin ( ) ! Evernote va concentrer ses forces sur la qualité et la stabilité du code en 2014.

image

Evernote doit rester simple, efficace, fiable et performant, donc j’approuve en partie ce choix. Par contre, certaines fonctionnalités font partie de ma liste au Père Noel:

  • La possibilité de générer un texte converti depuis une note manuscrite. J’en avais parlé dans mon essai du Livescribe, nous en avons reparlé ce soir.
  • La possibilité de créer des carnets d’index, référençant des notes figurant dans des carnets. Ce serait utile pour synchroniser des carnets sur mobile. Pierre nous a décrit comment il déplace les notes dans un carnet “offline” pour cela, l’obligeant ainsi à redéplacer plus tard sa note dans l’autre sens ! Pierre en parle d’ailleurs dans la dernière émission de son Podcast sur La Chaine Eléphant.

Démonstration du Livescribe Sky

C’est ma partie. Je ne vais pas vous refaire l’essai que j’ai déjà posté ici. J’avais amené tout le matériel, y compris les carnets. Je n’ai malheureusement pas été capable de connecter le stylo au Wifi local. Tout comme on avait pu jouer au voyeurs avec les notes de Pierre, on a pu faire la même chose avec les miennes. Egalité !

Fin de soirée

Une très bonne soirée, même si je suis arrivé un peu en retard. Pierre a été un peu plus rapide que moi pour poster son compte-rendu.
Je fais une partie du chemin de retour avec l’un des participants. Et je m’apperçois qu’il s’agit de Guillaume Vendé, le co-animateur du Podcast niplife ! Ca ne vous dit peut-être rien, mais je suis un (très) fidèle du grand frère de la famille, c’est à dire niptech podcast. Guillaume et Pierre se connaissent car ce dernier avaité té le premier invité de niplife où il avait été question de GTD.

C’est tout pour aujourd’hui, en espérant ne pas se languir encore un an pour le prochain meetup.

Agile Playground #12

Le par addinquydans Compte-renduLaisser un commentaire

Cela faisait un moment que l’Agile Playground m’échappait. La faute à un agenda difficile à concilier. C’était réglé pour cette fois. Nous nous retrouvions de nouveau dans les locaux de CLT pour cette nouvelle édition.

Au programme un jeu (et un seul) : Au tableau ! Ce jeu a largement été promu par Alex Boutin, bien qu’il n’en soit pas l’auteur.

Le but du jeu est simple : on nous donne la situation d’un portefeuille de projets, et à partir de là il faut trouver la forme de “management visuel” donnant le meilleur impact. 2 itérations de 20 minutes sont prévues, entrecoupées d’une dizaine de minutes de rétrospective. Nous n’étions pas nombreux, nous avons donc formé 3 équipes de 6 ou 7 personnes.
L’une des équipe disposait d’une table

image

Les deux autres utilisaient une tenture adhésive. Avec pas mal de difficultés à faire tenir dessus ce que nous voulions.

image

Petit (gros) biais de l’exercice : y participaient des personnes rompues au management Visuel ou au Kanban. Le résultat de la première itération montrait des résultats plutôt très convergents, avec quelques particularismes locaux.

image

La seconde itération intégrait bien de nouveaux éléments, mais qui ne posaient guère de problème à des habitués. Au final, l’inspiration transverse aidant, les résultats se montraient réellement semblables !

image

Il y avait peu à dire sur les directions prises par chaqune des solutions. La discussions de fin a plutôt porté sur les différentes dynamiques de groupes, je pense que ce n’était pas dans la cible de l’exercice. J’en tire quelques conclusions :

  • L’exercice est plutôt destiné aux novices. Cela n’est pas si porteur de le faire avec des vétérans. De plus, les niveaux hétérogènes ont mal marché dans notre cas. Probablement de notre faute.
  • Il faut limiter le nombre de personnes par tableau. Nous étions 7, c’est beaucoup trop : on ne peut pas travailler autour du tableau en si grand nombre. Je dirais que 4 est le maximum.
  • Nous aurions dû en profiter pour délirer plus, faire un Kanban circulaire avec des swimlanes en forme de part de camembert ou d’autres choses dans le genre. Non seulement nous nous serions plus amusé, mais il y aurait même pu y avoir des choses inattendues à en retirer !

Venez comme vous êtes au FKUG !

Le par addinquydans Compte-renduLaisser un commentaire

“venez comme vous êtes”, c’était le thème de cette première rencontre des affiionados de Kanban ! Au programme : 2 présentations chez “un grand de l’assurance dont le nom commence par A” et “l’acteur majeur des paris hyppiques en France”. Couthaïere Farfra, à l’origine de ce groupe, assurera la première présentation, ainsi qu’une rapide et efficace présentation du groupe, de ses objectifs et de son organisation.

A force de trainer mes guêtres dans diverses réunions agiles, on fini par connaitre du monde. C’est mon cas, et débarquer en connaissant déjà une bonne moitié de l’audience est plutôt agréable, on se sent en famille. Cela a aussi son petit côté jubilatoire quand ceux que vous ne connaissez pas vous voient aborder tout le monde comme s’il s’agissait de vieux amis (c’est d’ailleurs le cas pour certains). On s’amuse comme on peut, n’est-ce pas ?

Kanban à grande échelle chez un grand de l’assurance.

Couthaïer nous fait ici un retour sur la mise en place, les pratiques et les impacts d’une mise en place sur un grand plateau de développement impliquant un grand nombre d’équipes, en mode distribué qui plus est : les product owner étant sur un autre site. Cette transition vers Kanban s’est opéré à partir d’un processus “Scrum”. Je mets des guillemets car à la description, il me semble qu’il s’agissait là d’un Scrum “Canada Dry”, customisé pour les besoins du client comme on dit. Chaque fois que j’entends cela, je sais que je ne dois pas m’attendre au meilleurs…

image

Quoi qu’il en soit, cette mise en place a commencé par un pilote : 2 équipes totalisant 30 personnes (tout compris). L’accompagnement a pris une allure standardisée : 8 semaines à temps plein par coach et par équipe. Chaque coach ne s’occupe que d’une équipe ! Au niveau de a portée du suivi, sont exclus :

  • La partie amont : identification et spécification du besoin
  • La partie aval, dévolue à la partie “devops” !

Les objectifs sont également clairs :

  • La satisfaction du client
  • Améliorer la qualité
  • Tenir les promesses (!)

La mise en place du Kanban reflète le backlog, avec des passages d’état : MMF >> Acceptée >> Critère d’acceptante >> BDD >> INVEST >> Dévelopment >> Tests

A cela se rajoutent bien sûr la mise en place de limites, qui doivent à terme nous permettre de connaitre la véritable capacité de notre système. La maitrise de cette capacité est en bonne partie subordonnée au fait que les stories entrant dans le système sont relativement homogènes en terme de taille. Dans la pratique, elles sont estimées au stade “INVEST”.

Au Kanban lui-même s’ajoute la mise en place de KPI : ici c’est le “cockpit”. Tout cela est bien beau, mais prends beaucoup de place. En fait, le plus gros problème est là : trouver des murs pour afficher ces Kanbans !

Supprimer les gaspillages

Ils sont subordonnés aux obstacles. Et les obstacles, il faut les surmonter. Ils sont de deux types: les petits obstacles et les gros obstacles.

Pour les petits obstacles, on passe par des fiches Kaisen. La revue des obstacles s’effectue lors du stand-up sur le tableau de suivi des obstacles.
Pour les gros obstacles, on passe par des A3 et des Kata.

Réduire les anomalies

Le pair testing est une activité clé ici, dans le cas présente entre un développeur et un testeur. Les anomalies sont considérées comme critiques : on les traitent sans attendre. Au bout du compte, un ratio d’anomalies très réduit, de l’ordre de 0,7 anomalies par User Stories.

La délocalisation : c’est tellement mieux de se compliquer la vie…

Comme je l’ai évoqué, le “avant”, c’était du Scrum pas vraiment “by the book”. En fait, un mixte qui me semble un peu contre nature entre Scrum (au moins le vocable), CMMi et le near shore. C’est une des difficultés de la chose.

La réponse mise en oeuvre est un Kanban miroir sur le site délocalisé, synchronisé au début du stand-up commun aux différents sites. Cet aspect de synchronisation est un des aspects difficiles. Les outils électroniques n’ont pas ce problème mais leur lacune en terme de visualisation limitée pose d’autres questions…

Tenir les promesses

Le CFD (cumulated flow diagram) est l’outil utilisé à priori pour suivre la machine Kanban. Il donne des indications sur :

  • Le débit
  • Les goulots d’étranglement
  • Les en cours

Cela dit, il n’est pas facile à lire… Le CFD montre verticalement le débit, il peut permettre d’extrapoler une date d’atterrissage et montre aussi les perturbations, là où la monotonie de la courbe est rompue. L’axe horizontal montre les temps de cycle, du moins une approximation de ceux-ci. On peut comparer les deux approches, mais c’est un poil compliqué.

Le suivi du Kanban, c’est aual le suivi d’indicateurs issus de son évolution. Ici ils sont mis à jour hebdomadairement. Un point crucial est que la pertinence des informations reste très subordonnée à l’homogénéité des items qui figurent sur ce Kanban !

Pause éclair

Guère beaucoup de temps pour se dégourdir les jambes, on a à peine 5 minutes pour cela. J’aimerais bien échanger avec certaines personnes. Ce sera pour après, peut-être…

image

Renaud Chevalier : La conception d’un Kanban en suivant la méthode Morrisseau

Laurent serait fier de son disciple : Renaud va nous faire suivre la mise en place de son Kanban en suivant sa méthode. Il l’apprécie et elle marche. Démonstration.

Cette mise en place a été effectuée chez “l’acteur national majeur des paris hippiques”. Si vous n’avez pas compris,cherchez encore. Il nous faut remonter à Septembre 2012 pour comprendre l’origine de cette mise en place. A l’époque, le projet fait face à deux inquiétudes majeures :

  • Un problème de “qualité” de backlog, qui ne donne que 2 sprints de visibilité. En tout cas, c’est rangé dans les problèmes par le management.
  • Un risque technologique lié aux choix opérés : Du Java en back-end exposant des services ReST, un front-end en backbone.js et une gestion de contenu accédée en ReST ; c’est du Drupal. Ce n’est pas la mort, mais bon on est chez … af ! C’est vrai… on ne peut pas le dire !

La dessus, la vision macro de ce qui reste à réaliser annonce 1 an de retard ! Branle-bas de combat ! Audit !!

image

Les propositions issues de l’audit proposent entre autre la mise en place d’un grand Kanban transverse, voilà qui est intéressant ! En plus, ça ne parait pas si difficile, un Kanban. Il est rapidement mis sur pied.

Hélas, trois fois hélas : au bout de 2 semaines seulement, ce Kanban ne vit plus ! Que s’est-il passé ? Renaud décide de reprendre les choses à la base, donc de suivre la démarche de Laurent Morrisseau.

image

La portée et les objectifs

Justement, on met directement le doigt là où ça a pêché : une portée trop importante de ce Kanban initial ! La portée du Kanban doit être celle où l’équipe est propriétaire du processus. Ce n’était pas le cas du Kanban précédent, remontant trop en amont (dans l’élaboration du besoin) et en aval (dans la partie production / exploitation).

De plus, inutile également de produire un Kanban correspondant à un processus cible. Il faut commencer là où l’on est, avec le processus courant.

Pour matérialiser les objectifs, il faut identifier ceux-ci ainsi que les insatisfactions actuelles. Cela s’est fait sous forme d’interviews.

La nature de la demande

Pour la connaitre, il faut identifier ce qui arrive à l’équipe, ce qui l’alimente. Dans le cas présent, on a :

  • Les anomalies en provenance de la QA
  • Les demandes du marketing
  • Les “stories techniques”
  • La dette technique

La question subsidiaire est celle de la taille de ces demandes. Comme on l’a vu précédemment, la qualité du Kanban est subordonné à l’homogéneité des items. Ici, Renaud va utiliser les tailles T-Shirt pour évaluer ces items (S, M, L, XL).

Enfin, pour se faire une idée de la situation actuelle, on procède à 3 analyses:

  • Débit par Sprint et par type de demandes
  • Débit par sprint et par taille T-Shirt
  • Débit par catégorie d’anomalies

Le flux de travail et carte Kanban

Au départ, il faut identifier le workflow spécifique à chaque type de demande. En l’occurrence, chacune des 4 catégories a son propre cycle, seules les demandes marketing rentrant dans les sprints !

4 catégories de demandes, cela veut dire 4 cartes Kanban. Elles diffèrent légèrement en contenu en fonction de leur type, mais les éléments de même nature se retrouvent au même endroit : la rigueur d’organisation est un facteur clé d’efficacité. On affectera aussi une couleur spécifique à chaque type de demande. Nous verrons que cela s’avère très important au niveau du tableau.

Le tableau

Justement, le tableau nous y sommes ! Et l’on commence par déterminer les règles de priorités des demandes, quel que soit leur type. C’est intéressant, car on a coutume de subordonner la priorité au type. Or ici on va utiliser l’évaluation du “cout du délais”. C’est une bonne façon d’éviter de se faire hacker le système en transformant une demande en anomalie, par exemple !

Donc, sur ce tableau, on commence par alimenter le système par type de demande, et le premier triage consiste à réalimenter la suite du tableau par classe de service en utilisant ce facteur de cout du délais. Comme chaque classe de service peut théoriquement contenir n’importe quel type de demande, il est opportun de pouvoir facilement distinguer facilement ces différents types : d’où les couleurs !

Règles, règles…

C’est là que l’on rentre dans le volet pas très “agile mind set” du Kanban. Cela couvre 3 volets :

  • Les règles aux interfaces : Quelle règle pour réalimenter le système ? Quel règle pour déclencher la sortie des items ? C’est aussi (surtout) une question diplomatique avec les équipes avec lesquelles on collabore…
  • Les règles internes. Elles sont de plusieurs types. La principale est la “definition of done” qui permet à une carte de passer à l’étape suivante. Les autres règles traitent des exceptions (escalade, changement de priorité, annulation, etc.)
  • Enfin, la grande question : qui s’occupe du respect des règles. La réponse est : le process manager ! Oui, vous avez bien lu, on a un process manager, comme il y a 20 ans !

La capacité du système

Le système en place, il s’agit maintenant de le monitorer et le “tuner”. Au départ, il faut fixer des limites hautes et basses, de manière plus ou moins empirique au départ. Un point particulier concerne la gestion de la dette technique : on en garde toujours une en cours. C’est un tâche de faible prioité qui peut être interrompue pour répondre à une classe de service de niveau le plus élevé.

Le juste à temps et la cadence

Travailler en mode Kanaban ne signifie pas abandonner complètement les rituels réguliers. En fait chaque rituel a sa propre cadence, et ce n’est pas calé de manière global sur une fin d’itération. En fonction du type de cérémonie, on trouvera des rythmes :

  • Journaliers
  • Hebdomadaires
  • Pluri-hebdomadaires

</FKUG #1>

Si j’ai trouvé la seconde session particulière instructive et bien présentée, je dois dire que globalement le contenu de ce premier rendez-vous valait largement le coup. En fait, il était même mieux que ce à quoi je m’attendais !

Expérience réussie, donc. J’ai hâte d’être au second rendez-vous !

Coach retreat Parisien

Le par addinquydans Compte-renduLaisser un commentaire

Après en avoir laissé passer deux ou trois (au moins) pour cause d’agenda surchargé, je me suis pris par la main et ai pris mon ticket pour ce premier Coach retreat 2014. Ticket tout à fait bon marché par ailleurs, car Criteo nous hébergeait dans ses magnifiques locaux Parisiens (en plus d’assurer les vivres) et Oana Juncu associée à Adrian Perreau de Pinninck ont accordé bénévolement de leurs temps, leur énergie et leur savoir-faire pour rendre possible cette rencontre.

Les 17 présents sur les 24 inscrits ont, eux, consacré leur samedi à investir sur eux-même pour parfaire leurs pratiques !

Modus operandi

Le coach retreat fonctionne avec quelques règles de base :

  • Une même étude de cas répétée tout au long de la journée (ici 4 fois). A sélectionner parmi quelques unes. C’est le concept de base (le répétition) que Oana a emprunté au code retreat.
  • Un “seeker” qui jouera le rôle du coaché et devra s’approprier la situation. Nous aurons l’opportunité de jouer ce rôle une fois durant la journée.
  • Deux coaches, qui doivent s’efforcer de travailler de concert (pas évident quand on ne se connait pas !) et d’appliquer une technique donnée.
  • Deux à quatre observateurs en position “méta” qui restitueront ce qu’ils voient se passer.
  • Une technique de coaching différente à essayer à chaque session. Durant chaque session, nous formons 3 équipes de 5 à 7 personnes.
  • 40 minutes de session, suivi de 10 minutes de retrospective en équipes et se concluent par 10 minutes de mise en commun.

Au départ !

On commence par sélectionner l’étude de cas que nous avons envie de dérouler. Elles sont affichées dans le hall et on procèdera tout simplement par un “dot voting”.

image

Ce qu’il faut, c’est une situation dans laquelle on parviendra à se retrouver, car il faudra jouer le rôle du seeker à un moment donné. Comme Frédéric, on peut trouver cela Cornélien…

image

Première session

On commence en douceur, sans appliquer de structure de session de coaching proprement dite, mais une technique : celle du “click rewind” qui nous permet d’arrêter le déroulement pour revenir en arrière quand on pense s’être fourvoyé. C’est assez pratique, presque tricher, car c’est impossible à mettre en oeuvre dans une séance de coaching normale. Dans la pratique, nous utiliserons aussi le “click pause”.

image

Le débrief met en lumière deux difficultés, au moins dans notre équipe :

  • Une réelle difficulté d’accorder nos violons à deux coaches avec des approches radicalement différentes.
  • Coacher un “sachant” qui occupe beaucoup le terrain n’est pas évident. Mais c’est la vraie vie.
image

Seconde session

Durant cette seconde session, nous allons mettre en oeuvre une technique promue par Virginia Satir : substituer le “oui, et…” au “oui, mais…”. Autrement dit, substituer à ce qui n’est jamais qu’une négation déguisée, une démarche constructive.

Cette fois, la mise en oeuvre s’avère un peu décevante, malgré un seeker très créatif à habiller la mise en situation. J’ai relevé par exemple :

  • Une difficulté à orienter le coaché vers le “oui, et…
  • Des "solutions” poussées par les coaches assortis de “peut-être…”

Je n’étais pas coach mais observateur cette fois. Mais rien ne dit que j’aurais fait mieux. On fait ici ce qu’on doit faire : s’essayer et découvrir les difficultés auquel il nous faut faire face pour nous améliorer. C’est donc positif.

Le débrief est là pour nous aider à y voir plus clair.

image

Pause Pizza

La pause déjeuner est bienvenue : pizzas et mousses au chocolat au menu. J’en profite pour discuter un peu avec Christopher Mann. J’avais apprécié l’excellent travail de couverture photographique de Christopher lors d’Agile France 2013. Christopher tente de concilier une double activité et une double passion de photographe au travers de son activité Seeeshoot et de conseil informatique, ce qui n’est bien sûr pas facile.

image

Reprise : 3ème session

L’après déjeuner, c’est souvent un moment un peu délicat. Notre solution : nous y remettre tambour battant. Cette 3ème session va nous permettre d’expérimenter une technique plus structurante que les précédentes : l’appreciative inquiry. Dans cette technique, on va se focaliser dans ce qui va bien en menant l’entretien en 4 étapes, également appelé “les 4 D” (mais ça ne marche qu’en Anglais) :

  1. La découverte : Comme es ta vie ?
  2. Le rêve (dream) : Comment ta vie devrait être ?
  3. Design : quelles sont tes options qui pourraient convenir, être suffisamment bonnes ?
  4. Define : Comment y arriver.

Cette fois, je serais le seeker. Une session pas trop mauvaise, mais que nous avons peiné à mener à bout. En fait, nous n’y sommes pas arrivés. Parmi les points que nous avons relevés :

  • Il faut progresser “vers l’avant” sans faire de retours arrières.
  • Notre timing était trop serré, au moins pour cette mise en oeuvre.

Au-dessus des toits de Paris

Nous avions prévus une petite coupure avant la dernière ligne droite. Adrian a eu la bonne idée de nous proposer de monter sur la terrasse pour nous y détendre un peu.

image

Et surtout pour profiter de la vue sur Paris. Jugez-en un peu. Vers le sud-ouest, donc vers la Tour Eiffel.

image

Et vers le nord-est, vers le Sacré-Coeur qui est à un (gros) jet de pierre.

image

Et pendant que les handicapés dans mon genre utilisent benoitement leurs appareils photo, Dov lui, choisit de croquer un dessin…

image

Dernière ligne droite : 4ème session

Cette dernière session met en oeuvre la technique la plus délicate de la journée : le solution focus si cher à mon collègue Géry Derbier.
Le solution focus, c’est un peu le remember the futur. Nous allons le jouer en 4 temps :

  1. Quel est votre situation aujourd’hui ? Sur une échelle de 1 à 10, quelle note donnerez-vous ? Expliquez pourquoi vous êtes (quand même) à cette note ?
  2. A quel note souhaiteriez-vous être demain ?
  3. Imaginez qu’un miracle vous amène à la situation souhaitée pendant la nuit, comment constatez-vous que vous y êtes le lendemain matin ?
  4. Comment les autres constatent que nous sommes dans cette situation.

J’ai binômé en tant que coach pour la seconde fois de la journée sur cet exercice. Succès mitigé.

  • Notre seeker a fait un très bon boulot en adoptant une attitude constructive, mais qui ne nous facilite pas trop le travail.
  • Sans être éblouissant, nous avons progressé correctement sur les 3 premières étapes, voir même la quatrième.
  • Nous nous sommes un peu enlisé pour aider le seeker à trouver son chemin. Paradoxalement, c’est une idée que j’ai poussé en mode assertif, pas du tout façon coaching , qui a le plus retenu l’attention du seeker.

Pour tout dire, la fatigue commençait un peu à se faire sentir, il est temps de conclure.

This is the end

On partage l’expérience de cette journée à tour de rôle avant de se quitter. Pas de retranscription ici, c’est entre nous !

Par contre, vous pouvez regarder ce qu’il est dit sur le “mur des Ah-ah !”

La journée se termine. Nous remercions Criteo pour son accueil mais aussi sa participation, car ils sont 4 à s’être joins à nous ! Adrian pour sa gentillesse et son organisation pou avoir rendu cela possible. Et bien entendu Oana pour son animation, son énergie et sa bonne humeur !

… Et Neo4J devint CMS !

Le par addinquydans Compte-renduLaisser un commentaire

Lors de ce Meetup Neo4J de Janvier, toujours dans le zLocalHost de Zenika, nous avons pu découvrir Structr, et comment il adresse la problématique du CMS. Ou du moins, nous allons le faire.

Cédric Fauvet au pas de charge !

Cédric commence par sa très classique introduction à Neo4J. Introduction un peu écourtée d’ailleurs : c’était la soirée des problèmes techniques et il a fallu rattraper le temps perdu.

Le temps tout de même de donner quelques nouvelles de la communauté et de l’actualité. On s’attardera quelques instants sur la dernière référence Française : Meetic ! Bien entendu, comme pour Viadeo, le but est la recherche d’adéquation de profiles. Ce n’est d’ailleurs pas une première expérience pour Neo4J qui a équipé d’autres sites de rencontre avant de s’occuper du n°1 européen.

Autre nouvelle intéressante : la mise à disposition de cours en ligne ! J’ai hâte d’aller voir ça…

Structr

Axel Morgner est fondateur de Structr, il est venu spécialement de Frankfort pour évoquer son usage de Neo4J. Après avoir longtemps travaillé dans le domaine du CMS, il a décidé de changer d’horizon, de faire autre chose. Il a découvert Neo4J, et a décidé de construire avec … un CMS !

image

Structr c’est une société mais aussi un logiciel open-source. La motivation ? Construire des sites web dynamiques avec du contenu. La première release de la bête est apparue en 2011.

La première itération : c’est une classique webapp standalone, dont la partie front utilise freemarker.

Les choses changent radicalement en seconde itération ! C’est d’abord un changement de scope : Structr devient un pur back-end, le front-end est abandonné ! Le produit assure un mapping bidirectionnel entre JSON et le graphe. Et le produit intègre une notion de schéma et de contraintes (avec même une gestion des suppressions en cascade), des choses qui vont bien plus loin que les évolutions apportées par Neo4J 2.0 !

L’interface utilisateur revient en 3ème itération, mais elle s’est faite HTML5 ! Elle permet l’édition sur place, la visualisation des liens entre pages, etc…

Démo time !

Axel nous fait bien sûr une petite visite guidée de la bête. On commence fièrement par un import de page que l’outil digère pour le transformer en graphe. On peut utiliser alors l’édition sur place pour importer ou saisir du contenue … ou faire référence à du contenu dans le graphe, via des requêtes Cypher, par exemple !

image

La sécurité n’est pas en reste et elle se configure sur les noeuds. Elle est bien sûr transitive, suivant les liens “contains”. L’IHM est aussi synchronisée entre les clients, permettant l’édition de contenu collaboratif.
Mais tout cela, c’est du statique. Du “boring stuff” comme le dit Axel. Structr gère la dynamicité du contenu, en partie du fait qu’il ne gère pas de cache et se repose sur la performance de neo4J. L’une des clés est la référence qui peut être faite depuis les pages vers du contenu structuré lui-même dans le graphe.

Pour cela il faut créer un projet “data type”. C’est lui qui permet la structuration des données et les contraintes dont nous avons parlé plus haut. On y crée aussi des bindings qui peuvent être référencés par des noms symboliques.

L’une des question que je me posais pendant que la démo se déroulait concernait les contenu volumineux, de type “blob”. On sait que Neo4J n’est pas fait pour cela. Qu’a cela ne tienne, les data types peuvent référencer des fichiers ou même des répertoires ! Au-delà de cela, il y a aussi des concepts de “web components” et de “shared components area”, mais ne m’en demandez pas plus, car j’ai un peu perdu le fil à ce moment là !

Malgré quelques petits accrocs lors de la démo, il faut avouer que cette gestion de contenu est pour le moins étonnante et résolument différente de ce qui se fait !

Teasing

Cédric souhaitait innover en donnant une minute de parole au débotté à des participants du Meetup ayant un projet avec Neo4J.

Un étudiant de Supinfo Lille (désolé, je n’ai pas noté son nom) nous a donc parlé de son projet d’étude : un “Dropbox like” intégrant une dimension sociale de partage. L’utilisation de Neo4J permet ici de représenter les structures de fichiers, répertoires, partages et droits, tandis que les contenus eux-même peuvent être répartis sur différents serveurs de stockages, ces contenus étant simplement référencés dans le graphe.

Quand Sébastien Just est venu nous parler de Seij, j’ai cru que Structr venait de trouver son frère jumeau ! J’ai pu discuter un peu avec Sébastien et suis maintenant convaincu que ce n’est pas le cas. Certes les deux applications partagent nombre de concepts : le CMS basé sur des graphes Neo4J et la possibilité de constituer son contenu en assemblant les éléments issus des noeuds. Mais là où Structr s’appuie sur une structuration et un typage fort, Seij s’enorgueillis de son approche “free form”, un peu comme si l’on avait un Excel pour la gestion de contenu. Des concepts très proches mais un ciblage client très différents en font deux produits qui ne se comparent finalement pas. J’espère que Sébastien aura l’occasion de revenir nous le présenter et nous en parler !

Stoos Satellite Paris en Janvier

Le par addinquydans Compte-renduLaisser un commentaire

Le nombre ne fait pas forcément la qualité (il est vrai que l’inverse ne se vérifie pas non plus), nous n’étions que 3 pour ce premier déjeuner Stoos de 2014 !

Passer un moment intéressant ensemble, avec des personnes que j’apprécie, avec lesquelles je vais pouvoir échanger des idées et qui me feront reflechir est déjà une bonne motivation pour moi. Yannick et Christine font sans aucun doute partie de ces personnes.

image

La co-création de valeur

Christine nous avait fait rencontrer Manfred Mack l’an dernier, ce dernier nous avait parlé de co-création de valeur et de son expérience en cette direction chez Spi-Batignolles. Ils semblent tous deux très motivés pour enclencher un évènement autour de cette question, peut-être une bonne occasion d’impliquer le groupe et enfin faire quelque chose de concret.

Par contre, il reste à déterminer quelle forme donner à cela. Car si des témoignages sont intéressant, cette approche se vit plus qu’elle ne s’expose. Nous avons donc encore du pain sur la planche.

Pour l’instant notre réflexion nous a conduit à explorer l’existence de cette co-création à différents niveaux stratégiques ou opérationnels. C’est peut-être une voie à explorer pour une thématique du genre “la co-création de valeur aux différents niveaux de l’entreprise” ?

Les tests d’acceptance sont de la co-création

Il semble que Yannick et moi partageons la même expérience sur ce sujet : Ecrire des tests d’acceptance en faisant travailler côte à côte les différents métiers impliqués dans un projet nous apporte une plus value à de nombreux niveaux :

  • Créer une convergence de point de vue et de compréhension du problème.
  • Etablir un langage commun.
  • Valoriser la complémentarité de points de vue et de savoir-faire des intervenants.

Le motif récurrent semble être le “langage commun” d’une part et l’effacement de la frontière entre le “nous” et le “eux” qui nous est si chère, à nous autres agilistes.

Communautés et équipes opérationnelles

Effacer les frontières entre les métiers pour réaliser des projets en mettant les personnes nécessaires dans une même équipe, c’est bien. C’est même indispensable. Mais c’est aussi détruire une citadelle pour en construire une autre !

En effet, le partitionnement organisationnel en métiers induit une friction dommageable au fonctionnement des projets, souvent coûteux, parfois fatal. Par contre il favorise la transmission d’information transversal et permet (ou plutôt devrait permettre) l’amélioration des savoirs-faire.

Les unités projets pluri-disciplinaires réduisent cette friction et améliorent l’efficacité de manière très importante. Mais elle créent de nouvelles barrières pour permettre la communication transversale et l’apprentissage au sein d’un même corps métier. C’est là qu’interviennent les principes de communauté et de guildes comme l’évangélise Jurgen Appelo ou que l’applique Henrik Kniberg chez Spotify. La difficulté étant de maintenir et entretenir ces communautés. C’est parfois fait via un “20% de management opérationnel”. Je vais tenter quelque chose en ce sens dans les mois qui viennent, j’aurais peut-être un retour à faire d’ici quelque temps…

Effectuation

Voilà plusieurs fois que j’entend revenir ce néologisme. Cette fois, c’est Yannick qui nous en parle ! Apparemment, il s’agit d’une logique d’expertise entrepreneuriale qui va à l’inverse de la logique causale, mais qui part plutôt de l’effet que l’on cherche à obtenir, si j’ai bien compris. Elle se rapprocherais ainsi de la logique de pensée du coaching orienté solution, si je peux me permettre cette association osée…

La vidéo de la conférence TED que m’a envoyé Yannick est un peu longue, mais Saras Sarasvathy est la chercheuse qui a identifié et formalisé ce concept, il est donc juste d’en donner le lien.

A bientôt pour un prochain déjeuner Stoos ou des nouvelles de l’évènement sur la co-création de valeur !

Meetup Neo4J de décembre 2013 : Des recommandations en temps réel avec Recolytic

Le par addinquydans Compte-renduLaisser un commentaire

Ce sont deux sujets qui seront abordés lors de ce meetup. En effet, en introduction à la présentation de Rochdi Chakroun, Cédric Fauvet a évoqué le concours GraphGist, concours où il y a peu à gagner. Mais ce n’est pas l’objectif. Ici, il s’agit plutôt de monter de petits cas d’utilisation originaux. Neo4J souhaite visiblement pouvoir montrer beaucoup de cas d’utilisation créatifs et variés de sa base de données.

Cédric Fauvet débute généralement ces rencontres par une présentation de la société, des cas d’usage de Neo4… Celle-ci ne fit pas exception.

image

Bien sûr il nous présente les mêmes concepts, les même cas d’utilisation ou presque, mais le propos évolue quand même un peu à chaque fois. Et de plus, il y avait aujourd’hui Neo4J 2.0 à évoquer ! Il n’y a rien non plus de rébarbatif dans sa façon de présenter les choses. Après tout, avant d’être responsable de Neo4J France, Cédric était un développeur comme nous !

Mais avant de passer à la suite : Pizza time !

image

Recolytic

Rochdi Chakroun est architecte logiciel chez Vente Privée. Mais ce n’est pas à ce titre qu’il venait aujourd’hui, mais plutôt pour présenter le fruit d’un projet personnel : Recolytic.

image

Le constat de Rochdi est que les systèmes de recommandation sont aujourd’hui obscures : "nous allons faire progresser votre chiffre d’affaire, vous n’avez pas à savoir comment". Une position qu’il juge insupportable au regard de l’aspect stratégique de ce traitement.

Autre aspect que l’orateur a voulu adresser : la recommandation en temps réel. Les moteurs de recommandation s’appuient sur la plupart sur des algorithmes et des traitements de machine learning qui demandent de longs temps de traitement en différé pour fournir de nouveaux modèles mis à jour.

Recolytic se veut performant, facile à intégrer et transparent sur la stratégie. Il s’appuie bien sûr sur Neo4J, ici le modèle c’est le graphe. Et ce graphe est composé de triplets utilisateur – action -ressource. Il est à noter que Rocolytic est complètement agnostique sur la nature des ressources. Des poids peuvent être accorder aux actions ou aux ressources, par exemple pour donner plus d’importance à un achat par rapport à une consultation.

Pour ce qui est des APIs, Rocolytic en propose 3 catégories :

  1. Les API de collecte : pour récupérer les actions des utilisateurs.
  2. Les APi de recommandation. Elles permettent plusieurs stratégies.
  3. Les API de mesure. Afin de mesurer après coup la pertinence de recommandations et ajuster le paramétrage en conséquence.

A l’initialisation de Recolytic, on débute sans informations de l’utilisateur. Il est donc pertinent de commencer avec la stratégie par défaut : les plus populaires.

Il sera ensuite possible de basculer vers une autre stratégie, par exemple la similarité de panier.

Pour démontrer le produit, Rochdi nous propose de nous promener dans un site d’e-commerce de démonstration.
Rochdi ne s’est pas encore fixé d’objectif pour les prochaines étapes : en faire un open-source, ou une startup… Il avoue surtout avoir besoin de récupérer de ses efforts. On le comprend : il a quand même réalisé tout cela en gardant son activité chez Vente Privée !

En Janvier, nous rencontrerons un autre cas d’utilisation avec Structr.

Evernote France Meetup 2013 (en images)

Le par addinquydans Compte-renduLaisser un commentaire

Comme l’an dernier, Evernote France nous a convié en ce début Décembre à un meetup assez corporate sur l’état du monde Evernote. L’occasion était bonne de glaner des informations, t-shirts et autres rencontres inattendues.
La rencontre se faisait dans un espace de coworking, Le Loft 50 Partners qui est également un incubateur de startups. L’un et l’autre fleurissent décidement à tous les coins de rue de la capitale, je finis par être regardé avec suspiscion et peut-être même méprisé à ne pas être moi-même entrepreneur ! Il y a matière à réflexion.
Mais ce n’est pas la reflexion du jour. Ici, on parle Evernote, et on fait salle comble !

En attendant le début (3)

On a aussi fait le plein de speakers, même si les interventions seront courtes.

En attendant le début (2)

Cristina Reisen

Cristina est manager d’Evernote pour la région Europe ! On fait d’abord le compte des utilisateurs : c’est 80 millions de par le monde. On n’a pas celui de la France, mais sachez qu’il a doublé depuis l’an dernier.

Cristina Riesen (2)

Quelques faits également sur l’année écoulée :

Bref le message est clair : Evernote s’étend, aussi bien sur l’écosystème que sur les verticales !

Julien Boedec : La plateforme Evernote

On a de la chance cette année : tous nos intervenants s’expriment en Français ! Cela dit, j’ai été un peu déçu par cet intervenant. J’espérais plus “d’insights” sur la plateforme Evernote. On en a pratiquement pas parlé, mais plutôt eu un apperçu sur ce qui gravite autour !

Julien évoque 2 axes de développements :

  • Le travail conjoint avec les partenaires : IFTTT, Dolphin browser, postach.io, etc…
  • L’évènementiel en relation avec l’entreprenariat (encore…) : hackathons, meetups dev, accélérateurs…

Bref, pas grand chose à me mettre sous la dent.

Xavier Delplanque, senior product manager

Si j’ai été déçu par Julien, ce n’est pas le cas de Xavier. Son exposé est en fait une excellente surprise, même si je ne pourrais résumer son intervention ici.

Xavier Delplanque

Xavier nous explique le processus de travail et de création autour de l’expérience utilisateur. En l’occurence ici : comment améliorer la première impression sur plateforme mobile. Les nouveaux partenariats avec des sociétés telles qu’Orange drainent en effet de nouveaux utilisateurs potentiels à même de quitter l’application si les premières minutes (voir secondes) d’utilisation ne sont pas convaincantes !
Ainsi l’orateur nous explique le travail itératif autour des solutions, s’adossant sur de l’A-B testing, où finalement les fonctionalités sont injectées uniquement quand elles ont prouvé avoir un impact réel.
Bref un court mais instructif voyage dans le monde de l’UX et du design thinking… Merci Xavier !

Maxime Garrigues : Evernote ambassadeur

Ambassadeur Evernote, Maxime nous parle de sa façon d’appréhender Evernote. Pour lui, l’important est de pouvoir consacrer plus de capacité mentale à l réflexion et donc de lâcher prise sur les choses dont il faut se souvenir et laisser Evernote s’occuper de cela !

L’autre usage principal est en tant que support du GTD.

Cocktail

Ces présentation se concluent par le très classique buffet qui sont une occasion d’échanger avec des visages connus ou moins connus.

Cocktail (1)

Parmi les visages connus : Pierre Journel, qui un peu relâché les efforts autour des meetups Evernote pour se consacrer à une activité d’entreprenariat autour de la Chaine Guitare. Celle-ci jouit déjà d’une belle communauté. Pierre travaille à proposer du contenu payant. Cela commence à porter ses fruits, mais c’est un travail de longue haleine pour lequel je lui souhaite bonne chance.
Dans la série des rencontres inattendues, j’ai pu échanger un peu avec Grégory Lefort, l’un des créateurs d’Azendoo. Il a brièvement évoqué ses reflexions actuelles sur la plateforme et sa volonté de faire des choses qui soient réellement différentes de ses concurrents. J’aurais pensé qu’il aurait focalisé sur Basecamp. En fait il semble d’avantage en concurrence avec Asana.

L’invité surprise

Cristina Riesen l’avait évoqué à quelques reprises : nous allions avoir un invité surprise. J’avais parié, dans mon fort intérieur, sur Phil Libin, le créateur et CIO d’Evernote. Apparemment, j’ai gagné.

Phil Libin (2)

Il est arrivé vers la fin de soirée et nous a gratifié d’un court speach de remerciement à la communauté Evernote. Les nombreuses groupies se sont vites agglutinées autour du big boss. Pas moi. Sa visite était très sympathique, mais en fait je n’avais rien à lui dire !

Phil Libin (1)

Précédent LeWeb, j’imagine que nous aurons droit à un meetup du même genre l’an prochain ? Pour ma part, les meetups plus orientés contenu de Pierre Journel me manquent un peu.

ScrumBeer de Décembre : avec passion !

Le par addinquydans Compte-renduLaisser un commentaire

C’est toujours un grand plaisir de nous retrouver autour d’une boisson houblonnée lors de ces rencontres organisées par Arnaud ! Les évènements du SUG sont certes de belle tenue, mais très espacés dans l’année et les ScrumBeer constitent pour moi le vrai fil rouge de ce user group !

ScrumBeer 11/2013 : la tablée

C’est maintenant une habitude : pas d’agenda, mais des discussions animées et passionnées ! Plusieurs sujets ont donné lieu à débat avec les quelques personnes qui m’entouraient.

Plaisir et professionnalisme

La notion d’envie et de plaisir versus le professionnalisme. Ces notions sont-elles incompatibles ? L’une doit-elle prendre le pas sur l’autre ? De là à parler du modèle Tayloriste, il n’y a qu’un pas ! Ayant lu le “Principles of Scientific Management” il n’y a pas si longtemps (oui, oui, la note de lecture viendra…), il nous fallait recadrer l’inadéquation du modèle par rapport à son usage initial : les postulats de base et le contexte historique.

L’engagement

Voilà une notion qui me met mal à l’aise, à défaut de la rejeter !

Oui à l’engagement consistant à se “considérer à bord” et contribuer à ce qui est nécessaire de faire pour faire avancer le projet sans se planquer derrière un processus.

Non à “l’engagement guet-apens” dans lequel les membres de l’équipe doivent absorber les incertitudes et les inconnus du projet car ils se sont engagés sur une date (avaient-ils le choix de ne pas le faire ?). Cette forme d’auto-mutilation moderne est sensée être cool car auto-consentie, mais n’a pour moi rien d’agile…

ScrumBeer 11/2013 : Arnaud en écoute active

Bien sûr, j’expose ici mon point de vue avec beaucoup de subjectivité. L’important est que ayons pu échanger dessus … avec passion !

ScrumBeer 11/13 : Discussion isolée

Carnet de route : Agile Grenoble 2013 en Images (2/2)

Le par addinquydans Compte-renduLaisser un commentaire

Je vous avais laissé à la fin de la pause déjeuner lors de mon précédent post. Nous allons débuter cette seconde moitié d’Agile Grenoble de nouveau dans le grand amphi.

Retour dans le grand amphi

J’ai oublié de vous parler de Jérôme Bourgeon. Il est … magicien ! Il introduira ce début d’après-midi et j’aurais aussi l’occasion de reparler de lui plus tard.

AG 13 : Jérôme le magicien (1)

Puisque l’on en est aux animateurs de cette journée, nous ne pouvons pas passer sous silence les organisateurs de cet Agile Grenoble, qui est quand même la plus grande manifestation agile en France ! Ils sont nombreux et nous avaient préparé une petite animation à base de fausses pizzas …

AG 13 : Team Agile Grenoble (3)

La keynote qui suit sera, elle, confiée à Pascal Van Cauwenberghe.

Pascal Van Cauwenberghe : Comment écrire du code legacy plus rapidement

Comme souvent, Pascal nous présente ce qui sera ma session préférée de cet Agile Grenoble. Ca fait aussi parfois un peu mal, car l’orateur ne fait pas trop de concessions.

AG 13 : Keynote de Pascal Van Cauwenberghe (1)

Outre le sens toujours aiguë de l’auto-dérision de l’agiliste Belge, on voit aussi de nouveau apparaitre nos Scribers prêts à l’action, chacun indépendamment d’un côté de la scène !

AG 13 : Keynote de Pascal Van Cauwenberghe, le scribing (1)

Il est surprenant de voir à quel point les résultats obtenus sont différents. Ils me laissent néanmoins toujours admiratifs

AG 13 : Keynote de Pascal Van Cauwenberghe, le scribing (2)

Revenons à la session de Pascal.

En bref, cette session est de “techniques” pour dégrader le code plus rapidement ! Le tout découpé en 4 catégories.

Pour le développeur : travaillez votre talent sur la dette technique !

Soyons clairs : ce que l’on nomme avec pudeur “dette technique” n’est ni plus ni moins que du code pourri ! Quelques techniques (sournoises) pour progresser (ou régresser, selon votre point de vue) en ce sens :

  • IDD ou “if driven développement” : J’ai un nouveau cas à prendre en compte ? Hop ! Un nouveau if, un nouveau cas spécifique … plutôt que de généraliser !
  • Des commentaires pour leurrer : Il suffit d’écrire une intention en commentaire et ne pas la respecter lors de l’écriture du code. Mais le plus souvent le commentaire devient simplement obsolète en n’étant pas mis à jour lors du “bug fixe”.
  • Du refactoring qui rend le code plus mauvais ! Là aussi à l’occasion de multiples bug fixes…
  • Désactiver les tests qui échouent (on les corrigera au prochain sprint). Evidemment, ce n’est jamais corrigé car il y a toujours mieux à faire…
  • Les tests sont une perte de temps : il y a du code à développer … mais comment sait-on qu’il marche ?
  • Le framework du jour. Ou comment faire sombrer un projet sous le poids des bibliothèques que l’on a envie d’essayer…
  • La collaboration c’est pour les nuls ! Et chacun bosse dans son coin en développant ses trucs de sioux qui nous font paraitre tellement plus intelligents…

Des techniques pour les testeurs

  • La loi de Pascal : La qualité du code est inversement proportionnelle à la taille de l’équipe de test ! Quand on est blindé par une équipe de test, pourquoi produire du code de qualité ? La solution ? Retirer l’équipe de test !
  • Ajouter la qualité en testant ! Bien entendu, les tests ne font jamais progresser la qualité.
  • Semer la confusion sur “la qualité”. Chacun peut interpréter “qualité” comme il l’entend. Mais quelle type de “qualité” attend-t-on en fait ?

Des techniques aussi pour le PO et les managers !

  • Je veux tout ! Le meilleur moyen d’avoir du travail bâclé en abdiquant ses responsabilités.
  • C’est pas ça ! … ou le syndrome du PO distant. Un rôle bien confortable, où l’on se désengage du produit en rejetant la faute sur ceux “qui ne comprennent pas”.
  • C’est trop cher ! Essayer de faire “une bonne affaire” en rentrant dans une logique de négociation … ça se paie toujours à un moment ou à un autre !

Des techniques pour les managers, coaches, etc.

  • Protéger l’équipe. Malgré ce que dit Scrum, ce n’est pas une si bonne idée. L’équipe doit être au diapason des problèmes, des mécontentements, etc.
  • Isoler l’équipe. C’est le syndrome extrême. Les développeurs travaillent sans appréhender les utilisateurs.
  • Optimiser le développement de bugs avec une équipe de maintenance. Ou comme le dit Pascal : une équipe pour écrire les bugs, l’autre pour les corriger !
  • Obtenir l’engagement. Très bien pour mettre l’équipe au pied du mur et obtenir l’un des 3 résultats suivants :
  • Hacking de fin de sprint.
  • Presque done. Un travers dont j’avais déjà parlé.
  • Mentir sur sa vélocité pour garder un matelas de secours.

Ne pas suivre ses propres règles. Rétrospectives sans résultat. Pas la peine de faire croire que l’on va s’améliorer si l’on ne fait rien. Réécriture complète. Le genre de projet qui n’aboutit jamais … et peut même faire couler une boite !

L’énoncé des symptômes fait plutôt mal, surtout si l’on considère que j’ai bien eu au moins l’un d’entre-eux sur la plupart de mes projets ! Mais cela fait réflechir aussi pour m’aider à être plus exigeant. Merci Pascal !

Et pendant ce temps, chez Zenika …

Je l’avais évoqué, Zenika était sponsor de l’évènement. Nous avions donc un stand pour nous représenter.

AG13 : vue d'ensemble lors de la pause déjeuner (14)

Avec la présence active d’Hervé Jacob, notre directeur d’agence sur Lyon.

AG13 : Hervé Jacob

Et Christophe Campan en complément de la fine équipe.

AG13 : Christophe Campan au travail

Etre sponsor d’un évènement, est une expérience nouvelle pour moi. C’est juste la seconde fois après Rennes. Nous pouvons nous améliorer à cet égard (car on peut de toute façon toujours s’améliorer). Nous aimerions essayer de courtes animations agiles autour de notre stand. A réflechir et essayer pour les prochaines fois.

Service IT Agile, agilité managériale, agilité entrepreneuriale ? Par Michel Cezon

J’aurais voulu m’essayer au Visual Thinking, mais hélas la session a débuté avant l’heure avec une audience au complet ! Je me suis donc rabattu sur cette session.

L’introduction est un peu longue à mon goût : qu’est-ce que l’agilité, etc. Et même le manifeste agile ! C’est presque 20 minutes qu’il faut patienter pour en arriver au coeur du sujet !

AG 13 : La manager agile (3)

Le coeur du sujet, en l’occurrence, c’est la définition du manager agile selon Jérôme Barrand. Selon ce modèle (dont il serait beaucoup dire que je l’adopte) il y a 4 principes de base de l’agilité :

  • L’effisens (c’est un mot ?) : donner du sens, responsabiliser et optimiser la performance organisationnelle. Même si j’adopte certaines parties, cela fait un peu fourre-tout et je perçois mal la corrélation entre ces 3 éléments…
  • Coopération. Un classique. J’achète.
  • Anticipation : prévoir des plans d’action. Pourquoi pas, mais en quoi est-ce lié à l’agilité ?
  • Innovation : Mais pourquoi “avec parcimonie” et je ne vois pas le rapport avec la “performance durable”.

N’étant pas spécialement ébloui par les 4 principes agiles, voyons les 6 comportements, qui sont liés à 3 des 4 principes agiles :

  • Coopération
  • Empathie systémique : c’est favoriser la performance collective. On est d’accord !
  • Synchronisation : Agir pour ne pas bloquer la situation. Un bon sens que j’approuve.

Anticipation

  • Intelligence de situation : On en a plein la bouche, mais cela signifie simplement agir en fonction des informations disponibles. Je ne peut qu’abonder mais aussi remarquer que c’est pratiquement l’inverse de l’anticipation !
  • Proaction : Mettre en place une analyse des risque, des plans d’actions, bref tous les machins pas agiles. Et oui, là c’est bien de l’anticipation.

Innovation

  • Rebellion constructive : J’aime bien cette expression. Et en gros, c’est “sortir du cadre”.
  • Pédagogie relationnelle : agir comme un leader qui donne du sens correspond bien à ma vision des choses. J’aurais bien classé cela dans “effisens”.

Dans ce modèle de management agile, les outils du manager se classent en 2 catégories :

  • Les outils liés à la structure de personnalité. Ici on utilise surtout la Process Com.
  • La perception de l’environnement en utilisant un radar type “Agile Profile” avec une détermination en mode normal et en mode “sous pression”.

Le dernière partie avait trait à l’entreprenariat. Je vous laisse regarder les slides, mais je ne m’étendrais pas dessus, là moins qu’ailleurs, le propos me convainc.

Bref, assez déçu par cette session qui n’aura eu d’intérêt pour moi que l’évocation du modèle de Jérôme Barrand dont Véronique Messager avait parlé dans son ouvrage sur le coaching Agile. Je ne pense pas encore prendre ma carte du fan-club…

Petit break de l’après-midi

A Agile Grenoble, c’est café et boissons toute la journée. Mais aussi tours de magie à l’occasion !

AG 13 : Tour de magie (7)

Un impromptu drôle et réussi ! Finalement, je vais d’ailleurs rester avec Jérôme Bourgeon sur le créneau suivant.

Petits conseils aux orateurs, par Jérôme Bourgeon

Notre magicien de service est un artiste de scène chevronné et il nous fait partager quelques conseils à propos de nos prestations de présentateurs.

AG 13 : L'art de présenter sur scène

Première règle : Y’a pas de règle ! Bon, ça commence bien… 

L’espace de scène est en gros divisé en 6 :

  • Horizontalement : gauche, milieu, droite ; on entre à gauche, on s’arrête au milieu. A la fin, on sort par la droite. Sauf Steve Jobs qui fait l’inverse.
  • En profondeur : l’avant-scène permet de prendre une position dominante pour faire passer des idées, tandis que l’arrière scène permet au public de souffler, pour faire réfléchir.

Il faut se déplacer sur scène pour éviter la monotonie, mais ne JAMAIS tourner le dos au public ! La monotonie, c’est aussi faire attention à ne pas parler d’une voie monocorde ou ne pas agacer l’assistance avec des tics corporels (aka “la savonnette”, le “mal de mer”, etc.). D’ailleurs, si on doit présenter le matin, il faut penser à chauffer sa voie (je ne savais pas cela…).

Pour une présentation longue, on ne peut (ni ne doit) garder le même niveau d’énergie. Surtout pour un moment crucial, il faut faire monter la sauce, donc, comme dit Jérôme, “gérer sa chiantitude” !

Ah ! Il y a un point sur lequel j’ai bon, de toute évidence : penser à se créer une identité visuelle. Si vous voyez ce que je veux dire…

Enfin, avant de sortir : penser à remercier !

End of AG13

Il reste encore une session, mais déjà c’est l’heure des premiers départs.

AG 13 : Vestiaire départ (2)

Pas de session non plus pour moi sur ce créneau, surtout parce que je commence à fatiguer. 

Sur le stand Zenika, on plie les gaules, car on va avoir un peu de route pour rentrer sur Lyon (toujours pas de trains pour Paris en départ de Grenoble).

AG 13 : Rangement du stand Zenika

Mais on n’est quand même pas pressés au point de refuser le cocktail de fin offert par les organisateurs, ce serait mal poli. De plus, on va quand même pas rouler à jeun, c’est très déconseillé…

AG 13 : Cocktail (3)

Agile Grenoble, c’est terminé pour cette année. Je suis satisfait de l’accueil fait à ma session. Moins satisfait de moi-même sur mon parcours de session : il y avait beaucoup de sujets de qualité, mais je n’ai pas su bien sélectionner ceux qui me correspondaient. C’est un peu dommage, mais la faute m’en incombe.

Il s’agira de faire mieux l’an prochain : l’ambiance et les échanges étaient géniaux, j’espère revenir. Un grand merci aux organisateurs !