Note de lecture : The Principles of Product Development Flow, par Donald G. Reinertsen

Note : 8 ; Passionnant et passionnément austère !

Don Reinertsen n’est pas là pour s’amuser. Déjà vers la page 17, l’auteur nous explique que la manière d’appréhender les dimensions économiques d’un produit sont aujourd’hui bien naïve, que la théorie des contraintes de Goldratt est certes un progrès mais qu’elle ne représente qu’une étape intermédiaire, et que nous allons passer en revue tout cela au long de 150 principes que couvre le reste du livre. Oui : 150 ! A ce stade, on pressent que la lecture des 266 pages de l’ouvrage découpé en 9 chapitres va être bien plus longue que prévue. Une impression qui se vérifiera.

Le premier chapitre compte 26 pages. Il sert d’introduction aux 8 autres chapitres, ce n’est donc pas le plus difficile à lire. Et pourtant il fourmille déjà de concepts et d’une description très affutée des problèmes auxquels nous devons faire face lorsque l’on développe un produit. Bref, il campe le décors et for bien !

On a guère pitié du lecteur : le second chapitre sur la « vue économique » est déjà un des chapitres difficiles de l’ouvrage. Mais c’est aussi la clé de voute de ce qui suit, à savoir le coût du délai ! On y parle d’objectifs économiques clés et déjà de la perception économique de la taille des lots intégrant le facteur « coût de transaction ».

Lire la suite

Product Tank #16 : des produits et des jeux

La gamification était bien le thème de cette nouvelle rencontre. Avec 2 interventions très enlevées.

Siffler en travaillant, avec Anna Livia Gomart-Cardin

Anna Livia nous vient du marketing du jeu video, et elle va décortiquer pour nous certains mécanismes du jeu ! Pour commencer, elle distingue 2 notions :

  • « play » : sans règle
  • « game » : avec des règles

Les raisons principales qui nous conduisent à jouer sont aussi au nombre de deux :

  • On est très bon à ce jeu : on joue pour le plaisir, parce que cela met en avant nos compétences.
  • Pour apprendre, acquérir des compétences ; pour une vision de soi une fois ces compétences acquises.

Le jeu, c’est également le fun. Il provient de la vision, du sens que l’on donne à notre travail. Les chants de marins symbolisent l’engagement, le plaisir de l’action. Ce sont 4 types de « fun » que distingue Ann Livia :

  • « easy fun » : un moment sympa, facile.
  • « hard fun » : des moments qui nous grandissent. C’est la raisons pour laquelle on peut faire des mots-croisés, par exemple.
  • « fun social » : pour apprendre des autres
  • « fun sérieux » : des apprentissages qui servent hors du contexte d jeu.
image

Lire la suite

How do you know that your product works ?

Ai-je vraiment « terminé » ?

C’est sur cette notion sur laquelle Kniberg nous invite à nous pencher en premier. Quand est-on « done » ?

  • Quand le code est commité ?
  • Quand le produit est testé ?
  • Quand il est déployé en production ?

Dans ce cheminement, c’est l’utilisateur qui est perdu de vue. Même le déploiement en production ne suffit pas, ni même son utilisation par de véritables utilisateurs ? Car à ce niveau qu’est-il vraiment advenu ? Comment le savons-nous ? Le 0% defect peut-être plus qu’une douce illusion : un manque de feedback ! Ce qu’il nous faut, c’est mesurer la pertinence de notre solution.

Où l’on reparle de valeur

La valeur de la solution que nous fournissons à nos utilisateurs n’est pas une mesure absolue, mais la différence par rapport à l’ancienne solution. La valeur n’est d’ailleurs pas la seule valeur, la souffrance soulagée en est une tout assi pertinente. Et Kniberg nous propose de rapprocher ce niveau de souffrance au niveau de gain : est-il positif ? C’est l’ensemble du tableau qu’il faut regarder.

Pour le prouver, nous avons aussi besoin de mesures. Par exemple, les recommandations, qui montrent que le produit est désirable et non que l’on est coincé avec.

Un produit commence avec une grande idée

Mais au-delà de cette idée, ou plutôt en chemin, nous avons toute sorte de risques.

  • Des risques techniques : avons-nous la technologie pour réaliser notre produit, la maîtrisons-nous ?
  • Des risques sociaux : pourrons-nous faire travailler ces personnes ensemble.
  • Des risques de coût et de planification : pourrons-nous sortir le produire à temps et aurons-nous les fonds pour le faire ?
  • Mais surtout, surtout : des risques business ! Notre produit doit être pertinent, donc désirable.

Henrik Kniberg nous rappelle ainsi 3 exemples de produits qui ont échoué à l’épreuve de la pertinence, pourtant tous issus de Google !

Suis-je en train de construire le mauvais produit ? C’est là la question clé à laquelle le Lean Startup nous invite à répondre afin de vérifier nos hypothèses par le biais de MVP et d’expérimentations.

C’est l’exemple de Dropbox que j’utilise moi-même souvent (et cité dans le livre d’Eric Ries que Kniberg reprend : ici le MVP est une vidéo ! Une vidéo totalement « fake » bien sûr, mais qui a permis de tester le marché à pas cher !

Une technique alternative est le « paper prototyping ».

De l’idée à la mesure

La « pirate metric ». Pourquoi « pirate », car le cri du pirate à l’abordage, c’est AARRR !!

  • Acquisition : Les clients viennent-ils ?
  • Activation : Utilisent-ils le produit
  • Rétention : Reviennent-ils ?
  • Référent : Nous recommandent-ils à leurs semblables ?
  • Revenu : Paient-ils ?

Le tout en forme de « funnel ».

Après le big bang

Par rapport à ceci, le big bang apparait une approche très risquée : on accumule les coûts en différent l’acquisition de valeur (si jamais elle arrive). Le chaos manifesto 2013 nous explique même que limiter la taille et la complexité est le principal facteur clé de succès. Autant pour ceux qui clament qu’il faut faire de l’agilité à plus grande échelle… Pensez plutôt à descaler, à faire de plus petites choses, de plus petits projets… ou de petites releases. Petites releases qui signifient déploiement en production réellement aisé.

A contrario, l’approche « big bang » nous conduit à faire de grosses releases, donc des releases difficiles. Et comme celles-ci sont difficiles, on s’efforcera d’en faire le moins souvent possible… Pour sortir de ce cercle vicieux, il faut faire de la release une routine. Comme on l’a fait il y a 15 ans pour l’intégration

Si quelque chose est difficile, faites-le souvent.

Où l’on (re)parle de la rapidité d’apprentissage

Déployer plus souvent, c’est avoir un feedback plus rapide de ses utilisateurs : c’est apprendre plus rapidement ! Apprendre plus rapidement cous permet de délivrer ce qui a le plus de valeur en premier, et ainsi de « dépasser la courbe d’investissement » tôt dans le cycle, et ceci en sélectionnant nos fonctionnalités de manière plus pertinente.

Nous le savions déjà, ce n’est pas l’occupation que nous devons optimiser, ni même « l’output », ce que nous délivrons, non c’est la valeur que nous délivrons que nous devons optimiser. Et cela ne peut se faire qu’en apprenant de nos utilisateurs. Henrik Kniberg trouve une manière très élégante d’exprimer cela :

Être focalisé sur la réduction de la distance plutôt que sur l’augmentation de la vitesse.

Spotify again

C’est avec Spotify, bien sûr, que l’orateur choisit d’illustrer tout son fil conducteur.

On part d’une idée. C’est le « think it » de Spotify. Pour toucher terre, il faut l’associer à un « narrative » et déterminer les métriques qui nous guideront.

Le « build it » qui suit s’inspire directement du Lean Startup, car c’est d’un MVP qu’il est question.

Le « ship it » met ce MVP entre les mains de l’utilisateur, pour en recueillir le feedback et en tirer les enseignements. On passe du « guessing » aux enseignements.

De ces enseignements, on tire les ajustements ou les changements de direction à opérer. C’est le « tweak it ».

Plus que savoir, c’est s’assurer que le produit fonctionne : en comprenant le problème, en apprenant de nos utilisateurs. Puis en itérant jusqu’à ce que le problème soit résolu.

La captation est de mauvaise qualité hélas, mais suffisante pour entendre le propos de l’auteur lors d’Agile Ceylon en 2014 à Colombo

Note de lecture : Stand Back and Deliver, par Pollyanna Pixton & al.

Note : 7 ; Du modèle de valeur au modèle de leadership.

Pas facile de classer ce livre de prime abord. Finalement, c’est du côté du « Product management » qu’il a le plus sa place. La première chose qui surprend dans ce livre, c’est le titre ! Les auteurs s’en expliquent dans la préface : le point clé du « process », c’est de mettre ensemble les acteurs clés, puis de se tenir en retrait ! La seconde chose qui surprend un peu, c’est la taille de l’ouvrage : seulement 150 pages, qui ne nécessitent guère plus de 7 chapitres.

Le premier chapitre ne compte que 9 pages. C’est une introduction au reste du texte, on y présente dans les grandes lignes les 4 éléments du framework qui feront l’objet des chapitres suivants. Justement le chapitre 2, avec ses 30 pages a trait au premier élément : le « purpose alignment model ». Celui-ci permet de qualifier les éléments d’un portefeuille de projets par rapport aux axes différentiateurs de l’entreprise. Bref, un bel exemple de discrimination par la valeur. Mais surtout un modèle pleinement utilisable tous les jours. Certainement le plus utile du livre !

Le chapitre 3 a trait à la collaboration, c’est l’aspect « stand back » du titre. Ici les auteurs, au long des 25 pages de ce chapitre, nous proposent 3 outils :

  • Collaboration steps : Comment créer le contexte qui va inviter les participants à réellement collaborer.
  • Collaboration process : Comment initier et maintenir une collaboration vers un but défini, où l’énergie est maintenue par les participants.
  • Leading Collaboration : En tant que leader, quel est votre rôle et quelle doit être votre posture pour permettre au projet d’avancer dans la bonne direction ?

Le chapitre 4 consacre ses 25 pages au delivery. Les auteurs y développent le « context leadership model », qui combine incertitudes et complexité pour former 4 quadrants. Un modèle simple mais que je trouve moins utile que le purpose alignment model. Chaque quadrant appelle un comportement adéquat du leader.

Le chapitre 5 développe aussi sur 25 pages la question de la décision. Et celle-ci est directement relative à la question de la valeur. C’est d’ailleurs le modèle de la construction de la valeur qui est au centre de cette partie.

Le chapitre 6, quand à lui, compte 20 pages et s’intitule « leadership tipping point ». C’est donc encore de leadership dont il est question ici, mais il s’agit de la posture du leader par rapport à l’équipe : à quel moment celui-ci doit prendre du recul pour laisser l’équipe opérer. A quel moment peut-il reprendre les manettes pour donner une impulsion nécessaire au projet ?

Finalement, ce sont moins de 10 pages qui sont consacrées au chapitre final faisant office de conclusion. Les auteurs s’y efforcent de mettre les éléments du puzzle ensemble pour en donner une vue aérienne.

Ce texte n’est ni réellement un ouvrage sur le product management, pas plus qu’il n’est consacré au project management. C’est un peu de tout cela à la fois. Je dirais qu’il s’agit d’une boite à outil orientée product management pour le leader de projet. Un projet qui serait, même si les auteurs s’en défendent, plutôt à connotation agile. Une très bonne lecture.

Référence complète : Stand Back and Deliver, Accelerating business agility – Pollyanna Pixton, Niel Nickolaisen, Todd Little & Kent McDonald – Addison Wesley 2009 – ISBN : 978 0 321 57288 2

Stand Back and Deliver: Accelerating Business Agility


https://www.goodreads.com/book/add_to_books_widget_frame/0321572882?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

L’Impact Mapping s’invite au French SUG !

Décidément, cette nouvelle année du French SUG voit émerger une nouvelle dynamique : celle de permettre aux membres de la communauté d’être acteur des évènements ! D’accord, pour l’évènement de février on peut argumenter que je suis un ancien membre du bureau… Mais ce n’est pas le cas de celui-ci . Il a été imaginé par Géraldine Legris, épaulée par Dragos Dreptate.

image

A l’image de la soirée « en finir avec… », cette rencontre prend la forme d’un open-space. Le principe est simple et commence à être bien connu, ne revenons pas dessus. Le thème est encadré, certes. On dispose de 2 créneaux horaires et 3 salles qui seront finalement 4 ! Une restitution en fin de première session, pour la seconde, ce sera autour des pizzas !

La place de marché est rapidement alimentée et il ne reste plus qu’à faire son choix. Pas mal de monde ne connait pas en fait l’Impact Mapping ! Pour toi, cher lecteur, sache que j’avais fait une note de lecture sur le livre éponyme et que Gojko Adzik était venu en parler dans les locaux de Zenika !

Session 1 : un « why mesurable »

Ce point précis est souvent vu comme une difficulté, et s’en est bien une. Mais c’est aussi une aide, car ne pas avoir de mesure signifie souvent que l’on encore dans le moyen et non dans le « pourquoi » ! Un certains nombre d’idés et pratiques remontent rapidement :

  • Le « why » est notre pôle nord, la direction à prendre sans nécessairement devoir l’atteindre.
  • L’impact est notre boussole, qui nous indique si nous sommes dans la bonne direction.
    • Les OKR : Objective Key Results.
    • Les NPS : Net Promoter Scores.

Bien sûr, rapidement la conversation dévie sur des sujets connexes : User Story mapping et le problème de la convergence sur le why… Il est temps de passer à la restitution !

Restitution !

C’est Géraldine qui se charge de la restitution pour le groupe. Inutile de revenir là-dessus.

L’impact mapping de la soirée

Beau challenge que s’était donné l’une des équipes : construire un impact mapping sur la soirée elle-même ! Une sorte de paradoxe auto-référençant… Laurent se charge de la restitution.

La construction de la map a donné lieu à 2 difficultés :

  • D’abord converger sur un même objectif quantifiable. Au final celui qui est choisi me semble sujet à caution. Mais l’exercice est difficile.
  • Choisir dans quel sens construire la map ! Descendant ou montant 

Finalement, l’équipe aura utilisé les deux directions alternativement. C’est en fait ce qu’on fait dans la vraie vie !

Qu’est-ce que l’Impact Mapping

C’était le track « débutant », mais qui manquait un peu de praticiens expérimentés pour aider ! Le group a donc exploré diverses questions liées à l’impact mapping :

  • L’impact Mapping permet de redonner du sens à ce que l’on fait !
  • Comment se positionne l’Impact Mapping par rapport au Story Mapping ?
  • La construction d’un impact mapping conduit à des cycles successifs de divergence / convergence à l’image de ce que l’on fait en Design Thinking. Cette alternance évite l’effet fractal des mind-maps et induit une sorte de « respiration ».
  • Qu’il y a-t-il au delà de l’Impact Mapping ? Les cartes heuristiques ?

Second créneau

Impact Mapping et Lean Startup

L’Impact Mapping et le Lean Canvas sont deux outils qui me semblent pertinents pour donner du sens à ce que l’on construit, de manière agile. Mais sont-ils concurrents ou complémentaires ? Peuvent-ils s’utiliser en association ? Si oui, comment ? Voilà des questions sur lesquelles je reste pour l’instant complètement sans réponse.

C’est pour réfléchir ensemble à cette question que j’avais choisi ce groupe. Hélas pour moi, la session prend la tournure d’un long exposé.

Non seulement la teneur ne m’intéresse pas, mais je viens aux open-space pour échanger : réfléchir, écouter, enrichir les autres de mes idées et m’enrichir de même. Je ne trouve pas cela ici, je fais marcher la « loi des deux pieds » !

Retours d’expérience

Je m’arrête dans la salle où se discutent des retours d’expérience. Plusieurs sujets d’intérêt sont évoqués :

  • Comment sait-on qu’un Impact Mapping est réussi : lorsque les participants ont envie de continuer !
  • L’impact Mapping crée un effet positif important au niveau des conversations et de l’alignement.
  • Il est important de construire une branche complète (avec les 4 niveaux) assez tôt. Ce premier accomplissement soulage les participants.
  • Il faut rester « macro » sur les impacts. Cet outil n’est pas là pour créer des stories détaillées.
  • C’est un outil utile quand on ne sait pas par où commencer !
  • On peut l’utiliser dans les projets qui ont déjà commencé pour consolider ce qui existe, ou pour s’en servir comme outil de communication.
  • Ce n’est pas un outil « fire and forget » : on l’initialise avec de premiers chemins, puis on revient dessus plus tard, à la lumière de ce que l’on a appris.

Fin de soirée

Sans aller jusqu’à dire que la 3ème mi-temps est ma préférée, c’est au moins un moment dont j’essaie de profiter. Discussions avec Frédéric sur les spécifications et l’agilité, retrouvailles avec Sébastien après 8 ans… Il se fait hélas tard…

Le bitcoin sous toutes ses faces !

En cette fin Janvier, le meetup Product Tank nous proposait un programme tout à fait prometteur : 3 invités venus pour nous présenter le bitcoin sous 3 perspectives différentes ! Sébastien Levaillant a fait un travail remarquable pour organiser cela. Travail mal récompensé par une participation plutôt faible : seulement 25 personnes présentes sur les 75 inscrits !

image

Bien sûr, le sujet est moins cliquant que lorsque l’on invite le Product Manager d’un commerce en ligne très en vue. Toutefois le sujet est au moins aussi intéressant, plus même dans ce cas précis, car on se situe là en pleine innovation économique !

Il est temps de s’élancer avec notre premier orateur.

Le Bitcoin, par Stanislas Marion

C’est à Stanislas que revenait l’exercice de nous présenter le Bitcoin ! D’abord qu’est-ce que c’est ? Et à quoi celà sert-il ?

A la découverte du bitcoin

Le Bitcoin, oui c’est une monnaie virtuelle, mais surtout un protocole peer to peer ne nécessitant pas de tiers de confiance, donc pas de banque (d’ailleurs pas toujours dignes de confiance). En cela Stanislas nous présente le bitcoin comme l’avancée la plus importante sur la gestion des comptes depuis la comptabilité à double entrée apparue à la fin du 15ème siècle ! A la différence des autres monnaies virtuelles jusqu’ici, le bitcoin adresse de manière fiable le problème du double spending. Il faut d’ailleurs préciser, pour briller dans les salons qu’il existe 2 bitcoins :

  • Le Bitcoin (B majuscule) : c’est le protocole.
  • Le bitcoin (b minuscule) : c’est la monnaie.

En parlant de protocole, celui-ci s’appuie sur un élément majeur : la Blockchain, la base de données contenant l’historique de toutes les transactions bitcoin. Cette base de données n’est pas centralisée : elle est dupliquée sur tous les noeuds du réseau bitcoin. La validation des transactions se base sur le consensus entre tous les noeuds du réseau bitcoin, en lieu et place du processus basé sur la « confiance ».

image

Minons le bitcoin

Les bitcoins, ça se génère, ou comme l’on dit dans le jargon : ça se mine ! Tout le monde peut miner des bitcoins, en fait cela génère même une forme de compétition entre mineurs. Celle-ci n’est pas anodine car le minage demande beaucoup de puissance de calcul, il s’agit en fait de la résolution d’un problème mathématique dont la difficulté augmente progressivement, environ tous les 15 jours. Finalement « tout le monde » n’est pas le mot juste, le minage demande beaucoup de ressources matérielles (pour « gagner »), de l’énergie aussi car le but est que le minage soit effectivement coûteux, ce qui n’est guère écologique.

Le minage ne sert pas seulement à fabriquer de nouveaux bitcoins, il sert à valider les transactions en les attachant à la Blockchain. Cette Blockchain ne représente pas seulement l’état du marché, mais l’historique complet des transaction. Même si bitcoin permet un certain anonymat, l’argent lui est complètement tracé !

Bref, le bitcoin, c’est :

  • Open-source : on peut tester le code du bitcoin !
  • Décentralisé : pas d’autorité faisant foi. La validation est basée sur un consensus et une connaissance partagée.
  • Une complète transparence des mouvements d’argent : tout le monde peut savoir d’où vient quel montant.
  • Fondé sur des mathématiques solides. Les incentives économiques paraissent saines, du moins jusqu’à présent.
  • Une simplification des risques.

Mythes et état de l’art

Un certain nombre de croyances gravitent aujourd’hui autour du bitcoin. Voyons cela.

  • Les transactions sont gratuites. Ce n’est pas la cas, par contre le coût est encore inconnu car nous sommes actuellement en phase de «  bootstrapping ». La validation des transactions est récompensée par des bitcoins « fabriqués » pour l’instant. Dans 20 ans, quand le bootstrapping sera terminé, il faudra effectivement payer la validation des transactions.
  • Le mining dépense de l’énergie inutilement. En fait la « dépense d’énergie » est la façon de sécuriser le bitcoin. C’est un facteur qui ne peut être fraudé !
  • Les transactions sont anonymes. En fait, on devrait dire qu’elle dépend de notre capacité à nous anonymiser ! Un facteur de moins en moins évident aujourd’hui et qui demande une forte technicité.
  • Le bitcoin c’est sûr car c’est crypté. Non, on peut se faire vider son compte bitcoin ! Un bitcoin c’est une clé privée sous forme de chaine de caractères. Elle figure localement chez vous. On peut s’en faire voler le support physique !
  • Le bitcoin est techniquement supérieur à tout le reste ! En fait son succès est lié au fait que son principe a un sens économique.
image

Tout n’est pas complètement aboutit quand on parle de bitcoins.

La technologie qui l’entoure est encore immature. Son « utilisabilité » est réservée aux personnes avec de solides connaissances techniques. Mais cela change beaucoup depuis un an. Des solutions facilitant la gestion de la sécurité apparaissent. Nous allons en voir une en 3ème partie.

En bref

Très bonne première partie, même si elle est un peu menée tabours battants, pour prendre connaissance des essentiels du bitcoin.

The Bitcoin blockchain, a new way to secure social interactions par Oleg Andreev

Le bitcoin c’est avant tout une nouvelle façon de penser notre présence sur l’Internet.

  • En 2000, la question était : Quelle est notre stratégie Internet ?
  • En 2005, c’était : Quelle est notre stratégie des réseaux sociaux ?
  • En 2015, c’est maintenant : Quelle est notre stratégie bitcoin ?

Une « ligne » bitcoin, c’est essentiellement 4 éléments:

  • Une origine, qui peut être une personne (via sa clé publique) ou un programme.
  • Une signature de la transaction.
  • Une destination, elle-même pouvant être une personne ou un programme.
  • Et bien évidemment : un montant !

Les transactions sont chainées entre elles : le destinataire de la première étant nécessairement l’origine de la suivante. Ainsi la Blockchain n’est pas une construction miraculeuse, elle adresse simplement bien certains problèmes tout en n’étant pas adapté à d’autres. Oleg l’illustre avec le cas d’un achat de places de cinéma :

  • Cet achat est « local », il n’a aucun sens a être connu à l’échelle planétaire.
  • Ce type d’achat est fréquent, on parle de dizaines de milliers de places par minutes à l’échelle du globe.
  • Il n’y a pas de revente. Donc suivre cette transaction dans le temps a peu d’intérêt.
  • La gestion de ce type de vente est centralisé.

A l’inverse de, par exemple, une action boursière, l’achat et la vente de ce type de produit n’ont pas de sens dans l’univers bitcoin.

image

Quand bitcoin redéfinit…

Oui, il redéfinit certaines choses, à commencer par la possession.

Aujourd’hui la possession est définie par l’accès physique, donc également notre capacité à protéger celle-ci, ce qui nous amène vers des considérations de hiérarchies, de lois, etc… Bref comme le dit si bien Oleg : « big guys win ». Toujours.

Avec la Blockchain, la possession est définie différemment, elle est définie par la connaissance : une simple base de données synchronisée partout. 

Le bitcoin redéfinit également la responsabilité : alors détenue par une autorité centrale, elle revient vers l’utilisateur.

Enfin, la Blockchain redéfinit la notion de contrat. Elle n’est plus assurée par un système légal mais par la sécurité intrinsèque du système.

La décentralisation que permet la Blockchain nous projette dans un monde où là où des autorités contrôlant nos échanges seront remplacés par des systèmes décentralisés.

En bref

Oleg nous a un peu surpris, finalement en se détachant du bitcoin lui-même pour se focaliser sur la Blockchain et évoquer toutes les nouvelles perspectives qu’offre cette plateforme, au-delà de la monnaie.

Ledger Wallet par Eric Larchevêque.

C’est bien en parlant de produit que nous allons terminer cette rencontre : Eric, qui est également le créateur de la maison du bitcoin, est venu nous parler de Ledger, une solution simple pour traiter de manière sérieuse les problèmes de sécurité que pose le bitcoin !

image

Pour Eric, le bitcoin c’est aussi et surtout une réinvention de l’identité. On peut désormais avoir une infinité d’identités numériques… à condition de savoir préserver son « secret ». Et cette sécurité est un sujet très complexe.

Ledger se présente comme une solution de sécurité dans un contexte Blockchain. Concrètement, il s’agit d’une smart card (la carte à puce n’a-t-elle pas été inventée en France ?), qui n’est pas une simple carte mémoire, mais un ordinateur complet avec son propre système d’exploitation et particulièrement résistant aux attaques. Cela me rappelle un peu le module de sécurité des concentrateurs Linky …

Cette smartcard n’expose jamais le secret, elle valide elle-même les transactions. En fait, même sa signature RF est indétectable. Nous avons parlé d’une infinité d’identités numériques : Ledger est capable de les générer sur la base d’un générateur d’identités digitales s’appuyant sur un code sur 256 bits, lui-même issu d’un code formé de 24 mots (ceux-là il ne faut pas les perdre).

image

En bref

C’est vrai, cette dernière présentation était particulièrement attrayante. Sans doute parce qu’on nous y montre un produit réel ! Au fait, combien coute-t-il ? pas très cher, en fait : 34 euros !

Il n’y a pas de magie dans ce prix. L’objectif est bien la démocratisation du bitcoin, et cela nécessite au moins deux facteurs :

  • Une simplification de l’usage. C’est l’objectif avoué de Ledger.
  • Un coût d’acquisation des produits et applications de support marginal. D’où le prix !

Alors oui, il va falloir en vendre beaucoup ! Mais Ledger vise aussi le marché de renouvellement avec les technologies émergentes : NFC et même TEE !

Agilité et hospitalité Libanaise

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

image

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

image

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

Bienvenue à l’Agile Tour Beyrouth !

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

image

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

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

image

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

image

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

Pierre ouvre le bal.

Agile the Origin, par Pierre Hervouet

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

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

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

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

Scrum At a Glance, par Joanna Khoury

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

image

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

The Best Way to Convey Information, par Kimberly Samaha

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

image

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

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

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

Extreme Ice breaking

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

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

image

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

Scrum Shu Ha Ri

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

image

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

Agility for Customer Delight, par Mehmet Yitmen

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

image

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

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

Pause déjeuner

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

image

Une petite pause pour dévorer des yeux aussi.

image

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

image

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

Improve your Public Speaking Skills, par Fadi Jeanbart

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

image

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

Carpaccio Game

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

image

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

image

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

Keynote de clôture : Ken Schwabber

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

image

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

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

image

Vous avais-je parlé du charme des Libanaises ?

En finir avec l’Agile Tour

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

image

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

image

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

image

En attendant le retour…

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

image

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

image

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

align=“center”image

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

image

Améliorer la société au Product Tank

Ce nouveau rendez-vous du Product Tank avait aujourd’hui un focus très clair et très particulier : des produits qui n’en sont pas … et surtout qui sont là pour améliorer la société. Nous étions accueillis à cette occasion au John Paul Lounge, un espace ouvert sur les Champs Elysées !

image

Un petit comité hélas pour un sujet pourtant si particulier et une soirée qui s’avèrera riche d’enseignements.

Open Food Facts

Pour ouvrir la soirée, Stéphane Gigandet nous parle d’Open Food Facts. Et Open Food Facts, c’est avant tout une association loi de 1901, avec uniquement des bénévoles à son bord ! D’ailleurs Stéphane ne se définit pas comme un Product Manager, mais comme un « Product Opener » ! Et ouvert, la base de données d’Open Food Facts l’est, car disponible en open data et sous license Open Database !

Le but, ou la mission devrais-je dire, qu’openfoodfacts.org s’est imposée, c’est d’améliorer la transparence sur la constitution des aliments, donc sur la qualité nutritive de ce que nous achetons, en décryptant les labels ! Et avec plusieurs milliers d’additifs en cours sur le marché, il y a du boulot. Surtout que ceux-cis s’efforcent d’être le moins compréhensibles possibles.

image

Notre orateur du jour est informaticien. Il a d’ailleurs développé les outils que propose Open Food Facts. Notamment, l’application mobile permettant la saisie et la reconnaissance des produits. En fait, il semble bien tenir le projet à bout de bras ! L’inspiration du modèle de fonctionnement vient de Wikipedia : utiliser le crowdsourcing pour aider à décrypter les produits. Aujourd’hui la communauté compte plus de 1000 contributeurs.

Au fait, pourquoi « Product Opener » ? Stéphane nous avoue qu’un tel projet ne peut être dirigé. Subordonné au bénévolat, il ne s’étend pas en fonction des besoin, mais des motivations des contributeurs. L’organisation veut cette base d’intérêt public, elle est donc librement accessible via des API JSON. Mais des projets naissent aussi au sein même d’Open Food Facts :

  • Projet de « science citoyenne ».
  • Repérage de produit contenants du lactose ou du gluten
  • Produits contenant de l’huile de Palme
  • Projet d’archéologie alimentaire, etc.

Bref, Open Food Facts, c’est bien plus que le repérage des ingrédients sur l’étiquette !

image

Aujourd’hui, l’ambition s’étend aux produits de beauté, et aux produits en dehors de la France. De grandes ambitions et un bel état d’esprit !

Open Data Gouv, avec Pierre Pezziardi

Pierre est quelqu’un qu’il est facile de croiser dans différentes communautés, par Exemple, à Agile France. Aujourd’hui, il vient nous parler d’Open Data Gouv, un projet dans lequel il est pleinement impliqué. A la base, il s’agit d’un projet de référencement des données libres. La première question qui s’est posée est : comment évaluer le succès. Par le nombre de réutilisations, par le nombre de personnes réutilisant ces données ! C’est une direction qui a induit la voie suivie par le site qui est passé d’un CMS a un réseau social, et s’est efforcé de suivre les canaux d’engagements.

Cette plateforme s’est voulue résolument en rupture avec les règles établies de l’administration, d’où la nécessité de la créer en dehors d’elle ! Car on ne peut innover dans la structure, on ne peut qu’y reproduire ses codes. Au contraire du principe de méfiance qui prévaut dans l’adminsitration, tout ici est basé sur la bienveillance avec un contrôle à postériori, car les utilisateurs peuvent publier leurs données ! Ils peuvent même reprendre les bases de l’administration pour les rendre plus exploitables ! En pratique, il y a peu de spam.

image

Le co-design est aussi un pilier important de ce travail. Il permet essentiellement deux choses :

  • Engager les personnes dans la création du produit. Celui-ci étant développé selon un cycle Lean Startup.
  • Régler le problème du « démarrage à froid » propre aux réseau sociaux : lors de l’ouverture des portes, il y a déjà beaucoup d’inscrits !

Pour autant, beaucoup d’obstacles se dressent :

  • Ouvrir les portes de l’entreprise pour y mettre l’utilisateur, voilà qui n’est pas naturel !
  • Certaines organisations ont transformé le monopole sur certaines données en rente économique … quand bien même celles-ci sont de mauvaise qualité !

Le but d’opendata.gouv et de libérer les données, inviter tout un chacun à y contribuer, bref faire jouer le crowdsourcing à l’image d’openstreetmap.org ou d’openfoodfacts.org que nous venons de voir. On ne peut avoir des référentiels larges et profonds seuls, il est indispensable de mener ce travail collectivement.

Un point réccurent du raisonnement de Pierre est la recherche des « irritants », il appelle ainsi des problèmes qui se répètent sans arrêt. Ces irritants sont l’occasion de développer de nouvelles possibilités. C’est ainsi qu’est né le Marché Publique Simplifié.

En conclusion

Nous avons eu la chance d’avoir deux interventions non seulement très vivantes, mais aussi très riches. Bien sûr, pour Pierre, on savait déjà. Cela dit ce meetup se distingue surtout par son thème éthique : faire du bien à la société, apporter une destruction créatrice.

Sur ce, je dois me sauver, une Scrumbeer (ou ce qu’il en reste) m’appelle…

Note de lecture : Specification by Example, par Gojko Adzic

Note : 8 ; La référence sur le développement guidé par les tests. Book of the year 2014 !

Régulièrement, je retarde le moment d’ouvrir un livre que je sais excellent (de réputation) et qui prend la poussière sur une de mes étagères. Ce livre est de ceux-là ! Bien que Manning nous gratifie de temps en temps de titres non-techniques, il est assez étonnant de trouver celui-ci chez cet éditeur, probablement parce que ce n’est pas un livre pour remplir un vide thématique.

Il s’agit bel et bien d’un texte nous proposant un regard novateur sur les tests d’acceptance, même si l’auteur rappelle régulièrement au fil des pages qu’il fait suite à son ouvrage précédent « The Communication Gap ». Ce n’est pas non plus un livre très facile à lire, non qu’il soit volumineux car il ne compte que 250 pages, mais il s’appuie essentiellement sur de nombreux témoignages qui transforment le fil conducteur en une sorte de patchwork. Evidemment, ces nombreux témoignages qui sont autant de cas d’étude font beaucoup pour la crédibilité du texte qui est ainsi à la fois un travail digne d’un universitaire et l’œuvre d’un praticien de terrain. Venons-en au contenu.

L’ouvrage se découpe en 3 parties inégales. La première d’entre-elles ne compte que 60 pages réparties en 4 chapitres. Le premier chapitre nous laisse un peu dans le flou, il s’agit surtout d’un argumentaire étayé de témoignages sur la raison de s’intéresser à la spécification par l’exemple. On rentre dans le dur au chapitre suivant qui aborde la manière dont Gojko Adzic voit s’articuler le besoin depuis les « business goals » jusqu’à la « documentation vivante ». Les aspects amont sont par ailleurs l’objet de son ouvrage suivant « impact mapping ». On y apprend incidemment pourquoi l’auteur préfère « spécification par l’exemple » à « développement guidé par les tests d’acceptance ». Un chapitre à ne rater sous aucun prétexte ! Le chapitre 3 « living documentation » offre pour moi peu d’intérêt, sauf peut-être celui de couvrir le schéma de processus que l’auteur nous a exposé au chapitre 2 ? La spécification par l’exemple ne se veut pas une pratique spécifique aux projets agile, bien que ce soit un terrain de jeu naturel. Au chapitre 4, l’auteur aborde différentes façon de basculer d’un projet classique à l’écriture des tests en amont sous forme de patterns (bien qu’ils n’en empruntent malheureusement pas la forme).

La seconde partie est la plus imposante du livre, avec environ 130 pages et 6 chapitres. C’est le cœur de l’ouvrage. Les 11 pages du chapitre 5 « deriving scope from goal » sont un prélude à « impact mapping » et on y retrouve les mêmes thèmes. Je ne peux qu’en recommander la lecture. Le chapitre 6 est un de mes thèmes préférés car on y évoque la spécification collaborative. Tous les patterns de cette vingtaine de pages valent de l’or. J’applique déjà certains d’entre eux mais trouve ici des éléments pour m’améliorer. Encore un chapitre à ne pas rater.

Les deux chapitres suivants sont au cœur de l’ouvrage. Le chapitre 7 aborde l’écriture même des tests, comment les concevoir, comment les penser pour couvrir une spécification. Là encore ce sont des patterns desquels se dégage une stratégie claire et précise : sur la conception des tests, des cas passants et non passants, des données de test et des exigences « non fonctionnelles » ! Le chapitre 8 est un approfondissement du précédent, avec un accent mis sur les antipatterns.

Il était probablement difficile de parler de ce sujet sans évoquer les questions d’automatisation. C’est ce que font les 2 chapitres suivant. Le chapitre 9 évoque les options techniques d’automatisation y compris l’épineuse question des IHM. Le chapitre 10 se préoccupe surtout de l’intégration de ces tests dans des plateformes d’intégration et des stratégies possibles : isolation des systèmes tiers, plusieurs niveaux de validation, etc. Le chapitre 11 qui clos cette partie reprend le thème de la « documentation vivante ». Les patterns n’y sont pas sans intérêt, mais il reste le chapitre le plus léger de cette partie.

La Troisième partie est consacrée aux études de cas, c’est à dire les projets principaux (pas tous) qui ont donné la matière au livre. Des 7 chapitres qui la compose, 6 sont consacrés à ces études de cas sur 40 pages. J’ai eu du mal à me passionner pour cette partie. Y sont exposés les challenges auxquels ces différents projets ont été exposés à leur passage à le spécification par l’exemple, pourquoi ils l’ont fait et ce qu’il y ont appris.

Le dernier chapitre du livre nous livre les conclusions de l’auteur. L’une des plus importantes me semble être le passage d’une pratique des tests basée sur la défiance (coûteuse et inefficace), à une dynamique basée sur la collaboration et la confiance. Pas étonnant que cette pratique marche mieux en milieu agile.

L’ATDD ou plutôt la spécification par l’exemple est aujourd’hui ce que je considère comme un des plus forts effets de levier pour un projet agile, une fois acquis les pratiques d’ingénierie. L’auteur aborde les différents aspects (collaboration, processus, écriture et conception) avec un regard aiguisé que corrobore des données de terrain. En le lisant, je suis passé du « waouh effect » au « mais bien sûr » jusqu’à « ah oui, c’est ce que je fais et ça marche du tonnerre ». Cet éventail de réactions me rappelle la lecture du Design Patterns. Une autre façon de dire que je pense qu’il s’agit là d’un texte majeur !

image

Référence complète : Specification by Example, How successful teams deliver the right software – Gojko Adzic – Manning 2011 – ISBN : 978 1617290084

Specification by Example

https://www.goodreads.com/book/add_to_books_widget_frame/1617290084?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on