Agile Game France 2014 en images (4/4)

Dernier volet de notre périple de 3 jours, ce post conclut mon retour sur l’Agile Game France dont vous retrouverez les opus précédents ici, ici et ici.

Rétrospective

Nos scribers sont réellement talentueux, voici ce à quoi ressemble désormais notre fresque

image

Et les voici à l’oeuvre.

image

Certains devant partir tôt, nous n’attendons pas le dernier moment pour nous livrer à une rétrospective de l’évènement. Elle s’effectue en 3 groupes, Jacques facilite le nôtre.

image

On prends très peu de temps, juste ce qu’il faut pour identifier un point d’amélioration.

image

La restitution se déroule tout aussi rapidement.

image

Tombola

Toujours dans le thème “je conclue l’Agile Games France en beauté”, il y avait une petite tombola pour gagner des polos. Il n’y en avait pas pour tout le monde ! En fait, il n’y en avait que 3 : tailles M, L et XL respectivement. Comme vous pouvez le voir de dos ici.

image

Et les gagnants sont : Alfred, Michel et … moi-même ! Le sort m’est généralement défavorable, c’est bien sympa que les choses ait tourné dans le bon sens justement aujourd’hui !

image

Et nous reste juste le temps pour 2 ateliers assez rapide.

Le jeu du Tao

Ce jeu avait été animé hier par Romain Couturier. Il avait été apprécié et une seconde session a eu lieu dans la matinée, mais animé cette fois par des participants de la session précédente. Alfred s’était tout d’abord proposé d’en animer une 3ème session, puis avait finalement décidé de remplacer cela par un retour sur ce jeu. D’abord déçu, j’ai vite compris qu’il ne se sentait pas armé pour une animation.

image

D’ailleurs, le jeu n’en est pas vraiment un, avec un livret qui ressemble plutôt à un annuaire et un contenu plus proche de la psychanalyse de groupe que du bon moment de détente ! Je trouve d’autant plus remarquable la prestation de Romain dont j’ai eu d’excellents echos qui se livrait à cette animation pour la première fois !

image

La chose mérite donc un peu de réflexion avant de s’y lancer tête la première. Tao Village propose des initiations, peut-être à essayer…

The Lean Takeoff

Alfred Almendra s’est donné un gros challenge : illustrer l’amorçage d’un cycle Lean Startup à l’aide d’un jeu ! Le jeu se focalise sur le “fit” entre le problème et la solution et tourne autour de cycles d’expérimentations. En l’état, le jeu ne me semble pas convainquant. Nous avons donné du feedback à Alfred pour lui donner des idées d’évolution.

L’exercice de construire un jeu autour de cette idée me semble vraiment très difficile. Je ne me vois pas relever le challenge. Je ne peux que souhaiter bon courage à Alfred (qui n’en manque pas par ailleurs) pour faire aboutir son idée !

Cloture

Cette 3ème édition d’Agile Game France se conclut maintenant.

image

Mon regret le plus important est d’avoir surtout été consommateur lors de cette édition, ce qui ne me convient guère ! Au départ je voulais présenter la version 2 du Business Value Fail que j’avais développé conjointement avec Yannick Ameur et présenté lors d’un Agile Playground. Mais j’ai été trop occupé pour mener à bien mon projet ! J’ai donc au moins deux objectifs pour l’an prochain (car oui, j’ai bien l’intention d’en être à nouveau !) :

  • Proposer l’animation d’au moins 1 jeu.
  • Mettre en place le Kanban des sessions que nous avons proposé lors de la rétrospective.

Un évènement comme celui-ci, c’est plutôt à la base pour les extravertis. Etant une sorte d’introvertis de compétition (si, si je vous assure), ce ne devrait pas être un lieu où je serais particulièrement à l’aise. Et poutant ! Pourtant, j’en suis ressortis gonflé à bloc avec des idées. Il faut dire que l’évènement garde son caractère bon enfant, détendu et bienveillant. Je ne peux comparer à l’an dernier, mais le lieu se prêtait plutôt bien à nos activités : 2 salles avec l’utilisation du palier, cela nous permettait 5 activités en parallèle, voir plus !

Pour terminer, je me dois de saluer la famille Siber venue au complet. Pas évident de venir avec un enfat en bas âge, mais ils l’ont fait !

image

Et bien entendu un grand bravo et merci aux artisans de cette évènement auto-organisé !

L’agilité à grande échelle chez Spotify, par Henrik Kniberg & Anders Ivarsson

Dans cet article, les auteurs décrivent la façon dont Spotify est parvenu à maintenir une dynamique agile malgré une montée en taille importante et rapide sur les 6 dernières années. Elle s’appuie sur un petit nombre de concepts organisationnels

Les squads

A mi-chemin entre la Scrum Team et la Feature Team, le squad est doté d’une mission sur le long terme, possède un espace de travail en propre et regroupe toutes les compétences nécessaires à sa mission. Son mode de travail s’inspire du Lean Startup, mais ici on appelle cela “think it, build it, ship it, tweak it”. Les squads bénéficient aussi des 10% hack days inspirés des 20% ou des exploration days de Jurgen Appelo (c’est la même chose).

L’objectif, sinon la clé est d’avoir des squads autonomes.

Les tribus

Les squads sont nombreux : il y en a 30 chez Spotify. Ils sont regroupés en tribus. Une tribu est focalisée sur une problématique métier particulière est fonctionne un peu en “incubateur de startup”. Elles sont de taille variées mais ne dépassent pas 100 personnes.

Les tribus organisent leur propres rassemblements et partagent outils, idées, etc… 

Les chapitres

Ce sont des regroupements “transverses” de personnes de même domaine d’expertise. Ils se rencontrent régulièrement pour partager outils, expérience, challenges, etc.. Chaque chapitre est géré par un manager qui est de fait le responsable hiérarchique de ses membres … mais est lui-même membre d’un squad avec des responsabilités opérationnelles ! Les chapitres sont locaux aux tribus.

Les guildes

Ce sont des communautés d’intérêt, plus informelles que les chapitres. Elles sont transversales à l’entreprise et regroupent souvent les chapitres correspondant des différentes tribus. L’animateur d’une guilde l’est à temps plein. 

Là aussi, la lecture du Management Workout de Jurgen Appelo peut être instructive…

L’organisation dans son ensemble

Elle est en quelque sorte matricielle. La dimension dominante est celle du “quoi”, l’axe opérationnel, donc les squads et les tribus. Il y a une seconde dimension, celle du “comment” qui correspond aux chapitres et aux guildes.

Et bien d’autres choses…

Voilà, il s’agit juste de l’apéritif pour vous encourager à lire cet article par ailleurs fort bien écrit et illustré. Il y a de nombreux éléments que j’ai passé sous silence, comme la gestion des dépendances entre les squads.

Spotify est une entreprise dont la structure dominante est tournée vers l’opérationnel. Elle rompt avec les structures traditionnelles orientées compétences qui fragmentent l’organisation en silos, obligeant les projets à franchir les obstacles entre ces silos, consommant temps et énergie et souvent aussi hélas, vidant les projets de leur substance !

User Stories … What else ?

Voici le support de ma présentation, faite lors d’Agile Grenoble 2013. Elle aborde le sujet épineux de l’emprunt de techniques issues du monde non-agile dans nos projets agiles !

Le teaser

Les users stories sont rapidement devenus la formulation convenue du besoin. Mais est-ce la seule ? Est-ce toujours la meilleure ? On dit que quand on a un marteau, tout ressemble à un clou. Notre communauté agile tend à ignorer ce qui vient d’ailleurs. Pourtant ce qu’on appelle l’ingénierie des exigences est un domaine riche de plusieurs décennies de connaissances et de techniques. Certaines peuvent être utilisées directement, d’autres doivent être adaptées ou peuvent servir d’inspiration.

Cette présentation va nous permettre d’étudier ensemble plusieurs techniques et concepts du recueil des besoins et les regarder par le prisme de nos pratiques agiles. A l’aide d’exemples, nous verrons comment elles peuvent renforcer nos pratiques actuelles.

Ce que vous allez en retirer

Découvrir l’ingénierie des exigences, prendre conscience de la profondeur de ce domaine de connaissance. A la fin de cette session les participants auront des clés pour enrichir leur maitrise de la capture du besoin en s’alimentant hors du champs de l’agilité, et j’espère le goût de le faire !

Si j’ai assez de courage, je produirais cette présentation sous forme d’article. Mais alors pas avant Janvier !

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…

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

Note de lecture : Business Model, nouvelle génération par Alexander Osterwalder & Yves Pigneur

Note : 9 ; Une approche disruptive du marketing tourné vers l’innovation. Un contenu de qualité qui devrait faire partie du bagage de base. Book of the Year 2013 !

Voici un ouvrage qui ne ressemble à aucun autre. Contrairement à mon habitude, j’ai acheté la version française, sans qu’il n’y ait de raison à cela. Visiblement la qualité de la traduction ne compromet pas le contenu. Une bonne nouvelle ! La chose qui frappe le plus lorsque l’on feuillette ce livre au format très inhabituel est la mise en page sophistiquée où chaque page semble être une maquette. En fait, on a même l’impression d’être face à une plaquette marketing, ce qui fait craindre que le contenu ne soit pas à la hauteur des espérances…

Coupons court au suspens : cette crainte est infondée. En fait la mise en page accentue et supporte le contenu. Mais il est temps de parler de ce dernier. Le livre (je n’ose dire « le texte ») compte 280 pages regroupées en 5 parties principales.

La première partie constitue la fondation du reste, car elle présente l’outil de base de l’approche Business Model Generation : la canevas. Les auteurs suggèrent ainsi, plutôt que de produire de lourds et fastidieux business plans de produire un canevas sous forme de poster découpé en 9 aires. Les 50 pages de cette première partie sont consacrées à décrire ces 9 aires.

La seconde partie montre 5 typologies de business, exemples à l’appuie et montre comment ces typologies se présentent dans la canevas. Une excellent façon d’illustrer et comprendre l’utilisation du canevas.

La 3ème partie, « design » s’éloigne un peu du Canevas pour s’intéresser aux techniques d’innovation permettant la génération d’idées. Ce sont 6 techniques qui sont passées en revues au long de 70 pages consacrées à cette partie : connaissance du client, design thinking, story telling, prototypage, etc… Chacune de ces technique est un champs de connaissance à part entière, mais la façon dont chacun d’entre eux est traité en fait une excellente introduction.

40 pages (seulement, pourrait-on dire) sont consacrées à la stratégie qui constitue la quatrième partie du livre. On y couvre la compréhension des éléments environnementaux (forces du marché, forces du secteur, tendances et forces macro-économiques), l’évaluation des modèles économiques basée sur le SWOT, la stratégie « océan bleu » et le support de plusieurs modèles économiques. Finalement, beaucoup de matière en si peu d’espace !

La cinquième partie parle processus de création du modèle économique. Celui-ci se décline en 5 phases : mobiliser, comprendre, concevoir, déployer et gérer.

Il n’y a pas une forces, mais des forces dans ce livre, qui en font à mon avis une lecture incontournable.

La présentation du Business Model Canvas. Celui-ci a été depuis repris et adapté par Ash Maurya et présenté dans son ouvrage : Running Lean. A vous de voir celui qui vous paraît le plus adapté.

Chacune des parties aborde une face importante de la construction du business model et est elle-même structurée en différents volets articulés entre eux. C’est presque comme si l’on avait 5 livres en un seul ! De nombreux sujets sont traités et le livre en est une excellente introduction. Il est toujours possible de creuser chaque sujet avec des contenus spécialisés.

La construction graphique du livre avec sa mise en page sophistiquée en font un outil pédagogique d’une rare efficacité.

Le seul défaut que je vois à ce livre est la fragilité de sa reliure ! L’objet est donc hélas à manier avec précautions (et/ou à ne pas prêter à tout le monde). Cette réserve mise à part, la conclusion ne fait aucun doute : un livre à lire ! 

Business Model Genaration

Référence complète : Business Model, nouvelle génération – Alexander Osterwalder & Yves Pigneur – Pearson education France 2011 (V.O . : Business Model Generation ; John Wiley & sons 2010) – ISBN : 978-2-7440-6487-6

Business Model Nouvelle Génération: Une Guide Pour Visionnaires, Révolutionnaires Et Challengers


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