David Cliquot
Transcription (Traduit)
Je suis très, très heureux d'être ici. Je pense que nous avons vu des personnes vraiment brillantes, des personnes très inspirantes aussi.
Je pense à Alexander que nous venons de voir avant, ainsi qu'à Carl et David Anderson et Claudio avec le popcorn. J'ai adoré. Aujourd'hui, je vais vous parler de notre parcours utilisant Kanban dans plusieurs contextes, des grandes entreprises aux startups.
Tout d'abord, je vais me présenter. Je m'appelle David Clicquot. J'ai fondé deux entreprises. La première s'appelle Reactive et nous offrons du conseil en lean startup et agile aux grandes entreprises. Et la seconde s'appelle MVP Stars. C'est un studio de startups où nous aidons les entrepreneurs à donner vie à leurs idées. Et nous parlerons de cette activité pendant ce discours. Comme vous le voyez, nous recrutons dans ces deux entreprises, donc si cela vous intéresse, n'hésitez pas à vous connecter. Que vous soyez agile et souhaitiez aider les grandes entreprises, ou que nous cherchions aussi des développeurs iOS pour aider nos startups.
Une dernière chose, je voudrais remercier mon partenaire, Nicolas Morin, qui est aussi le co-auteur de cette présentation, il n'a pas pu être là aujourd'hui, alors merci à lui.
Et maintenant, nous sommes prêts à commencer.
Je vais donc partager avec vous notre histoire avec Kanban. Tout a commencé quand je l'ai lancé. Nous l'avons lancé dans notre ancienne grande entreprise financière. Nous avons découvert une toute nouvelle façon de travailler et nous avons commencé à remettre en question de plus en plus le statu quo. Ensuite, je partagerai avec vous comment nous avons essayé de mettre en œuvre les principes du lean startup et comment nous avons tenté de créer notre première startup, les choses que nous avons apprises, les techniques que nous avons utilisées. Et enfin, je partagerai avec vous
Notre façon actuelle de travailler, qui mélange les principes du lean startup et Kanban. Et c'est ce que j'appelle le lean Kanban startup. J'espère que personne n'a déposé ce terme. Ce n'est pas une marque déposée.
Donc, en gros, c'est ce que nous allons aborder.
Alors, comment ai-je découvert Kanban ? Je dois à nouveau remercier l'organisateur de cette conférence car j'ai découvert Kanban il y a trois ans lors du premier Lean Kanban France 2012. Mon partenaire, le gars que vous avez vu avec la barbe, était déjà intervenant là-bas car il avait déjà mis en œuvre Kanban dans notre entreprise. Il m'a donc invité et j'ai eu la chance de voir, cette fois encore, des personnes très inspirantes. Donc David Anderson, Don Reinertsen et Stephen Parry. Et j'ai découvert le concept. L'après-midi, j'ai joué avec le Kanban Zine. C'est un jeu sérieux où l'on peut pratiquer Kanban. Et je savais qu'il y avait des choses que je pouvais en tirer et que cela allait m'aider en tant que chef de projet informatique. Alors j'ai acheté le livre, le livre de David Anderson. J'ai pris le petit livret.
Arrêtez de commencer, commencez à finir. Je l'ai ramené à la maison, je l'ai lu, et j'étais prêt à commencer à mettre en œuvre Kanban dans mes équipes.
Je ne vais donc pas passer par toute cette mise en œuvre, cette transformation. Je sais que Claudio n'aime pas ce terme. Nous parlons plus d'une évolution car il n'y a pas de point final. Mais je vais partager avec vous quelques histoires que je trouve intéressantes.
Juste pour vous donner un peu plus de contexte, je dirigeais une équipe d'environ 15 personnes travaillant sur le développement logiciel. Nous faisions déjà du Scrum depuis quelques années et nous avions également traversé une vague de transformation lean IT. C'est pourquoi j'ai matérialisé une évolution réussie. Donc Kanban aurait été la prochaine étape. Je ne sais pas ce qui vient après.
Donc l'équipe était déjà assez agile, si je puis dire, ou du moins ils étaient vraiment ouverts à l'amélioration continue. C'était donc un très bon point de départ. Pour donner l'exemple, j'ai commencé mon Kanban personnel pour susciter un peu de curiosité. J'ai simplement dessiné mon tableau Kanban derrière mon bureau. Nous travaillions dans un espace ouvert et j'intégrais dans mon système Kanban mes tâches de chef de projet. Et j'ai pu m'entraîner moi-même avant de le faire avec l'équipe. J'ai aussi laissé le livret 'Arrêtez de commencer, commencez à finir' sur mon bureau, pour que les personnes assises à côté de moi puissent le voir, le lire peut-être, et poser des questions à ce sujet. Ainsi, la curiosité a commencé à monter dans l'équipe et autour.
Ensuite, j'ai organisé une partie du jeu Get Kanban avec l'équipe avec l'aide de coachs internes. Ils ont expliqué à l'équipe, expliqué la méthodologie, expliqué la théorie, puis nous avons divisé l'équipe en deux. Et ils allaient s'affronter au jeu Get Kanban. Connaissez-vous Get Kanban ? C'est un jeu sérieux très connu. Vous pouvez y pratiquer Kanban aussi. C'est dans un contexte de développement informatique.
Donc à ce moment-là, je suis parti. Je n'ai pas joué avec l'équipe. C'est très important. Je les ai laissés jouer et tout. Je suis juste revenu à la fin de l'après-midi pour le débriefing. J'ai offert des bonbons ou des chocolats à l'équipe qui a gagné. En discutant avec l'équipe, j'ai réalisé que la plupart des gens avaient vraiment, vraiment compris les avantages que nous pourrions tirer de Kanban. Certains étaient vraiment très enthousiastes. Et un développeur m'a demandé, d'accord, mais quand est-ce qu'on va faire ça ? Et je pense qu'il croyait que nous jouions juste et que nous ne le ferions pas. Donc quand je lui ai répondu, nous commençons demain, il était très...
très heureux.
C'est comme ça que ça a commencé.
Ensuite, j'aimerais partager l'histoire du tableau blanc-blanc. Donc juste après ça, toute l'équipe est partie. Et j'ai effacé le tableau que nous avions. C'était un tableau Scrum ou un tableau lean IT ou peu importe comment vous l'appelez. Mais il était important pour notre équipe car nous l'utilisions tous les jours. Nous avions des indicateurs, nous avions beaucoup de choses dessus. Donc ce n'était pas rien de l'effacer. Je l'ai donc complètement effacé. Et quand le gars, je suis arrivé tôt au bureau le lendemain, donc quand les gars sont arrivés au bureau, ils étaient vraiment surpris. Et à la réunion du matin, je leur ai demandé, d'accord, maintenant,
Vous avez décidé d'adopter Kanban, alors allez-y, créez votre propre Kanban, faites ce qui fonctionne.
Et toute l'équipe a discuté une journée entière. Ils n'ont pas travaillé, ils ont juste discuté, débattu de la cartographie du flux de valeur, de tout, des limites de travail en cours, de ce que nous allions faire.
Je n'ai pas pu m'empêcher de participer à la discussion, alors j'ai dû me forcer à m'éloigner, à partir à nouveau, pour ne pas trop guider la discussion. Et à la fin de la journée, nous avions notre premier système Kanban, notre premier tableau Kanban. C'était plutôt bien. Il nous a fallu encore quelques semaines avec des améliorations continues pour obtenir quelque chose qui fonctionne bien au sein de l'équipe.
Ensuite, j'ai commencé à travailler sur le côté demande de notre système. J'ai donc commencé à discuter avec nos clients de ce que nous faisions un étage au-dessus.
Il a fallu un peu de temps pour les embarquer, mais ils ont très bien compris les améliorations de type flux. Et ils étaient très satisfaits de la priorisation en direct. Nous nous sommes débarrassés du comité de priorisation. Donc, à chaque fois que nous avions de la place dans notre système Kanban, ils priorisaient simplement la prochaine chose à faire. Mieux vaut le faire maintenant. Mais d'une manière ou d'une autre, j'étais toujours coincé avec le cycle de release, la planification des dates de release et tout le reste. Et un jour, mon client m'a redemandé, alors, quand est votre prochaine release ? Et puis tout est devenu clair et j'ai simplement répondu : c'est En gros, quand vous voulez. Montez simplement à l'étage, regardez notre tableau, et regardez la valeur que nous avons dans la colonne 'terminé', et dites-nous simplement quand vous voulez que nous livrions. Prenez juste en compte, considérez que nous avons environ trois jours de charge de travail de tests manuels pour effectuer la release en production. Donc si vous considérez que vous avez assez de valeur, allez-y et dites-le nous. Et pour visualiser cela, nous avons utilisé une note adhésive spéciale que nous avons appelée 'voiture balai', je ne sais pas si on peut dire ça en anglais. Ainsi, tout le monde dans l'équipe savait quelle était la dernière fonctionnalité ou la dernière user story de la release. Et les clients pouvaient venir tous les jours et la déplacer, en fonction des nouvelles priorités ou des nouvelles choses.
Donc à la fin, nous étions dans une position où le client pilotait nos priorités en direct, notre backlog, en continu, et il décidait exactement quand nous ferions la release. Donc il ne me restait presque plus de travail en tant que product manager.
Alors j'ai commencé à aider de plus en plus de gens autour de moi.
C'est à ce moment-là que nous avons commencé à travailler sur le côté droit de notre système Kanban, c'est-à-dire le processus de livraison. À cette époque, j'ai lu le grand livre sur la livraison continue de Jez Humble et David Farley. Et je l'ai fait circuler dans l'équipe, de la même manière que j'avais fait avec Kanban au début. Et maintenant que nous avons du temps de marge, grâce à Kanban, tout le monde sait ce qu'est le temps de marge ? Bien sûr.
Puisque nous avons du temps de marge, nous avons décidé en équipe de consacrer tous nos efforts de temps de marge au processus de livraison continue.
Nous avons passé un très bon moment à faire des choses techniques. C'était très stimulant. Les gars de l'équipe ont adoré. Mais nous avons été moins performants sur le plan politique, car nous devions convaincre l'équipe d'architecture et les équipes d'exploitation d'utiliser ce que nous avions construit. Nous avons donc fait des choses en interne, nous avons benchmarké des solutions de fournisseurs et autres. Et à la fin, nous avons obtenu beaucoup d'améliorations, mais nous n'avons pas pu atteindre le point où nous faisions des releases tous les jours constamment dès qu'un ticket était prêt. Mais je pense qu'aujourd'hui, c'est peut-être différent parce que DevOps est un mot à la mode très tendance. Donc peut-être que vous obtiendrez de bien meilleurs résultats que nous sur cette partie de votre processus.
Et qu'en est-il des autres coéquipiers, des autres équipes autour, comment coordonnons-nous la gestion ?
Il était assez difficile de se coordonner avec les autres équipes, avec mes pairs, les responsables de programme ou de projet, car ils avaient toujours les mêmes questions : quand allez-vous faire la prochaine release le mois prochain, quelle est votre date de release, quand allons-nous mettre cela en place et tout le reste. Mes réponses ne leur semblaient pas très bonnes. Elles n'étaient pas vraiment bien comprises quand je disais : mais dites-moi simplement quand vous en avez besoin et je le mettrai en place. Nous pouvons livrer à tout moment. Il suffit d'appeler mes clients et ils pousseront la release. C'était assez difficile. Du côté de la gestion, ils étaient assez confus, mais au moins les clients étaient heureux, donc ils étaient contents. Et comme je l'ai dit, nous avons déjà traversé quelques transformations à nouveau, donc personne ne voulait prendre la responsabilité de mettre cela à l'échelle, même si cela fonctionnait bien.
C'est à ce moment-là que j'ai commencé à devenir de plus en plus exigeant avec les demandes des clients. J'avais le sentiment que nous ne créions pas assez de valeur, que nous faisions les choses correctement, mais était-ce la bonne chose à faire ? Je crois fermement que dans de telles organisations, on tend à faire de l'optimisation locale en raison de la division de la chaîne de valeur.
Voilà notre conclusion pour cette partie.
Faire les choses correctement est assez facile si vous suivez la méthodologie Kanban. Il est facile de l'implémenter au niveau de l'équipe, mais très difficile à mettre à l'échelle pour plusieurs raisons. Je suis donc curieux de savoir sur quoi David Anderson travaille aujourd'hui avec la planification des services d'entreprise. Je pense qu'il est très bon d'essayer de présenter Kanban aux cadres supérieurs. les choses correctement, mais était-ce la bonne chose à faire ? Je crois fermement que dans une telle organisation, on tend à faire de l'optimisation locale en raison de la division de la chaîne de valeur.
Voilà donc notre conclusion pour cette partie. Faire les choses correctement est assez facile si vous suivez la méthodologie Kanban. C'est facile à mettre en œuvre au niveau de l'équipe, mais très difficile à étendre pour plusieurs raisons. Je suis donc curieux de savoir sur quoi David Anderson travaille aujourd'hui avec la planification des services d'entreprise. Je pense qu'il est très bon d'essayer de présenter Kanban aux cadres supérieurs.
Donc Kanban ne vous dit définitivement pas quoi faire. C'est à ce moment-là que nous introduisons la chose lean startup.
Alors, comment ai-je découvert Lean Startup ? Un jour, j'ai toujours voulu lancer ma propre entreprise. Et un jour, j'en discutais avec un ami. Et je disais à quel point ce serait difficile de quitter mon emploi confortable. Et il m'a dit que des gars dans la Silicon Valley avaient écrit un livre et qu'il s'agissait d'une technique pour démarrer des entreprises et que je pourrais même le faire, en gardant mon emploi, en éliminant les risques et tout le reste. Alors je suis rentré chez moi et j'ai commandé un livre sur Amazon.
Et j'étais tellement excité que j'ai aussi téléchargé le livre en PDF, désolé pour ça. Et avant que le livre n'arrive par la poste, je l'avais déjà lu en PDF et c'était formidable. C'était exactement ce que je cherchais, des techniques pour démarrer.
Et c'était en même temps que nous mettions en œuvre Kanban. Donc, j'avais déjà le sentiment que le lean startup plus la chose Kanban que nous faisions, ils semblaient former un très bon combo, mais je ne savais pas très bien comment gérer cela.
Donc, je me suis plongé dans toute la littérature sur les startups, la génération de modèles économiques, bien sûr, et toute la série d'Eric Ries, Running Lean, Lean Analytics et tout le reste. Toutes ces lectures ainsi que notre récent succès avec Kanban m'ont donné beaucoup d'énergie pour commencer quelque chose.
Puisque j'aime faire des choses, je me suis dit, d'accord, essayons maintenant. Alors, trouvons un problème et essayons de le résoudre.
À cette époque, les bureaux de cette entreprise venaient de déménager en dehors de la ville, pas en dehors de Paris, mais en dehors du centre de Paris. Et à cet endroit, il y avait très peu de restaurants. Et ils étaient assez éloignés. Donc, à midi, à l'heure du déjeuner, tout le monde dans l'open space ne cessait de demander, où mangeons-nous aujourd'hui ? Et les gars disaient, non, pas cet endroit, non, je ne l'aime pas, ou cet endroit, non, le service est trop long. Et nous avons commencé à réfléchir à ce problème. Une idée que nous avions était de publier les menus du jour des restaurants aux alentours.
Pourquoi les menus du jour ? Parce qu'en général en France, c'est ce que les gens commandent à l'heure du déjeuner parce que c'est généralement moins cher. Le service est plus rapide et la plupart du temps, c'est fait maison.
Donc, nous voulions tester cela. Bien sûr, tout ce que j'ai dit, nous l'avons testé avec le principe du lean startup par la suite. Et la vision plus large de la chose que j'avais, c'est que je voulais rassembler et peut-être plus tard monétiser toutes les données éphémères qui existent là-bas.
Google, Wikipédia et tout le reste, ils sont très bons pour indexer les connaissances humaines immédiatement, mais il est encore très difficile d'obtenir des données qui ne sont pertinentes que pendant quelques heures. Donc, disons quel est le menu, quel est le plat du jour dans les restaurants aux alentours ? Combien y a-t-il de places, reste-t-il de la place dans mon cinéma pour ce film ? Ce genre de choses. C'était la vision plus large et commencer par le plat du jour était une façon de s'exercer.
Alors, allons-y. Donc, nous devions construire une plateforme. C'est très courant. Dans une plateforme, il y a deux côtés. Le premier côté pour nous était le restaurant qui devait publier ses plats du jour. Et de l'autre côté, il y avait les visiteurs affamés qui voulaient choisir leur restaurant pour le déjeuner.
Donc, il est temps de sortir du bâtiment. À ce stade, nous pensions devoir commencer par le côté vente de la plateforme. Donc, chaque jour, nous allions dans les restaurants et prenions des photos de leurs plats du jour. Donc, le plat du jour, soit ils sont à l'extérieur des restaurants, soit ils sont à l'intérieur. Donc, nous devions discuter avec tous les propriétaires de restaurants de cette zone, environ 20 restaurants.
Et après quelques jours, certains d'entre eux nous ont demandé, mais vous n'allez pas venir tous les jours prendre des photos de mon tableau, n'est-ce pas ? Et j'ai dit, si, nous devons le faire. Et ils nous ont simplement dit, mais comment puis-je vous aider ? Comment puis-je vous envoyer cette photo ? Et c'est là que l'idée est venue et ils nous envoyaient simplement un email avec la photo de leurs plats du jour. Et de notre côté, nous indexions simplement cet email à un restaurant particulier. Et c'est... Ce que nous appelons de nos jours une application transparente, c'est très tendance, cela signifie que vous n'avez aucune interface utilisateur et que votre utilisateur utilise quelque chose qu'il possède déjà. Et cela fonctionnait parfaitement pour les restaurants parce que ces gars ne veulent utiliser aucune application spécifique. Ils ne veulent pas utiliser un formulaire sur votre site web. Donc, ils utilisaient simplement leur smartphone, prenaient une photo et l'envoyaient. Avec cela, nous avons développé ceci, cela nous a pris moins de deux semaines pour comprendre cela. C'est donc très, très puissant ce que vous pouvez obtenir lorsque vous sortez du bâtiment.
Et puis cela a commencé à devenir fou parce qu'à cette conférence Lean Startup, désolé, Lean Kanban Conference, nous avons entendu le discours de Stephen Parry, qui présentait Sense and Respond. En gros, il disait qu'il faut écouter ce que vos clients veulent. Et peut-être que nous n'avons pas très bien compris cela. Donc, nous avons commencé à vendre aux gens un tas de choses. Parce que nous étions amis avec tous les propriétaires de restaurants, ils ont commencé à nous demander des choses folles. Premièrement, ils étaient d'accord, ils nous ont demandé des sites web. Donc, nous leur avons vendu des sites web. Ensuite, ils nous ont demandé du marketing sur les réseaux sociaux. Donc, nous leur avons vendu du marketing sur les réseaux sociaux. Ensuite, certains nous ont demandé des impressions papier de leur menu. Donc, nous nous sommes associés à un imprimeur et nous leur avons vendu des menus imprimés. Et à un moment donné, un restaurant voulait décorer sa voiture, promouvoir son restaurant avec un autocollant de voiture. Et nous étions sur le point de le faire. J'apprenais sur YouTube comment poser un autocollant sur une voiture. Et puis nous avons dit, non, nous devons choisir. Nous ne pouvons pas tout vendre aux gens. Et après cela, nous avons commencé à dire non, nous avions encore plus de demandes étranges. Demande. Certains clients nous ont demandé de réparer leurs rideaux et ils étaient prêts à payer pour cela. D'autres voulaient que nous décorions leurs restaurants.
Je dois remercier Stephen Parry parce que c'est très fou quand vous construisez une bonne relation avec vos clients et que vous les écoutez vraiment, vous pouvez leur vendre beaucoup de choses.
C'est incroyable.
Par la suite, nous avons commencé à travailler sur le côté demande de notre plateforme, c'est-à-dire les visiteurs. Et nous avons commencé à utiliser davantage les principes et techniques du lean startup. Tout d'abord, nous avons mené quelques entretiens pour recueillir ce que nous appelons des retours qualitatifs. Et nous l'avons vérifié quantitativement avec des enquêtes, par exemple. Nous avons découvert les métriques pirates à ce moment-là. Nous en avions entendu parler lors de la conférence. Vous savez, acquisition, activation, rétention, revenu, recommandation. Vous devez choisir la métrique correspondant à votre modèle économique et à votre stade.
Et nous avons commencé à travailler avec des expériences également. Ainsi, par exemple, nous testions si nous obtiendrions plus de visiteurs en plaçant des autocollants sur le tableau des restaurants. Donc nous avons simplement pris 20 autocollants et nous avons cherché à savoir, d'accord, cela fonctionnerait si nous avions 20 % de visiteurs en plus. Nous avons donc commencé à mener ce type d'expériences. Une autre expérience, par exemple, nous avons compris que c'était facile d'aller se reposer. dans les restaurants, demander aux gens, les indexer et leur faire publier leur menu, mais cela ne passerait jamais à l'échelle. Et si nous le faisions par téléphone ? Donc nous nous sommes simplement dit, d'accord, quel serait un critère de validation ? Si, je ne sais plus ce que c'était à ce moment-là, mais si 40 % des restaurants étaient d'accord pour rejoindre une plateforme après un appel téléphonique ou uniquement par appels téléphoniques, ce serait un succès. Donc je prenais simplement 20 ou 30 numéros de restaurants dans les Pages Jaunes et je les appelais pour essayer de les faire rejoindre la plateforme. Et ainsi de suite. C'était très cool. Nous utilisions vraiment cette méthode lean startup et nous apprenions beaucoup.
Le désavantage, c'est à l'intérieur de l'entreprise, parce que nous développions tout ce que nous devions pour mener ces expériences, parfois nous avions besoin de développements, en plus de développer et améliorer notre produit. Et à ce stade, nous étions très mauvais pour organiser notre travail. Et l'un d'entre nous était déjà à plein temps, mais les deux autres, parce qu'une autre personne avait rejoint le projet, un designer UX, nous avions encore un emploi de jour.
Et nous avons oublié tout ce que nous avions appris et fait avec Kanban, Agile et tout le reste. Nous faisions juste des choses. Aussi vite que possible. Et un jour, une expérience nous a bloqués pendant très longtemps. Nous nous attendions à avoir plus de visiteurs si nous avions un design soigné. Donc nous avons commencé à repenser notre site web. Et cela nous a pris des semaines à travailler la nuit. Et je dois dire que cela nous a pris beaucoup d'énergie. Et c'était important pour la suite de l'histoire. Et à ce moment-là, lorsque nous faisions des choses, nous avons arrêté d'apprendre de nos clients. Nous avons arrêté de vendre des choses folles et nous avons arrêté de voir des gens. C'était très, très mauvais.
Ainsi, au cours de ce parcours, nous avons réalisé que construire une telle plateforme nécessite beaucoup plus que du développement informatique. Les opérations et le développement commercial prennent vraiment beaucoup de temps et si vous pouvez coder la nuit, vous ne pouvez pas appeler vos clients ou indexer de nouveaux restaurants ou vendre des choses la nuit, c'est très difficile. Nous avons également réalisé que atteindre l'échelle requise par notre modèle économique serait très difficile. Nous devrons encore résoudre beaucoup de problèmes par des expériences. Une opportunité que nous avons eue était peut-être de fermer le site web et de simplement offrir un service aux restaurants pour promouvoir leur activité en ligne, en gros. Mais un concurrent, un concurrent français, faisait déjà cela très bien et était très bien financé. Nous avons donc décidé de ne pas entrer dans cette bataille et nous avons arrêté le projet. Mais à la fin, nous avons beaucoup appris. Nous avions une équipe, une infrastructure informatique, et nous avions déjà codé certains composants génériques que nous pourrions réutiliser.
Donc notre conclusion pour la partie lean startup est que
Faire la bonne chose est très difficile. C'est très amusant, mais c'est encore très difficile. Heureusement, en cours de route, nous avons trouvé quelque chose de plus intéressant.
Ainsi, pendant l'année où nous avons construit ce site web appelé Near and Fresh, nous avons commencé à nous immerger dans l'écosystème des startups parisiennes et nous avons identifié qu'il y avait un réel manque de fondateurs techniques ou de directeurs techniques (CTO). Presque chaque mois, l'un d'entre nous recevait une proposition pour rejoindre une startup en tant que fondateur afin de les aider à lancer leur projet.
Nous avons donc lancé ce que nous appelons le Startup Studio pour résoudre ce problème et aider les personnes talentueuses à créer leur entreprise. Alors, comment cela fonctionne-t-il ? Nous nous associons avec des entrepreneurs. En gros, ils viennent à nous avec une idée. Et si nous aimons l'idée, nous nous associons avec eux et nous agissons en tant que fondateur. Nous prenons donc une participation au capital et nous lançons le produit. Et dès qu'il y a une certaine activité, des clients, ou idéalement dès que nous levons des fonds, en tant que fondateur, nous commençons à être payés pour les nouvelles fonctionnalités. Voilà ce que nous faisons. nous faisons maintenant.
Et nous allons aussi plus loin qu'un CTO classique parce que nous offrons des conseils en lean startup issus de ce que nous avons appris. Nous offrons l'UX, le design et bien sûr le développement mobile et web.
La première étape de cela, il y a environ un an, consistait à réduire à nouveau les risques de notre modèle économique.
Nous avons donc identifié trois risques principaux. Tout d'abord, nous avions ce sentiment, mais nous devions vérifier que la demande était forte. Alors, comment avons-nous fait pour cela ? Nous sommes simplement allés à des événements où les gens sont censés rencontrer des cofondateurs. Et nous avons identifié qu'il y en a un à Paris appelé Adopt a CTO, par exemple, mais il y en a beaucoup d'autres. Et dans de telles rencontres, il y a un ratio d'un CTO pour trois idées d'affaires, en gros. Nous étions donc assez confiants que la demande était correcte. Deuxièmement, comme nous allions nécessiter un montant important de financement, soit pour nous soit pour nos startups, nous sommes allés voir les investisseurs pour leur présenter notre idée et voir si elle était attrayante.
J'ai donc présenté le projet aux 20 réseaux de business angels présents à Paris, et nous avons suscité un certain intérêt. Certains d'entre eux nous ont rejetés. Et la question la plus importante que nous avions pour ceux qui nous ont rejetés est : d'accord, vous ne voulez pas investir dans mon startup studio, je comprends, ce n'est pas votre domaine, mais si l'une de nos startups obtient une quelconque traction, investirez-vous dedans ? Et les gars qui m'ont rejeté très violemment ont dit, ouais, d'accord, pas de problème, je le ferai. C'était donc aussi un feu vert très important pour nous.
Et puis la troisième chose que nous devions vérifier était la configuration légale. Parce que nous devions contractualiser les actions et en plus nous devions résoudre tous les problèmes de propriété intellectuelle. Nous sommes donc allés voir un avocat, nous avons pris un bon avocat spécialisé dans les startups et après une ou deux réunions, nous avions plusieurs options pour mettre en place cette configuration. Avec tous ces feux verts, j'étais vraiment confiant et j'ai quitté mon emploi.
Donc encore une fois, arrêtons de parler, passons à l'action. Faisons le premier projet. Nous nous sommes donc associés avec un médecin. Il voulait lancer une application pour améliorer le bien-être des gens. Nous avons aimé cela parce qu'il avait vraiment ce que nous appelons un avantage injuste parce qu'il était assez célèbre dans ce domaine. Et d'autre part, le modèle économique était un peu délicat, mais nous avons tenté le coup. Nous avons aimé cela. Et nous les avons aidés, lui et son partenaire, à définir leur produit minimum viable, leur MVP, et nous avons commencé à l'implémenter. Alors encore une fois, arrêtez de parler, passons à l'action, réalisons le premier projet. Nous avons donc collaboré avec un médecin, qui voulait lancer une application afin d'améliorer le bien-être des gens. Nous avons aimé ce projet parce qu'il avait vraiment ce que nous appelons un avantage injuste, car il était assez célèbre dans ce domaine. Et d'autre part, le modèle économique était un peu délicat, mais nous nous y sommes lancés. Nous avons aimé ce projet. Et nous les avons aidés, lui et son partenaire, à définir leur produit minimum viable, leur MVP, et nous avons commencé à le mettre en œuvre.
Et nous avons dû passer par le développement d'applications mobiles. Nous avons donc dû tout apprendre à ce sujet en quelques semaines. C'était très excitant.
Cela faisait partie d'un plan parce que nous en avions besoin pour lancer des startups, car de nos jours, tout tourne autour du mobile et des données.
Et encore une fois, en faisant cela, nous avons oublié la plupart de ce que nous savions sur Kanban, Agile et tout le reste. Et en ce qui concerne le développement d'applications mobiles, je ne parle même pas de la livraison continue et tout le reste, car c'est très difficile à industrialiser et il faut être présent dès le premier jour. Si quelqu'un met un mauvais commentaire sur l'App Store le premier jour de votre lancement, vous êtes mort. Personne ne va télécharger votre application. Donc, vous ne pouvez pas itérer. Aussi souvent que sur un site web, vous pouvez commencer avec quelque chose de vraiment médiocre, mais pour un lancement, c'est une approche totalement différente.
Mais à la fin, nous avons réussi à lancer notre première application en quelques mois. Elle s'appelle Smile Life. Elle est disponible sur l'App Store français et le Red Store. Et nous avons reçu des retours plutôt bons, donc nous étions contents de cela.
Mais maintenant, qu'en est-il de Kanban ?
Conférence Celine Kanban. Et maintenant, j'admets que sur ces deux projets précédents, nous faisions juste des choses. Peut-être avions-nous un tableau de suivi et c'est tout. Mais maintenant, les choses ont changé. Nous avons deux autres startups à lancer très rapidement. Et nous devons être très cohérents et organisés. Donc, en nous basant sur tout ce que je vous ai partagé, toutes nos apprentissages, toutes nos expériences précédentes, toutes les choses que nous avons mal faites,
nous avons construit la première version de notre système d'exploitation. Et c'est ce que j'appelle le Lean Kanban Startup. Et je vais vous le partager maintenant.
Ce cadre est notre réponse à la question de savoir comment combler l'écart entre la vision, la stratégie et les opérations quotidiennes tout en restant vraiment, vraiment concentré. Et nous savons Et nous l'avons appris à la dure, qu'il est très difficile de réussir cela dans une petite équipe. Parce que dans une petite équipe, vous êtes CTO, vous êtes codeur, mais vous êtes aussi fondateur, donc vous participez à la stratégie de l'entreprise. Et quand vous êtes PDG, vous êtes fondateur, mais vous faites aussi beaucoup de choses. Et il est très difficile de penser à la stratégie et ensuite de faire avancer les choses au quotidien. Soit vous vous perdez d'un côté, soit de l'autre.
Donc, nous n'avons rien inventé du tout, nous utilisons simplement, combinons et adaptons des principes et techniques très bien documentés dans les communautés startup et agile. Donc, ce que vous trouverez dans ce cadre, ce sont des documents qui vous aideront principalement à définir votre stratégie, des systèmes Kanban pour vous aider à tester et exécuter votre stratégie, des techniques qui vous aideront à vous concentrer sur ce qui doit être fait maintenant, c'est très important, et aussi les réunions qui établiront le rythme et vous aideront également à rester concentré.
Donc, en haut, les quatre premières cases, c'est ce que nous appelons la couche stratégie. Elle est composée d'un lean canvas. C'est votre modèle économique, en gros. Votre vision. C'est quelque chose de grand et attrayant. Et c'est là où vous voulez aller. Et un plan. C'est très important. Vous devez avoir un plan. Comment passez-vous d'aujourd'hui à cette vision ?
Ensuite, sur la partie inférieure, nous avons ce que nous appelons la couche exécution. Et elle est composée de trois systèmes Kanban. Le premier système Kanban est pour les expériences. Qu'il s'agisse d'expériences réduisant les risques ou d'expériences d'apprentissage. Le deuxième système Kanban est pour le développement de produit.
Donc, en gros, nous y mettrons votre logiciel. Et le troisième système Kanban est pour toutes les autres opérations, pour faire avancer les choses. Et la technique que nous avons est la chose en jaune où vous devez rester concentré. Donc, nous utilisons des choses comme la proposition de valeur unique, une métrique qui compte, et ainsi de suite. Alors, passons en revue cela.
Donc, dans la couche stratégie, vous aurez votre lean canvas qui décrit votre modèle économique. Je ne vais pas décrire tout le lean canvas maintenant. C'est très bien documenté et je suis sûr que la plupart d'entre vous le connaissent déjà. Mais ce qui est important pour nous, c'est de rester concentré tout au long de votre parcours. Et pour ce faire, vous devez bien définir votre proposition de valeur unique et les segments de clientèle associés. Par exemple, chez MVP Star, nous avons trois segments de clientèle. Le premier est les diplômés des écoles de commerce. Le deuxième est les experts dans leur domaine, comme le médecin avec qui j'ai collaboré. Et le troisième est l'entrepreneur en série. Et la proposition de valeur unique sera différente pour ces segments. Donc, pour les diplômés,
notre proposition serait de lancer votre startup sans argent, par exemple. Pour les experts, ce serait de lancer votre startup sans compétences en informatique. Et pour les entrepreneurs en série, notre proposition serait de lancer votre prochaine startup en trois mois.
Et vous n'allez pas travailler sur tous ces segments en parallèle. Donc, vous devez indiquer dans ce document sur quoi vous travaillez maintenant.
Vous avez également besoin d'une vision.
Tout le monde parle de vision. Pourquoi devez-vous avoir une vision ? C'est nécessaire si vous voulez attirer qui que ce soit. Et quand je dis qui que ce soit, je veux dire tout partenaire, tout employé ou tout investisseur. Si vous n'avez pas une vision assez attrayante,
personne ne s'engagera dans votre objectif.
Nous n'avons pas de modèle pour cela. Habituellement, c'est juste un pitch. Vous pouvez pitcher cette vision. Pour nous, par exemple, nous voulons simplement aider les entrepreneurs à travers le monde à lancer des centaines d'entreprises prospères et à créer des milliers d'emplois.
Et ensuite, vous avez besoin d'un plan. C'est la partie que les gens n'ont généralement pas. Ils sont très bons pour avoir une très grande vision. Mais si vous avez une grande vision sans même avoir une idée de comment vous y rendre à partir de maintenant, c'est inutile. Donc, peut-être devez-vous vous en tenir à une vision plus petite, mais avoir vraiment un plan. Donc, ce plan peut être un business plan. Par exemple, vous pouvez y inclure des éléments financiers, mais ce n'est pas nécessaire. Il doit simplement s'agir d'un plan sur la manière dont vous allez de maintenant à votre vision.
doit être ambitieux et réaliste aussi. Et vous en avez également besoin si vous voulez intégrer des personnes.
Donc, ce que nous suggérons comme rythme, c'est de revoir cela mensuellement avec vos conseillers, vos membres du conseil d'administration ou vos investisseurs.
Et vous obtiendrez également, lors de cette réunion mensuelle, des résultats en retour de la couche exécution.
La couche d'exécution est là où vous faites avancer les choses. Donc, un système strict et contraignant. Tout d'abord, nous en avons parlé, les expériences. Donc, cela découle essentiellement de votre stratégie. Et selon la phase de votre projet, vous allez soit réduire les risques, disons qu'au tout début vous devez réduire les risques, et ensuite vous vous concentrerez sur les apprentissages. Nous avons donc discuté de la métrique unique qui compte. Par exemple, si vous êtes vraiment en phase précoce, vous voudrez peut-être vous concentrer sur l'activation ou peut-être sur la rétention. Ce que nous proposons, c'est simplement de l'afficher sur votre tableau pour vous aider à prioriser
les bonnes expériences que vous devez lancer parce que vous avez une capacité limitée.
Et ce que vous faites, c'est que vous passez en revue ces expériences. sur une base hebdomadaire, par exemple. Certaines expériences vous prendront plus de temps pour recueillir des données. Ensuite, vous avez un système Kanban plus traditionnel pour le développement de produit. Donc au début, vous allez vous concentrer sur votre MVP. Donc c'est important. Vous obtenez votre proposition de valeur dans votre Lean Canvas. Et cela vous aide à définir votre MVP. Cela vous aide donc à prioriser dans le développement de votre produit.
Kanban. Et puis, lorsque le MVP est sorti, vous suivez la priorisation traditionnelle basée sur la valeur ou le coût du retard dans ce tableau.
Et nous avons lancé un autre système Kanban, ce qui peut prêter à confusion, mais pour toutes les autres choses qui doivent être faites. Et c'est plus orienté GTD, donc c'est très basique, où vous avez à faire, en cours, terminé, et pour rester concentré, vous allez utiliser des limites de travail en cours (WIP). Alors pourquoi avons-nous séparé l'opération du logiciel ? C'est parce qu'il est de plus en plus tendance, par exemple, de communiquer à vos clients vos progrès, ce qui signifie que vous pouvez partager votre tableau de développement de produit.
Et vous pouvez garder vos tâches quotidiennes sur l'autre tableau. Et parfois aussi, si vous êtes dans une logique de livraison continue, vous voulez automatiser certaines choses. Donc c'est une bonne raison de garder le développement logiciel à part et d'avoir les tickets comme 'je dois aller signer ce contrat' séparément. Vous n'avez pas besoin de livrer en continu. Et ce qui est important, c'est que vous allez passer en revue cela quotidiennement avec l'équipe.
Avec cela, vous obtenez une bonne chose pour
Avoir votre stratégie, définir votre stratégie et l'exécuter.
Donc vous êtes censé être équipé pour faire ce qu'il faut correctement.
C'est la fin de mon discours. En conclusion, ce que je peux dire, c'est que d'après mon expérience, Kanban, dans les grandes entreprises, donne de très bons résultats au niveau de l'équipe, mais est difficile à mettre à l'échelle.
Le lean startup, c'est génial pour la découverte client, le développement client, mais ce n'est définitivement pas un système d'exploitation. Et peut-être qu'avec ce lean Kanban startup, en combinant les principes du lean startup pour la stratégie et la concentration, et l'exécution Kanban, vous obtenez un très, très beau combo. Merci beaucoup.