Skip to content

L’agilité et le lean dans l’entreprenariat

Cette semaine, je suis allé à la rencontre d’entrepreneurs désireux de découvrir et d’échanger sur l’agilité et le lean. Une vingtaine de personnes, travaillant dans des domaines différents, ont ainsi pu expérimenter et s’approprier quelques valeurs et principes de ces approches empiriques.

Nous avons pratiqué des jeux agiles de sensibilisation. Ces jeux utilisent la pratique émotionnelle et ludique pour faire ressentir et ancrer en soi ces valeurs et principes.

Auto organisation

Le jeu des triangles, aussi connu sous le nom de « complex system », est un jeu sans matériel qui permet de sensibiliser sur l’auto organisation et la systémique d’un système complexe.

Nous avons effectué 2 tours :

  • le premier tour avec un chef, seul maître abord, qui doit organiser ses troupes. Bravo Flavien pour le niveau d’engagement et de créativité !
  • le second tour en mode auto organisé, avec en bonus quelques variantes sur la systémique et l’adaptabilité.

Les participants ont exprimé leur ressenti, et fait émerger les différences entre les 2 types d’organisation, notamment en termes de confiance, de motivation, de réactivité, et d’adaptabilité.

Ce jeu fonctionne d’autant mieux qu’il y a beaucoup de participants (au moins 10 ou 15 personnes, sans limite maximum). Avec moins de participants, on peut utiliser le jeu du « noeud humain » qui produit sensiblement les mêmes effets.

Entrainement

En guise d’intermède, nous avons utilisé un simple serrage de main (main droite puis main gauche) pour montrer l’utilité de s’entraîner, même sur des actions qui peuvent paraître extrêmement simples au quotidien. En effet, l’entrainement permet de transformer un acte réfléchi, lent et maladroit en un réflexe automatique, rapide et précis.

Vision versus spécifications détaillées

Nous avons utilisé le jeu des « vaches et spécifications » pour constater le risque de non pertinence du produit lorsque la demande détaille trop, voire impose, le « comment » au lieu de se contenter de décrire et d’expliquer le « pourquoi », c’est-à-dire le besoin, la vision.

 

Nous avons également discuté de cette vidéo de Simon Sinek sur la vision, le « pourquoi » :

Merci à David Barnholdt de Crisp.se pour ce jeu court et percutant.

A noter : comme l’ont fait remarquer plusieurs participants, dans certains domaines il existe des normes, des standards, des côtes, et autres contraintes d’assemblage qui contraignent les réalisations, doivent impérativement être mentionnés dans le cahier des charges, et conditionnent la validation du produit ou service.

Dîner

Plus qu’une pause, le repas a permis d’échanger sur les jeux pratiqués et leur analogie dans la vie quotidienne des participants. Il est toujours aussi intéressant de constater à quel point nous rencontrons les mêmes problématiques dans nos activités respectives, bien que nos domaines soient très différents les uns des autres.

Limitation du travail en cours

Le dernier jeu s’appelle « combien de temps faut-il pour écrire un prénom ? ». On le doit à Henrik Kniberg de Crisp.se (une version française est disponible en ligne, au format PDF).

Les participants ont pu constater, par une mesure scientifique, à quel point le multitâche peut être néfaste, et combien le mode focalisé peut permettre à la fois d’être efficace, et surtout de viser un mode prédictible et d’engagement de service.

  

Nous avons également discuté de la théorie des files d’attente, et de la loi de Little qui dit que le délai de traitement d’un élément est égal au temps de traitement unitaire multiplié par le nombre d’éléments en cours de traitement.

Clôture

Le ROTI (Return On Time Investment, littéralement retour sur le temps investi) va de 3 à 5 (sur une échelle de 1 à 5). Beaucoup de 4, et tout de même pas mal de 3.
Principal point d’amélioration : éviter les anglicismes.

La soirée s’est achevée sur des échanges très stimulants. Nous avons discuté en particulier du livre Lean Startup : adoptez l’innovation continue.

Merci aussi à Denis pour son retour d’expérience sur la mise en place de Kanban dans son entreprise.
A ce propos, voici les 2 livres en français qui présentent la méthode Kanban, et que j’ai cité en référence : Kanban pour l’IT et Kanban : enclenchez le moteur d’amélioration continue de votre IT

Remerciements

Un grand merci aux participantes et participants, et au CEC (le Club des Entrepreneurs de Couzon au mont d’or) pour leur accueil chaleureux, et pour cette soirée conviviale et pleine d’échanges très intéressants.
Merci à Yann pour l’invitation.

Liens utiles

Le manifeste agile
Le référentiel des pratiques agiles de l’institut agile
Le CARA Lyon, antenne lyonnaise du club agile rhone alpes

Publicités

L’apprentissage au coeur du développement de logiciel

Dans une démarche empirique, on adopte un cycle d’expérimentation, d’apprentissage, et d’amélioration. Cette démarche n’est pas nouvelle : le PDCA a plus de 60 ans.

PDCA

Plus récemment, le Lean Startup met l’accent sur la nécessité d’avoir des cycles courts et rapides d’apprentissage pour pouvoir innover et entreprendre.

Lean Startup learning loop

Pour pouvoir faire des cycles courts et rapides d’apprentissage, il faut faire des cycles aussi petits que possible. C’est la notion de “baby step” (pas d’enfant) : on tâtonne, petit à petit, et on améliore progressivement.

Apprendre tout en construisant le logiciel (temps projet/produit)

Lorsqu’on utilise une démarche empirique pour développer un logiciel, j’identifie 3 boucles d’apprentissage et d’amélioration utilisées en continu :

  • on crée de la valeur fonctionnelle que l’on ajoute ou adapte grâce à un feedback fréquent des utilisateurs
  • on suit un processus de fabrication que l’on améliore par des rétrospectives régulières
  • on investit sur la qualité intrinsèque que l’on cultive par des pratiques techniques

Le 1er axe constitue un cycle d’exploration et d’apprentissage du contexte des utilisateurs, et d’amélioration de la pertinence et de la valeur fonctionnelle du logiciel. Il permet notamment de réduire l’effet tunnel, c’est-à-dire le risque de découvrir tardivement la non ou faible pertinence du logiciel.

Le 2ème axe constitue un cycle d’apprentissage et d’amélioration du flux de travail, et permet notamment de réduire le délai moyen de fabrication.

Le 3ème axe vise d’abord à améliorer quotidiennement la qualité du code et diminuer la dette technique : un code se cultive, jour après jour.
Certaines de ces pratiques techniques, comme le binômage et la revue de code, constituent également en elles-mêmes un partage des connaissances pendant la réalisation du logiciel.

Improvement loops

Mon propos est que ces 3 moteurs d’apprentissage et d’amélioration devraient toujours être en marche, même à faible régime. Par exemple, lorsqu’une organisation souhaite passer d’une approche prédictive à une démarche empirique, la tentation est grande d’appliquer exclusivement une amélioration du processus de fabrication. Cette recherche exclusive de rentabilité à court terme prive alors l’organisation des véritables bénéfices d’une démarche empirique : satisfaction des utilisateurs, des collaborateurs et des parties prenantes, pertinence et pérennité du logiciel, innovation.

Ces moteurs ne sont pas incompatibles. Dans cette vidéo, Michel Goldenberg explique comment il se sert du sprint burndown chart (un indicateur visuel d’avancement sur l’itération en cours) pour piloter l’apprentissage collectif tout en cultivant la motivation individuelle.

Sprint burndown chart

Il cite aussi des outils simples pour gérer les compétences individuelles au service du collectif :

  • market of skills : pour identifier qui veut donner ou recevoir telle ou telle compétence

Market of skills

  • profil T : élargir le profil T des personnes permet de les motiver tout en augmentant la compétence collective

T-shaped profile

  • matrice des compétences de l’équipe : permet de piloter le risque qu’une compétence importante soit maîtrisée par trop peu de personnes

Team skill risk board
S’améliorer, s’entraîner (temps hors projet/produit)

Même lorsqu’on n’est pas en train de “produire”, il est également possible de monter en compétences sur les 3 axes : valeur fonctionnelle, processus de fabrication, qualité intrinsèque.
La fréquence compte plus que le temps consacré. Idéalement, on se réserve quelques minutes par jour, et/ou quelques heures par semaine pour sortir du cadre de production en cours et améliorer continuellement ses compétences.

Quelques jours de formation sont toujours bénéfiques, tout comme les livres, les conférences, les blogs. Mais ces enseignements sont généralement ponctuels, loin du poste de travail, et leur application directe dans le quotidien n’est pas toujours aisée.

Rien ne vaut la pratique en situation réelle. Voici 3 techniques efficaces :

  • côté valeur fonctionnelle : l’immersion dans la situation réelle des utilisateurs, pour percevoir la réalité de leur contexte.
  • côté processus de fabrication : les jeux agiles permettent, entre autre, d’apprendre et de se perfectionner sur telle ou telle méthode de travail.
  • côté qualité intrinsèque : les katas utilisés dans les sessions de coding dojo et les journées de code retreat sont des moyens efficaces d’améliorer son savoir-faire technique. Pour en savoir plus, voir le post de Claude Falguière sur le blog des Duchess.

Improvement
A ce propos, le samedi 8 décembre 2012 aura lieu la journée mondiale du code retreat. Si votre ville n’apparaît pas dans la liste, n’hésitez pas à créer l’événement.

Pour découvrir et expérimenter des jeux agiles, le mieux est de consulter les événements de l’agenda agile : rares sont les évènements agiles qui n’en proposent pas.

Démarche empirique

But du développement logiciel

L’objectif du développement de logiciels informatiques est de satisfaire les utilisateurs, qui utilisent le logiciel (produit ou service), et les clients, qui le payent – ce ne sont pas toujours les mêmes personnes -, en mettant à leur disposition le produit ou service qui répond à leurs besoins.

Empirisme : profession de foi

Je crois en une approche empirique du développement de logiciels, c’est-à-dire basée sur l’expérimentation, l’observation, et l’apprentissage, et faisant le lien aller-retour entre la théorie et la réalité, comme le fait dans son domaine la physique expérimentale, ou encore comme un enfant apprend à marcher, à manger, etc….

Utilisées seules, les approches prédictives (comme le Génie logiciel, le Cycle en V, et plus largement le Taylorisme) me semblent limitées voire inadaptées dans un monde de plus en plus changeant.

Pourquoi ce blog ?

D’abord pour moi, comme outil d’apprentissage.

Egalement pour partager à mon tour mes réflexions et mes retours d’expérience, comme une modeste compensation de ce que j’ai déjà reçu et continue de recevoir de la communauté.

Je souhaite me concentrer sur l’exploration, la critique, et l’amélioration des approches empiriques, ainsi que la transformation que leur adoption engendre dans la culture d’entreprise.

Soyons constructifs

Ce blog n’a pas pour objectif de pointer du doigt les approches prédictives, ou d’alimenter un débat fratricide entre les différentes approches empiriques elles-mêmes.

Les critiques n’ont pas pour objectif de blâmer ou dénigrer. Elles se veulent constructives, espérant donner l’occasion de trouver des moyens de s’améliorer.

@AlfredAlmendra

%d blogueurs aiment cette page :