Carnet de route : Le ScrumDay 2014 (2/4)

Je vous avais laissé au moment du déjeuner. La pause n’aura pas été si longue. Sur le créneau suivant, j’ai coché la session de Véronique Messager sur mon programme.

En tant que Scrum Master, je veux m’améliorer pour mieux coacher mon équipe

Cette session de Véronique Messager, n’en est pas une : c’est une table ronde à laquelle elle a convié des Scrum Masters allant du néophyte à l’expérimenté, qu’elle-même coach chez Orange. Cet aréopage de Scrum Masters vient partager avec nous leurs points de vue sur leur travail, leurs manières d’aider les équipes et leurs sensibilités qui peuvent varier.

image

Le contexte

A l’origine, il y a un groupe d’échange de pratiques se réunissant tous les mois. Le produit de ce groupe d’échange est aujourd’hui une check-list de 52 bonnes pratiques. Véronique nous propose de les aborder regroupées en 3 thèmes, avec le panel de Scrum Masters. Hélas, les contraintes de temps nous limiteront à deux de ces thèmes.

Le changement dans la posture du Scrum Master

Un premier constat partagé est la perte de connaissance sur le code ! Le travail de Scrum Master tient ceux-ci de plus en plus éloigné de cette matière première. De cette perte de connaissance nait un certain sentiment de culpabilité : Suis-je toujours légitime dans mon rôle ? Le travail du Scrum Master n’est pas quantifiable, il n’est même pas visible car il n’a pas de raison d’être évoqué en stand-up. Une crainte qui n’est pas nécessairement étayée : il n’y a guère de remarques sur le fait que le Scrum Master développe beaucoup moins.

Malgré tout, le Scrum Master peut-il continuer à développer ? Les avis sont un peu plus partagés, mais des « oui » s’élèvent, toutefois tempérés :

  • Pas question de prendre des tâches critiques ! A cet égard, binômer ou prendre en charges des corrections d’anomalies s’avèrent de bonnes idées.
  • En tout état de cause, les tâches de Scrum Master doivent rester prioritaires.
  • Rester impliquer dans le développement peut induire un travers de partialité lorsque des discussions s’engagent sur l’architecture, les solutions, etc. Il faut y prendre garde.

La maturité de l’équipe allant croissant, peut-on un jour se passer de Scrum Master ? Une question réccurente, que l’on a aussi trouvé sur Quora. Ici la réponse est unanime : non, le Scrum Master reste indispensable !

Par contre la question reste ouverte sur le Scrum Mastering à temps plein ou à temps partiel ! Si certains par ailleurs pensent qu’au final ce rôle peut tourner (ce que j’ai expérimenté), Bruno Margueritat ne suit pas cet avis, par exemple.

Motiver les membres de l’équipe

Comment s’appercevoir que cette motivation baisse ? En regardant la productivité de l’équipe (donc les « retards »). Véronique a une affinité particulière pour la Process Com, il n’est donc pas étonnant que les Scrum Masters présents évoquent cet outil pour comprendre le fonctionnement des membres de l’équipe.

Ils évquent aussi le temps libre : l’importance d’en ménager (par exemple entre les itérations), mais aussi d’observer comment ce temps libre est utilisé.

Donner du sens et visualiser l’avancement : c’est bien entendu un leitmotiv bien connu et pourtant souvent négligé. Mais il s’agit aussi d’impliquer activement les membres de l’équipe. Pour l’un des Scrum Masters cela passe par la délégation d’une partie des tâches … du Scrum Master ! Par exemple lors des rétrospectives. J’aime bien l’idée et l’état d’esprit !

Ce que j’en ai pensé

image

Nombreux sont les experts prêts à nous expliquer le rôle et la posture du Scrum Master. Tous ces experts ne sont d’ailleurs pas tous d’accord entre-eux (j’en fais partie !). Ici, ce ne sont pas des experts, mais des vrais praticiens de terrain avec différents niveaux d’expérience et une certaine variété de point de vue.

Du coup, je pense que l’échange aurait pu être encore plus riche avec des Scrum Masters venant d’autres horizons. Les débats auraient été plus intense, ce qui ne serait possible qu’avec un format un peu plus long toutefois.

La culture du programmeur, par Jean-Laurent de Morlhon

J’avais une double raison d’assister à cette session : tout d’abord J’aime bien Jean-Laurent qui est aussi un ancien collègue (double ancien collègue, devrais-je dire). Et ensuite le sujet éveille mon intérêt, même si ma propre crédibilité en tant que programmeur s’étiole certainement de jour en jour… Jean-Laurent est certainement la bonne personne pour transmettre cette culture, sans compter l’humour et le dynamisme qu’il met dans ses interventions. Celle-ci ne fera pas exception !

image

Pourquoi programmeur ?

Jean-Laurent nous explique quel était son plan pour devenir maître du monde et partir à la retraite à 35 ans. Cela n’a pas marché. Pour moi non plus, d’ailleurs. Car sa passion c’est programmeur (qu’il préfère à « développeur » ou « codeur »). Donc c’est « programmeur ». Et ça veut dire quoi ? Le Larousse dit qu’il s’agit « d’une personne de la préparation, de l’écriture et de la mise au point d’un programme pour ordinateur ». Pour les personnes en-dehors de notre domaine, ils sont souvent perçus comme des personnes aptes à faire des choses mystiques (t’es dans l’informatique ? Tu peux m’aider à brancher mon imprimante ?).

Mais hélas, dans notre milieu professionnel, nous sommes confrontés à un problème de jeunisme. Programmeur n’est pas considéré comme un métier au-delà d’une certaine tranche d’âge. Pour de nombreuses entreprises et écoles, l’évolution normale du programmeur est de devenir chef de projet !

Une culture

La culture, c’est ce qui lie les gens entre eux. Quels sont donc les éléments de cette culture ? L’une d’entre-elle est le « craftmanship ».
C’est avant tout une attitude de pragmatisme, un rééquilibre entre processus et technique. C’est aussi un état d’esprit d’amélioration qui passe par l’entrainement (les dojo, les code retreat, les kata). C’est évidemment utiliser les ressources en ligne : les MOOC sont partout, sur tous les sujets. La culture du programmeur, c’est aussi :

  • Disposer des meilleurs outils que l’on puisse acheter : aujourd’hui, c’est disposer de grands écrans, de CPU puissants, ne pas être limité par la mémoire, booster les I/O avec des disques SSD, des environnements d’intégration, les bons IDEs, etc..
  • Vivre en permanence avec de la frustration : nous passons un temps considérable à essayer de faire marcher des trucs … ou à essayer de comprendre pourquoi ils ne marchent pas !

Ce que j’en pense

Une session de « J-Lau », ça vaut toujours le déplacement. Certes, je n’y ai pas appris grand chose, mais je n’étais pas non plus le public visé. Mais la présentation fait un très bon boulot à faire toucher du doigt cette culture du développeur. A voir absolument pour les PO / MOA / Managers à qui sont étranger ces aspects.

Acceptance Tests Workshop

Voilà, c’est mon tour ! J’avais préparé cet atelier avec Benoit Nouyrigat afin de transmettre par la pratique un aspect du développement agile qui nous semble avoir un impact crucial : l’écriture de tests d’acceptance collaborativement entre les différents intervenants d’un projet. Nous avions donc structuré notre atelier en petites équipes, l’atelier lui-même nous conduisant depuis l’écriture de user stories sur notre étude de cas jusqu’à l’implémentation des acceptance tests en BDD avec Cucumber JVM !

image

Je ne vais pas détailler l’atelier ici, je réserve cela pour un futur post !

Ils ont aimé

  • Clarifier les specifications en les « instanciant » avec des cas de test.
  • Découvrir les cas aux limites qui font émerger des règles métier.
  • Travailler collaborativement autour des cas de test.

Ils pensent que l’on peut améliorer

  • La phase initiale, avec l’écriture des user stories par les équipe qui apporte peu.
  • L’absence de temps pour s’approprier les persona.
  • La brièveté du temps consacré à la partie « outils ».

Ce que j’en pense

Nous devons ajuster certaines parties, c’est tout à fait normal, compte tenu qu’il s’agissait d’une première. Je pense toutefois que les conditions ne nous ont pas permis de juger de l’atelier de manière adéquate : nous avions été programmé en toute fin d’après-midi (avec en plus un démarrage en retard), ce qui équivaut pratiquement à une garantie d’échec pour un atelier très intense comme celui-ci.

La première heure s’est très bien passé, mais la fatigue a rattrapé le groupe dans la seconde. En fait, je suis plutôt satisfait d’avoir eu une bonne moitié d’atelier, car je m’attendais à un échec complet. Les participants se sont même déclarés très satisfaits !

J’aimerais toutefois pouvoir jouer cet atelier dans de bonnes conditions pour avoir un meilleur aperçu de son impact.

Nous avons joué l’écriture des acceptance tests en deux temps, avec ou sans le style « given when then », mais nous n’avons pas donné d’indications suffisantes pour marquer la différence. A retravailler.

Une certaine déception de Benoit et moi-même sur la demande d’avoir plus sur la partie outil ! Notre expérience commune est que la différence se fait dans l’écriture collaborative (d’ailleurs la collaboration est à gauche et les outils à droite, si vous voyez ce que je veux dire…). Soit nous ne sommes pas parvenus à être assez marquants sur l’importance de cet aspects, soit notre public est incorrigible sur l’idée que les outils sont ce qui importe le plus. Nous avons là un sujet de reflexion pour la version 2.0 de notre atelier…

Le diner

J’ai fait l’éloge du lunch du midi, je dois les mêmes au diner auquel j’étais convié n tant qu’orateur. C’est bien sûr une belle occasion d’échanger avec les membres de la communauté…

image

… Ainsi qu’avec les joyeux membres du bureau.

image

J’ai aussi passé un très agréable moment avec Alex Boutin, à échanger sur ce que l’un et l’autre nous aimons faire, les questions que nous nous posons… Alex est l’une des personnalités de la communauté agile que j’apprécie le plus, pour son sens du partage et de l’invitation. Je n’en apprécie que plus ce genre d’opportunités.

Il est maintenant temps de retourner dans mes pénates. Rendez-vous bientôt pour la seconde journée de ces Scrum Days !

Carnet de route : Le ScrumDay 2014 (1/4)

Bienvenue au ScrumDay 2014 !

Cette édition sera particulière pour moi : c’est la première où je ne fais pas partie du comité d’organisation ! Certes, j’y aurais ma session, mais je vais faire mon possible pour profiter pleinement de ces deux jours, et vous en faire bénéficier maintenant !

Pour tout dire, ça commence par un peu de galère : Xavier Warzee voulait depuis longtemps organiser l’évènement chez Disney. C’est loin et cher (le prix de la conférence triple donc au passage), mais mon statut de conférencier me donne accès à la conférence « full package », celui qui vaut 290 € ! Reste l’accès. Venir en voiture s’avère plus galère que si nous avions été en plein Paris, j’opte pour le RER.

L’accès est un rien compliqué, mais le SUG a tout prévu : Pascal est là pour nous accueillir dès la sortie de la gare !

image

N’oublions pas que chez Mickey on est presque aux états-unis, le délit de sale gueule existe encore. Pour moi, c’est fouille minutieuse à chaque contrôle de sécurité. Même avec une certaine habitude de la chose, ça ne me met pas spécialement de bonne humeur. C’est dommage d’autant que le French SUG n’y est pour rien. Mais si c’est au même endroit l’an prochain, ce sera probablement sans moi.

Je découvre le centre de conférence en arrivant : vraiment très spacieux (et même un chouia labyrinthique), quand au hall principal…

image

Le temps de prendre un café et d’échanger avec les amis, nouveaux ou anciens, l’heure est vite passée et nous sommes attendus dans la salle où se dérouleront discours d’ouverture et keynote.

Ouverture du Scrum Day

Rameuter Presque 500 personnes, ça prend du temps, on va donc débuter avec un peu de retard. Que du classique pourrait-on dire.

image

Comme il est de coutume, le président du SUG ouvre ce ScrumDay ou ScrumDays, devrai-je plutôt dire.

image

On retrace un peu d’histoire, quelques chiffres et surtout on présente le déroulement de ces deux jours, le maître de cérémonie de la seconde journée sera Laurent Bossavit, épaulé de Raphael Pierquin pour un grand open-space, à l’image de ce qui se fait à Grenoble.

image

On termine cette ouverture par le mot des sponsors. Les sponsors ! Il y en a 17 ! C’est certainement un record, en tout cas c’est un marathon de les écouter tour à tour.

image

Laurent Delvaux ouvre le tir pour Zenika, et j’ai vite perdu le compte. Mention spéciale pour le représentant de HP France qui nous a gratifié d’une introduction au style humoristique bien enlevé !
Heureusement, on va maintenant enchainer sur la keynote.

Alistair Cockburn : What’s new with agile ?

J’étais curieux de voir ce dont Alistair allait parler. Après tout, j’ai l’habitude de l’entendre parler d’agilité, ou comme dirait Géry Derbier de jeu de coopération et collaboration. En fait, il commence par évoquer les personnes … et les difficultés que nous avons face aux problèmes et à nos décisions. C’est un préambule au manifeste agile dont il est l’un des signataires.

image

Mais pour parler de Scrum, Alistair évoque le Shu Ha Ri ! Curieusement, c’était le sujet de ma présentation à Caen il y a 3 semaines, je suis tout ouï. Si vous l’ignorez, il s’agit des 3 niveaux de maturité en agile, emprunté par Alistair aux arts martiaux, à l’Aikido pour être plus précis.

  • Le Shu est le niveau initiatique. Le Shu c’est copier la technique sans en dévier. Hélas, nombre de personnes tombent amoureux du Shu et ne le quitte jamais…
  • Le Ha est le perfectionnement, il signifie « cassure ». Dans le Ha, on collectera nombre de techniques utiles.
  • Le Ri est le niveau de la maîtrise, c’est littéralement l’abandon. On invente, mixte ses propres techniques.

Core Scrum

Scrum n’est pas fondamentalement du niveau Shu, il est du niveau Ri. Et au niveau Ri, le « core Scrum » se définit ainsi :

  • Délivrer à chaque Sprint (plutôt que démontrer)
  • Laisser l’équipe décider (en assignant une tâche)
  • Inspecter et adapter à chaque Sprint

Ca c’est l’esprit du Scrum. Autour de cela, gravitent des rumeurs ou des freins (Alistair parle de balanes).

Les « balanes » sont tous ces éléments de Scrum, des éléments « Shu » sur lesquels on se focalise alors qu’ils n’ont qu’une importance secondaire :

  • Le burndown chart : il n’est pas essentiel, faites-le si vous en avez envie, d’ailleurs il ne fait plus même plus partie des éléments « obligatoires du Scrum Guide !
  • Le Scrum Board : Doit-on en faire un ? A quoi doit-il ressembler ? L’équipe décidera.
  • Le Scrum Master est-il un chef de projet ? Un tech Lead ? Cela dépendra du contexte.
  • Le Product Owner doit-il assister au stand-up ? Laissez l’équipe décider !
  • Les 3 questions du stand-up : ce peut être une aide, mais pas un dogme !

Rumeurs et ouïe dire, ou les « lutins » comme dirait Laurent Bossavit:

  • Les User Stories : Elles ne font pas partie de Scrum, elles ont été créées avec XP. Scrum n’oblige pas à utiliser les stories.
  • Le Planning Poker : Cette pratique vient également d’XP ; si elle convient, alors utilisez-la !
  • La suite de Fibonacci / les story points : Ce ne sont pas non plus des pratiques spécifiquement liées à Scrum. Tirez-en parti si vous aimez.

Le « big agile »

Alistair évoque pour commencer le framework SAFe. J’avoue y avoir porté peu d’intérêt, bien que ce soit un sujet dont on parle en ce moment. Je m’attendais à voir Alistair le démonter, mais non ?!?

Quand on parle d’agile en grand en ce moment, on évoque souvent Spotify autour duquel Henrik Kniberg communique beaucoup en ce moment. Ce qu’il appelle l’organisation 3D semble aussi une référence pour Alistair. Et qui dit grande organisation dit dépendances : l’architecture du système doit prendre en compte cet aspect afin de rendre le déploiement asynchrone.

image

Disciplined learning

Le dernier point évoquer par notre keynote speaker est l’un de ceux qui lui tiennent beaucoup à coeur : l’apprentissage. Alistair oppose le « big bang » synonyme d’apprentissage tardif d’un apprentissage au plus tôt (ou réduction des risques, mais l’emphase sur l’apprentissage n’est-il pas préférable ?). Cette courbe n’est d’ailleurs pas une courbe, mais une espèce d’escalier, car tous les progrès ne se valent pas et certaines expérimentations d’avèrent stériles. Géry Derbier évoque souvent la chose quand il anime le Carpaccio Game : il y a 4 dimensions d’apprentissage sur un projet :

  • Business (ce volet pouvant lui-même avoir différents axes, et pas seulement le ROI).
  • Social (la formation de l’équipe).
  • Technique
  • Coût / délais (découverte de la vélocité, par exemple).

Cette façon d’appréhender le projet permet de le borner (trim the tail), soit par la date, soit par la valeur.

Ce que j’en ai pensé

Peut-être Alistair Cockburn n’était pas aussi percutant qu’il nous en a donné l’habitude, mais s’agissant du Scrum Day il nous a livré une keynote s’articulant autour du Scrum, du vrai Scrum ! Je ne peux qu’apprécier le propos faisant écho à ma propre présentation du Printemps Agile, bien sûr, mais surtout je trouve important de mettre en exergue les aspects importants de Scrum (le Scrum Core), par rapport aux choses secondaires qui sont celles sur lesquelles se focalisent souvent les détracteurs de Scrum !

Romain couturier nous a aussi gratifié d’un « scribing » de la session d’Alistair. Il a bien voulu le partager avec nous, et je m’incline devant son talent !

image

Nous avons déjà pris un peu de retard sur le timing, le changement de salle est un tout petit peu serré. Pour moi, le choix de la session suivante était déjà fait.

Coaching Teams Through Change, par Rachel Davies

Rachel Davis est l’auteur d’un des quelques ouvrages disponibles en rayonage sur le coaching agile. Un ouvrage que j’avais trouvé correct sans être fantastique. Le sujet de cette session lui, me fait plutôt penser au Fearless Change !

image

D’abord, quel est le plus grand obstacle au changement ? Bien entendu : la résistance ! Alors certes, on voit beaucoup de choses à faire … tellement à faire et si peu de temps ! Mais la première précaution est justement de ne pas se précipiter !

Communiquer

Choisir ses mots avec soin (en fonction du canal de votre interlocuteur, comme dirait Véronique Messager). N’oublions pas de nous mettre à la place de notre interlocuteur : ce que nous voulons dire correspond rarement à ce que nos interlocuteurs veulent entendre !

La communication, c’est aussi un processus bidirectionnel. N’oublions pas l’écoute, en fait, commençons par cela. Une bonne écoute c’est :

  • Absorber de l’information
  • Rester calme et attendre.
  • Encourager l’interlocuteur.

Voilà qui me rappelle la session de Florence Chabanois à l’Agile France 2013.

Leadership

Et ceci me rappelle à nouveau le Fearless Change. On y trouve plusieurs idées:

Aller parler aux sceptiques : comprendre ce qui les retiens est le premier pas vers la compréhension des faiblesses de notre message. De plus les sceptiques ne sont pas des opposants, du moins pas nécessairement. Ils peuvent même s’avérer être à terme vos plus ardents défenseurs.

Plusieurs facteurs peuvent influencer le refus de suivre :

  • La difficulté
  • La permission
  • Le (mauvais) timing
  • Ce n’est de toute manière pas mon idée !

L’exemplarité: Pour inciter les autres à suivre, commencer par faire vous-même. Vous voulez mettre en place un Kanban ? Utilisez déjà un « personal Kanban ».

Traiter les problèmes

Les rétrospective sont là pour les mettre en évidence et dresser des plans d’action. Mais plus encore, rendons les problèmes visibles tous les jours en les affichant !

Ce que j’en ai pensé

Pour être franc, j’ai eu du mal à m’enthousiasmer pour cette session un peu fourre-tout, avec un fil conducteur un peu difficile à saisir ! Bref, un peu déçu, je l’avoue…

Sébastien Ferron a publié un excellent post sur cette session sur le blog de SOAT.

Pollénisation croisée avec la communauté des designers ?

Pierre Hervouet et Joumana Mattar nous proposaient cette session. Si l’audience était nettement plus réduite qu’avec Rachel Davies, le contenu… eh bien j’ai préféré cette session, voilà !

Pourtant je suis venu sans trop savoir à quoi m’attendre. Mais j’avais aimé la session que Pierre avait animé avec Pascal Van Cauwenberghe à Agile France 2013. Je l’ai donc suivi ici.

Pierre vient ici avec une étiquette « Agile Lebanon », et il venait nous parler du Global Service JAM !

image

Le Global Service JAM, c’est une sorte de Startup Week-end pour les designers : une unité de lieu et d’action pour 48 heures, et pour sortir avec un produit ! Le JAM s’organise sur 3 jours.

1ère journée : Open minder

Au programme : ice-breaker, brainstorming et agile games !
On explore l’espace, on répartit des idées sur une table (cela offre une meilleure circulation qu’un mur) et on met l’utilisateur au centre en utilisant des personas.

A ce stade, on ne sait pas encore ce que l’on va construire !
Une première journée jugée très positive par Pierre et Joumana. Avec un outil atypique : l’unstuck jarre, remplie de questions perturbantes quand on est en panne…

2nd journée

Beaucoup de choses dans cette seconde journée ! En fait tellement d’outils que Pierre et Joumana nous ont distribué un jeu de cartes les rassemblant tous ! Voilà, vous n’aviez qu’à être à cette session !

image

On va donc y trouver pêle-mêle :

  • Get out of the building : à l’image du Lean Startup Machine, pour aller valider son concept dans la rue !
  • Des energizers
  • Le bottleneck game de Pascal Van Cauwenberghe et Portia Tung, pour introduire l’amélioration continue
  • 5 focus steps !
  • La carte d’empathie pour explorer les personas. A l’image de ce que l’on fait en Lean Startup.
  • Le User Journey map pour explorer l’expérience utilisateur via du story telling.
  • Le PoP (prototyping on paper).

3ème journée : stress et deadline

A la fin de cette journée, il faut livrer !

Ce que j’en ai pensé

Beaucoup de choses dans cette session, j’ai la sensation d’en avoir raté la moitié. Au moins ! Cela m’a permis d’explorer un concept que je ne connaissais pas et je repars donc avec pas mal de pointeurs à investiguer !

Si l’aventure du Global Service JAM Libanais vous a intéressé ou intrigué, vous pouvez les retrouver sur leur Blog Tumblr.

Il est bientôt l’heure du déjeuner. En passant, je vois Romain qui termine sa session.

image

Déjeuner

Disons-le tout net : ce ScrumDay est de loin celui qui m’aura laissé la meilleure impression sur cet aspect : on a de la place et plusieurs buffet sont disposés de manière à ce que l’on ait jamais besoin d’attendre très longtemps. Les plats sont diversifiés et de qualité, et l’on peut s’assoir pour converser en même temps que l’on se restaure. Bravo !

image

Profiter de la pause déjeuner pour converser avec les nombreuses brillantes personnes que je peux croiser ici est un luxe que je n’ai jamais eu jusqu’à présent au ScrumDay ! C’est avec Jean-Laurent de Morlhon que je passerais la plus grande partie de cette pause. Le développement (le vrai) est la passion de Jean-Laurent. Aujourd’hui il partage son temps entre les missions de dev orientées « craftmanship », Serpodile la société créé par sa femme et le partage au sein des communautés qui lui tiennent à coeur. Nous retrouverons Jean-Laurent au cours de l’après-midi pour sa session.

image

Je clos ici le premier volet de mon retour sur ce ScrumDay, il ne faudrait pas risquer l’indigestion !

Scrum Shu Ha Ri, la présentation

« On a pas mal de nouveaux venus à l’agilité, et on n’a pas beaucoup de sessions pour eux ». C’est ce que Jean-Luc Lambert me disait à propos de ce Printemps Agile 2014. En fait, je fais peu de sessions d’initiation, ce n’est pas ce que je préfère. Puis j’ai repensé à mes expériences récentes et ma façon d’appréhender Scrum comme un framework à même de nous accompagner du débutant à l’agiliste expérimenté.

Ainsi est née cette présentation « Scrum Shu Ha Ri ». Il n’est pas certain que j’aurais l’occasion de la resservir, ce n’est en tout cas pas prévu pour l’instant.

Le thème est inspiré du « Shu Ha Ri » présenté par Alistair Cockburn. J’ai en quelque sorte « instancié » ses idées à l’image que je me fais de Scrum.

J’escompte aussi pouvoir vous proposer plus tard cette présentation sous forme d’article, comme je fais parfois. Il vous faudra quand même patienter un peu.

Carnet de route : le Printemps Agile 2014 à Caen (1/2)

J’avais participé à l’édition précédente (vous trouverez mes comptes-rendu ici et ici). Cette année je suis de retour, mais comme je l’avais annoncé, cette fois comme orateur !

Ce Printemps Agile a d’ailleurs pris pas mal d’ampleur. C’étaient 70 personnes qui s’y étaient inscrites l’an dernier. Nous voici rendus à plus de 200 ! Même avec un peu moins de présents (un peu plus de 150, semble-t-il), car l’évènements étant gratuit, nous subissons le phénomène du désistement, cela reste un sacré succès. Par rapport à l’an dernier, l’équipe d’organisation s’est aussi bien étoffée. Je pense à Emilie Sulmont et Myriam Boure, mais aussi aux étudiants de Jean-Luc !

Un Marshmallow pour commencer ?

image

Passé le traditionnel accueil, non nous n’avons pas droit à l’habituelle keynote. Désolé mais le créneau dévolu à entretenir l’égo d’un quelconque gourou, ce n’est pas le genre du Printemps Agile !

Au programme, on nous a prévu un agile game, un classique, avant tout, avant même le petit mot d’introduction. Franchement j’étais perplexe sur la faisabilité de cette idée : des gens qui arrivent, doivent se mettre dans le rythme, ont envie de boire leur petit café…

image

Eh bien non, j’ai eu tord. L’idée est franchement géniale ! On s’est rapidement mis en mouvement sur une quinzaine de tables.

image

Comme c’est souvent le cas, les essais et réussites sont très diverses. Depuis la tentative, disons modeste…

image

… Jusqu’aux plus ambitieuses (ça ne marchera pas).

image

Le team gagnat aura plutôt fait dans le simple, avec une oeuvre tout bonnement achevée au bout de 3 minutes !

image

Bravo à Eve et Alfred (entre autre), il ne faut pas non plus oublier le 4ème membre de l’équipe : celui qui est derrière l’appareil photo !

Je déclare ouvert…

Cette année encore, c’est Jean-Luc qui introduit cette nouvelle édition du printemps agile. Si la communauté agile Caennaise est restreinte, elle est très active comme le démontre l’agenda annuel. De plus, cela fait plaisir de voir l’enseignement supérieur s’y intéresser sérieusement, aussi bien du côté étudiant que du côté enseignant !

image

Scrum Shu Ha Ri

Sur ces bonnes paroles, je dois vous abandonner : ma présentation “Scrum Shu Ha Ri” figure sur le premier créneau horaire. Ne vous en faites pas : je partagerais bientôt mon support de présentation pour faire suite à mon teaser. Avec un peu de chance, je pourrais aussi vous partager une vidéo et l’article correspondant si j’ai le courrage !
C’est d’ailleurs toute une matinée Zenika qui se partageait la salle ce matin là : Géry Derbier prenait ma suite pour un Carpaccio !

Carpaccio Game

Le Carpaccio, c’est ce jeu agile créé par Alistair Cockburn pour appréhender le découpage des fonctionnalités en tranches fines. Géry en est littéralement devenu le spécialiste et l’a pratiqué de nombreuse fois.

Moi-même, j’ai eu l’occasion de l’animer une demi-douzaine de fois, car il fait partie de mon “package immersion agile” chez mon client actuel.

image

J’assistais Géry durant cet atelier, car nous avions un nombre de participants tout à fait conséquent. La premi§re partie se fait sans machine : nous cherchons à découper le problème en tranches.

La seconde produit un peu plus de sueur: il faut développer et démontrer le produit toute les huit minutes !

image

L’animation de Géry diffère un peu de la mienne. Celle de Géry est certaine plus orthodoxe : il enchaine directement les itération de 8 mainutes (8 minutes !) … démo comprises. Pour ma part, je demande à ceux qui assistent à la démo de faire des vérifications approfondies… du coup je neutralise le chrono au bout de 45 secondes. Cela me permet aussi de tracer les courbes d’évolution des différentes équipes.

image

Du coup, le stress selon l’animation de Géry est beaucoup plus élevé. On termine l’atelier par une petite rétrospective: qu’avez-vous appris de ce jeu ? Qu’y avez-vous observé ?

image

Ceci termine notre matinée du printemps agile… et la première partie de ce retour. A très bientôt pour la seconde partie !

Gojko Adzic : Making impact !

L’association We Do Product Management nous proposait ce 11 Mars une soirée exceptionnelle avec 2 orateurs. Gojko Adzic himself nous proposera une présentation sur le thème “making impact” tandis que Nicolas Gouy nous gratifiera d’un développement autour de l’Agile with GUTS !

Zenika accueillait cette soirée : un grand merci à Sébastien Sacard et Lisa Marçais du côté du WDPM, et aussi à Al chez Zenika pour son aide avant, pendant et après la soirée !

On commence d’ailleurs par une petite présentation du WDPM avant d’attaquer les choses sérieuses.

image

Making Impact par Gojko Adzic

La définition amont d’un produit se heurte à des facteurs d’imprédictabilité. Facteurs que l’on connait par ailleurs depuis plus de 100 ans :

  • Le facteur local
  • Le facteur temps
  • Le facteur Humain

Ces facteurs ont été identifiés par Peter Palchinsky. Dans The Ghost of the Executed Engineer, les auteurs reviennent sur certains désastres de l’Union Soviétique illustrant les facteurs de Palchinsky. Intéressons-nous spécifiquement à l’un d’entre-eux: le canal de la Baltique à la Mer Blanche.

image

Ce canal peut être considéré comme un succès, car il a bel et bien vu le jour, comme prévu. Cependant, il échoue aux 3 critères da Palchinsky et malgré son existence c’est effectivement un échec cuisant :

  • Le facteur temps : la construction du canal n’a pas anticipé l’évolution des cargos. En définitive, le canal s’est avéré rapidement trop peu profond pour les nouveaux navires !
  • Le facteur local : Sa situation septentrionale le rend gelé, donc impraticable 6 mois par an !
  • Le facteur humain : creusé à main d’hommes par des prisonniers dans des conditions extrêmes, il aura coûté le vie à 200000 d’entre-eux !

Autre exemple d’échec : le PC Junior d’IBM. Cette aventure coûta à IBM pas moins de 2 milliards de dollars ! Et pourtant, le géant de l’informatique ne fit jamais que délivrer exactement ce que l’utilisateur voulait ! Mais il échoua sur l’imprédictabilité du facteur humain.

D’un point de vue du Product Manager, on tend à planifier comme si tout était sous notre contrôle. Il faut au contraire créer des plans à même d’exploiter cette imprédictabilité au lieu de la combattre vainement.

Rechercher de nouvelles idées, essayer de nouvelles choses.

Cette approche trouve une incarnation dans le Set Based Design, l’aptitude à essayer différentes solutions en éliminant progressivement les moins valables.

En 2002 (ou était-ce en 2003 ?) Ducati se lance dans l’aventure Moto GP. Plutôt que d’essayer de construire d’emblée la meilleure moto, les ingénieurs conçoivent un engin sur lequel ils peuvent essayer multitude d’options. Après des débuts laborieux, celle-ci devient redoutable en seconde moitié de saison et l’écurie finit 2nd au championat constructeur !

Vous courrez après le déploiement continu ? Mais qu’en est-il de votre capacité à multiplier les versions, les comparer, créer des variations ? Cette approche permet d’expérimenter et d’apprendre. Bref essayer de nouvelles idées pour comprendre dans quelle direction il convient de se diriger !

La survivabilité

Le principe est simple : si votre expérimentation échoue, que les dommages en soit minimes … en tout cas que cela ne fasse pas couler l’entreprise !

Les connaissances et les pratiques d’ingénierie sont là … mais pas l’état d’esprit du product management !

Selection

Il faut faire le nettoyage sur ce qui ne sert à rien ou ce qui a échoué. En développement logiciel on ne supprime jamais rien (on garde, on ne sait jamais…). Et ce code ou ces composants morts deviennent un passif qui nous empêche d’avancer.

Non aux roadmaps, oui aux map of roads"

Mauvaise nouvelle pour les agilistes : le Product Manager n’est pas intéressé par les User Stories ! Ou plutôt, il est intéressé par leur faible granularité et leur côté “survivable” !

C’est le boulot du Product Manager de se créer des options, et les User Stories sont un bon outil pour cela : explorer des directions, sélectionner, changer d’option … bref tout sauf un plan linéaire ! Quelque chose qui ressemblerait à un plan avec un GPS pour s’y diriger. Ce GPS, c’est l’impact Mapping !

L’alignement rapide avec l’impact Mapping

L’impact mapping, c’est avant tout 4 questions pour arriver à une meilleure solution : 

  • Pourquoi ?
  • Qui ?
  • Comment ?
  • Quoi ?

Ce framework nous aide, car il nous évite de nous enfermer dans une logique unidirectionnelle, il nous permet d’explorer des variations : cette hypothèse contribue-t-elle au pourquoi ? Dois changer le “quoi” … ou m’intéresser à un autre acteur… S’il est parfois difficile de déterminer le pourquoi, les clients ont souvent moins de mal à dire ce qu’ils ne veulent pas. C’est un autre moyen d’arriver à nos fins !

On peut rapprocher l’approche Impact Mapping du Design Thinking : se générer des options, les explorer et les éliminer ! On a changé le mode dialogue au niveau du product management : on est passé du sacro-saint périmètre aux options et à leur contribution à un objectif…

Nicolas Gouy : Agile with GUTS

Nicolas est l’auteur d’un ebook portant ce titre et publié par infoQ.

image

Désolé pour la piètre qualité de la photo, vraiment l’éclairage (ou son absence, plutôt) m’a rendu la tâche difficile…

Parlons de valeur

Tout d’abord, c’est une notion subjective ! Et comme l’a indiqué précédemment Gojko Adzic, elle est subordonnée aux facteurs d’imprédicatabilité. Histoire de bien commencer, et de commencer fort (je dois dire), Nicolas nous parle des Shreddies. Les voici en image, pour illustrer le propos.

image

En passant d’un modèle à l’autre (sic !), Schreddies a vu son chiffre d’affaire s’envoler : la valeur n’est pas une question de sens commun ! Mais cela se travaille. Pourtant, sur nos projets agile, nous arrêtons notre horizon au backlog, comme si ce qu’il y avait avant était tabou !

Dans GUTS, il y a “G”, et ce “G”, c’est le Goals ! Notre but, c’est d’avoir un impact en étant en empathie avec notre client.

Le “U” quand à lui, c’est “Uncertainty”, et nous retrouvons les éléments que nous a partagé Gojko juste avant : il nous faut être à l’aise avec cela, et même en tirer parti. Comment ? En “crash testant” nos idées, en les validant au plus tôt.

Le “T” est plus original, car il s’agit du “Trade Off”. La solution parfaite est rarement un but désiré et raisonnable : il faut faire des compromis intelligents. Sur ce point, je ne suis pas sûr d’avoir compris ce que Nicolas voulait dire (exprimé plus simplement : je n’ai en fait rien compris). Bon, je verrais cela plus tard…

Le “S” signifie lui “Speed”. Une notion qui devrait remplacer celle de vélocité. Si la seconde notion couvre l’idée d’abattre plus de travail en moins de temps, la seconde consiste plutôt à atteindre un but plus rapidement … donc à être intelligent sur la manière d’y arriver ! C’est donc en fait remplacer la notion de périmètre par celle d’objectifs !

Quand on met l’acronyme ensemble, eh bien on parle bien entendu de “courage”. Et avoir du courage, c’est savoir être pertinent : toujours chercher à faire plus avec moins !

… Et Neo4J devint CMS !

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 !

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

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.