lundi, avril 25, 2016

Le SelfLean et l’art d’attendre



Le billet de ce jour est une réflexion personnelle sur l’efficacité du collaborateur dans l’entreprise, à travers le prisme des principes du lean management, dans la lignée des billets précédents : « SelfLean : l’efficacité systémique individuelle ». C’est un sujet personnel, car ma première source d’inspiration est l’analyse des causes de l’inefficacité du travail collaboratif dans les entreprises que je peux observer, à commencer par mon propre travail. Mon premier billet sur l’application des principes lean à la gestion des emails date de 2007, comprendre l’inefficacité systémique n’est pas une chose simple. Je parle de l’efficacité du « knowledge worker », que je pourrais aussi appeler « cerveau d’œuvre » en référence aux travaux sur l’iconomie (voir par exemple Michel Volle ou Jean-Pierre Corniou). Je vais commencer par un résumé des principes du « self lean » dans la première section.

Si je reprends la plume sur ce sujet à nouveau, c’est que je perçois une tension. D’une part, les principes du lean thinking sont très pertinents pour optimiser les processus collaboratifs et les flux de matière grise. Ce n’est pas par hasard si le processus d’innovation du Lean Startup fait référence au lean. Je suis même de plus en convaincu qu’il existe un véritable enjeu de qualité de vie, ce qui sera l’objet de ma seconde section. Travailler en mode lean, au sens du Toyota Way, réduit le stress (ce qui n’est évidemment pas le cas du « lean » mal compris comme élimination des marges de manœuvre). En revanche, et c’est la tension que j’évoquais, le cerveau d’œuvre est soumis à un flot stochastique, voire chaotique, de demandes, avec des caractéristiques profondément dynamiques (la priorité, le contenu, le contexte associé à chaque demande évoluent de façon continue). Cela invalide certaines pratiques et techniques du lean, tout du moins si on les prend de façon littérale. Ceci va être l’objet de la troisième section de ce billet. Je vais me tourner vers le Yield Management comme source d’inspiration, pour proposer une gestion de classes de services qui n’est pas sans rappeler le Heijunka. Un titre plus prétentieux pour ce billet aurait pu être « Self-Lean, Yield Management et Heijunka » - un bon sujet à explorer : la combinaison de « lean thinking » et « yield management » est très peu représentée sur le web.

J’ai préféré évoquer l’art d’attendre dans mon titre car il s’agit d’un autre débat, plus accessible, sur l’attente dans l’approche lean. Le lean propose une véritable dualité au sujet de l’attente : il proscrit les attentes inutiles pendant l’exécution, mais il propose – logiquement - de « partir » le plus tard possible, au « bon moment » dans un flux tiré. Le fait d’attendre « le dernier moment » pour démarrer est systématiquement utile dans un contexte très changeant. En revanche, la notion de « pause » semble antithétique avec le lean, je me souviens de débats houleux il y a une dizaine d’année avec des consultants lean. Pourtant, prendre le temps de s’arrêter pour réévaluer le contexte, obtenir un feedback, murir une intuition, n’est pas forcément un gaspillage (« muda »). En particulier, dans une processus d’innovation, il existe un temps long pour l’incubation des idées et la caractérisation des problèmes à résoudre, qui n’est pas incompatible avec le temps court et sans attente du développement du « Minimum Viable Product » du Lean Startup. Cette réconciliation du lean avec le temps long sera l’objet de la section 4.


1. Le «Toyota Way » appliqué au cerveau d’œuvre



Je vais commencer par rappeler brièvement les grandes idées du SelfLean, développées ailleurs dans ce blog, à commencer par un des premiers billets sur le sujet. Il s’agit simplement de réinterpréter les principes du Toyota Way dans le contexte du knowledge worker :
  • Eviter la décomposition avec attente pour aller au contraire vers le « streamlining », l’exécution en flux continu. Un des premiers principes lean est de maximiser le rapport « temps utile » / « temps total », il s’applique parfaitement pour le cerveau d’œuvre. L’exécution en flux continu apporte un double bénéfice : éviter des temps d’attentes inutiles et éviter des temps de « reprise de contexte », équivalents aux temps de changement d’outil dans une chaîne de production. Un temps d’attente est lui un double gaspillage (muda) : c’est une exposition aux aléas (plus on attend plus la probabilité d’une désynchronisation avec le contexte de la demande augmente) et une charge mentale inutile. La pratique de la visualisation du « work in process » sert précisément à alléger cette surcharge.
      
  • Utiliser le « pull » plutôt que le « push » : définir l’ordonnancement des tâches en fonction du consommateur et non pas du producteur. C’est probablement la révolution la plus importante pour un knowledge worker : apprendre à synchroniser sa production avec l’usage de ses consommateurs au lieu de se caler sur sa propre disponibilité. C’est un des apports clé du Kanban dans les processus de coopération, à commencer par la production logicielle. On retrouve toute l’importance de la synchronicité, par opposition au travail asynchrone qui n’a que le vernis de l’efficacité (précisément lorsque la complexité fait que les coûts de resynchronisation explosent les gains que l’asynchronisme permet du point de vue de l’ordonnancement).
      
  • Éliminer tout ce qui ne produit pas de valeur pour le client, le « muda ». Cette pratique est parfaitement transposable dans les activités du knowledge worker, au delà de la traque des temps d’attente que nous venons d’évoquer.  Les temps de recherche, de changement de format, de classement, sont des opportunités d’optimisation en utilisant des outils tels que les 5S (qui se transposent aussi bien dans le domaine du logiciel que du travail du cerveau d’œuvre).  On pourrait d’ailleurs étendre cette remarque sur les 5S à l’ensemble des pratiques de « management visuel individuel» qui trouvent également leur place chez les cerveaux d’œuvre – ainsi que la pratique des « cinq pourquoi » - pour les mêmes raisons : le besoin de maîtriser la complexité de l’environnement par l’apprentissage continu.
      
  • Pratiquer l’exigence « right on the first time » : le lean s’attache à éviter les erreurs, dont la correction coûte plus cher que la prévention. Une des plaies des projets informatiques ou de développement de produits est le « rework », lorsqu’on refait plusieurs fois la même chose. Ce n’est pas limité à l’informatique, le « rework » est un symptôme de la complexité des organisations. Une des principales erreurs lorsqu’on pratique les méthodes agiles est de confondre vitesse et précipitation : pour faire bien et vite, il faut faire peu (d’où l’importances des « small batches »). 
L’application de ces principes dans des processus de « matière grise » a été abordé de multiples fois dans ce blog. Lorsqu’il s’agit d’un processus d’innovation, on retrouve les fondations du Lean Startup. Lorsqu’il s’agit de développement logiciel, on retrouve certains principes élémentaires de la « Lean Software Factory ». Bien sûr, il s’agit d’une liste partielle puisqu’elle est concentrée sur l’individu, et qu’elle laisse de coté – volontairement - la dimension essentielle du lean, le travail d’équipe (le kaizen, l’apprentissage collectif, le management visuel collectif, etc.).

2. Le Self Lean et la qualité de vie


Les principes du lean sont avant tous des principes d’efficacité systémique, dont l’objectif est d’améliorer la performance de l’ensemble de l’entreprise, mesurée au travers de la satisfaction client. Il se trouve que ces principes améliorent grandement la qualité de vie des collaborateurs, d’un point de vue individuel. Une partie de cette appréciation est probablement subjective et personnelle … je ne vais pas trop détailler, la suite se trouve dans les classiques de l’efficacité personnelle, tels que le célèbre : « Getting Things Done » ou « The 7 Habits of Highly Effective People ». Je souhaite néanmoins souligner quatre bénéfices fondamentaux de la pratique du SelfLean pour le cerveau d’œuvre :
  • La pratique du SelfLean permet de rester agile, de savoir saisir une opportunité et de démarrer rapidement sur une nouvelle demande réellement importante. C’est la conséquence systémique d’un taux de charge sous contrôle. Je vous renvoie aux articles plus anciens pour faire le lien avec la théorie des files d’attentes ; ce qui m’importe ici au delà de l’efficacité collective, c’est le bien-être que procure la sensation d’être en contrôle de son agenda, par opposition à la situation de stress « de ne pas pouvoir faire face aux demandes » dont nous savons qu’elle constitue la cause première des « burn outs ». C’est, selon mon expérience, le premier bénéfice de la maîtrise visuelle du « WIP ».

  • L’utilisation du Kanban permet de retrouver le sens du travail coopératif, en s’assurant à la fois de la disponibilité, de la réactivité et de la synchronicité de son propre travail par rapport aux attentes des autres. La frustration de terminer dans l’urgence et dans l’effort un rapport qui n’est ensuite lu que fort tard, de façon partielle parce qu’il est trop long et par une petite partie des destinataires est malheureusement trop courante dans nos organisations Tayloristes. Je dois pour ma part à un déjeuner d’été lorsque j’étais DSI avec Philippe Montagner le moment ou j’ai pivoté : considérer son travail du point de vue de la valeur délivrée aux autres et non pas du point de vue de ce qui est produit change radicalement la définition du « knowledge worker ».

  • Si l’on prend au sérieux l’exigence « right on the first time » ainsi que l’exécution en flux continu, on retrouve très vite un des principes de Google « Do one thing really, really well ». Le cerveau d’œuvre travaille mieux lorsqu’il fait une seule chose en y affectant la totalité de son énergie. Il y a plein de bonnes raisons évidente pour promouvoir ce principe du point de vue de ce qui est produit, mais il y a un autre bénéfice non moins important : c’est une garantie contre la surcharge, et le stress qui en résulte. Il est frappant de voir que nous avons tous fait l’expérience d’un « off-site » pendant lequel la concentration sur un seul sujet a produit des miracles, alors que cette pratique est souvent immolée sur l’autel de « l’efficacité ».

  • Le lean promeut la décision et l’amélioration continue fondées sur la mesure, et donc l’auto-observation (évident dans le cas du Lean Startup ou du Lean Software). C’est ici que le « standard » (au sens de Michael Ballé – lien) prend tout son sens. Un des bénéfices systémiques du « standard » est de permettre la capitalisation et l’objectivation de l’amélioration continue. Du point de vue de l’individu, c’est également un formidable outil de réduction du stress. Le knowledge worker a souvent tendance à sous-estimer un certain nombre de ses tâches (en particulier la relecture, qui demande du temps et des efforts) et il se trouve logiquement dans une situation de sur-promesse. La combinaison du standard (savoir combien il faut de temps pour écrire le premier jet, terminer la rédaction, relire ou valider, un document de 1,3 ou 10 pages) et du « management visuel personnel » permet d’éviter les promesses non tenues et le stress qui en résulte (ou qui devrait en résulter … si ce n’est pas le cas, c’est qu’on est passé en mode bureaucratique chaotique).
C’est le bon moment pour répéter que la science est maintenant unanime sur l’inefficacité du multi-tasking. Il y ne devrait plus y avoir de débat sur l’utilité du troisième point de la liste précédente : « faire une chose à la fois et le faire du mieux possible ». A coté des études de l’université de Londres, que j’ai souvent citées dans ce blog puisqu’on y trouve l’exemple désormais célèbre qui montre que travailler en face de son Blackberry allumé fait perdre 10 points de QI, on trouve des résultats semblables dans des études plus récentes de Stanford. Le multi-tasking est carrément dangereux pour notre cerveau. Des recherches à l’Université de Sussex ont montré que les personnes qui font beaucoup de multi-tasking ont une plus faible densité d’une partie du cortex antérieur, une partie qui est associée à l’empathie et au contrôle cognitif.

3. Le Yield Management et l’optimisation stochastique des opportunités


On vient de voir qu’il y a des nombreux avantages à appliquer les principes du lean à des processus «de cerveau d’œuvre », qu’il s’agisse d’innovation ou de fabrication et diffusion de connaissance. Il y a également des limites importantes, à cause de la plus grande volatilité de la demande. Si l’on se réfère à un modèle de production de voiture façon Toyota, il faut imaginer des voitures dont la configuration requise change en temps réel, ainsi que le prix final, avec la possibilité pour le client d’annuler à tout moment, tandis que certaines pièces uniques prennent un temps de fabrication avec une très grande variabilité.

Le Yield Management  est précisément la discipline de gestion de demandes stochastiques que l’on utilise dans ces situations, qu’il s’agisse de remplir un avion ou un hôtel. Les fondamentaux du Yield Management sont qu’on ne connaît pas les opportunités qui vont arriver, mais qu’on dispose d’une certaine connaissance statistique de ce qui pourrait arriver, et que la valeur est très inégalement répartie. Il y a donc un double objectif de bien utiliser les capacités face à une demande aléatoire et d’optimiser l’allocation des ressources pour mieux servir les demandes les plus génératrices de valeur.

Ces deux dimensions stochastiques se retrouvent dans le travail de notre knowledge worker, illustré sommairement par le processus de la figure suivante. Un flux continu et aléatoire de demandes arrivent, qui se retrouvent regroupées dans un in-box (boite email, premier colonne d’un kanban, boite de tâches, etc.). La première tâche du cerveau d’œuvre est d’en prendre connaissance, et de faire une des 5 actions suivantes (si l’on est un adepte de GTD on va bien sûr s’assurer que ce travail de triage n’est fait qu’une seule fois : (1) exécuter – pour des tâches très simples (2) planifier pour une exécution ultérieure (3) planifier et fournir un accusé de réception en s’engageant à réaliser la demande (4) refuser la demande avec une réponse (5) ignorer la demande.  La deuxième catégorie de décisions du knowledge worker est liée à l’exécution des tâches : comment décomposer une tâche en sous-tâches (plus on décompose, plus on évolue vers du « multi-tasking », plus on augmente les opportunités de feedback mais plus en encourt des temps de « context switching ») et quand les exécuter (ordonnancement). On retrouve la dialectique connue : le push laisse plus de marge de manœuvre apparentes, mais expose au risque de changement des objectifs, tandis que le pull (« juste à temps ») demande une plus grande rigueur mais a le double avantage de délivrer « selon les conditions du moment » et « en ayant le contexte de la demande en tête au moment où l’on délivre ».
 
La première tension qui affecte le knowledge worker dans une entreprise de nos jours est la surcharge de demandes. Il lui faut donc trouver une discipline efficace pour le premier aiguillage (sort) afin de pouvoir tenir par la suite ses engagements. La deuxième tension est la grande variation dans la priorité, l’importance et le contenu des tâches, à la fois de façon globale et dans le temps. Une approche purement dynamique (la dernière tâche urgente et importante arrivée gèle les autres) conduit à deux défauts : le premier est une incapacité à tenir des délais pour des tâches simples d’importance moyenne  et le second est bien connu : ce qui est urgent chasse ce qui est important. La séparation entre ce qui est important et ce qui est urgent est l’embryon d’une approche par classe de services. Définir des classes de services consiste à regrouper des niveaux de priorité, d’urgence et de complexité semblables pour traiter ces groupes de façon fiable et reproductible (on se souvient que l’efficacité du knowledge worker est jugé par son environnement, et non pas par sa production), sous la forme de « promesses de service » (SLA). Les classes de services vont servir de support à une approche de type Yield Management, en réservant de la ressource (du temps « utile » du cerveau d’œuvre) à l’avance pour garder la capacité à faire ce qui est le plus utile. Un des premiers principes du SelfLean est de considérer son efficacité collective en priorité sur son efficacité individuelle. Ceci se traduit par l’importance de la « signalisation » (répondre rapidement qu’on peut ou ne peut pas prendre une demande) dans la figure précédente. Maintenir des bons SLAs collaboratifs dans un contexte de surcharge exige une notion de classe de service.        

La notion de classe de service trouve tout de suite sa place dans le processus d’aiguillage. Le SLA (service level agreement : promesse de niveau de service, ici le temps mis à accuser réception d’une demande) doit forcément être segmenté par classe de service, en particulier pour éviter que le ratio « temps de tri / temps de travail » ne devienne trop important (ceci n’est pas un problème théorique, avec plus de 100 emails entrants, de nombreux cerveaux d’œuvre perdent toute capacité de production propre). Une autre subtilité du contexte systémique du knowledge worker est que l’environnement s’adapte au SLA qu’il est capable de fournir. Un knowledge worker zélé qui cherche à fournir tout de suite un accusé de réception ou un refus documenté reçoit souvent un autre message, une autre demande ou une reformulation. Le SLA par classe de service permet également ralentir l’accélération chronophage rendue possible par les outils de communication modernes.

Une autre tension intéressante dans l’application du lean thinking au processus ci-dessus est le temps d’adaptation à un nouveau contexte, qui fait qu’il ne faut pas aller trop loin dans le principe lean des « petits batchs ». Morceler une tâche en nombreuses sous-tâches a de nombreux avantages systémiques (plus d’agilité, moins d’inertie, plus d’opportunité de feedback) mais un inconvénient majeur qui est que le « setup cost » est important pour passer d’une tâche à l’autre. On retrouve ici très précisément les arguments contre le multi-tasking et contre les interruptions. Le temps qu’il nous faut pour passer d’une tâche à une autre (switching) est important, et cela d’autant plus que la tâche est complexe, c’est-à-dire en liaison avec un environnement riche. Le chiffre communément admis est qu’il faut 25 minutes pour se remettre dans le contexte d’une tâche (une nouvelle tâche, ou la tâche précédente après une interruption).

La pratique du Yield Management repose sur la notion de prévision. Il y a donc une tension culturelle apparente avec les pratiques lean, telles que le « juste à temps », qui cherchent à obtenir l’agilité en s’affranchissant des prévisions, et celles du YM qui supposent que l’on peut prévoir. Si l’on regarde de plus près, certaines pratiques du lean, telles que le heijunka – le lissage de la charge au moyen de l’ordonnancement sélectif de différents types de tâches – s’appuient également sur une certaine connaissance de ce qui va probablement se passer en terme de charge. La plupart des articles sur le Heijunka cite la phrase suivante de Taiichi Ohno : « The slower but consistent tortoise causes less waste and is much more desirable than the speedy hare that races ahead and then stops occasionally to doze. The Toyota Production System can be realized only when all the workers become tortoises ». Le heijunka s’appuie sur une typologie des actions à réaliser, et utilise – entre autres – des ordonnancements pour lisser la charge ou la difficulté en réservant des positions pour certains types de tâches par rapport à d’autres, ce qui n’est pas sans rappeler une gestion de classes de service.

Néanmoins, il subsiste bien une tension entre le désir d’optimiser et planifier d’une part, et la nature fortement aléatoire de la charge, souvent marquée par des « crises » que l’on n’a pas vu venir. La pratique des classes de services, la limitation de la charge et le pilotage en flux tirés grâce au Kanban donnent des réponses systémiques pour rendre le cerveau d’œuvre adaptable. Mais puisque cette tension subsiste, les pratiques précédentes doivent être complémentées par la « réflexion » (prise de recul). Il faut régulièrement prendre du recul pour : (a) évaluer la réalité par rapport à ce qui est perçu (b) réévaluer constamment le travail en cours et ses priorisations. C’est précisément tout l’intérêt des outils de management visuels, de la simple représentation du WIP jusqu’au Kanban.

4. Eloge du temps long, l’art d’attendre


J’ai déjà abordé le sujet de la gestion des demandes dans un mode lean, qu’il s’agisse d’un knowledge worker face à sa boite email ou d’un système d’information piloté par ses SLA, dans le cadre de mes travaux sur l’OAI. La première contribution à cet éloge du temps long vient précisément de la théorie des files d’attentes. Traiter les demandes dans l’ordre dans lesquelles elles arrivent n’est pas robuste et ne se prête pas à la maximisation de la valeur. Dans les deux cas, on trouve facilement par l’analyse ou la simulation qu’il faut implémenter des classes de services et définir des stratégies de routage des flux de tâche qui tiennent compte de la priorité (de la valeur créée) et se rapproche d’un ordonnancement « juste à temps ».

On aboutit de la sorte à ce qu’on pourrait qualifier de « slow scheduling » : le Yield Management appliqué aux classes de services, qui construit un emploi du temps « calme » qui réserve des zones pour des futures opportunités (à haute valeur) et pour la gestion des aléas, ce qui est nécessaire pour tenir les SLA évoqués dans la section précédente. Le principe est simple : pour la plupart des demandes, il faut utiliser des classes de services pour faire un ordonnancement paresseux (au plus tard) qui évite de devoir ensuite déplacer des tâches de priorités moindre pour « faire de la place ». Un des grands principes de la vie en entreprise est que les changements de dernière minute sont fatigants et inefficaces. Ils engendrent un stress inutile pour le cerveau d’œuvre lui-même et sont dommageables du point de vue de l’efficacité collective (rupture des SLA qui rythme l’orchestration). Je vous recommande chaleureusement pour poursuivre sur ce thème la lecture du billet de Faisal Hoque « Five Ways Working More Slowly Can Boost Your Productivity ».
Il existe une autre raison pour recommander l’ordonnancement paresseux (le « slow scheduling »), c’est qu’il est plus conforme au temps long de la créativité. Je vous recommande ici vivement les exposés de Steven Johnson sur les « slow hunch ». La créativité repose sur une alternance de temps courts et longs – le « slow hunch » c’est le processus qui raffine progressivement l’intuition au fil du temps. Le temps de l’incubation des idées est un temps long. Avant qu’un lecteur ne m’oppose les principes du lean startup, la décomposition en phases de design thinking et de MVP permet justement de concilier temps court et temps long. Ce n’est pas par hasard si Ash Maurya insiste sur les efforts (longs) à faire pour caractériser le problème (et les « hypothèses ») avant de se lancer (rapidement) dans le MVP pour valider ou invalider ces hypothèses. Si vous n’avez pas le temps de regarder sa vidéo TED, lisez l’article suivant qui résume le livre de Steven Johnson, dont une des leçons est « World-changing ideas generally evolve over time as slow hunches rather than sudden breakthroughs ». Cet excellent article insiste également logiquement sur l’importance des réseaux et de la collaboration entre knowledge workers.

Tous ces arguments se combinent avec ceux des sections précédentes, puisque l’innovation est un processus éminemment coopératif. Pour reprendre les propos d’Yves Morieux : « coopérer c’est mettre ses marges de manœuvre au service des autres », donc, pour innover, il faut avoir des marges de manœuvre (slack time). Il faut également soigner sa qualité de vie (cf. section 2) et l’adéquation de son environnement. Si nous revenons à l’éloge de « l’art d’attendre », il s’agit bien de donner « du temps au temps » pour la transformation. Ce qui n’est nullement incompatible avec la rapidité de l’action. Le potentiel de situation se construit sur le temps long, mais la décision pour saisir l’opportunité doit être rapide et l’action agile. Pour simplifier, on peut dire qu’une forme de l’art d’attendre se retrouve dans la vision systémique des « cultivateurs » au sens de François Jullien, en particulier lors qu’il faut cultiver des apprentissages. On retrouve cette intuition dans une partie de l’article « How slow work make us more productive » du New York Times. Le temps long est compatible avec le Toyota Way – le lean ce n’est pas « que les cycles courts de l’amélioration continue ». Ce sujet déborde amplement le cadre du SelfLean. Je vous renvoie, par exemple, à ce que j’ai écrit sur la combinaison du lean thinking et de l’architecture

lundi, mars 28, 2016

Lean User Experience et Lean Analytics



1. Introduction



J’utilise pour la Digital Agency le schéma suivant pour représenter la démarche Lean Startup. Ce schéma est une extension d’un schéma original à deux boucles de Dave Landis, modifié avec Stéphane Delbecque pour y ajouter la dimension de développement analytique sous le chapeau du « Growth Hacking ». Il y a plusieurs variantes de ce dessin, celle-ci représente ma meilleure synthèse du moment, en définissant deux moments clés pour le passage d’un cercle à l’autre :
  • le « «sprint zero », lorsqu’on démarre le processus de construction du MVP (cercle 1 à 2)
  • la mise à disposition dans les stores (App Stores) de l’application, lorsqu’on passe des « beta testers » aux « vrais clients » (cercle 2 à 3)

La représentation sous forme de 3 cercles insiste sur le fait que chaque étape : Design Thinking, MVP agile development et Growth Hacking est itérative. Ce dessin cristallise deux parti-pris éditoriaux : 
  1. le Lean Startup couvre l’ensemble des 3 phases (build – measure – learn s’applique partout)
  2. le Growth Hacking commence dès que l’application est entre les mains du marché, et pas seulement lorsque le « Product-Market Fit » a été obtenu. 
Je place le « growth hacking » sous l’égide du « nail it, then scale it » : les méthodes de lean analytics, les pirate metrics et les modèles de croissance sont utiles avant et après l’obtention du Product-Market Fit. Il est possible de prendre une définition plus large pour la définition du MVP et de faire du product-market fit la transition avec une phase plus étroite du Growth hacking, mais je préfère faire du lancement la seconde transition car elle sépare deux étapes (on construit / on améliore) qui sont plus distinctives en termes de gouvernance et mode de travail (l’atteinte du Product-Market-Fit n’est pas aussi simple à caractériser).


Le billet de ce jour propose la revue de lecture de deux livres fondamentaux qui alimentent respectivement les deux premières – design thinking & minimum viable product – et la dernière étape – growth hacking – de cette démarche de Lean Startup. Ces deux livres font explicitement référence à Eric Ries et au Lean Startup, et me semblent des lectures indispensables pour bien comprendre l’ensemble de la démarche.

2. Lean UX



Le premier livre est « Lean UX : Applying Lean Principles to Improve User Experience » de Jeff Gothelf (avec Josh Seiden). C’est un livre de la collection « The Lean Startup Series » proposée par Eric Ries. Dès les premières pages, les auteurs font références à trois « fondations » pour la démarche de Lean UX (User eXperience) : Design Thinking, Product Agile Development et Lean Startup. Comme toujours, je vous propose un résumé synthétique émaillé de quelques citations, mais je vous recommande la lecture, d’autant plus que ce livre est court et contient des exemples intéressants.

  • Le Design Thinking, la première composante de lean UX, s’appuie sur l’observation des clients : « innovation powered by...direct observation of what people want and need in their lives and what they like or dislike ». Le design thinking a une applicabilité beaucoup plus grande que le développement de produits numérique, c’est un outil fondamental pour le développement de toute proposition de valeur, dans tous les secteurs d’activité, qui devrait, à mon avis, être enseigné dans tous les MBA (« every aspect of a business can be approached with design »). On trouve dans le design thinking deux caractéristiques transverses de l’ensemble du lean startup : build-measure-learn (des cette première phase, on construit des prototypes qui matérialisent des hypothèses – « There is more value in creating the first version of an idea than spending half a day debating its merits in a conference room ») et la confrontation régulière aux futurs utilisateurs (« A critical best practice in Lean UX is building a regular cadence of customer »). Il faut équilibrer les deux : l’approche analytique et l’approche qualitative : « It’s not all numbers! It’s worth noting that there’s been a lot of backlash in the design world against measurement-driven design ».  Une des autres idées clé du livre est l’importance du focus (« Lean UX is an exercise in ruthless prioritization »). Une fois définies les différentes personas, il faut choisir le moins possible et se concentrer sur quelques « unique value propositions ».

  • Puisque Lean UX s’appuie sur les méthodes agiles pour le développement de produit, ce livre contient un résumé des principaux principes du développement agile ainsi que quelques conseils. Par exemple, on retrouve le résumé(reformulé) suivant du « agile manifesto » : (1) priorité aux personnes et aux interactions sur les processus et les outils (2) priorité à un logiciel qui tourne plutôt qu’une caractérisation complète de ce qu’il doit faire (3) collaborer avec les clients plutôt que de contractualiser un projet (4) s’adapter à ce qui change plutôt que suivre un plan. On retrouve également les traits classiques de l’approche agile : « small, dedicated, colocated teams », « small batch size », etc. Je cite : « This is the day-to-day rhythm of Lean UX: a team working collaboratively, iteratively, and in parallel, with few handoffs, minimal deliverables, and a focus on working software and market feedback ». Comme toujours, la co-localisation est la meilleure façon de travailler mais le livre aborde également le sujet de « la collaboration avec des équipes géographiquement distribuées » (par exemple : « Each conference room had a Mac in it with a location-specific Skype account (i.e., it wasn’t a specific individual’s account, it was that office’s account). The two offices connected to each other via their office Skype accounts so that we could see each other as a group »). On trouve également une référence au « sprint zéro » que je mentionnais en introduction :  « They use a technique called Cycle 0 (you may have heard it called “Sprint Zero” or “Staggered Sprints” as well ». Comme ce livre pose les fondations pour la collaboration entre designers et développeurs, il contient des définitions très intéressantes, comme celle qu’il propose pour les user stories : « The smallest unit of work expressed as a benefit to the end user. Typical user stories are written using the following syntax: As a [user type] I want to [accomplish something] So that [some benefit happens] » (cf. un peu plus loin la discussion sur outcome-vs-feature)

  • Un des principes clés de cette approche est la notion d’équipe cross-fonctionnelle (pas de surprise, c’est une des idées fondamentales partagées par la plupart des livres auxquels je fais référence dans ce blog, et une des fondations de l’Entreprise 3.0), c’est-à-dire des équipes qui embarquent le développement, le design, la conception produit, le marketing et l’assurance qualité. La véritable collaboration entre designer et développeurs est une des clés de la réussite, et il est facile de se tromper : « Many teams have missed this critical point and have instead created workflows in which designers and developers communicate by handoff, creating a kind of mini-waterfall proces ». Il faut au contraire une véritable collaboration (au sens de « travailler ensemble sur la même chose » entre les membres de l’équipe pour produire le « shared understanding », au sens lean/kaizen du terme : « Shared understanding is the collective knowledge of the team that builds up over time as the team works together. It’s a rich understanding of the space, the product, and the customers ». Les auteurs insistent : « Without that collaboration, you don’t build shared understanding, so you end up relying heavily on documentation and handoffs for communication ». Tout cela doit se faire dans une équipe autonome, qui n’est pas soumis à un flux de contrôle trop important : « Management check-ins are one of the biggest obstacles to maintaining team momentum », ce qui conduit naturellement à l’utilisation du visual management et du « management by walking around ». Je termine          avec une dernière citation : « Lean UX requires cross-functional collaboration. By creating interaction between product managers, developers, QA engineers, designers, and marketers, you put everyone on the same page ».

  • Le deuxième principe fondamental de l’approche Lean UX (et Lean Startup) est de définir le progrès (ou le succès) à partir de la satisfaction client, et donc de l’expérience, et non pas à partir de ce qui est produit : « progress is defined by outcome, not outputs ». C’est pour moi le pivot de la « transformation numérique », lorsque le succès est définit par la satisfaction des utilisateurs, pas la liste des features qui ont été livrés. "Our goal is not to create a deliverable, it’s to change something in the world — to create an outcome. We start with assumptions instead of requirements. We create and test hypotheses. We measure to see whether we’ve achieved our desired outcomes »

  • Pour éviter la douche froide à la sortie, il faut donc inclure la boucle d’apprentissage à partir des feedbacks clients le plus tôt possible, et à toutes les étapes du processus de développement Lean Startup, depuis le Design Thinking jusqu’au Growth Hacking. Les auteurs insistent sur l’utilisation de tous les canaux de communication pour écouter les clients «Customers can provide feedback through many channels », selon les principes de ce que nous avons appelé le « Customer Feedback Learning Loop » (CFLL). Nous allons y revenir avec le livre suivant. Il faut aller voir les clients sur place (ce que les auteurs appellent GOOB : Get out of the Building) : « It’s the realization that meeting-room debates about user needs won’t be settled conclusively within your office ».

 3. Lean Analytics


Le deuxième livre est « Lean Analytics : Use Data to Build a Better Startup Faster » de Alistair Croll et Benjamin Yoskovitz. C’est également un livre de la collection « The Lean Startup Series ». Ce livre est très riche, plus long que le précédent, et contient beaucoup de chiffres utile. Il commence par un principe qui n’est pas sans rappeler Ash Maurya : « don’t sell what you can make, make what you can sell ». C’est un ouvrage de référence pour développer la dimension analytique d’une démarche Lean Startup, puisqu’il contient à la fois des conseils pour choisir ses métriques et des ordres de grandeur de comparaison qui sont très utiles pour commencer (« There’s lots of information in this book. We interviewed over a hundred founders, investors, intrapreneurs, and innovators, many of whom shared their stories with us, and we’ve included more than 30 case studies »). Le résumé qui suit est plus incomplet qu’à l’habitude, il s’agit vraiment d’une incitation à la lecture.



  • L’innovation est une démarche complexe, qui demande beaucoup de travail (« Innovation is hard work — harder than most people realize »), même si la technologie rend le passage à l’acte facile (« It’s vanishingly cheap to create the first version of something. Clouds are free. Social media is free. Competitive research is free. Even billing and transactions are free »). On retrouve ici les conseils de Oussama Amar aux jeunes entrepreneurs. Il n’est jamais trop tard pour bien faire (build-measure-learn) mais il vaut mieux commencer une démarche lean startup dès le départ : « Many startup founders discover Lean Startup at a specific point in their growth: they’ve built a product and it has a bit of traction, but not enough to be exciting ». Comme exprimé précédemment, l’utilisation de l’approche analytique ne remplace pas l’intuition et la vision, mais c’est un outil pour corriger ses propres erreurs : «  Lean Analytics isn’t about eliminating your gut, it’s about proving your gut right or wrong ».

  • La première métrique qui doit être le centre de l’attention est celle de l’usage, et plus précisément le « Monthly Average Users » (MAU). Je cite ce paragraphe car il contient l’essentiel :  « The real metric of interest — the actionable one — is “percent of users who are active.” This is a critical metric because it tells us about the level of engagement your users have with your product. When you change something about the product, this metric should change, and if you change it in a good way, it should go up. That means you can experiment, learn, and iterate with it ». Le reste du livre donne beaucoup de détail sur la mesure des MAU, qu’il s’agisse de SaaS, de e-commerce ou d’applications mobiles.

  • L’approche analytique est au cœur de la démarche Lean Startup (build-measure-learn) puis qu’il s’agit précisément d’apprendre à partir des nombres. Au delà du MAU, les auteurs introduisent plusieurs métriques dans la lignée des « pirate metrics ». On retrouve l’acquisition, l’activation (« The percentage of people who download the app, actually launch it, and create an account »), la rétention (et son opposé, le churn) et la viralité. Le churn reçoit une grande attention, en particulier dans le domaine du SaaS, ce qui est parfaitement judicieux selon ma propre expérience. On retrouve très vite la référence au Growth Hacking : « Growth hacking is an increasingly popular term for data-driven guerilla marketing. It relies on a deep understanding of how parts of the business are related, and how tweaks to one aspect of a customer’s experience impact other ». On retrouve également les conseils de la catégorie « nail it, then scale it » comme celui-ci : « There’s a risk that you build virality and word of mouth at the expense of engagement ». Je souligne également le point suivant qui justifie la décomposition en trois cercles que j’ai proposé en introduction : « Growth hacking combines many of the disciplines we’ve looked at in the book: finding a business model, identifying the most important metric for your current stage, and constantly learning and optimizing that metric to create a better future for your organization ».

  • Comme l’avait déjà remarqué Ash Maurya, la mesure doit être combinée avec le contact direct avec les utilisateurs : « Customer development is focused on collecting continuous feedback that will have a material impact on the direction of a product and business, every step of the way ». Le livre contient de nombreuse anecdotes à ce sujet, telle que : « Then co-founder and CEO Kyle Seaman did something critical: he picked up the phone. Kyle spoke with dozens of parents. He started calling parents who had signed up, but who weren’t active ». Pas besoin de voir trop grand : « We suggest that you speak with 15 prospective customers to start. After the first handful of interviews, you’ll likely see patterns emerging already ». Mais, également comme Ash Maurya, les auteurs nous préviennent de la difficulté : « For one thing, user feedback suffers from horrible sampling bias. Few people provide feedback when they have a predictable, tepid experience. They reach out when they’re ecstatic or furious. If they’re feeling aggrieved, you’ll hear from them ».

  • La méthode préférée pour réussir une innovation est de construire une petite communauté d’utilisateurs et de la satisfaire au point d’en faire des ambassadeurs : « After all, if you can’t convince a hundred users to stick around today, you’re unlikely to convince a million to do so later ». On retrouve ici les propos de Guy Kawasaki, et on peut évidemment faire le lien avec le principe « nail it then scale it » de Nathan Furr préalablement évoqué, « Your top priority is to build a core set of features that gets used regularly and successfully, even by a small group of initial users » ; « There’s no question that growth is important. But focusing on growth too soon is bad ». Je vous recommande l’exemple de Reddit sur l’utilisation de sa communauté : « Reddit has an engaged, passionate community, and it’s perfectly designed to collect feedback ».

  • Ce livre est un trésor en terme d’exemples chiffrés et d’ordre de grandeur pour comprendre ses propres résultats. Voici un exemple frappant : « Joel shared some numbers with us: 20% of visitors create an account (acquisition). 64% of people who sign up become “active” (which the founders define as posting one status update using Buffer). 60% of people who sign up come back in the first month (engagement/stickiness). 20% of people who sign up come back (are still active) after six months (engagement/stickiness) ». Les auteurs proposent de travailler « one core metric at a time » : « The core idea behind Lean Analytics is this: by knowing the kind of business you are, and the stage you’re at, you can track and optimize the One Metric That Matters to your startup right now ». Cette notion d’étape et de contexte métier est essentielle pour apprécier les métriques que l’on suit : « You need to know what sport you’re playing. Online metrics are in flux, which makes it hard to find a realistic baseline. Only a few years ago, for example, typical e-commerce conversion rates were in the 1–3% range. The best-in-class online retailers got a 7–15% conversion rate, because they had offline mindshare or had worked hard ». Les auteurs donnent également des chiffres sur ce à quoi il faut s’attendre en terme de génération de contenus par les utilisateurs : « By our estimates, expect 25% of your visitors to lurk, 60–70% of your visitors to do things that are easy and central to the purpose of your product or service, and 5–15% of your users to engage and create content for you



  • En particulier, ce livre est indispensable pour construire des applications mobiles. On trouve le même genre d’ordre de grandeur particulièrement utile : « For mobile applications, 30% of the people who download the app use it each month. 10% of registered users will use the service or mobile app every day. The maximum number of concurrent users will be 10% of the number of daily users ». Je reproduit ici l’illustration trouvée dans l’article de Peter Farago sur l’engagement et a loyauté par type d’application, parce que ce graphique me semble très utile pour évaluer le comportement des utilisateurs d’une nouvelle application. Les explications sur la viralité des applications mobiles sont également utiles : « Recall that virality is actually two metrics: how many new users each existing user successfully invites (your viral coefficient) and the time it takes her to do so (your viral cycle time). ». Ces conseils sont déclinés dans le cas du modèle freemium, pour lequel les auteurs conseillent de s’assurer que la valeur d’usage augmente avec le temps. Un autre exemple de statistique utile : « An October 2012 study by mobile analytics firm Flurry showed that across more than 200,000 applications, only 54% of users were still around at the end of the first month, only 43% were around at the end of the second, and only 35% were using the application by the end of the third ».

  • Pour finir, ce livre donne des multiples équipes pour des équipes qui veulent mettre en place une démarche lean startup, et en particulier une démarche d’« intrapreneurs ». Je suis particulièrement en phase avec l’idée de la « minimum viable vision » (l’ensemble des UVP) : « A minimum viable vision (MVV) is one that captivates. It scales. It has potential. It’s audacious and compelling ». Il y fort logiquement une très grande cohérence avec Running Lean : « Find Problems, Don’t Test Demand Once you start doing customer development, remember that you’re testing problems and solutions — not existing demand ». Je vous recommande également très chaleureusement les 14 règles librement adaptées de Kelly Johnson. Je termine ici avec mes 5 préférées : (1) exiger l’accès à de vrais clients (2) construire une petite équipe agile … si ce n’est pas possible, vous n’avez pas les conditions de réussite (3) tester vos propres produits et passez du temps en face-à-face avec vos utilisateurs (4) protégez l’équipes des pessimistes et des agressions externes (5) faite du client un acteur majeur du processus d’innovation et transformez vos tests en marketing.