Meetup Lean Startup en Entreprise : le Lean Canvas

On commence à bien connaitre le buzz word « Lean Startup« . Cette méthodologie imaginée par des startupers consiste à valider au plus tôt et à moindre coût des hypothèses sur l’adoption d’un produit, la survie d’une startup étant en jeux.

« Mais pourquoi faire du Lean Startup quand on n’est pas une startup ? »
Pour éviter les 50% de fonctionnalités qui ne seront pas utilisées dans vos projets.

Dans son rapport Chaos de 2013, le Standish Group évalue à 50% la part de fonctionnalités jamais ou rarement utilisées. S’il y a un gisement d’économie à réaliser, c’est bien dans ces fonctionnalités inutiles plutôt que dans les coûts unitaires de développement.

Justement, le Lean Startup se concentre sur une des sources de gaspillage identifiée par le Lean Management de Toyota : la sur-production. Comme le rappelle Eric Ries, l’inventeur du concept Lean Startup : « Si vous produisez quelque chose dont personne ne veut, peut importe que cela soit fait dans les temps et dans le budget ! »

On comprend vite l’intérêt de cette méthodologie pour des entreprises établies qui veulent innover en limitant les risques.

« Et comment faire du Lean Startup quand on n’est pas une startup ? »


Il reste à adapter ces outils, pensés initialement pour des startups, à de plus grosses entreprises ayant des contraintes spécifiques, par exemple :

  • Comment tester le concept au plus tôt sur le marché avec un Minimum Viable Product lorsque la confidentialité est un enjeu clé pour une entreprise leader surveillée de près par ses concurrents ?
  • Comment utiliser le Lean Startup, pour une application SI interne lorsque l’utilisateur est un employé ?
  • Comment créer une culture de l’innovation basée sur la preuve, ce qui implique l’acceptation par le top-management de la remise en cause de ses idées par le « crash-test » du terrain ?

C’est pour répondre à ces questions rencontrées lors de nos missions Lean Startup que nous lançons un rendez-vous Meetup régulier sur le Lean Startup en Entreprise.

Nous vous donnons rendez-vous pour un premier épisode mercredi 24 juin à 19h : cadrer par le Lean Canvas.

Le Lean Canvas a pour but de synthétiser en une page le business model, et d’identifier les hypothèses les plus risquées de ce plan.

Appliqué à un projet d’entreprise, il peut être utilisé sur tout projet BtoC, BtoB ou BtoE (employés internes) pour aligner les acteurs projets autour d’une vision commune et identifier les hypothèses à valider dans la démarche Lean Startup.
Nous vous proposons de venir vous exercer pratiquement en remplissant en direct votre Lean Canvas sur un projet de votre choix. Ceci donnera une support concret pour vous présenter l’outil et partager nos conseils suite à nos retours d’expérience dans des contextes d’entreprise.

 

Mercredi 24/6/2015 de 19h à 21h
Chez OCTO Technology
50 Avenue des Champs-Elysées, 5e étage, Salle André Gide.
Métro Franklin-Delano Roosevelt

Nombre de places limité.
Inscrivez-vous  sur le groupe meetup

Ecrire du code propre – Le nommage

Après ce premier article sur les piliers qui soutiendront votre pratique du code, je vous propose de commencer par la pratique la plus simple mais bien souvent la plus négligée : le nommage. Un nommage adéquat sera la source première de sens à votre code. Quand on sait que 70% du temps d’un développeur  consiste à lire du code, il est important d’en optimiser sa compréhension.

Lire la suite

Comment rater vos revues de code ? – Épisode 1

Dans le précédent article, nous avons présenté la pratique de la revue de code ainsi que deux formats que nous utilisons sur nos projets.

Mais introduire une nouvelle pratique avec succès n’est pas une chose aisée. C’est un peu comme mettre une barque à la mer : une fois dans l’eau, les premiers mètres sont assez chaotiques. Il y a beaucoup de vagues, on commence à se demander si c’était une bonne idée. Ne serait-il pas plus sage de retourner au rivage ? Mais en persévérant, on arrive finalement au large, où la mer est plus calme : il suffisait de s’accrocher.

Nous avons rencontré dans nos expériences de revue de code plusieurs écueils qui nuisent aux bénéfices attendus et qui peuvent mettre en péril la pratique dans l’équipe.

Voyons au travers de quelques anecdotes vécues* pourquoi vos premières revues de code risquent d’être difficiles et quels sont les fondamentaux nécessaires à des revues de code réussies.

Lire la suite

Les cinq principes pour échanger avec vos utilisateurs

Depuis mai 2014, nous avons ouvert elCurator, la plateforme de curation collaborative à destination des entreprises. Notre objectif principal dans la construction de ce produit est d’échanger avec nos utilisateurs. 

Il est essentiel de communiquer avec nos utilisateurs pour réaliser un outil qui réponde à leur besoin. Et l’enjeu est de taille pour nous, puisque nos clients ne nous paient que quand leurs utilisateurs sont actifs.

Voici les cinq principes que nous suivons pour le faire. Lire la suite

Développer ses super pouvoirs chez OCTO – Mode d’emploi !

Les carrières chez OCTO sont un vecteur important de bien être au travail. « Comment ? » me direz-vous et surtout : « Est-ce possible ? »

Chez OCTO nous croyons que donner de la perspective et de la liberté aux Octos leur permet de s’épanouir et de grandir sereinement.

Quelque soit l’âge ou l’expérience, on peut continuer à apprendre et ce, à travers des missions, des retours d’expériences partagés, des conférences, … Bref, en étant curieux et en favorisant le partage avec ses pairs, on peut s’épanouir tout en développant son employabilité. Lire la suite

Revue de code : quel format choisir ?

Nous utilisons principalement deux formats de revue de code dans nos projets : la revue collective, plutôt formelle et la revue par un pair, un format plus léger. Les deux présentent des avantages et des inconvénients : revenons ensemble sur ces formats et comment les mettre en place dans une équipe.

Mais commençons par le commencement : qu’est-ce qu’une revue de code et quels bénéfices apporte-t-elle ?

Dans la plupart des domaines impliquant l’écriture, on n’imagine pas que ce qui est écrit soit publié sans avoir été relu. Un article sera toujours relu avant publication (par exemple celui que vous êtes en train de lire), que ça soit pour une vérification sur le fond – le sujet de l’article est-il bien traité ? – ou sur la forme – orthographe, grammaire, structure et lisibilité du texte.
De la même manière, la pratique de la revue de code consiste à faire relire son code afin d’y trouver le maximum de défauts, que ça soit sur le fond – est-ce que ce code fonctionne, et matérialise bien la fonctionnalité prévue ? – ou sur la forme – clarté, lisibilité, respect des standards, etc.

Et chez vous, combien de lignes de code mettez vous en production sans qu’elles aient été relues ?

Lire la suite

Transformation Agile : est-ce SAFe pour moi ?

Si d’aventure vous avez suivi la blogosphère agile ces 18 derniers mois, il peu probable que vous ayez échappé au buzz créé par le framework SAFe : Scaled Agile Framwork. Est-ce le nouveau Grâal du déploiement de l’agile à l’échelle de l’entreprise ? Est-ce la recette de la potion magique des Google, Amazon, Netflix et autres (Gaulois) Géants du Web ? Je vous propose de gagner un peu de temps et répondre d’ores et déjà que non. SAFe n’est pas LE framework universel qui s’appliquera comme par enchantement à votre contexte et fera de vous l’Amazon de votre secteur d’activité.

« Tous les modèles sont faux, mais certains sont utiles » Georges Box

Lire la suite

Ecrire du code propre – Les piliers

Le « Clean Code » regroupe plusieurs règles et principes pour vous aider à construire mais surtout refactorer votre code. En effet, comme le disait Michel dans son article sur les artisans du code, le respect de ces différentes règles énoncées par Bob Martin a pour but d’offrir à votre code, entres autres, simplicité, lisibilité et structuration pour qu’il soit le plus évolutif et maintenable possible sur le long terme.

Ce premier article traite des piliers qui vous soutiendront dans votre pratique de l’amélioration de la qualité de votre code.

Lire la suite