Skip to content

Gestion des entreprises : une formation unique en France avec Donald Reinertsen

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 »

1_cout_realisation

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 »

2_loi_de_little

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 »

3_type_de_cout_du_delai

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 »

4_cout_du_delai

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 »

5_performance

Merci Alexis pour la relecture et nos différents échanges.

Exemple d’innovation : créer le besoin par l’envie

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.

PersonaEmotion0

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.

PersonaEmotion1

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.

PersonaEmotion2

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.

PersonaEmotion3

Et qui dit réglementaire dit collectivités et organismes d’état divers et variés qui régissent l’ensemble du système.

PersonaEmotion4

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.

PersonaEmotion5

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.

PersonaEmotion6

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à.

PersonaEmotion7

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

Agile Games France 2013 : sur le pont d’Avignon, on y joue tous en rond !

20130201_154904

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.

Quelques photos ici.

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.

20130202_095908

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.

20130201_164624

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.

20130201_110917

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.

20130202_112509

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.

20130201_144607

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é.

SANYO DIGITAL CAMERA

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é.

20130201_172818

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 !

20130202_160552

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.

20130202_101846

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.

20130201_121005

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 !

20130202_113006

D’autres en parlent aussi

Jacques

Alex

Christophe

Guillaume

Pierrick et Grégoire

Cécilia

Matthieu

Alexis

Claude

Design et Agilité

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).

Agile, Lean, UX : attention au risque sanitaire !

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 !

Viser la perfection : il y a un jeu agile pour ça !

Si l’équipe qui réalise un produit ou service le fait avant tout pour satisfaire ses utilisateurs,

si l’équipe prend également soin de la satisfaction de ses équipiers,

si l’équipe souhaite également satisfaire les parties prenantes, c’est-à-dire les personnes concernées mais pas directement impliquées dans la fabrication et l’utilisation du produit ou service,

et si l’équipe s’inquiète de tout cela régulièrement,

alors l’équipe doit probablement trouver cela compliqué, difficile et fastidieux de satisfaire aussi souvent autant de monde à la fois !

Pourtant, il existe une arme fatale, simple et efficace : le perfection game

Dans ce jeu collectif, chaque participant peut soumettre autant de feedback (i.e. d’information en retour) que souhaité sous la forme suivante : « j’attribue au résultat une note de x/10, voici ce que j’aime …, et afin de permettre d’atteindre la note de 10/10 je propose les améliorations suivantes … « .

Une fois les idées collectées, il ne reste plus qu’à prioriser et sélectionner les prochaines améliorations à mettre en œuvre.

Les règles originales et le jeu en ligne.

S’améliorer c’est sortir de sa zone de confort. Et sous la simplicité de ce jeu se cache un levier énorme de progression qui peut déstabiliser les individus.

L’astuce consiste à ne pas tenir compte de la note de départ et de se concentrer sur la valeur attribuée à chaque suggestion d’amélioration, c’est-à-dire la différence entre 10 et la note attribuée.

Agile Grenoble 2012 : cultiver le désir et le plaisir des utilisateurs et des collaborateurs

Merci aux organisateurs et aux participants d’Agile Grenoble et Agile Innovation, les 8 et 9 novembre derniers, pour ces 2 très belles journées : quel plaisir de se ressourcer !

Concernant le titre, ce sont les 2 clés que j’ai vu émerger de ces 2 journées, valables à la fois pour les utilisateurs, les équipes projet, les parties prenantes, et les acteurs du changement.

Merci à Nicolas Gros, le facilitateur graphique de la journée, qui a pris le temps de nous parler de son savoir-faire.

Photo de la fresque 6Mo

Reinventing software quality par Gojko Adzic

Excellente keynote pour lancer l’évènement, concise sur la finalité du développement logiciel. Gojko nous a proposé une nouvelle définition de la qualité du logiciel en revisitant la pyramide des besoins de Maslow. Voir son article paru en mai dernier).

Pyramide de Gojko

LA phrase : « la valeur d’une information est fonction du nombre de décisions (réellement) prises par l’utilisateur ».

Et son corollaire : concentrons-nous sur l’information dont l’utilisateur a besoin plutôt que sur l’information que nous lui fournissons.

Que ce soit pour le contenu du produit (aspect Expérience Utilisateur) ou son processus de fabrication (aspect Lean), la concision de cette phrase en fait un garde fou, un outil indispensable pour tous ceux qui œuvrent dans la création de logiciels.

Changer pour mieux coder par Rémy Sanlaville et Johan Martinsson

Excellente session claire et bien rythmée sur la pratique du binômage et du refactoring pour promouvoir l’entraînement via des règles claires, aux apparences simples, et nécessitant de sortir de ses habitudes pour progresser.

Les règles utilisées : Object Calisthenics. Le code source, basé sur le Gilded Rose Kata. 2 liens importants : code retreat et coding dojo.

Le message : « entraînez-vous ! »

Une mention spéciale pour cette performance claire et dynamique qui, à mon sens, en plus de l’aspect entrainement, permet de démystifier et de faire prendre conscience de l’intérêt du refactoring habituellement dénigré ou incompris, notamment par les parties prenantes. A diffuser !

Mon Binôme m’a tué par Emmanuel Gaillot et Jonathan Perret

Une représentation théâtrale amusante autour de la sortie de la zone de confort que représente la technique du binômage. Pour que 1+1 soit plus grand que 2, il est nécessaire de travailler sur soi pour valoriser l’interaction.

Lors des échanges, j’ai bien aimé cette réponse : « oui, binomer c’est plus efficace, mais c’est moins agréable ! »

Un jeu à 540 personnes !

Merci à Frédéric Dufau-Joël et ses collègues pour cette expérience intéressante.

Rompez les amarres par Laurent Sarrazin

Un retour d’expérience dense sur la transformation agile. En tant qu’acteur du changement, j’ai apprécié les nombreuses références, la « trousse à pharmacie », et la transparence sur les difficultés. Plusieurs outils de coaching humain fournis par Sylvaine Pascual, et des outils agiles : une salle de jeux dédiée aux innovation games, le storytelling, les safaris. Pour ma part, un OVNI à découvrir : le tribal leadership. Et un jeu à tester dès que possible : le fearless journey.

LA phrase : « sans désir, pas de transition ».

Un point litigieux qui a ouvert un débat (presque une polémique) le lendemain lors du forum ouvert : la référence au livre de Michael Sahota « An Agile Adoption and Transformation Survival Guide » disponible sur InfoQ, et notamment à la prétendue compatibilité de culture, sorte de distorsion du modèle de Schneider.

Autres morceaux choisis :

  • le middle management est le ventre mou de la transformation agile, une manière imagée de dire que c’est le middle management qui détient les clés de la transformation.
  • le manager devrait être au service de ceux qui produisent la valeur en bas, et non pas du haut de la hiérarchie.
  • la principale KPI est la « banane » des utilisateurs et des collaborateurs

Et enfin, l’annonce officielle de la sortie du livre rupture douce, co-écrit par une vingtaine d’agilistes réputés de la communauté agile.

Quel chemin vers l’agilité ? par Thierry Cros

Quelle est la taille de la première marche que votre organisation est prête et capable de gravir dans sa transformation culturelle ? Passage en revue concis de la finalité, des valeurs, des piliers de plusieurs méthodes (XP, Scrum, Kanban, LSD, UP) pour nous aider à identifier le chemin qui pourrait nous correspondre le mieux. Quel exploit de parler si simplement d’autant de méthodes en si peu de temps, de façon claire et digeste !

Message crucial : oui, il faut adapter une méthode à son contexte, mais dans l’esprit de la finalité, des valeurs et des piliers de cette méthode.

Autres morceaux choisis :

  • le refactoring dépend de la plasticité du produit.
  • les premiers résultats de la transition agile ne suffisent pas : le plus difficile, c’est bien la pérennité.
  • utilisation du modèle marketing AIDA (Attention, Intérêt, Désir, Action) pour effectuer la transition agile.

Des mots, des maux ? Démo ! par Caroline Damour-Nobi et Emilie Franchomme

Ce n’est pas uniquement parce que l’on trouve peu d’informations sur la démonstration de Scrum que cette présentation en devient une référence notable. Belle étude bibliographique complétée par un sondage de plusieurs agilistes de renom qui permet de rappeler à quel point cette étape est au cœur de Scrum.

A retenir absolument : « ne pas oublier de solliciter/récolter le feedback aussitôt après la démonstration ».

Autres morceaux choisis :

    • les user stories  présentées sont terminées. On ne devrait pas avoir de mauvaise surprise, sinon, il faut l’analyser lors de la rétrospective.
    • le « wow effect » (i.e. bonne surprise) au moment de la démonstration pose également un problème. Pourquoi ne l’a-t-on pas su avant, alors que le 1er pilier de Scrum est la transparence ?
    • la démonstration, et plus généralement la revue de sprint, n’est pas un tribunal. Il s’agit d’abord de prendre acte de ce qui est fini, et non pas de juger l’équipe.
    • proposition : la validation/acceptation des users stories par le PO (responsable produit) pourrait faire partie de la définition de terminé (DoD), donc être effectuée tout au long du sprint, et donc avant la démonstration.
    • la démonstration participe à maintenir l’alignement, voire elle incite à repartager/retravailler la vision du produit.

Innover avec Lean Startup, de l’idéation à l’utilisation par Oana Juncu

Notre point de départ : une idée extra pour des clients inexistants. Notre objectif : transformer cela en business. Innover c’est prendre des options dans un océan d’incertitudes.

Problématique : comment mesurer pour savoir si on avance sur la bonne voie ? Bien sûr il faut observer la réaction et le comportement du client. Proposition d’utiliser des mesures AAA : accessibles, auditables, actionnables.

Cette démarche, Oana l’appelle le TDB : Test Driven Business. Un exemple concret en est donné avec sa présentation qui devient interactive et s’adapte à la satisfaction des participants.

LA phrase : « il faut produire juste ce qu’il faut, juste à temps ».

D’où l’inspiration Lean sur la prise de décision au dernier moment responsable pour disposer de toutes les bonnes informations.

Le constat d’échec : notre culture d’irréprochabilité (surtout en France) bride notre capacité à satisfaire le client et à lui fournir un produit/service utilisable. C’est dit !

A noter

Les enquêtes de VersionOne ont été citées dans plusieurs sessions.

Ils en parlent aussi

Olivier Azeau

Xavier Nopre

Fabrice Aimetti

Alexandre Boutin

Alexis Monville

Mathieu Cans

%d blogueurs aiment cette page :