Est-il possible qu’une entreprise n’arrive pas à identifier, comprendre et résoudre efficacement les difficultés qu’elle rencontre dans le développement de produit ? Est-il possible que la principale cause de cette impuissance réside dans les certitudes erronées et illusoires de cette entreprise ?
« Ce n’est pas ce que vous ne savez pas qui pose problème, mais ce que vous savez avec certitude et qui n’est pas vrai » — Mark Twain
Le constat fait par Donald Reinertsen sur la gestion de la très grande majorité des entreprises est que les postulats sur lesquels elle repose sont fondamentalement faux. Il identifie 12 problèmes, et propose une gestion en flux avec 175 principes, souvent contre intuitifs, répartis en 8 thèmes pour aider à réconcilier l’économie et le développement de produit (cf. article sur MOM21).
Grâce à la société YISY, les 1 et 2 octobre 2013 aura lieu à Paris une formation unique en France avec Donald Reinertsen pour découvrir ces principes et savoir comment les appliquer : « Formation appliquez les principes du flux« . Voici un code de réduction de 13% valable une seule fois :
yisy-almendra-13%-reduc-idakfuid
Savez-vous par exemple que la diminution de la variabilité permet d’augmenter la prédictibilité, et qu’à l’inverse la tolérance à la variabilité favorise l’innovation ?
Ou encore, connaissez-vous la théorie des files d’attente, la loi de Little et le coût du délai ? Sous ces mots barbares se cachent quelques notions très simples. Voir l’article d’Alexis Nicolas dans Les Echos : « La baisse du coût du travail avec impact social positif, c’est possible !« .
Beaucoup d’entreprises ne jurent que par la baisse du coût de réalisation unitaire moyen, ce qui se traduit généralement par une utilisation maximale de la capacité de production. Dans les domaines de production intellectuelle comme le développement logiciel, il faut produire à 100% de son temps de travail.
« Plus on produit, moins ça coûte cher unitairement »
Derrière cette approche évidente et visible se cache un autre coût beaucoup plus discret.
L’augmentation de l’utilisation de la capacité de production induit des stocks d’encours et des files d’attentes, généralement invisibles dans les entreprises qui n’ont pas conscience de leur existence. Cette augmentation de l’encours induit un délai unitaire moyen plus élevé. La loi de Little est la formule mathématique qui permet de le calculer :
Dans un système stable, le délai unitaire moyen est égal
au temps effectif moyen de réalisation multiplié par le nombre d’éléments en cours
« Plus on produit (à capacité et système constants de production), plus c’est long unitairement »
Le coût du délai n’est autre que le coût induit par le délai de réalisation unitaire moyen. La sensibilité de ce coût dépend du profil type de la demande (cf. blog de Karl Scotland) : urgence (ex : problème en production), proportionnel (standard), à date (ex : réglementaire ou saisonnier), intangible (ex : diminution de la dette technique et autres demandes sans valeur métier directe).
« Plus on met de temps à livrer, plus ça nous coûte cher »
En résumé, l’augmentation de l’utilisation de la capacité de production induit une augmentation du délai unitaire moyen qui elle-même induit une augmentation du coût unitaire moyen.
« Plus on produit (à capacité et système constants de production), plus ça coûte cher unitairement »
C’est ainsi que la plupart des entreprises, dans la recherche de l’optimisation de leurs coûts de réalisation, oublient d’identifier et de prendre en compte l’impact des stocks d’encours et du coût du délai.
« La maximisation de l’utilisation de la capacité de production n’est pas la performance optimale de production »
Merci Alexis pour la relecture et nos différents échanges.
Depuis quelques mois, j’accompagne un créateur. Il construit progressivement ses services qu’il fournit depuis plus d’un an, mais n’arrive pas à faire décoller son modèle économique.
Voici comment, grâce à un travail sur les émotions des acteurs du système, nous avons trouvé 2 nouvelles pistes à explorer.
Dans ce qui suit, le métier des différents acteurs du système est volontairement flou, par souci de confidentialité. Voici également un point important de vocabulaire :
- utilisateur : personne qui utilise un produit ou service
- client : personne (physique ou morale) qui paye ledit produit ou service
- consommateur : personne à la fois utilisatrice et cliente
Et oui, car il y a une différence entre payer et utiliser. Et comme le dit l’adage : « Si c’est gratuit, c’est vous le produit »
Le système
Voici un (très) court résumé du système dans lequel ce créateur évolue.
Il y a tout d’abord des opérateurs itinérants, sur le terrain.
Le créateur connait très bien leur métier. C’est à eux qu’il délivre ses services, et les opérateurs en redemandent, car les services qu’il propose répondent à leurs besoins, au delà même de leurs attentes.
Il y a ensuite les consommateurs des opérateurs.
Grâce aux innovations mises en place par le créateur, les opérateurs peuvent augmenter la valeur ajoutée pour leurs consommateurs.
Il y a aussi et surtout le prescripteur local, sans qui la relation entre opérateurs et consommateurs ne pourrait réglementairement pas exister.
Et qui dit réglementaire dit collectivités et organismes d’état divers et variés qui régissent l’ensemble du système.
Le problème
Le créateur a misé sur un autofinancement pour maîtriser l’éthique de la structure, et sur une logique de démontrables devant convaincre les opérateurs pour permettre d’avoir des cycles courts de feedback.
Le modèle économique n’est pas viable, car ni rentable ni extensible. Il serait peut-être rentable sur du volume, mais comme il n’est pas extensible les volumes restent faibles.
En termes Lean Startup, on peut dire que le créateur a déjà trouvé un moteur de valeur auprès des opérateurs, et qu’il manque un moteur de croissance pour obtenir un modèle économique viable.
Ravir au delà des besoins
Avec le créateur et son équipe, nous avons passé en revue la liste des acteurs.
Quels sont les utilisateurs et leurs besoins ? Ce qui m’a frappé c’est que les prescripteurs n’ont pas de besoin : ils ont déjà tout ce qui leur est nécessaire pour travailler efficacement.
Qui est prêt à payer pour quels produits et services ? Hormis les opérateurs qui payent pour un service fonctionnel, personne ne semble prêt à débourser 1 centime. Souvent le cas tant qu’on n’apporte pas LA valeur ajoutée…
En particulier, le créateur n’arrive pas à décrocher une quelconque aide ou subvention d’un organisme d’état pour lui permettre de développer son activité.
Nous avons alors utilisé la technique des personas pour mieux comprendre et décrire le profil et le comportement des différents acteurs du système. Et nous avons approfondi le type de personnalité de ces personas, notamment sur l’aspect émotionnel, un peu comme avec une carte d’empathie.
Un point fort a très vite émergé : les prescripteurs sont et veulent rester les maîtres de ce système. Ils ont un très fort ego, ne veulent pas être déjugés, et adorent avoir la sensation de contrôler le reste de ce système.
Afin d’alimenter cette soif de pouvoir et de contrôle, et bien que les prescripteurs n’en aient pas réellement besoin, le créateur a vu naître une nouvelle piste à explorer : mesurer l’attrait auprès des prescripteurs des informations terrain collectées par les opérateurs.
Cela ne représente pas un surcoût significatif pour le créateur, et pourrait en revanche constituer une nouvelle niche. Et on peut alors constater que pour ravir de nouveaux prospects, le fondateur ne répond pas à un besoin existant, mais se contente de flatter leur ego.
Bien que cette nouvelle piste n’en soit qu’à ses premières heures en tant qu’hypothèse de valeur et de croissance, elle a déjà permis de générer une seconde piste : un organisme d’état semble maintenant intéressé par son nouveau modèle économique, et lui a même proposé un partenariat avec lui et un autre organisme d’état local dont le fondateur n’avait pas connaissance jusque là.
Conclusion
Voici les leçons apprises ou réapprises :
- répondre à un besoin existant n’est pas le seul moyen de vendre, surtout en termes d’innovation, l’important étant de ravir les clients et les utilisateurs
- les techniques de l’UX (l’eXpérience Utilisateur) devraient être valorisées auprès des créateurs
- tant que le modèle économique n’est pas viable, on ne peut pas préjuger de qui sera le client, l’utilisateur, et de ce que sera le produit ou service
- 1 heure d’atelier UX peut débloquer la situation
Comme l’an passé, la seconde édition du rendez-vous national des jeux agiles restera gravée longtemps dans les mémoires des participantes et participants. Rien d’étonnant puisque l’expérimentation ludique et émotionnelle est un fort moteur d’apprentissage.
Et, comme l’an passé, bien que rien n’ait été planifié et établi à l’avance, les 2 jours ont été denses, riches d’enseignement et de plaisir, de nouvelles rencontres et de retrouvailles. C’est toute la magie du format du forum ouvert : permettre à chacune et chacun de donner et recevoir, au maximum des motivations respectives.
3 coups de cœur
La crevasse
Entre le jeu et l’animateur qui l’a créé, je ne sais pas dire lequel m’a le plus impressionné ! Merci et bravo Olivier pour ce magnifique jeu, passant en revue bon nombre de valeurs et principes, au-delà même de l’agilité : les 3 confiances ! S’il existe un Panthéon du jeu agile, celui-ci mérite sa place. Merci aussi pour le lien vers d’autres ateliers.
Fearless journey
Merci Gilles d’avoir apporté la version pro du matériel du fearless journey, d’avoir animé le jeu, et pour les éclairages lors du débriefing. Ce jeu est un excellent moyen d’apprendre et de s’inspirer des 48 patterns exposés dans le livre Fearless Change, concernant le changement au sein d’une organisation.
Lean Pitch : comment monter une startup en 3 minutes !
Un jeu court, dynamique, créatif et collaboratif : merci Luc pour cet excellent jeu, particulièrement adapté au lancement d’un startup week-end.
Un tour d’horizon
Remerciements spéciaux
Merci Claude d’avoir apporté et animé avec Jean-Pierre le Kanbanzine : quasiment en exclusivité mondiale ! Un jeu particulièrement adapté pour des personnes hors IT.
Merci Yann pour la fleur de lotus : un outil intéressant et malléable pour les rétrospectives et la résolution de problème.
Merci Alexis pour l’ice breaker avec les photos : dans notre cas, c’est une bonne façon de ne pas oublier d’appliquer à nous-mêmes les principes et pratiques que l’on porte.
Merci Oana pour ton aide lors du Lean Startup Snowflakes. Et merci aux participant(e)s pour le feedback. Pour les lyonnais, on remet le couvert mardi soir au CARA Lyon !
Merci Grégoire de m’avoir montré le matériel de la version 2 du jardinier agile, en guise de consolation de n’avoir pas pu y jouer. Et en même temps c’est une frustration, car cette nouvelle mouture est magnifique !
A propager
Vincent a ravi les participant(e)s aux jeux du bâton d’hélium et de son théâtre d’improvisation autour de la collaboration : Vincent, les lyonnais comptent sur toi pour les rejouer au CARA Lyon !
Je suis ravi que l’atelier MVP et le jeu des Mocks aient été autant demandés et appréciés. Merci pour le feedback et les propositions d’améliorations sur le jeu des Mocks.
Boîte à idées
Alex a eu la très bonne idée d’améliorer l’impromptu speed networking en y ajoutant une action : écrire le mot clé symbolisant la raison de la venue de l’autre personne. Résultat, un tableau de post-it, cultivé par chacun(e) pendant la 1ère journée, et dont sont ressortis certains mots clé.
Pour ma part, j’ai été agréablement surpris de voir ressortir autant de fois les mots découvrir et apprendre, alors que la grande majorité des participant(e)s connaissent et pratiques déjà les jeux agiles. Révélant probablement une culture d’apprentissage et d’amélioration permanente de cette communauté.
D’ailleurs, par rapport à l’édition 2012, je n’ai compté que 4 jeux en commun (excellents jeux d’ailleurs) : le Beer Game, le petit oiseau (Birdie-Birdie), le jeu des triangles (complex system), et le co-coaching. C’est dire la capacité de renouveau en matière de jeux !
La constellation d’Émilie et Christophe a été très plaisante. Et merci Olivier pour l’idée du Bull Shit Bingo !
Gilles nous a régalé de jeux et supports de discussion concernant le management 3.0 de Jurgen Appelo, dont le meddlers, et le delegation poker qui a eu un franc succès.
Merci Luc pour le jeu pandémie autour notamment de la collaboration, la complémentarité, la stratégie et la prise de décision. La prochaine fois on fait small world, pour expérimenter la notion de pivot du Lean Startup ?
Merci Pierrick pour le retour concernant la tentative d’un Lego4Kanban.
Il ne faut pas être frustré par ce qu’on a raté, et profiter de ce qu’on a fait. Je vais quand même citer quelques jeux que je n’ai pas joué mais dont j’ai eu un très bon écho : agile ooops, les derdians, et un atelier proposé par Jean-François autour des valeurs d’une équipe Scrum.
Organisation
Feedback sur l’organisation :
- Merci Alex de porter la vision de ce rendez-vous, et de soutenir son (auto-)organisation. On sait ce qu’on te doit !
- 1 seul lieu pour tout faire, ensemble : jouer, manger, discuter, dormir. A conserver !
- rétrospective après le déjeuner du dernier jour : impeccable !
- changer de ville à chaque fois : oui !
- janvier/février pour être loin des autres conférences, ou au printemps pour des températures plus clémentes : pas facile de choisir. Quoique, printemps 2014 : c’est dans plus d’1 an, et 1 an c’est long !
D’autres en parlent aussi
Parmi les extraits du livre Présentation Zen DESIGN de Garr Reynolds, on trouve Penser comme un designer en 14 points.
Les 8 citations de cet extrait regroupées ci-dessous en 3 idées fortes m’ont interpelé, car faisant écho aux pratiques de développement logiciel. Plus que jamais, le design et l’ergonomie ne se limitent pas à la charte graphique !
Jean-Claude Grosjean souligne sur son blog et dans sa conférence Dans la peau du Manager Agile (présentée début 2012 au ScrumDay et à Mix-iT) la convergence de plusieurs disciplines.
Dans cette idée de convergence, je réalise à quel point les méthodes agiles et autres pratiques empiriques constituent un cadre compatible, approprié et même favorable au design.
Produire juste ce qu’il faut
Morceaux choisis :
« Le génie se trouve souvent dans ce que vous omettez »
« […] le plus est inutile quand le moins suffit » Isaac Newton
« La simplicité consiste à soustraire les évidences pour ajouter ce qui a une signification » John Maeda
« L’espace vide est primordial pour la clarté d’un message »
Dans le développement logiciel, l’efficacité passe notamment par le fait de s’arrêter à temps, et de ne pas trop en rajouter. Je ne présente pas la célèbre loi des 80/20. Encore faut-il pouvoir s’arrêter au meilleur moment.
Les méthodes agiles, et particulièrement les cycles courts itératifs et incrémentaux (comme Scrum ou XP) permettent cela : la fin d’une itération (ou d’une version) est un moment propice de décision « stop ou encore ».
Le jeu The Big Payoff, créé par Alexandre Boutin et Erwin van der Koogh, est un excellent moyen de comprendre cet aspect du pilotage via la pratique d’une gestion de portefeuille de projets en mode agile.
Produire juste ce qu’il faut nécessite également une priorisation avisée du contenu fonctionnel du logiciel. Plutôt que de pousser les fonctionnalités vers les utilisateurs, l’approche Lean, avec le flux tiré et le juste-à-temps, permet notamment de rester focalisé sur la valeur véritablement la plus essentielle et prioritaire à chaque instant.
Le mouvement du LeanStartup, qui constitue déjà en soi une convergence de plusieurs disciplines de la technique au marketing, utilise la notion de Minimum Viable Product (MVP) : c’est-à-dire l’élément le plus rapide à produire permettant de valider ou invalider une hypothèse (à la fois en termes de valeur et de croissance).
Ressentir et engendrer de l’émotion
Morceaux choisis :
« […] tout design doit avoir un composant émotionnel […] même si les utilisateurs n’en sont pas conscients. »
« L’empathie est une compétence sous-évaluée qui peut vraiment vous faire sortir du lot »
Les méthodes agiles ont comme premier principe d’augmenter la satisfaction des utilisateurs, ce qui inclut une part de subjectivité et de plaisir.
L’approche Lean (Go&See, San Gen Shugi, 3G) préconise d’observer et d’entendre les vraies personnes, dans leur contexte réel, concernant leurs usages concrets. Plus que de comprendre ou constater, il s’agit de s’approprier les problématiques et besoins des utilisateurs en se mettant « dans leur peau ».
L’expérience utilisateur (UX) préconise également de travailler avec les vrais utilisateurs via par exemple la pratique du Test Utilisateur, et propose également des techniques complémentaires pour percevoir, mesurer, et augmenter le ressenti des utilisateurs. Par exemple : persona, carte d’empathie
Raconter une histoire
Morceaux choisis :
« […] entraînez plutôt les gens dans un court voyage […] les gens se souviendront avant tout de l’histoire »
« Penser communication et non pas décoration »
Dans le développement logiciel, les méthodes agiles révolutionnent l’expression des besoins et la spécification. Désormais, on ne commande plus une fonctionnalité via une lourde documentation, on raconte un usage via une User Story, et par une communication orale en face-à-face.
A ce propos, je vous recommande vivement le livre suivant, dont la première version est parue en début de semaine : « Spécifiez agile – Expression de besoins : la boite à outils du Product Owner » de Thierry Cros.
L’expérience utilisateur (UX) propose également des techniques comme la customer journey map ou le storytelling.
Côté pratiques techniques, on retrouve cette notion d’histoire dans les spécifications par l’exemple (on parle aussi de spéc exécutable, de BDD, ou encore d’ATDD).
En ces temps hivernaux où foisonnent les virus tels que la grippe ou la gastro entérite, les praticien(ne)s de l’agilité, du lean, et de l’UX se retrouvent particulièrement exposés. Pour que ce message ne devienne pas un argumentaire tangible anti méthodes collaboratives, il est important de prendre quelques mesures.
Merci aux CHSCT de bien vouloir relayer cette note.
Post-it : c’est le mal !
Outil fétiche des agilistes et autres aficionados du management visuel, le post-it est probablement le plus grand concentrateur de microbes et autres virus. En attendant que les fabricants utilisent un revêtement auto désinfectant, il est prudent, voire vital, d’utiliser des gants.
Si dans votre contexte le post-it n’est manipulé que par une seule personne, vous ne craignez rien.
Programmation en binôme : à prohiber !
Technique particulièrement prisée des artisans du logiciel, la programmation en binôme constitue un risque évident de par l’utilisation d’un seul et unique clavier par 2 personnes à tour de rôle, avec plusieurs rotations, et pendant plusieurs heures. Sans compter les risques dus à une communication orale avec une telle proximité.
En attendant le retour des beaux jours, vous pouvez tenter de remplacer cette pratique par une revue de code, surtout que celle-ci peut se faire à distance, par outil électronique interposé. Notez toutefois que la qualité du logiciel et la collaboration entre équipiers s’en ressentiront.
Si dans votre contexte vous n’utilisez pas du tout la programmation en binôme, jamais, soyez rassurés.
Rencontres avec utilisateurs et clients : le fléau !
Que ce soit :
- pour avoir un feedback fréquent, par exemple lors d’une démonstration pour les Scrumiens ou d’un test utilisateur pour les ergonomes,
- pour mieux connaître et comprendre les utilisateurs, leur contexte, et leurs problématiques, pour les adeptes du San Gen Shugi,
- ou plus généralement pour collaborer sur l’identification et la priorisation des fonctionnalités innovantes et à forte valeur ajoutée, par exemple via des jeux agiles,
les rencontres avec les utilisateurs et clients sont fréquentes. Et c’est probablement là que réside le plus grand risque sanitaire, car ces rencontres favorisent la propagation des virus à une échelle nationale !
Plutôt que de risquer de dégrader leur santé, il est préférable que tous les acteurs profitent du trimestre hivernal pour se reposer. Repos bien mérité, surtout après 3 trimestres de tant d’innovations. Si toutefois ces rencontres doivent avoir lieu, il est impératif que chacun(e) se munisse d’un masque, et que les salles disposent de distributeurs de solutions désinfectantes.
Si dans votre contexte vous ne rencontrez pas vos clients et utilisateurs, ou très peu souvent, il est probable que la météo ne vous incitera pas à en faire plus, et vous serez donc à l’abri.
Processus collaboratifs : trop risqués !
Pour les managers qui pratiquent le MBWA et les entretiens fréquents en One-to-One, pour les collaborateurs qui privilégient la communication face à face, et plus généralement pour tous ceux qui utilisent les rencontres régulières de collaboration telles que la planification d’itération, le daily meeting, et autres rétrospectives, adoptez ces quelques mesures préventives qui éviteront de transformer votre lieu de travail en zone de quarantaine :
- éviter de serrer la main, de faire la bise, et tout contact de façon générale,
- se laver régulièrement les mains,
- utiliser des masques, et conserver une certaine distance entre les personnes.
Si dans votre contexte ces rencontres sont peu fréquentes, il y a fort à parier que ce contexte ne favorise déjà pas le contact et la proximité, vous devriez donc être naturellement épargnés, y compris lors des laborieux entretiens annuels de fin d’année.
Une dernière inquiétude tout de même…
Si, au travers de cette note, vous ne vous êtes jamais sentis concernés ni inquiétés au niveau sanitaire, il se pourrait que les approchent agile, lean et UX aient encore quelques améliorations salutaires à vous proposer !
Atelier logiciel 