Carnet de Route : Agile Grenoble 2013 en images (1/2)

Agile Grenoble 2013, cela commence par des chutes de neige ! Elles ne sont peut-être pas très conséquentes entre Paris et Lyon…

AG13 : Entre Paris et Lyon

Mais il en va autrement entre Lyon et Grenoble, à tel point que je ne peux poursuivre mon voyage comme prévu le mercredi soir : plus aucun train ne circule ! Pire encore, pas moyen de trouver une chambre d’hôtel, je vais donc loger chez l’habitant !

Here we are

Après un trajet eneigé en voiture au petit matin, nous y sommes. J’y suis moi pour la première fois, à cet Agile Grenoble ! Hop, perception du badge.

AG13 : L'accueil / vestiaire

Et du sac à dos “Agile Grenoble”. Il est réservé aux orateurs, et il est bien mieux que le sac à ds promo standard ! C’est cool !

Dans la foulée, montage du stand Zenika. Au vu des intempéries, on craint le pire en ce qui concerne la fréquentation de l’évènement et surtout la présence des orateurs. Finalement il y aura bien eu quelques absents, mais on ne s’en sort pas trop mal. Idem avec les participants : au total 90 personnes n’auront pu venir. Mais les organisateurs auront eu fort à faire pour réajuster le programme en temps réel !

AG 13 : Le programme definitif

Mot d’ouverture

Le grand amphi du WTC de Grenoble a belle allure. Il autorise les 540 inscrits à cette conférence (la plus grande de France sur l’agilité), même s’il n’est pas totalement rempli aujourd’hui.

AG 13 : Le public à l'ouverture (1)

Le traditionnel mot des organisateurs ouvre ce nouvel opus d’Agile Grenoble.

AG13 : Ouverture de la conférence (1)

Place à la Keynote de Neal Ford !

Keynote de Neal Ford : When geeks leak

Neal Ford est un orateur de très bonne tenue. D’ailleurs il est l’auteur d’un ouvrage sur les patterns de présentation. Toutefois sa prestation du jour ne m’a pas laissé un souvenir impérissable.

AG13 : Keynote du matin avec Neal Ford (2)

Sans doute le propos était-il un peu trop décousu à mon goût, même si Neal Ford est un orateur de premier ordre. Mélant histoire des sciences (avec une prédilection pour Richard Feynman), application des sciences au monde moderne et techniques de présentations, le propos est difficile à syntéthiser ici. Je doute hélas que le support de présentation ci-dessous aide beaucoup : la présentation m’a aussi aidé à comprendre la différence entre un support de présentation et un “info deck”. Et ce n’est pas un info deck.

Premier créneau des présentations

J’ai aussi séché le créneau horaire suivant : j’ai pris pour habitude de passer l’heure précédent mes présentations à passer en revue celle-ci, afin de me remémorer l’ordre de passage de mes slides, la teneur de mon propos et surtout les transitions entre eux. C’était d’autant plus important aujourd’hui que je n’avais pas eu le temps de faire ne serait-ce qu’une répétition !
Le hall se vide, on n’y croise plus que les organisateurs qui profitent de ce moment de répis pour souffler…

AG13 : Les organisateurs

Users stories … what else ?

C’est mon tour de passer sur scène. On m’avait réservé une salle pouvant contenir 55 personnes. Finalement il faudra rajouter des chaises, des personnes resteront debout, d’autres finiront par terre. On était plutôt aux alentours de 70, sans compter celles qui feront demi-tour, rebutées par la foule ayant investi le lieu !

UG 13 : L'assistance lors de ma session "user stories, what else ?"

Je posterai bientôt mon support de présentation. Et plus tard, si j’ai le courage, cette présentation sous forme d’article. Mon but était d’éveiller l’intérêt des Product Owners envers les techniques de structuration et de recueil des besoin et aussi aux sujets annexes : vision, stratégie, marketing, etc… Je souhaitais aussi vérifier si l’approche consistant à venir étayer le métier de PO avec le corpus de connaissance de l’ingénierie des exigences et autres domaines non familiers des agilistes attirait l’intérêt. C’est ce qu’il me semble au vu des réactions très positives. Il va bientôt falloir enclencher la seconde étape !

Pause déjeuner

L’heure du repas arrive et l’espace centrale est rapidement envahi de tables où l’on déjeune en échangeant sur ce début de conférence. Les cartons-déjeuner sont très pratiques, je dois dire !

AG 13 : vue d'ensemble lors de la pause déjeuner (1)

Du côté de l’espace partenaires, on peut opter pour un mange-debout.

AG 13 : vue d'ensemble lors de la pause déjeuner (3)

J’opterais moi-même pour cette solution pour déjeuner en compagnie de Caroline Damour-Nobi et Pascal Van Cauwenberghe. Ah oui : nous avons aussi reçu la visite des hommes invisibles pendant notre déjeuner !

AG 13 : Les scribers (2)

Les scribers !

Peu de personnes étaient au courant du hacking planifié par Romain Couturier et Jacques Couvreur. Je crois même que j’étais le seul à être au courant avant le début de la conférence. Romain et Jacques sont des “scribers” très talentueux : Ils prennent toutes leurs notes sous forme graphique. Ils ont eu la fantastique idée de se balader dans la conférence ainsi équipés en hommes-sandwiches, scribant à tour de rôle l’un sur l’autre les conversations qu’ils écoutaient en tant qu’hommes invisibles !

AG 13 : Les scribers (4)

Ils poursuivront cet exercice durant les sessions. C’était leur première tentative. Il y a fort à parier que nous les reverront dans cet équipage lors de prochaines manifestations ! Pour ce premier essai, Alexandre Boutin n’était pas du tout au courant, il a été aussi surpris que les autres (sauf moi).

AG 13 : Alex Boutin et les scribers

Un grand merci à Romain et Jacques pour cette animation vraiment différente et d’excellente qualité !

AG 13 : Les scribers (8)

Passer à la suite…

La pause déjeuner touche à sa fin.

AG13 : Gros plan lors de la pause déjeuner (11)

Vous êtes peut-être un peu déçu, car j’accorde souvent bien plus de place pour parler des sessions ?

Je vais essayer d’un peu me rattraper lors de mon prochain post !

Carnet de route : DevFest 2013 à Nantes, en images (2/2)

Pause déjeuner

Suite de notre parcours de la DevFest. La pause déjeuner à la DevFest, c’est standing. Ca change des sandwiches qui sont le quotidien de certaines autres conférences que l’on ne nommera pas…

DevFest 2013 : Le buffet (1)

Le service ne semble pas en reste.

DevFest 2013 : Le buffet (3)

D’un autre côté, il semble qu’il nous faille mériter notre pitance. La file d’attente s’allonge terriblement.

DevFest 2013 : En attendant le buffet

Passant sur le second créneau de l’après-midi, j’ai courageusement choisi de sauter la première séance d’après-déjeuner afin d’être fin prêt. Nous avons une salle “réservée orateurs” à cet effet.

DevFest 2013 : la salle de repos des organisateurs

Christophe Addinquy & Martin Mouterde : De l’agilité pour mon projet, pourquoi faire ?

C’est notre tour, à Martin et moi-même. Notre session d’introduction à l’agilité n’est pas vraiment un thème “mainstream” de cette DevFest, il est donc peu surprenant qu’elle n’attire pas foule. Une trentaine de personnes environ.

DevFest 2013 : le public de ma session

Je ne vais pas faire de résumé de notre session ici. Je posterais le support plus tard.

Why Google+ Sign In ? Par Ian Barber

Gros fail pour cette session. J’aurais pu me douter qu’elle était en Anglais (et j’avoue que le sujet ne me passionne pas assez pour avoir envie de faire un effort). Mais pire, elle était retransmise par Hang out !

DevFest 2013 : Google Sign In (2/2)

Pour être honnête, je n’ai pas fait d’effort et me suis laissé décrocher assez rapidement. Pas de résumé, donc pour cette session. Je ne suis même pas sûr que le préposé au Hang out ait trouvé cela palpitant !

DevFest 2013 : Google SignIn (1/2)

Break de l’après-midi

Une pause avant la dernière ligne droite. C’est l’occasion de faire un petit tour.

DevFest 2013 : signalétique à l'accueil

D’aller s’intéresser au paysage, aussi.

DevFest 2013 : Stand sponsor (4)

Ou de voir ce que j’ai bien pu rater au programme (et essayer de ne pas rater la dernière session).

DevFest 2013 : le programme

Web Components, l’avenir des développeurs Web, par Julien Vey

Pour ma part, ce fut la meilleure session de la journée, par son contenu et la maitrise du sujet par Julien. Par exemple, on crée des <div> que l’on masque ou l’on crée du DOM via du Javascript…

Demain, il suffira d’utiliser la balise <template> pour créer des fragments HTML qui seront parsés mais ni chargé, ni exécuté, mais qui pourront l’être en instanciant ce fragment d’arbre en Javascript via cloneNode().

DevFest 2013 : Julien Vey (2/3)

Le shadow DOM est un nouveau moyen d’encapsuler un élément. Il est utilisé par exemple dans le cadre de la balise <video>. Mais ce concept est aujourd’hui fermé. Il sera disponible demain aux développeurs, via la méthode createShadowRoot() qui crééra un élément auquel il suffira d’accrocher des sous-éléments. L’un d’entre-eux pourrait d’ailleurs être une balise <content> pour injecter du contenu dans ce shadow DOM.
On peut apparemment mixer DOM et CSS, mais comme je suis imperméable à ces considérations, le mieux sera pour vous d’aller gambader dans les la vidéo de le session de Julien !
Enfin, les Web Components permettent de créer ses propres balises, via la balise <content>.
Bref, les Web Component, c’est l’avenir. Du moins, ce le sera quand la norme sera finalisée, ce qui n’est pas encore le cas. On pourra alors intégrer des Widgets d’un nouveau genre qui ne ressembleront plus à un amas sordide de <div> et de Javascript ! Toutefois, il n’est pas nécessaire d’attendre ce jour béni. On peut déjà utiliser Polymer qui émule l’état actuel de la norme.
Outre l’excellente présentation de Julien, on peut aller vers le site de référence sur HTML5, à savoir htmlrocks pour en savoir plus et surtout trouver les bons tutoriaux !

Check out

La DevFest touche à sa fin, quelques irréductibles s’essaient encore au zPilot et il sera temps de plier les gaules.

DevFest 2013 : Fin de la conférence

Un bon DevFest en ce qui me concerne. Si les sessions front-end sont assez loin de mon habitat naturel, j’ai réussi à ne pas être trop largué, ce qui est déjà pas mal pour moi…

Carnet de route : DevFest 2013 à Nantes, en images (1/2)

La DevFest, c’est l’évènement Google pour les développeurs. Pour être exact, il n’est pas organisé par Google (bien que supporté par le géant de Mountain View) mais par le GDG Nantes. Je m’étais joins aux festivités pour une session d’introduction à l’agilité avec mon collègue Martin Mouterde.

Check-in

On débute tôt la journée ici, les portes sont ouvertes à 8h20 ! Rien à voir avec notre rythme de bâton de chaise Parisien… Heureusement, Martin et moi étions arrivés la veille pour répéter. Café et croissants sont prévus pour accueillir les participants.

DevFest 2013 : Le café en arrivant

Jusqu’ici tout va bien. Direction la keynote.

Keynote : Des opportunités pour s’associer

On a tranquillement rempli l’amphithéâtre pour cette keynote. A priori, nous étions 350. Julien Landuré a délaissé son polo Zenika pour un T-shirt GDG Nantes pour évoquer l’année écoulée.

DevFest 2013 : Présentation GDG Nantes

L’organisation avait aussi prévu une couverture en image plus solide que celle de vôtre serviteur. J’espère avoir bientôt un lien à vous donner.

DevFest 2013 : La photographe

Place maintenant à la keynote ! Une keynote surprenante, car elle ne va pas parler de technologie, mais de collaboration. L’orateur y évoque des outils parfois connus comme les modèles DISC, MBTI ou Process Com. Il en évoque d’autres moins connus comme Strength Finder, qui me donne bien l’envie d’essayer !

DevFest 2013 : Keynote

Connaitre ses forces, c’est une bonne façon de savoir comment les associer, lequelles acquérir pour se renforcer.
S’associer, c’est essayer au travers de Startup Week-ends, Hackathon et autres Roadtrips… si on n’arrive pas à s’entendre sur 2 jours intenses, ce n’est peut-être pas la peine d’insister sur une longue durée…
S’associer, enfin, c’est s’engager :

  1. En formalisant au plus tôt les statuts.
  2. En rédigeant une lettre récapitulant ces statuts.
  3. En s’aidant d’un avocat d’affaire.

Pawel Kozlowsky : AngularJS: making a browser a better development platform

Pawel est l’auteur de ce qui est encore l’un des rare livres sur AngularJS. Il pratique en outre ce framework depuis 3 ans.
Béotien absolu du développement Javascript, je me suis campé dans cette session justement pour cette raison, et aussi pour avoir un peu parcouru les tutoriaux AngularJS…

DevFest 2013 : introduction à Angular JS par Pawel (3)

Pawel le dit lui-même: le développement dans le browser, c’est parfois douloureux ! Les frameworks sont là pour soulager, mais un framework comme JQuery se focalise surtout sur le requêtage du DOM, afin de le rendre plus facile. Ce n’est ni n réel changement de paradigme, ni un “game changer”.
AngularJS propose un binding bidirectionnel entre modèle et vue, sans qu’il soit nécessaire d’enregistrer le modèle, ni procéder à des notifications explicites ! AngularJS est réellement déclaratif ! En fait, une grande partie des fonctionnalités d’AngularJS consiste en propriétés (notées ng-*) qui peuvent être ajoutées aux éléments, tel le ng-repeat qui permet de construire des templates.
AngularJS permet aussi de construire des tags “custom” à l’image des futurs Web Components, ainsi que l’injection de dépendance en JavaScript.
En conclusion, AngularJS, c’est :

  • Du data binding bidirectionnel sur un modèle.
  • Un DSL customisable au-dessus de HTML
  • Un framework complet et solide.

Et une excellente ressource pour commencer : http://egghead.io/

Guillaume Campion : Retour d’expérience sur les Google Glasses

Bien sûr, les Google Glasses, ça attire les badauds, même si la session n’est pas très technique. En fait, même pas du tout !

Les objets connectés, c’est le nouvel eldorado, qu’on se le dise ! Pourtant il n’y en a que 8 paires en France actuellement. Pourtant les “lunettes informatiques” ne sont pas nouvelles. Steve Mann (http://spectrum.ieee.org/geek-life/profiles/steve-mann-my-augmediated-life ) en construit et en porte depuis 35 ans. Chez lui, elles sont vissées à la boite cranienne, car il ne fait pas dans la demi-mesure !
Les lunettes Google disposent des fonctionnalités suivantes :

  • Un touchpad sur le côté.
  • Un appareil photo de 5 Mega pixels
  • 12 GB de mémoire
  • Une mise à jour du firmware tous les mois.

Voilà la bête, sur Guillaume :

DevFest 2013 : 6 mois avec les Google Glasses (2)

Prendre une photo n’a jamais été aussi facile. L’orateur objecte cependant à ce que l’on puisse les considérer comme le nouveau gadget du voyeur.

Prendre une photo n’a jamais été aussi facile. L’orateur objecte cependant à ce que l’on puisse les considérer comme le nouveau gadget du voyeur.

DevFest 2013 : 6 mois avec les Google Glasses (3)

L’interface utilisateur de compose de “cartes”. Pour ce qui est du développement, il peut se faire de 2 façons:

  • Miror API : Ca passe par une connexion permanente chez Google !
  • Natif : C’est un gros un SDK Android (il y a un GDK, mais qui n’est pas encore publié). Ce mode donnera accès aux senseurs des lunettes quand il sera accessible.

En résumé :

  • Les Google Glass, c’est un 6ème sens !
  • On peut toujours les avoir sur soi, mais elles sont non intrusives (pas une réelle réalité augmentée).
  • Un usage plus spontané, ne nécessitant pas les mains et “quasi” see-through
  • Une interface utilisateur différente qui nécessite pas mal de boulot.

J’ai eu la possibilité de prendre une photo de plus près des lunettes (mais pas de les essayer) dans la salle réservée aux orateurs. Voilà:

DevFest 2013 : Les Google Glasses (2)

Et si vous voulez la présentation in-extenso :

Présence Zenika

L’une des raisons de ma présence ici était la présence de Zenika en tant que Sponsor. Notre stand proposait des animations autour de jeux video.

DevFest 2013 : On joue sur le stand Zenika (2)

De manière générale, l’espace était assez exiguë. Celà renforce l’impression d’affluence générée par les jeux.

DevFest 2013 : On joue sur le stand Zenika (1)

Comme à Rennes, une petite photo du staff s’impose

DevFest 2013 : L'équipe Zenika (1)

Je vais m’arrêter ici pour ce post, histoire d’en garder pour un peu plus tard.

Carnet de route : Agile Tour Rennes en Images (2/2)

Nous nous sommes quitté lors du premier post à l’heure du déjeuner. En fait cette heure du déjeuner était réservée aux lightning talks, chacun sur son créneau horaire afin de permettre de les voir tous au besoin !
Hélas cette méthode n’est pas très efficace. Seuls les derniers lightning talks rencontreront un public. Pas facile de gérer cela. Seul l’Agile Tour Nantes m’a convaincu sur ce point l’an dernier. Mais les organisateurs de l’Agile Tour Rennes restent très loin du fiasco du Scrum Day !
On en termine donc rapidement avec la pause déjeuner pour voir cela.

AT Rennes 2013 : Lunch (8)

Prélude au second mouvement : Le Podojo par Emilie Esposito et Damien Sainte

Un Ligtning Talk, c’est déjà court. J’arrive pourtant à en rater la moitié. C’est quoi le PO Dojo ? Un atelier construit collaborativement pour les PO et un groupe Google pour le faire vivre ! Ce qui semble remarquable, c’est l’aspect complètement communautaire, sans PO donc. Sans roadmap non plus, avec un catalogue d’ateliers qui évolue au fil des besoins et des idées.

AT Rennes 2013 : PO Dojo (1)

Alors que le concept de PO promeut que quelqu’un tienne la barre, ces PO ont su s’affranchir de l’idée d’avoir un chef (quelque soit la forme qu’on lui donne), une roadmap prévue à l’avance et tout et tout. Chapeau à eux !

Avant de me rendre à la session de Laurent Morisseau, je passe rapidement la tête dans la salle où officie Dov…

AT Rennes 2013 : Dov

Reprise : #OMG, mon équipe fait son haka en Kanban style ! Par Laurent Morisseau

Un petit challenge pour notre ami Laurent en ce début d’après-midi : faire bouger le public à l’heure de la digestion…

Et d’abord, c’est quoi Kanban dans un projet agile ? De l’amélioration continue + de la gestion de projets !

Commençons avec Scrum

Quand l’on part de Scrum, le point de départ, c’est le tableau des tâches : à faire, en cours, fait… MAIS on met un nom sur une tâche ! C’est un antipattern. Le stand-up devient un reporting !

AT Rennes 2013 : Scrum et Kanban (2)

Améliorer les choses

  • En utilisant les “classes de service”, pour traiter les bugs urgent, par exemple
  • En régulant le flux des stories et des tâches en cours en utilisant des limites de WIP (work in progress) à chaque niveau.

Bref, l’idée est de rendre les problèmes visibles dès qu’ils sont évoqués et de poser des limites hautes et basses.

Quand le PO est dépassé…

Que dire d’un backlog de 70 user stories pour 7 développeurs ?
C’est bien trop, ou bien trop détaillé ! Scrum en tant que process met la contrainte sur l’équipe de développement. En amont, le PO doit travailler en flux, donc sans faire trop de stock.
On peut remédier à cela en matérialisant ce flux tiré et en étendant le Kanban aux activités amont et un matérialisant les états des stories.
Vous pourrez en savoir plus sur le site de Laurent, où vous trouverez non seulement une video mais le matériel de cette présentation sous forme de podcast.

Entracte : Zenika à l’Agile Tour Rennes

Je vous l’ai dit, nous étions présent en force à cet Agile Tour Rennes, pour représenter Zenika. Non seulement depuis l’agence de Rennes, mais aussi de Paris et de Nantes ! Cela valait bien une petite photo de famille.

AT Rennes 2013 : Staf Zenika (4)

Pour une fois, ce n’est pas moi qui prend la photo, cela me donne l’occasion d’y avoir l’air d’un niais. Et tant que j’y suis, j’en profite pour remercier Allison qui s’est dépensée sans compter pour préparer notre présence ici.

AT Rennes 2013 : Allison (2)

Les session s’enchainent. Il est l’heure de celle de Géry

Interlude : Carpaccio Game avec Géry Derbier

Géry nous propose un grand classique : Le carpaccio game. Mais qu’il anime avec grand talent et tout autant d’énergie.

AT Rennes 2013 : Carpaccio Game (2)

C’est très studieux, car il s’agit de programmer le sujet proposé par tranches de 8 minutes et d’apporter de la valeur à chaque itération. Un exercice auquel je me suis d’ailleurs livré il y a peu.

AT Rennes 2013 : Carpaccio Game (3)

Acte 2 : Booster Scrum avec le Lean Startup par Olivier Lafontan

Là encore j’ai bel et bien raté une partie de la session, mais j’étais très curieux de la voir, car elle a eu une belle affluence au Scrum Day en Avril dernier.

Lean Startup nous apprends à mettre l’investissement là où il y a de la valeur. Scrum tend à se “débarrasser” de ces questions sur le PO qui se tape un peu tout sur cet aspect. Et celui-ci se trouve un peu démuni face à ce genre de problème avec pour seul appui le backlog… Lean startup apporte quelques outils :

  • Le Lean Canvas
  • Le Validation Board
AT Rennes 2013 : Olivier Lafontan (1)

La charnière entre Lean Startup et Scrum se trouve au niveau de ces outils. La priorisation du travail devient une priorisation des hypothèses à vérifier. Car Lean Startup ne parle pas de besoin … mais d’hypothèses. Tant que ces “besoins” n’ont pas été vérifiés ils sont en effet hypothétiques. Le cycle Scrum devient un cycle de validation des hypothèses.
A plus grande échelle, un gestion de portefeuille se traduit en portefeuille de Canvas.

Conclusion : Christophe Keromen

C’était ma dernière session de l’après-midi (même si en fait il y en avait une après).

Christophe nous offre une session rafraichissante pour nous ressourcer aux origines de l’agilité. Il remonte au manifeste agile et à l’invitation d’Alistair Cockburn. Non, en fait il remonte plus loin : à Henry Ford, Richard Denning et Taïcho Ohno…

AT Rennes 2013 : Christophe Keromen (1)

Je ne vais pas essayer de reconter la session de Christophe qui mérite plutôt d’être vue. Toutefois, je ne résiste pas au plaisir de dévoiler le Lean version Dan Brown : “Le Lean est un projet Franc-Maçon pour dominer le monde” ! Un grand moment…
Pour finir, Christophe nous propose un nouveau gourou agile : Bob l’éponge … pour absorber les pratiques qui marchent !

Tombée de rideau : A l’année prochaine !

Cet Agile Day était un peu marathonien, force est de l’avouer. Sur la durée, je dirais qu’il y avait une session de trop. Mais ce fut une excellente journée, aussi bien du point de vue de la qualité des sessions que de celle des échanges. Figurez-vous que j’y ai même rencontré l’un des fidèles lecteurs de mon blog (du coup, je le salue !).

AT Rennes 2013 : A l'accueil (1)

Il est temps de se quitter et de se donner rendez-vous à l’année prochaine. A moins qu’un coach retreat, entre-temps…

Carnet de route : Agile Tour Rennes en images (1/2)

C’était cette année ma première visite à l’Agile Tour Rennes. Venu en renfort du staff Zenika local, je ne présentais aucune session, au contraire de Géry Derbier, animateur d’un atelier l’après-midi. Une journée que l’on pourrait donc qualifier de relax pour moi. J’en ai profité pour prendre pas mal de photos, ça va donc être encore plus “en images” que d’habitude !
Pas d’autre choix que d’arriver la veille : les organisateurs de cet Agile Tour avaient prévu une journée particulièrement dense débutant à 8h30, pas moins !

Lever de rideau

Première conséquence : l’ouverture des portes alors que le soleil n’est pas encore levé !

AT Rennes 2013 : début des festivités (1)

Et pour nous, la nécessité d’arriver encore une demi-heure avant pour nous installer.

AT Rennes 2013 : début des festivités (3)

L’occasion aussi de voir le point central avant l’arrivée de “la horde”. Profitez-en, vous n’allez plus jamais le voir comme ça !

AT Rennes 2013 : début des festivités (2)

Le comité d’organisation ouvre les festivités, c’est l’occasion de saluer cette équipe sympathique et dynamique !

AT Rennes 2013 : accueil (3)

Le programme est dense, aucun doute. Jugez-en !

Programme Agile Tour Rennes 2013

Prélude (Keynote) : Ensemble c’est tout, par Aurelien Morvant

… Où l’on parle de sociocratie. Un petit rappel pour moi, certes, mais Aurélien aborde le sujet de manière intéressante.

Petit rappel historique

Donc, ça commence au Jurassique … euh non, là on est quand même remontés un peu loin !
Avançons dans le temps : les monarchies. Sociales, je ne sais pas, elles semblent plutôt autocratiques. Apparues avant ou après selon les cas, les dictatures revêtent les mêmes habits !
Les démocraties semblent se rapprocher d’un modèle participatif. Oui mais la concertation se fait surtout à l’élection, guère après. Sauf lorsque l’on fait des référendums et encore est-ce fait avec des questions fermées.
Et le monde de l’entreprise, alors ? Celui-ci parait en fait également se caler sur le mode autocratique.

AT Rennes 2013 : Keynote

Comment ça marche ?

Edenburg définit les 4 piliers de la sociocratie comme suit :

  • Le consentement
  • L’élection sans candidat
  • Le double lien
  • Le cercle

Le cercle est la base du dispositif. Il existe aux différents niveaux hiérarchiques.
Le consentement est le mécanisme de décision qui permet d’aller dans une direction sans nécessairement satisfaire tout le monde, mais sans insatisfaire personne, du moins de manière rationnelle. Le consentement, c’est accepter une proposition à laquelle on n’oppose pas d’objection valide (je peux vivre avec…). Au contraire du consensus qui doit satisfaire tout le monde est finit généralement par être vidé de sa substance !
Le double lien, c’est la hiérarchie classique qui descend les décisions, mais un délégué du cercle inférieur qui accompagne ce supérieur hiérarchique pour remonter ce qu’en pense le cercle d’en dessous.

Mais dans la vraie vie ?

Ce dispositif est déjà bien implémenté au sein de milieux associatifs. Il commence à l’être dans des environnements tels que des mairies, des hôpitaux..
Certaines entreprises commencent aussi à mettre en place la sociocratie, du moins dans une certaine mesure.

Entracte : une pause avant de poursuivre la matinée

La matinée est longue. Profitons des pauses, qu’elles soient prévues ou non pour se désaltérer et revoir de vieilles connaissances comme Emilie, c’est toujours un grand plaisir.

AT Rennes 2013 : Pause matinée (1)

Etant venu à Rennes pour soutenir l’équipe Zenika, il m’est difficile de me joindre à une session pour sa durée entière et je dois donc limiter mes choix à certaines salles. En fait, à l’amphithéâtre principale où l’on accède par les derniers gradins.

Acte premier : Comment devenir agile et surtout le rester, par Aurélien Morvant et Sylvie Le Bail

C’est de changement culturel dont nous parlent Aurélien et Sylvie. Mon “keep away” de cette session (que j’ai prise en cours de route) tient sur 5 points :

Le manager devient le garant des valeurs et de la culture

Le changement est quelque chose de paradoxal. C’est à la fois “je veux y aller” et “je ne veux pas y aller”. C’est la manager qui a pour rôle de rassurer en garantissant que certaines choses vont être stables.

Donner du sens

C’est répondre à 3 questions :

  • Pour quoi ?
  • Comment ?
  • Quoi ?

Le “pourquoi” nous amène fatalement au fameux Start with the why de Simon Sinek. Cela se décline pour une organisation en :

  • Vision
  • Valeur
  • Mission
AT Rennes 2013 : Aurélien Morvant (1)

Donner de l’autonomie

Il faut passer à “l’entreprise du pourquoi”. 4 étapes pour y arriver :

  1. La dépendance.
  2. La contre-dépendance. On s’oppose en répondant “non”.
  3. La confrontation avec la réalité : l’indépendance. Mais l’indépendant ne communique pas !
  4. L’interdépendance. Elle implique des relations d’égal à égal avec les autres.

L’autonomie, c’est la capacité à travailler avec les personnes de l’étape 4 !

Nourrir la démarche

Le constat sur l’entreprise d’aujourd’hui n’est pas glorieux:

  • 11% se sentent “engagés” dans l’entreprise.
  • 61% sont désengagés.
  • 28% sont activement désengagés. Ce qui veut dire qu’ils dénigrent l’entreprise !

L’objectif est de récupérer l’énergie des désengagés. Autant dire que cela ne se fait pas tout seul ! On peut agir sur l’environnement, mais on ne peut pas agir sur les motivations, car les motivations sont des facteurs intrinsèques.

Travailler sur les motivations

On retourne vers un vieux modèle, mais qui marche toujours : la pyramide de Maslow.

Pyramide de Maslow

Entracte : faisons une pause déjeuner

Nous sommes arrivés doucement à la pause déjeuner. On fait dans le style “snack”. L’avantage, c’est que l’on n’a pas de longues queues pour accéder à sa pitance.

AT Rennes 2013 : Lunch (3)

Et on peut en profiter pour discuter.

atrennes13-09pause-matin03

Au détour d’un buffet je croise Oana qui s’attaque aux organisateurs plutôt qu’au buffet.

AT Rennes 2013 : Oana (4)

Toutefois, il est bien clair qu’elle a ses préférences…

AT Rennes 2013 : Oana (3)

C’est tout pour aujourd’hui. Nous reprendrons les sessions de l’après-midi dans un prochain post !

Worshop Running Lean, avec Ash Maurya (2/2)

Alors que la première journée s’appuyait en grande partie sur Running Lean, cette seconde journée sera d’avantage centrée sur les techniques récemment développées par Ash Maurya.

User cycle

Act 1 : Est-ce un problème qui vaut la peine d’être résolu ?

Nous l’avons évoqué dans le post précédent : la clé est de se concentrer sur l’utilisateur, de rechercher quels sont ses sources de souffrance :

  • Son workflow (il ne faut pas l’ignorer, en fait on doit même s’y insérer)
  • Ses craintes, ses frustrations
  • Ses buts et aspirations.

L’approche à adopter est une alternance de recherche et d’interviews : La recherche permet d’établir des hypothèses et l’interview permet de valider ou invalider ces hypothèses. Il s’agit de “problem interviews” permettant de valider l’identification du problème.

Ash Maurya durant le workshop

Deux mesure de succès du “problem interview” permettant de vérifier ‘intérêt que l’on suscite:

  • L’acceptation d’un “follow up”
  • L’obtention d’autres référents avec lesquels travailler.

Deux points que l’on n’obtient pas si l’on a eu qu’un intérêt de politesse.

Acte 2 : Tester la Vision

On n’a pas nécessairement besoin de code pour tester sa Vision. Il faut surtout être capable de faire une démo qui raconte une histoire. On peut utiliser un outil de prototype comme Keynotopia ou Balsamiq .

Là encore la validation passe par une interview, cette fois c’est une Solution Interview, qui s’articule comme suit:

  • Attention : En cernant correctement et précisément le problème de départ.
  • Intérêt : Avec une démo qui déchire.
  • Désire
  • Action

L’objectif est de produire un engagement :

  • “soft” : c’est obtenir un “oui”. ça vaut ce que ça vaut…
  • “dur”: c’est déclencher un pré-vente !

Bien sûr, on a toutes les possibilités intermédiaires…
A propos de la pré-vente : l’ancrage du prix fait partie du solution interview. Il faut le justifier par rapport aux alternatives et bien entendu pouvoir montrer qu’on abaisse en fait le coût avec notre solution, donc changer la perception du client potentiel. Quelques références sur ce sujet :

Positionner le MVP

La première étape consiste, nous l’avons déjà dit, à se concentrer sur un petit nombre de clients, une dizaine peut-être, guère plus, souvent même moins ! On ne cherche pas à collecter d’informations quantitatives, mais qualitatives.
C’est pourquoi on va chercher à rendre ces clients très heureux, pas simplement satisfaits. Adresser le risque marché consiste précisément à identifier si la solution permet ce haut niveau de satisfaction chez des clients. On ne va pas chercher à abaisser le “signup friction” de ces early adopters, on doit cibler des clients pour qui la proposition de valeur représente un besoin important. Autant augmenter ce “signup friction”, au contraire !
Plus tard dans le cycle utilisateurs, on cherchera à élargir la base d’utilisateurs, en s’appuyant de plus en plus sur du self-service. A ce niveau, c’est le risque technique lié à la scalabilité que l’on adressera.
Et le prix ?
Cela semble malin de prime abord de proposer 2, 3 ou 5 “plans”. Mais en réalité, il est préférable de ne pas s’amuser avec ces plans, même s’ils ont pour but de guider le client vers un “plan préféré”. La présence de ces plans multiples peut être un obstacle pour apprendre des choses sur l’adéquation prix-service, car il introduit une dimension supplémentaire.
Le prix est une partie intégrante du MVP. Tant que la proposition de valeur n’est pas payante, sa validité n’est pas établie.

Nous sommes tous dans le “manufacturing business”

… Et ce que nous construisons, ce sont des clients heureux, dont on améliore la chaine de valeur !
En Lean, l’amélioration de la chaine de valeur passer par l’élimination du gaspillage à l’échelle de la totalité de la chaine de valeur. Celle-ci est formée d’un ensemble de processus interconnectés sur lequel il faut identifier la contrainte principale … sans perdre de vue qu’une fois cette contrainte levée, celle-ci se sera déplacée ailleurs dans le système !

Exercice pratique

Dans le principe, ça parait simple. Dans la pratique il faut prendre en compte la dimension irrationnelle des clients, bien que cette irrationalité soit en fait prédictible (voir Predictably irrationnal)
Ash Maurya gradue le niveau d’engagement des clients ainsi :
1. Acquisition
2. Activation
3. Rétention
4. Revenue
5. Référent
Cette échelle nous permet d’aborder le sujet suivant : la customer factory !

The customer factory

C’est le sujet du prochain livre d’Ash Maurya. Il représente cette Customer Factory ainsi :

The Customer Factory

Le principe est finalement assez simple :

  • L’étape initiale est l’acquisition : les prospects viennent chez vous. Mais attention ! ce doit être plus qu’un simple rebond !
  • La rétention : elle est matérialisée par le signoff (activation). C’est l’étape “usine”.
  • Le revenu : quand on parvient à faire payer le souscripteur.
  • Le référent : quand on parvient à acquérir de nouveaux clients grâce à ces clients existants.

Et le moteur de croissance ?

  • Le “paid engine” doit favoriser l’acquisition.
  • Le “sticky engine” doit permettre la rétention.
  • Le “viral engine” doit engendrer l’acquisition par référent.

Ash Maurya nous recommande pour le “paid engine” : une “life time value” = 3 x le coût d’acquisition.
Pour observer si les moteurs de croissances donnent le résultat escompter, il faut passer par des métriques de cohortes, mais surtout se livrer à de nombreuses expérimentations !

Le validation board

Le Lean Startup Machine a mis au point le “validation board” qui permet de suivre les expérimentations à faire et en cours (c’est une sorte de kanban, si on veut bien…) par rapport à des hypothèses.

The Validation Board

Les clés :

  • Identifier les expérimentations capables de valider les hypothèses.
  • Trouver la mesure adéquate. Ash recommande à ce sujet la lecture de How To Measure Anything.
  • Construire une offre.

L’auteur de Running Lean nous propose 3 types d’offres :

  • La “Maffia Offer” : comme son nom l’indique, c’est l’offre que l’on ne peut pas refuser !
  • Le “Smoke Test Offer” : Une offre dont la complétude s’arrête à ce qu’il faut pour tester une hypothèse de marché.
  • Le “Pré-order offer” qui serf à lever des fonds, à la façon Kickstarter.

Les idées clés sont de faire de petites expérimentations (2 semaines maximum) ne testant qu’une seule hypothèse, pour lesquelles on définit les objectifs avant les critères de satisfaction avant, afin d’éviter la rationalisation après coup.

Chaque expérimentation doit être documentée. Mais pas trop, car on est lean…

L’experiment report

L’experiment report est une déclinaison du A3 du Lean. Il va nous permettre de garder la mémoire des expérimentations déjà opérer : faire des erreurs, c’est apprendre. Refaire les mêmes, c’est bien dommage…

Experiment Report

La partie du haut nous permet de figurer les mesures, et la partie du bas résume ce que l’on a appris

This is the end…
Nous arrivons au terme de ces 2 jours. Ils furent bien remplis, même si la partie pratique pêche un peu. De toute façon, c’est bien sur du réel qu’il faut mettre tout cela en pratique, et sans trop tarder !
Il me faut remercier non seulement notre orateur, mais aussi Sebastien Saccard qui a rendu ce workshop possible.

Ash Maurya et Sébastien Saccar

Et bien entendu Zenika qui fut l’un des sponsors de cet évènement.

Ressources

Pour compléter ce que nous avons vu, voici 2 présentations. La première est d’Ash Maurya et reprend les éléments de son workshop.

Le seconde est de Camille Roux (qui était aussi présent au workshop) et reprend de manière très synthétique et percutante la démarche Running Lean.

Worshop Running Lean, avec Ash Maurya (journée 1/12)

J’ai eu la chance de pouvoir assister au workshop instruit par l’auteur de Running Lean ce mois-ci. Un workshop qui n’a eu aucun mal à se remplir car ce ne sont pas moins de 45 personnes qui s’y étaient inscrites !

Ash Maurya à l'accueil

Le temps d’avaler un café et une viennoiserie et on attaque le sujet !

Les stagiaires à l'accueil

Où l’on commence par casser un mythe…

Et c’est celui du visionnaire ! Certes le produit est important, mais pas SI important. Et comme Ash nous le répètera plusieurs fois durant ces 2 jours :

Votre produit n’est pas votre produit.
Votre Business Model est votre produit.

Ainsi la cause principale d’échec n’est pas un problème de réalisation du produit, mais l’incapacité à trouver des clients. En fait, parmi les startups réussissant à développer leur business, 2/3 d’entre-elles modifient leur plan en cours de route !
Comment savoir quelle direction prendre dans ces conditions ? En écoutant le client, et donc en apprenant à l’écouter : Quel est réellement son problème ? Mérite-t-il d’être adressé ? Le client que nous imaginons est-il celui correspondant au problème, ou devons-nous réévaluer le problème, à moins qu’il faille changer de client ?
Ces questions s’adressent sur les business classiques sur des cycles d’un ou deux ans. Il s’agit ici d’aller plus vite et de maximiser ce que l’on apprends en fonction du temps. Finalement, le développement du produit est une activité qui est en travers de notre route. C’est en évaluant l’usage du produit que l’on apprends des choses sur notre utilisateur, pas en le développant !
Il faut trouver des moyens de gagner du temps à ce niveau et d’optimiser nos moyens d’apprendre

Le Lean Canvas

Le Lean Canvas est un Business Model (il est d’ailleurs inspiré du Canvas du Business Model Generation). Peu importe que nous utilisions ce dernier ou celui de Ash Maurya. Ou même que nous inventions le notre. Mais il faut en faire un (et même plusieurs, en fait), et non un business plan ! Le Business Plan est un travail de fiction postulant sur des gains futurs dont on ne sait rien !

Lean Canvas

Il faut faire plus simple, un outil qui soit plus synthétique et tenant en une page et qui nous aide à construire nos hypothèses. Le Lean Canvas est cela et plus encore. Il suffit de 20 minutes pour commencer à le construire. Il faut encre moins de temps pour le déchirer et en recommencer un autre !

Le Lean Canvas nous aide à identifier la partie la plus risquée du plan :

  • Parviendra-t-on à être suffisamment différent pour acquérir un “unfair advantage” ?
  • Sur quelle marge (revenue – coûts) peut-on compter lors du scaling ?
  • Quels signes, quelles métriques mettront en lumière la “traction” sur le produit. Attention aux métriques de vanité, il est préférable de s’appuyer sur des métriques dites de cohortes et non des chiffres cumulés.
  • Enfin le problème est-il bien compris et bien articulé ? C’est la proposition de valeur. A ce stade, il est préférable de rétrécir le segment de marché auquel on s’adresse ! Geoffray Moore ne dit pas autre chose dans “Crossing the Chasm” !

Le véritable travail de l’entrepreneur

Nous allons le répéter une fois encore : votre produit n’est pas le produit, c’est le business model qui est le produit !
Le boulot de l’entrepreneur est de “dé-risquer” de manière systématique le business model au travers de conversations :

  • Avec les (futurs) clients
  • Avec l’équipe
  • Avec les mentors
  • Avec les investisseurs
  • … et même avec les compétiteurs !

Bien sûr, on ne parle pas de conversations au coin du feu, mais de conversations structurées, évaluables et capables de nous apprendre quelque chose !

Les 3 étapes de la startup

Dans l’approche “running lean”, Ash Maurya identifie 3 étapes majeures de l’évolution de la startup. Entre chaque étape on trouve un objectif de progression de clients d’un ordre de grandeur 100 ou plus !

Running Lean 3 stages

1 – Problem / solution fit

  • Le problème que l’on cherche à résoudre vaut-il la peine d’être résolu ?
  • Est-ce le bon client par rapport à ce problème ?

Comme le résume Ash Maurya :

La vie est trop courte pour développer quelque chose dont personne ne veut !

Durant cette phase on travaille avec très peu de clients, 1 à 10 par exemple. mais on travaille en grande proximité !
Le fameux MVP de Lean Startup prend place à cette étape. L’auteur de Running Lean nous donne 2 exemples de types de MVP :

  • Le concierge MVP : vous n’avez pas construit de système et vous effectuez manuellement ce qui sera plus tard automatisé.
  • Le magicien d’Oz : Vous laissez croire à vos utilisateurs qu’il existe un système derrière votre site web, alors que tout y est fait manuellement, à la manière du “mécanisa turk” que propose Amazon !

On en trouve d’autres dans le livre d’Eric Ries.

2 – Product / Market fit

Ai-je construit quelque chose dont les clients veulent ? Le tester avec un panel assez large d’utilisateur n’est pas la même chose que le tester avec trois. Il est temps de voir si le marché existe vraiment !

3 – Scale !

Comment accélérer la croissance ? C’est là que la notion de “moteur de croissance” prends tout son sens.

Running Lean as a startup

Tout cela nécessite bien un petit exemple. Prenons celui de la réalisation du livre : Running Lean !

Problème / solution

C’est ce que l’on appelle un “MVP accidentel”. En l’occurrence le Blog de l’auteur (octobre 2009). Il est démarré afin de documenter ses réalisations en mode startup en utilisant le Lean Startup ! A l’époque, l’auteur avait plus de questions que de réponses, une bonne motivation pour démarrer le blog.
Mais en faire un livre ? Pas question !

Customers interviews

Au fur et à mesure, les requêtes des lecteurs du blog s’intensifièrent pour convertir la série de posts en livre. D’où interviews pour en comprendre la raison. Ah ! C’est pour avoir du contenu qui permette de convertir les principes du Lean Startup en techniques applicables…

En mars 2010, Ash teste les clients potentiels via un teaser. Le nom n’est pas définitif (pas d’optimisation prématurée), mais la table des matière en est un élément important (proposition de valeur). L’objectif est de collecter 1000 emails (clients potentiels) afin de voir si il existe un intérêt sur le marché.

Workshop

Si le teaser est la définition de la solution, alors le workshop est la vérification quantitative.

En Juin 2010, l’auteur teste l’intérêt réel des clients potentiels via un workshop gratuit (small batch), puis payant en Juillet / Septembre 2010 (MVP où le prix est une part du produit).

Pré-order

A partir d’octobre 2010, il prend des pré-commandes pour un ebook en PDF (pas la peine de sortir la version Kindle, il n’y a rien à apprendre en la produisant).
On entre alors dans un cycle de release de 2 semaines. En cours de route, un éditeur manifeste d’ailleurs son intérêt (décliné par l’auteur).

Auto-publication

Elle est opérationnelle en Février 2011. S’en suivra une seconde version produite plus classiquement chez O’Reilly.

Un produit n’est jamais fini, juste “releasé”. D’autres étapes ont encore suivi celle-ci…

Objections !

Nous avons vu ce que sont les 3 étapes dans le cas de startups Web. Quelles peuvent être les objections ? L’approche Running Lean est-elle cantonnée à ces profils d’entreprises ?

B2C

Si je veux toucher 1 million de personnes, quel intérêt il y a-t-il à démarrer une première étape avec 1 à 10 utilisateurs ?
Disons que si les 10 premiers utilisateurs ne sont pas intéressés, il faut certainement changer quelque chose. Inutile de monter en échelle si l’on a pas identifié un problème méritant d’être résolu à petite échelle…

B2B

Les cycles de ventes y sont plus long. 

Ce sont les signes de rejet qu’il faut écouter avant même de commencer à conclure des ventes. Inutile d’engager des commerciaux trop tôt !

Low Tech

Un exemple “local”, c’est à dire à Austin, Texas : La restauration !
Inutile d’investir dans les murs pour tester son concept, c’est à dire la proposition de valeur. Une simple caravane permet de vérifier l’intérêt de la clientèle et en prime de tester différentes parties de la ville pour appréhender celle qui corresponds le mieux au concept.
En gros, voilà à quoi cela ressemble :

Restaurant Trailer

Une fois le concept validé, on peut monter en gamme, donc investir dans les murs !

Hardware

La construction industrielle semble mal se prêter à ce concept. Pourtant il a été mis en oeuvre pour la construction de voitures. Comment ? Simplement en commençant avec un prototype, et en le faisant essayer. Et en itérant !

Unique Value Proposition

Un problème bien exprimé est un problème déjà à moitié résolu !
L’UVP doit se focaliser sur un problème et éviter les promesses marketing vides de sens qui ne sont pas assez spécifiques.
Au contraire, il faut favoriser ce que Ash Maurya appelle “the instant clarity headline”. Par exemple : Youtube = Flickr for video !
Le prix est une partie intégrante de la proposition de valeur. Il ne faut pas hésiter à se comparer à l’alternative, à l’instar de ce que Jack Trout préconise avec son Product Ladder.
Partie complémentaire de l’UVP, le canal de vente est une partie importante qui déterminera si le modèle est scalable

Itérer !

Enfin il ne faut pas se cantonner à un seul canvas, mais au contraire itérer sinon l’on risque de se trouver piégé dans un optimal local. L’UVP doit aller de pair avec le “unfair advantage”, la caractéristique qui ne peut pas facilement être copiée, à l’image du Delivering Happiness de Zappos. Attention, sans cet “unfair advantage”, la proposition de valeur est risquée.

Boire un petit coup c’est agréaaaable !

Première journée terminée. Beaucoup d’informations. Certes, on la retrouve dans le livre en bonne partie, mais Ash Maurya fait un bon boulot pour insister sur ce qui doit l’être et l’illustrer. La partie “workshop” est moins bien gérée : peu de périodes de pratiques, et alors trop longues et peu dirigées…
On se retrouve au bar pour conclure cette première étape.

Bière à la fin de la 1ère journée

Carnet de route : Agile Tour Bruxelles 2013 (2/2)

Lunch break

En gagnant en taille, l’Agile Tour Bruxelles gagne en standing ! Fini les sandwiches, bienvenue au buffet commerce équitable ! La qualité est au rendez-vous, mais l’attente est un petit peu longue. Difficile de d’être parfait en la matière.

atbru13-06lunch02

De mon côté, je ne tiens pas réellement la forme. On sert aussi du potage en Belgique et je trouve en l’occurrence que c’est une très bonne idée. Surtout quand, comme ici, il est excellent.

atbru13-06lunch04

Bref, l’ambiance est au beau fixe. On est bientôt d’attaque pour la seconde mi-temps !

atbru13-06lunch03

Joanne Ho : Agile methodologies for research

Scrum nous enseigne que l’agilité s’applique bien au domaine des projets complexes, mais n’est pas conçue pour les domaines “chaotiques”. J’ai toujours (à tord ou à raison) classé la recherche dans cette catégorie. Joanne Ho nous donne l’occasion d’en savoir plus sur l’adéquation de l’approche agile pour les chercheurs.

atbru13-07joanne-ho02

L’un des points marquants du fonctionnement des chercheurs est qu’ils ne travaillent pas en équipe ! 

Pourtant la recherche est fondamentalement adaptée au mode itératif : étymologiquement cela ne signifie-t-il pas [Re]cherche ?
Pour Joanne Ho, chercheur environnementale, on peut faire une correspondance entre le travail de chercheur (du moins le sien) et Scrum:

  • Le client : c’est la société (au sens large).
  • Le produit : de nouvelles connaissances
  • La Définition de terminé : la pertinence sociale

Enfin oui, Joanne utilise un backlog. 

Un backlog très mouvant, il faut bien le dire, car :

  • Un item peut ne pas aboutir, nécessiter de nouvelles de nouvelles informations et donc être mis en suspens.
  • Il peut générer d’autres items.
  • Provoquer l’obsolescence d’items déjà présent dans le backlog.

Ce sont des choses qui existent déjà plus ou moins dans le fonctionnement des projets agiles. Sauf qu’il est très difficile d’avoir un plan de bataille fixe pour une itération. Donc la plupart du temps, Joanne dépile simplement l’item le plus prioritaire. Ce ne sont sont donc pas des sprints fixes et l’on est plus proche de XP que de Scrum, n’était-ce la présence du backlog…
Mais si on ne sait pas se fixer précisément d’horizon aux itérations, celles-ci gardent-elles un sens ? La réponse est : oui ! Les itérations aident à faire du bon boulot en gardant le rythme. Sans itération, la masse de travail devant soi devient vite déprimante. Les itérations permettent de se voir avancer, de délivrer de la connaissance grâce auxquelles il sera plus aisé de prendre des décisions en connaissance de cause.
Et les rétrospectives ? Mauvaise nouvelle : les chercheurs sont bien trop occupés pour se livrer à cela !

IMG_0121

Joanne Ho nous donne ensuite en exemple un travail récent sur les biogaz. Comment cela s’est-il organisé ?
Traditionnellement, la structure d’une telle équipe serait :

  • Le travail en silo est le standard.
  • Beaucoup de compétition interne.
  • Peu de transparence. Les revues de pair tournent vite aux critiques, voir aux insultes !
  • Les stakeholders sont des personnes imaginaires.
  • Une reconnaissance basée sur la quantité.

Pour cette étude, il a été constitué une équipe pluridisciplinaire, avec un mode de travail en pair et du test de groupe sur les hypothèses. Le processus était le suivant :

  • D’abord comprendre le problème, définir ce que l’on veut tester. Et donc faire l’expérience du stakeholder en allant sur le terrain.
  • Définir l’objectif, en définissant le critère de succès.
  • Une réflexion en binôme, pour modéliser toutes les facettes du problème. Ce travail doit produire des hypothèses.
  • Les tests unitaires, ce que Joanne appelle le “reality check”.
  • L’intégration continue : la mise en commun des éléments.
  • L’acceptance test : Une solution globale acceptable par le stakeholder.

En conclusion…

  • On peut utiliser l’agilité littéralement partout !
  • L’agilité est surtout une attitude.
  • Sans dialogue, on n’aboutit à rien.
  • Se déplacer pour aller réfléchir à différents endroits, sur le terrain.
  • Mettre toutes ses tâches dans un backlog.
  • Travailler en équipe est une chose nouvelle dans les université. ON n’a pas encore de modèle de fonctionnement pour cela.

En définitive, on fait émerger de meilleures questions, on prends d’avantage de plaisir !
La présentation de Joanne Ho reprends les thèmes développé dans son livre sur Leanpub.

Facile à bien utiliser, difficile à mal utiliser

C’était à mon tour, sur le créneau suivant. Pas de résumé de ma session, il ne faut pas pousser, mais la publication de ma présentation très bientôt, et celle-ci sous forme d’article lorsque je l’aurais complété !

IMG_0234

La mesure de mon temps n’était pas non plus excellente. Je vais jouer le joker “état grippal” sur ce coup. Il faut dire que j’avais quand même prévu 20 exercice pour une heure. J’ai probablement été optimiste…

atbru13-08easy-touse01

Domenico Musto : Event-Driven Architecture in Practice

Domenico est venu nous perler d’EDA. Il commence avec un point sur lequel j’achoppe : l’architecture doit être planifiée ! 

Enfin, surtout pour les gros projets d’après lui, et EDA n’est pas pour les petits projets.
Mais pourquoi EDA ? Parce que l’architecture doit être “business drivent” , suivre la structure des flux d’évènements métier. Au contraire, les architectures SOA favorisent l’intégration point à point, aboutissant à un réseau inextricable quand le nombre de composants augmente.

atbru13-09eda04

Les flux EDA ne sont pas nécessairement des messages d’un MOM, c’est surtout un concept logique qui peut se traduire en :

  • Enregistrements d’une base de données.
  • Fichiers
  • Messages d’un MOM (quand même !)

Le support de ces messages, le canal, transmet différents types d’évènements qui peuvent être :

  • Des évènements
  • Des commandes
  • Des doc-messages ; ce dernier type de message est auto-porteur. C’est un paradigme “push” dans lequel le message comporte tout ce qui est nécessaire au traitement par le composant cible. C’est le modèle vers lequel on souhaite se diriger.

L’architecture EDA implique aussi de nombreux corollaires :

  • Le cas des données de référence : Elles doivent être embarquées en partie dans le doc-message. Cela me rappelle un certain nombre de considérations autour du MDM…
  • La consistance (de l’ordre) des identifiants d’évènements : leur ordre est-il garanti ? S’il ne l’est pas, il peut y avoir nécessité de versionner les entités afin d’en reconsidérer l’historique depuis n’importe quel évènement.
  • L’idempotence, ou la capacité à rejouer un évènement. Cette propriété va de pair avec le versionning.

L’architecture EDA se matérialise par un pattern publish-subscribe asynchrone au niveau de l’architecture. Cela n’est pas sans poser certains challenges en terme de tests. Mais dans cet ordre d’idée, une fois la capacité de test acquise, les composants sont relativement indépendants les uns des autres.
La communication à base d’évènements rend aussi possible le business monitoring (le fameux BAM). Par contre les “évènements avec états” sont un autre niveau de challenge. Il est (en partie) adressé du côté des Web Services avec les corrélations, mais surtout avec les moteurs de workflow type BPEL / BPMN 2.0
Terminons avec les infrastructures techniques. Domenico s’est appuyé sur les “reactive extensions” de Rabbit MQ pour implémenter EDA. De mon côté je pense aussi à Storm que nous mettons en oeuvre actuellement…

Clôture et dernier verre !

Il est l’heure de nous rassembler à nouveau pour conclure ce second Agile Tour Bruxelles.

atbru13-10cloture01

C’est de nouveau Bruno qui nous donne rendez-vous aux prochains évènements Belges : XP Day Benelux (le seul, le vrai…), l’Agile Tour Namur … et bien entendu l’Agile Tour Bruxelles de l’an prochain !

atbru13-10cloture03

Comme l’an dernier aussi, les conférenciers ont droit à un cadeau local. Au menu : bierre, confiserie, chocolat et Schtroumph, entre autres…

Agile Tour Bruxelles 2013 : presenter gift

Pas questions de se barrer comme des voleurs à Bruxelles ! L’an dernier, on avait dégainé la bière locale. Cette année on est visiblement monté en gamme (comme je le disais au début).

atbru13-11dernier-verre02

J’avais prévu mon train de retour suffisamment tard pour discuter un peu. Et nous l’avons fait à propos de l’informatique et de l’éducation, de la représentation trop faible des femmes et des minorités dans notre métier en nous demandant pourquoi et en ne sachant toujours pas vraiment y répondre…

atbru13-11dernier-verre08

Il est temps de s’en retourner. Un grand merci à la très sympathique équipe organisatrice. Et à l’an prochain, si tout va bien…

Carnet de route : Agile Tour Bruxelles 2013 (1/2)

Nous y étions tout juste 70 l’an dernier. Cette année, ce ne sont pas moins de 180 badges qui seront distribués aux participants ! L’Agile Tour Bruxelles a pris une nouvelle dimension pour sa seconde édition.

atbru13-01accueil04

Parti à 6h20 de Paris, on apprécie évidemment d’être bien accueillis. Cela semble se vérifier d’année en année en Belgique.

atbru13-01accueil07

Petit café et discussion habituelle entre frenchies avant le début de la première pleinière. Tiens, on se demande bien pourquoi on va jusqu’en Belgique si c’est pour continuer de discuter entre nous.

Un mot d’introduction

Pas de Keynote en Belgique, et donc du coup plus de sessions “au choix” auxquelles participer. On a quand même le mot d’accueil des organisateurs.

atbru13-02ouverture06

C’est Bruno Sbille qui, comme l’an dernier, est le maître de cérémonie. Un excellent choix qui nous permet de goûter son inénarrable “accent Anglais”. Il le précise d’ailleurs lui-même : “I am speaking English right now” !

atbru13-02ouverture04

Cette introduction présentait deux petites originalité. La première était de nous présenter à nos voisins. Sympathique, quoique j’avais un peu l’impression de me retrouver à l’église à souhaiter la paix du Christ au gars situé à ma droite…
La seconde originalité devient plutôt une tradition de l’Agile Tour Bruxellois : chaque orateur est invité à teaser sa présentation devant l’assemblée entière durant une minute ! Une bonne idée, je trouve, qui était déjà présente l’an dernier.
Il est maintenant temps de se diriger vers notre première session !

My Product is a James Bond Movie, par Pierre Neis

“My name is Neis, Pierre Neis” ! C’est ainsi que Pierre débute sa session. Avec lui, le show est assuré ! L’introduction est toutefois un peu longue. Pierre bosse dans une grande compagnie, qui est globale, qui fait de l’agile et améliore ses techniques, et… Mais Pierre n’est pas satisfait !

atbru13-03Neis02

Il manque quelque chose, des choses !

  • Le “fun”.
  • L’excitation
  • La relation directe au client.

Bref, il manque de quoi faire de bons produits. Et de bons produits ne sont pas des produits standards!
Pour Pierre Neis, les bons produits peuvent s’inspirer de la recette des films de James Bond :

  • De gros succès
  • Une trame facile à comprendre
  • Toujours la même recette, en fait.

Et cette recette Pierre nous la décode ainsi : Boom ! => Yeah ! => Yeah ! => Boom !

  • Le premier “Boom” corresponds à l’avènement de la roadmap.
  • Les “yeah” suivants correspondent aux démos (amazing sessions !)
  • Le dernier “Boom” est la release vers le client.

C’est un peu long pour arriver à l’idée finale, mais celle-ci mérite d’être creusée.

Pause du matin

Parmi les petites originalités de cet Agile Tour figurent les pauses: elles ne font pas moins de 30 minutes. Les organisateurs ont en effet acté que beaucoup d’échanges s’y passent qui font la valeur de l’évènement. Ils ont donc rallongé les pauses !

atbru13-04pause-matin06

Produits bio et développement durable au menu de ces interludes.

atbru13-04pause-matin02

Et aussi, bien sûr, échanges entre participants et orateurs.

atbru13-04pause-matin10

Lean Startup for Developers : you can do it to ! Par Sébastien Arbogast

Je me suis tout bonnement trompé de salle ! Ce n’est pas cette session que j’avais sélectionné dans le programme ! Bien m’en a pris, ce fut ma session préférée.

Sébastien nous évoque sa propre expérience de Startuper. Une expérience qui a fini par s’arrêter d’ailleurs, mais qui ne signifie pas que l’orateur n’ait rien appris de valable à nous partager. Bien au contraire. Son expérience commence lors d’un startup week-end en 2011 auquel il s’était inscrit tardivement et qu’il avait préparé à la va-vite. A sa propre surprise … il a gagné ! Ainsi est né Kodesk, l’idée d’un service de partage de bureaux. Une idée qui n’a jamais pris l’ampleur escomptée car Sébastien avait sous-estimé la crainte fondamentale d’accueillir des étrangers au sein des bureaux d’une compagnie ! Mais de cette expérience a germé une autre idée : Peer Trust.
Mais ceci n’était que l’introduction. L’objet de cette présentation est à venir : Est-il possible de créer une startup pour n’importe qui ? Comment faire en appliquant le “lean startup” ?

atbru13-05leanstartup02

Sébastien veut nous convaincre et nous rassurer : NOUS pouvons le faire !

  • On a les compétences : pas besoin d’avoir un MBA !
  • Nous avons les opportunités : il suffit de regarder autour de nous.
  • Nous pouvons avoir les moyens : il existe de nombreuses initiatives destinées à aider.
  • Trop vieux ! Mais non, on n’est jamais trop vieux.
  • Mon idée n’est pas assez bonne. En fait le concept de “l’idée originale” est plutôt surévaluée. Allons même plus loin : l’idée n’a pas de valeur intrinsèque, tout est dans l’exécution.

L’une des choses qui nous effraie le plus est de perdre notre boulot … pour obtenir quoi ? En fait, il n’est pas utile de quitter son travail, en tout cas pas tout de suite. Sébastien nous conseille même d’attendre le plus possible, chose que lui-même n’a pas faite.

Votre produit n’est pas votre produit ! Votre produit est un business model. Et qui dit “business model” dit “business plan”, n’est-pas ? Erreur !

atbru13-05leanstartup05

Mais l’entrepreunariat n’est pas une loterie. En vérité, on commence en ne sachant rien sur nos clients potentiels et il faut avoir le courage de l’admettre. Et d’en admettre aussi le corollaire : on ne fera pas bon du premier coup. C’est un peu comme si on allait rater sa démo Scrum.

C’est tout l’objet du cycle Lean Startup : construire quelque chose pour le valider par le biais d’une mesure. Mais pas n’importe quelle mesure. Plutôt qu’une mesure quantitative (aka l’étude de marché, vous savez, celle avec laquelle le Paic Citron n’aurait jamais vu le jour…) on va chercher une mesure qualitative, donc en fait un (ou plusieurs, mais pas beaucoup) utilisateur avec un problème, et l’on va chercher à le rencontrer en personne !
Pour illustrer la démarche, Sébastien nous introduit la démarche Lean Startup sous forme de pseudo-code. Je ne saurais me livrer au même exercice que l’orateur (il est préférable d’aller voir sa présentation), mais cela donne des choses de ce genre :

IMG_0041

Ou pour résumer de manière plus sibylline:

  1. Revenir au problème (prendre de la distance avec la solution)
  2. Identifier les clients potentiels
  3. Identifier 3 clients potentiels. A priori les plus prometteurs, mais en définitive on fait un peu confiance à la chance…
  4. Pour chaque client, établir un Lean Canvas, celui décrit dans Running Lean (https://freethinker.addinq.uy/post/39835584866/note-de-lecture-running-lean-2nd-edition-par-ash)
  5. Trier les clients par :
  6. “pair level” c’est à dire votre alter égo, celui qui vous donnera donc le plus de feedback
  7. Facilité à atteindre. C’est à dire : puis-je facilement lui parler en direct
  8. Capacité à payer : Ou plus exactement : combien ce client est prêt à payer.
  9. Taille de marché. C’est en fait le dernier critère !

Lister les hypothèses. Attention il ne faudra tester qu’une hypothèse à la fois. En s’aidant, par exemple, du “validation board” (http://leanstartupmachine.com/validationboard/). Attention aux hypothèses ! Les clients potentiels ne paieront pas pour quelque chose qu’ils trouvent simplement “bien”, mais pour quelque chose dont ils ont vraiment besoin ! Sortir du bâtiment, pour aller faire des interviews. Le mieux est de pouvoir faire les interviews à deux, avec un observateur concentré sur la communication non-verbale. Travailler le MVP et le pricing Evaluer la solution proposée ; itérer si nécessaire Obtenir un signup et un paiement

Alors seulement, vous pouvez envisager de quitter votre travail. Mais pas avant : se sentir menacé alors que l’on a pas commencé le business est la meilleure façon de prendre de mauvaises décisions !

See you soon

Vous n’êtes probablement pas encore rassasié de ce Agile Tour Bruxelles ? Nous non plus. En fait, il est l’heure de se rendre au buffet de midi. Nous nous retrouverons très bientôt pour la suite de cette journée !