Agile France 2014, Bonus Track

Comme chaque année, il y a de nombreuses sessions que je n’ai pu voir. Je vais tenter d’y remédier en partie dans ce post.

Pour rappel les autres présentations, celles auxquelles j’ai assisté, sont couvertes ici et ici pour la journée du Jeudi. Elles sont ici et ici pour le Vendredi.

Projets Agiles, arrêtez les dérives

Cyrille Deruelle, en plus de sa présentation sur l’amélioration continue, a proposé ce sujet sur les projets agiles. Quelques clés et rappels pour ne pas pervertir nos pratiques et garder le cap sur ce qui est important.

Patrick Bobo a par ailleurs développé le contenu de cette session dans un post.

Comment Cadrer un projet agile ?

Pas de support pour la session de Guillaume Duquesnay et Jean-Claude Grosjean, mais un très bon post de Pascal Poussard !

Désapprendre à « bien faire », pour « faire juste à temps »

Le support est un peu déroutant, plutôt « zen » comme j’aime bien. Mais il n’aidera pas nécessairement à comprendre la substance du propos de François.

L’holacracy, un “système d’exploitation” pour des entreprises agiles et sociocratiques

Damien nous parle d’un nouveau mode de gouvernance des entreprises. Tout est dans le titre. Regardez le teaser pour voir si vous y voyez un sujet d’intérêt !

Son lightning talk a par ailleurs été enregistré.

Le support de la présentation de Damien est aussi accessible.

Si l’holocracy vous intéresse, vous pouvez consulter sa constitution.

Devenir une organisation apprenante dans l’IT

Eric Siber était absent, mais Nathaniel a présenté le sujet pour deux. Nathaniel nous parle durant cette session entretien et montée en compétence : comment faire ? Quel est le cadre légal ou ce que l’entreprise peut concéder ? Quels moyens se donner soi-même ?

Penser nos organisations

Pablo nous propose une session dont le moins que l’on puisse dire est que son teaser est décallé !

La présentation de pablo nous parle de communication, de théorie des catastrophe et de bien autre chose. Toutefois le support sans le « live » de Pablo n’est pas évident…

Doublures en folies

Le teaser d’Olivier Azeau n’est pas mal non plus, dans le genre décallé !

La présentation elle-même… eh bien, ce n’est pas vraiment une présentation, mais plutôt une scènette ! Bref, ça devait valoir le coup d’oeil en live !

Product ownership dans le brouillard

Ce n’est pas vraiment la première fois que Gilles nous gratifie de cette présentation. Mais elle est de bonne qualité

Vendredi matin…

Un petit coup de Pablo Pernot pour nous mettre en jambes…

Je veux tester avec les utilisateurs – Je fais comment ?

Je voulais au départ assister à l’atelier de Sophie Freiermuth, puis j’ai changé d’avis a dernier moment ! J’espère que ce n’est que partie remise. En attendant, voici son teaser.

Petits Outils de Management Agile à l’usage des… Honnêtes Managers!

Pas vraiment de teaser pour la session de Jean-Claude en mode « show and tell » ! Mais il l’introduit néanmoins sur son blog.

Par ailleurs je vous recommande ce billet de blog qui en parle.

Lean Agile Camp

Dominique de Prémorel évoque l’élaboration du « petit guide du management lean » lors du Lean Agile Camp

Expérience d’un maître de donjons et dragons sur le management, ou comment trouver son style

Pas de support de présentation pour la session de Guillaume Duquesnay, mais un excellent billet de blog !

La culture du programmeur

Jean-Laurent de Morlhon nous avait déjà gratifié de cette présentation très dynamique au Scrum Day. En voici la présentation

Mon projet est plus gros que le tien

Seulement le teaser pour la présentation de Cyrille : désolé !

Retour d’expérience sur Coding Dojo et Mob Progamming en entreprise

Sujet à la mode s’il en est, Bernard Notariani évoque le coding dojo mais surtout le Mob Programming, le dernière tendance. Voici son teaser

Au secours, le Père Noël a perdu ses rennes !

Simon Jallais nous propose une session créative autour du thème du Père Noël. A la lecture du support, je n’ai rien compris ! Ferez-vous mieux que moi ?

Let’s sketch together

Cette session d’Alvin était également présente au ScrumDay 2014. En voici le support

On en parle aussi ailleurs

Sans avoir relevé tous les blogs parlant d’Agile France (loin s’en faut), en voici quelques uns :

Carnet de route : Agile France 2014 (4/4)

Nous voici arrivés au bout de notre périple. Les épisodes précédents sont disponibles ici et ici pour la journée du Jeudi, et ici pour le vendredi matin.

Au programme de cette dernière après-midi : des demi-sessions (dont la mienne) et une clôture de l’évènement toute particulière !

Matti Schneider : Petit board deviendra grand

Je ne connaissais pas Matti. Je dois dire qu’il m’a bluffé par son niveau de maturité en agilité et la qualité de ses analyses. Peut-être est-ce lié au fait qu’en plus d’être ingénieur, il est également étudiant en anthropologie ?

image

Matti évoque pour nous l’amélioration continue, avec une approche qui sort des très classiques rétrospective et est d’avantage « centrée artéfacts ».

Façonner nos outils

Le point essentiel de la présentation est l’utilisation d’un outil (oui !), en fait un tableau, qui va guider l’équipe d’une façon particulière : faire entrer en résonance le descriptif et le prescriptif par le biais de cet outil !

Quand un changement de workflow est pressenti : le tableau change et devient prescriptif. Et comme l’équipe suit ce tableau, il devient alors prescriptif. Le tableau évolue par le biais de l’équipe de production qui est elle-même une partie de l’outil de production ainsi décrit.

Le passage d’une étape à une autre fait l’objet d’un « point fixe » : un état que l’on sait parfaitement définir par lequel passe obligatoirement les items. En dehors de ces points fixes, la façon dont évoluent ces items peut varier !

Voilà qui rappelle une citation de McLuhan : nous façonnons nos outils et eux-même à leur tour nous façonnent ! Et la façon dont nous les façonnons passe au travers de nos interactions.

Reflection workshop

Cette approche, à la base une variante des classiques rétrospectives agiles, est issu de Crystal Clear d’Alistair Cockburn. L’incarnation qu’en fait Matti est au travers d’un board synthétisant les décisions prises au long des itérations ! On a donc une vue d’ensemble de la chose. Les règles sont d’abord simples (dans les premiers sprints) et deviennent de plus en plus pointues. Elles peuvent aussi être changées / abandonnées, on leur superposent alors un post-it bleu avec le numéro de l’itération à l’origine de ce changement.

Les tickets agissent comme des « reminders » évitant de réitérer une discussion sur laquelle il y a déjà eu un accord. Certains guides focalisent sur l’usage du board lui-même, une sorte de niveau méta…

Ce que j’en ai pensé

Une présentation remarquable qui traduit une maturité tout aussi remarquable. Ce fut ma présentation préférée de cette après-midi là.

Géry Derbier : Les jeux de langage de Ludwig Wittgenstein

Ce n’est pas souvent que Géry nous gratifie d’une session qui n’est pas un atelier. En fait, c’est la première fois que j’y assiste ! Géry avait envie de partager depuis longtemps ce qui l’attire sur la pensée de Ludwig Wittgenstein. Une session pas très facile à suivre et encore moins facile à retranscrire !

image

Le plus simple est problement de ne pas faire de retranscription. Je vais simplement relever certains éléments que j’ai noté au fur et à mesure de la présentation de Géry.

  • La primauté de l’acte sur la pensée.
  • La théorisation est vaine. Il est préférable de voir et décrire ou « déconstruire » précisément.
  • Comprendre n’est pas l’intellectualisation de quelque chose, mais l’aptitude à le faire.
  • Nous utilisons un langage : regardons comment il fonctionne.

Cette façon de pensée amène Géry, en tant que coach, à demander au coaché de « déconstruire » les constats par une question : comment le savez-vous ?

C’est aussi ce mode de pensée qui a amené Gery vers le solution focus qu’il voit comme une incarnation de la pensée de Wittgenstein.

Ce que j’en ai pensé

Une session difficile à suivre qui nous amène vers les sentiers d’une philosophie à contre-courant. Je ne suis certainement pas rompu à cet exercice (je n’ai même pas d’épreuve de philo dans mon bac technique !). Bref, je passe pour l’instant…

Pierre Hervouet : Manipulé à l’insu de mon plein gré

Hélas, j’ai assez peu suivi la session de Pierre. Il faut dire qu’elle précédait juste la mienne. Au minimum pour commencer, je peux vous en livrer le teaser.

Pourtant cette session s’articule autour d’un de mes sujets préférés : les biais cognitifs ! Pierre évoque ainsi quelques mécanismes :

L’ancrage

Le cerveau humain juge souvent en relatif. Si on fournit une référence, elle biaise les résultats obtenus, par le haut ou par le bas, suivant que le référence d’origine est haute ou basse respectivement !

Le planning poker, en exigeant que les cartes soient montrées en même temps cherchent à éradiquer ce biais.

image

L’identification

S’identifier à une personne est plus fort que s’adosser à des statistiques ! Le mécanisme des persona s’appuie sur cela (en lieu et place des rôles, plus abstraits).

Ce que j’en ai pensé

Essentiellement que je suis frustré de n’avoir pas mieux suivi cette session. Damnation ! Car le sujet m’intéresse au plus haut point. Mais je ne peux en vouloir qu’à moi-même. J’espère que le support ou mieux l’enregistrement sera bientôt disponible…

Christophe Addinquy : User Stories, what else ?

C’est mon tour ! Au programme une version plus dense, en partie raccourcie et en partie modifiée de ma présentation faite à Agile Grenoble 2013. J’ai dans ma liste de tâches, la rédaction de cette présentation sous forme d’article, comme je l’ai fait pour Scrum Shu Ha Ri.

Je publierai aussi sous peu la nouvelle version correspondante du support.

Les 10 buzzwords du hipster agile

Cette dernière demi-session ne fut pas ma préférée de l’après-midi, bien au contraire. Le but était en principe de démystifier certains de ces buzzwords, de les dégonfler. En fait, je me suis trouvé en désaccord avec nombre des assertions de Christopher et Hervé !

image
  • Lean Startup = XP + Product Management ! Bien sûr, Eric Rie est un ancien de XP. Un peu léger pour affirmer que Lean Startup est un réhabillage d’XP avec les idées de Steve Blank ! Il ya mieux et plus à dire d’autant que l’inspiration initiale est beaucoup plus « lean ». Dehors !
  • Le MVP n’est pas la réalisation minimale de mon produit. Je suis d’accord !
  • Le devops n’est pas un process ou un outil, mais la collaboration entre ops et dev : d’accord aussi !
  • Continuous deployment, ce n’est pas mettre en production des bug fixes tous les jours. Certainement, mais d’ou vient cette idée ?
  • Le Kanban, il doit suivre la définition d’Anderson ! Ce n’est pas lui qui a inventé le Kanban, et on peut aussi faire des proto-Kanban sans mettre en place de WIP initialement !
  • Le Proxy PO : Bon, nous sommes d’accord sur l’absurdité du concept !
  • La transformation agile d’entreprise. Une foutaise pour les orateurs. Certainement, si on mène cela comme un nouveau process et non comme un changement culturel et organisationnel !
  • La feature team : Désolé, je ne suis pas prêt à considérer comme un « nouveau buzz » quelque chose décrit par Ken Schwaber en 2004…
  • Le Design Thinking. Bien, là aussi je doute que les orateurs ait fait l’effort de rentrer dans le concept…
  • Agile. Oui c’est vrai le « on fait ça depuis longtemps mais on appelait pas ça comme ça », on l’entend réellement tous les jours.

Bref, pas enthousiasmé par cette session. Mais alors, pas du tout…

Fresque Finale

Le scribing était notre grand fil rouge de la conférence. Pour clore en beauté celui-ci, Romain nous a invité à élaborer en commun une grande fresque faisant le tour de la salle Belvédère. Un bel exercice !

image

Keynote de clôture ?

L’organisation d’Agile France nous réservait une petite surprise pour clore ces deux jours : une fausse session proposée avec talent par la compagnie des Z’Humbles.

image

Drôle et bien enlevé. C’est une façon originale de terminer cet Agile France !

Alors, cet Agile France 2014…

image

Une formule en grand changement pour cette nouvelle édition, avec deux après-midi à caractère spécifique, sans oublier le fil rouge de Romain. Toujours une grande qualité dans les sessions et la magie du Chalet de Porte Jaune ! Les organisateurs ont réellement redoublé d’efforts pour réussir cette nouvelle édition.

Carnet de route : Agile France 2014 (3/4)

Suite du compte rendu d’Agile France, après la journée de Jeudi disponible ici et ici.

De bon matin…

De bon matin, ce n’est pas moi. J’arrive à temps pour le café et discuter un peu avec les autres. Mais quand j’arrive, un petit groupe se livre déjà à des exercices de Qi Gong.

image

Je retrouve les autres dans la salle commune. On discute, Alex Tweet. Business as usual…

image

Assez plaisanté ! La journée va commencer, place à la keynote !

Coaching Teams Through Change

Rachel Davies nous avait déjà gratifié d’une session il y a peu lors du ScrumDay. Fort heureusement, ce ne fut pas la même. J’ai d’ailleurs préféré cette keynote.

Rachel travail pour Unruly, une société spécialisée dans le « social media advertising ». C’est un domaine où les spécifications changent véritablement tous les jours. L’objectif est ainsi de déployer effectivement tous les jours !

image

Le début d’un changement

Au début les départements produit et développement étaient deux directions séparées. C’est le départ du directeur produit qui a permit d’enclencher un changement de structure.

Ce changement, c’est l’organisation en équipes de 3 à 5 personnes pour développer le produit. Et pas seulement développer : ces équipes prennent en charge la totalité des activités entourant le développement : l’écriture des user stories, les tests, etc. Ce sont eux qui vont solliciter les différents interlocuteurs (produit, marketing, commercial) quand cela s’avère nécessaire. Pas de product Owner qui est la seule voix du client, l’équipe va parler directement à tous les interlocuteurs ! Parmi ces interlocuteurs, nombre d’entre-eux ne sont accéssibles qu’à distance : l’équipe utilise Google Hangout pour communiquer. La conversation s’engage avec les interlocuteurs pour trouver la plus petite chose utile à construire, ce qui nécessite de prendre en compte tous les point de vue.

Lone rangers et development owners

Tout le développement est réalisé en binômes. Mais les équipes sont constituées d’un nombre impair de personnes ! En fait, par rotation, l’une d’entre-elle est le « lone ranger ». Elles s’occupe de diverse choses dans l’équipe, mais pas du code de production. C’est aussi à cette personne que les intervenants extérieurs à l’équipe s’adressent, afin de ne pas perturber les binômes en train de travailler.

L’équipe a aussi développé l’idée de « owner of the development area » : un développeur plus expert au sein d’un sous-ensemble fonctionnel. C’est lui qui élabore une proposition par rapport à un besoin exprimé.
Les propositions sont traitées en planning meeting. Celui-ci n’est pas un planning meeting classique XP : seule la priorisation des propositions y est traitée, il n’y a pas d’engagement de charge. Ces planning sont donc très courts : ils n’excèdent pas 30 minutes !

Gold card

A l’image de ce que Kniberg décrit pour Spotify, Unruly fait des efforts particuliers par rapport au bien être des équipes. Outre divers évènements sociaux, la société applique la politique du 20% free time inspirée de Google (bien qu’elle disparaisse progressivement de Google, justement). Ici elle s’appelle « gold card day » et sert de sources d’inspiration pour creuser de nouvelles idées.

Ce que j’en ai pensé

Sans être exceptionnelle, cette présentation nous offre l’opportunité d’avoir un retour sur une organisation d’équipe différente de ce que l’on voit aujourd’hui :

  • Les itérations s’estompent au profit de la déliverie continue, mais des points de priorités réguliers contrebalancent l’effet « court terme » du flux.
  • Pas de « product owner » ici : c’est l’équipe qui fait le lien avec les divers interlocuteurs. Le périmètre de responsabilité de l’équipe s’accroit, mais on évite ainsi l’effet paravent du PO !

Je change mon programme à la dernière minute. Je choisis en 15 secondes d’aller à une présentation résolument technique. Grand bien m’en a pris !

Le mythe du framework agile

Jean-Baptiste Dusseault vient mettre fin à quelques idées reçues concernant ces frameworks qui doivent nous agilifier / faciliter la vie. Au départ de ce « ras le bol » un titre de livre : Agile Web Developement with Rails ! Même co-écrit par l’un des signataires du manifeste agile (et par l’auteur de Rails), ll y a un problème ici. Probablement plusieurs même. Le premier est la taille du livre : près de 500 pages !

Le framework maison

Mais commençons par le commencement. Et le commencement, puisque nous parlons ici de frameworks « full stack », c’est le fameux framework d’entreprise. Un bon point : nous n’avons que trop rencontré ces pantalonnades. Lâchons-nous, ça va faire du bien !

image

Le but de ces frameworks, c’est d’avoir le « meilleur du moment », tout bien branché ensemble. On met les pantoufles, on débranche le cerveau, et l’on peut tranquillement produire plein d’applications en un tournemain !
Sauf que ça ne se passe pas comme ça. Ces braves frameworks transforment notre vie en enfer !

Citons dans le désordre :

  • Prévus pour être simples, ils s’avèrent en fait ultra-compliqués ! Peut-être leur conception et leur réalisation par des « équipes transverses » explique-t-elle quelque chose ?
  • Ils sont difficiles à tester et très bugués. Là encore, leur réalisation détachée des projets n’a pas contribué à leur testabilité. Utilisés uniquement par quelques projets de l’entreprise (au mieux) le « durcissement » du framework n’a jamais vraiment eu lieu…
  • pas de support : souvent les équipes ayant réalisé le framework sont parties depuis longtemps…

Qu’en est-il des « full stack » reconnus ?

Ici on parle des rails, Play, etc… Ils nous font la même promesse d’accélérer les développement du sol au plafond. En vérité, ils prennent des décisions d’architecture pour nous ! Jean-Baptiste va plus loin : en déléguant les choix d’architecture au framework, on laisse celui-ci nous utiliser !

Nous n’utilisons pas les frameworks “full stack” : ce sont eux qui nous utilisent.

Ce biais a des conséquences, on va le voir bientôt.

D’où vient leur succès ? Ils permettent de faire très vite 80% de l’application. Mais on galère sur les 20% restant ! Généralement, la réalisation en suivant le tutorial va vraiment vite.

Hélas, ils encouragent certains comportement. La partie « basse » entité et persistance est plus ou moins câblée. Il n’est pas possible d’y intervenir facilement. Et les entités ressemblent beaucoup aux tables de la base de données (ça rappelle les outils RAD client/serveur). On hérite donc d’un couplage vertical sur la base de données.

En fait, le seul endroit où l’on peut réellement raccrocher du code, c’est le contrôleur ! On l’accroche comme on peut. Et si des comportements communs apparaissent dans le code tartiné sur deux contrôleurs, le seul moyen efficace de le partager est le copié-coller ! Beurk !

Bref nous obtenons :

  • Des architectures monolithiques.
  • Des frameworks optimisés pour l’écriture de code … mais pas pour sa maintenance !
  • Des couplages forts avec la représentation et la base de données.
  • De grosses difficultés pour sortir des clous via des « plugins » et autres joyeusetés du genre qui ont de grosses courbes d’apprentissage.
  • Une testabilité rarement au rendez-vous.

Mais alors, c’est quoi un framework agile ?

Plutôt que de framework agile, parlons d’architecture agile, et des propriétés qu’elle devrait avoir.

  • Elle doit nous permettre de retarder les décisions
  • Elle minimise les couplages.
  • Elle est facile à changer.Elle est testable (via TDD et ATDD)

Une proposition et des inspirations

Pour Jean-Baptiste Dusseault, une telle architecture c’est :

  • Au centre un véritable modèle du domaine d’inspiration DDD, comme les proposent l’architecture hexagonale d’Alistair Cockburn ou la Clean Architecture de Bob Martin. Ce modèle ne dépend de rien et ne connait pas la persistence ni aucun système tiers, mais expose une API métier.
  • Une couche « commandes » implémentant les cas d’utilisation du modèle du domaine. Des idées que l’on retrouve dans la Lean Architecture de Jim Coplien.
  • Au-dessus un couche d’accès type CQRS dialoguant en asynchrone avec la couche commande et routant différemment les évènements commande (vers la couche commande) des requêtes qui sont adressées directement à la couche d’accès à la base de données.

Bien sûr le postulat de cette architecture, c’est que le métier est au centre des préoccupations. On n’évoque pas non plus l’architecture en micro-services qui me semble pourtant adaptée mais peut-être pas facile à concilier avec une architecture hexagonale…

La présentation de Jean-Baptiste est évidemment en HTML5 et elle est accessible en ligne ici.

Ce que j’en ai pensé

Cette session est une agréable surprise. Si le bashing des « frameworks agile » ne fait que confirmer ce que je pensais, les idées développées sur l’architecture agile me font beaucoup plus réfléchir, pour ne pas dire qu’elles soulèvent mon enthousiasme !

Comment j’ai développé mon muscle de l’amélioration continue en faisant mes courses

Ayant décidé de bouleverser mon programme, je n’ai de nouveau que 2 minutes pour changer mon programme. De nouveau, c’est une bonne pioche avec la session de Cyrille Deruelle !

Tout d’abord : pourquoi faire des exercices d’amélioration ? Pour que cela devienne une habitude, rendre cela naturel. Et Cyrille s’est livré à cet exercice en faisant ses courses du Samedi : c’est drôle et instructif !

image

Bien sûr tout ça n’a pas très bien marché du premier coup (d’où la nécessité de s’améliorer). Au départ, Cyrille a essayé d’impliquer son épouse (Product Owner des courses) dans la résolution des problèmes qu’il rencontrait. C’est une première leçon :

Les gens se foutent de la manière dont nous résolvons les problèmes.

Au hasard des améliorations, on va trouver :

  • « t’as rien oublié » … où comment suivre que l’on a tout acheté ? A l’aide d’une liste de courses et d’un gros feutre noir (le stylo fin ne convient pas).
  • Grouper les courses par catégorie : afin d’optimiser le parcours dans le magasin.
  • Prendre une photo des rayonnages pour les produits compliqués … afin de permettre à son épouse d’indiquer le produit souhaité. Le choix de la lessive a été vaincu ainsi !
  • Gérer les dates limites de consommation en les pré-calculant par rapport aux courses suivantes : afin d’éviter les erreurs pendant les courses.
  • Sortir des éléments du process : Les packs d’eau, c’est ingérable ! Alors on ne les sort du processus standard et on fait de temps en temps des ravitaillements en eau (en grande quantité) !

Les conclusions de Cyrille

  • Mes problèmes sont mes problèmes : Il n’est pas possible de s’en décharger sur d’autres personnes.
  • Il n’y a pas de choses simples : l’amélioration continue est une quête !
  • Les actions d’amélioration sont fragiles et difficiles ; c’est une discipline de tous les jours.
  • Mesurer l’impact d’un problème, c’est déjà 50% de la résolution

Enfin parfois, les améliorations ne sont pas possible, c’est le CCMCCC : C’est Con Mais C’est Comme Ca !

Grâce aux actions d’amélioration, Cyrille n’a pas seulement rendu son processus de meilleure qualité et plus efficace, il l’a aussi rendu fun !

Ce que j’en ai pensé

Une très bonne session : amusante et instructive. Bravo !

Refactorer du Legacy

Pas besoin de changer de salle pour la session de Johan Martisson. J’ai rencontré Johan lors du ScrumDay 2014. Ou plus exactement, Jean-Laurent de Morlhon me l’avait présenté. D’ailleurs Jean-Laurent était là à cette session résolument intimiste orientée craftmanship, avec des vrais morceaux de « live coding ».

image

Johan nous parle et nous démontre son approche de la reprise en main du code legacy, à l’aide de la librairie ApprovalTests. Pour résumer l’approche en quelques points :

  • On construit un harnais de tests résolument temporaires de manière rustique mais rapide.
  • On construit de manière assez brutale des combinaisons de conditions d’entrée pour couvrir une combinatoire de cas couvrant l’espace du problème.
  • On exécute une première fois les tests pour constituer la référence, sans se soucier de la justesse des résultats : il s’agit juste du comportement courant de la librairie.
  • On vérifie la stabilité du comportement du soft en comparant les résultats par rapport à la référence.
  • Au fur et à mesure du refactoring, on construit des tests unitaires définitifs. On peut envisager de se débarrasser définitivement des tests temporaires, de manière progressive.
image

Ce que j’en ai pensé

Au début de la présentation, je mes suis demandé où Johan essayait de nous emmener et j’ai pris conscience avec un peu de retard de l’efficacité et de la rapidité avec laquelle Johan mettait en place son harnais de tests ! Je dois dire que c’est très convainquant. Une petite vidéo pour vous en convaincre.

J’avais prévu d’être un peu plus long sur le descriptif de ce que Johan nous a montré avec l’outil, mais il le fait mieux que moi sur son blog. Je vous invite donc à le lire.

Pause déjeuner

Par une curieuse coïncidence, c’est de nouveau avec Jean-Luc Lambert que j’ai échangé lors de cette pause. Et nous avons parlé éducation et « génération Y ». Jean-Luc évoque avec enthousiasme le challenge que représente l’enseignement avec cette population.

  • Elle ne prend pas pour acquis les propos de l’enseignant. Le cours magistral a une vertu pour le moins limitée.
  • Ils sont « multi-tâches ». C’est assez déroutant, mais il faut faire avec !
  • Ils sont réceptifs aux jeux et aux exercices libres. Les techniques type « from the back of the room » leur sont bien adapté.
  • Ils ont beaucoup d’autonomie et sont entreprenant.
  • Ils ne se sentent pas beaucoup d’attache ni de fidélité pour la société pour laquelle ils travaillent.

Voilà pour cette dernière matinée. Je vous retrouve très bientôt pour la dernière partie de cet Agile France 2014 !

Carnet de route : Agile France 2014 (2/4)

Suite de notre première journée d’Agile France.

On se dirige tout doucement vers l’activité de l’après-midi. Toutefois, nous allons avant cela prendre 10 minutes pour une photo de groupe !

image

Une formule inédite pour cette première après-midi : elle est entièrement consacrée à un open-space ! Cela rapelle un peu la formule du ScrumDay, elle-même inspirée d’Agile Grenoble. Mais peu importe qui emprunte à qui !

Open-space : ouverture !

Pour cette ouverture, nous nous retrouvons tous dans la grande salle Belvédère.

image

Ca fait du monde, vous en serez peut-être plus convaincus avec la vue panoramique ?

image

L’ouverture de cet open-space ressemble d’autant plus à celui du ScrumDay que c’est de nouveau Raphael Pierquin que l’on retrouve aux commandes !

image

Il n’est pas seul, Lan Levi lui donne la réplique.

image

Nous avons de la chance en ce Jeudi après-midi : la météo est avec nous ! On pourra se mettre à l’intérieur des salles et dehors. Dans ces conditions, le Chalet de la Porte Jaune est tout simplement l’endroit idéal pour faire un open-space. La place de marché nous permet d’utiliser tous ces lieux.

image

Qu’est-ce qu’un manager agile ?

J’ai trainé un moment du côté de la session proposée par Alain Buzzacaro sur le manager agile, avec l’envie de confronter mon expérience avec celle des autres, mais aussi d’avoir la perception d’un membre de Codir (ce qui est le cas d’Alain). J’ai vite été déçu par la teneur des échanges. En fait, il m’est apparu qu’une bonne partie de l’assistance n’avait aucune expérience du management. Ca n’empêche pas d’exprimer un avis, visiblement…

image

Parmi les quelques points relevés (histoire que vous ne pensiez pas que je n’ai rien relevé) :

  • L’agilité est un style de management.
  • Le manager est en partie un coach pour son équipe.
  • Son travail est de faire grandir son équipe. Merci Alain !
  • Donner du sens est une dimension importante de son travail.

J’applique la loi des deux pieds et vais voir ailleurs.

L’assertivité

Dommage que je n’ai pu assister depuis le début à la session animée par Mathilde Remy ! Arriver en cours de route m’empêche de bien raccrocher les wagons. Mathilde anime cette session sous forme d’un jeu de rôle.

image

Doublement dommage, d’ailleurs, car Farid se livre à l’exercice : son calme et son rationalisme sont terriblement efficace. J’en sais quelque chose, je l’avais moi-même recruté dans mon équipe il y a quelques années…

Je sens que vous voulez un nouveau petit panoramique ! Allez, hop !

image

Ah oui, n’oublions pas non plus le travail des scribers !

image

Comment amener mon directeur à l’agilité

Cette session est du vécu, un cas réel. Cela m’a semblé intéressant de m’y pencher. Disons, pour diverses raisons…

Au départ, il s’agissait de confronter les expériences, mais finalement nous sommes arrivés à réfléchir autour de ce cas particulier ! Le constat n’apporte pas beaucoup d’espace de manoeuvre :

  • Ce manager n’a pas de problème : pourquoi devrait-il changer ? Rien d’étonnant à ce que l’argumentaire ne porte pas.
  • Est-ce important que ce manager aille dans ce sens ? Ne peut-on « vivre avec » ? C’est hélas important : cette attitude a un impact notable sur l’équipe : démoralisation, départs…

Je ne suis de toute façon pas très bon à cet exercice. S’il fut un temps lointain où je m’y livrais, j’ai abandonné de puis très, très longtemps l’idée de chercher à convaincre des personnes qui n’ont pas envie de l’être.

En fait aujourd’hui je ne cherche plus à convaincre du tout. Ca ne m’intéresse pas, je n’ai pas une vocation de martyre. Je préfère travailler avec des gens qui ont envie d’avancer dans le même sens que moi, avec qui je pourrais me poser des question, que je pourrais aider.

De nouveau, nous avons été scribés en live avec talent !

image

Ces fresques valent largement ma prose, je vous laisse en profiter.

image

Et aussi…

image

Les accords Toltèque

Depuis le temps que j’en entend parler… Je n’ai pas hésité longtemps à rejoindre le petit groupe se formant autour de Frédéric Dufau-Joël sur ce sujet.

Les accords Toltèque nous viennent du peuple éponyme d’Amérique Centrale. Ces accords sont au nombre de 4 :

  • Que votre parole soit impeccable.
  • Quoi qu’il arrive, n’en faites pas une affaire personnelle.
  • Ne faites pas de suppositions.
  • Faites toujours de votre mieux.

Je trahis certainement un peu la chose en disant qu’il s’agit d’une sorte de manifeste de la facilitation … ou même d’une discipline de vie, si j’en crois ce que disent certaines personnes du cercle !

image

Frédéric anime la discussion autour de deux livres écrits par un Chamane Mexicain, Miguel Ruiz, dont le premier est justement le best seller « les 4 accords Toltèque ».

Autres lieux, autres sujets…

On ne peut être partout à la fois. Ailleurs, il y avait aussi :

La définition du bon coach

image

ou encore du théatre d’improvisation, avec Vincent et Simon !

image

Clôture de l’open-space

Nous nous retrouvons une dernière fois en salle Belvédère pour partager nos impressions.

image

L’intelligence collective, par Thibaud Brière

Thibaud est « philosophe en entreprise » ! Je ne savais même pas que cela existait !

Pourquoi s’intéresser à l’intelligence collective, et surtout : pourquoi les grandes entreprises s’y intéressent-elles ? Parce qu’aujourd’hui, elles veulent concilier l’avantage que leur donne leur taille avec la réactivité des startups ! L’intelligence collective est donc un moyen pour être plus adaptable.

Qu’est-ce que l’intelligence collective ?

C’est une dynamique de groupe s’appuyant sur la capacité à diverger. En ce sens, on entretient la pluralité de point de vue plutôt que la convergence, qui est en fait du mimétisme et finalement une abolition du raisonnement. Le point critique est de passer de l’opinion à la pensée ! Cela signifie bien entendu des techniques de facilitation adaptées.

image

Pour Thibaud Brière, la pensée, c’est une opinion (au départ) + la confrontation à d’autres opinions.

L’orateur différentie aussi diversité et variété, une nuance que je ne suis pas parvenu à saisir.

Ce que j’en ai pensé

J’ai retenu deux ou trois choses de cette intervention :

  • Différencier opinion et pensée.
  • Faire fonctionner la divergence (cela me rappelle la keynote de Régis) et valoriser les opinions minoritaires.
  • Encourager l’impertinence.

Je reste un peu sur ma faim. Il faut dire que le format choisit favorisait les interruptions, ce qui n’a peut-être pas aidé (toutes interruptions étaient loin d’être pertinentes).

Au sortir de la cette intervention, les avis étaient très partagés sur l’intérêt de du sujet.

Fin de journée

Pas de diner pour moi, la faute à un gros mal de tête. Visiblement, celui-ci fut bien animé, Alex Boutin s’en est chargé en préparant un quizz durant l’open space !

C’est tout pour aujourd’hui. Rendez-vous très bientôt !

Carnet de route : Agile France 2014 (1/4)

Agile France, c’est un rendez-vous incontournable. Enfin disons : sauf cas de force majeure. Le lieu reste le même et surtout fidèle à lui-même : le chalet de la porte jaune !

En arrivant, on est certain d’y trouver du café, mais surtout des connaissances et des amis. Ca commence bien !

image

L’organisation se fait aussi un point d’honneur d’être dans le timing. Et ça, ce n’est guère évident ! C’est Damien Thouvenin qui officie comme que maître de cérémonie cette année.

image

Avant de laisser place à la Keynote de Régis Médina, je voudrais souligner la formidable présence de Romain Couturier pour animer un scribing en continu lors de cet Agile France. Il a également initié plusieurs groupes à son art, qui se sont aussi jeté à l’eau pour capturer les sessions de l’open-space !

image

Le produit, prochaine frontière de l’agilité

Le Product Management, c’est un sujet plutôt « trendy » en ce moment. Régis va l’évoquer pour nous avec sa sensibilité Lean.

Le bon vieux temps

Autrefois, avant l’agile, on produisait les logiciels en phase. Arrivait la phase de tests. En fait, le moment où commençait vraiment le projet. Parfois, tout était purement et simplement jeté à la poubelle. mais on sait maîtriser cela désormais. Hélas, la récompense pour un problème résolu, c’est un nouveau problème !

Le nouveau problème, c’est que nos utilisateurs veulent plus et plus vite : ils ont des services en ligne accessibles depuis partout, des applications mobiles … Ils ne sont plus dupes ! Le niveau monte, il n’y a plus le choix : il faut produire un SUPER logiciel !

Obtenir le whaou effect !

Et déjà, deux trucs pour ne pas l’obtenir:

  • « design par comitee ». Ici les Product Owner ne servent que d’aiguillage entre des besoins plus ou moins divergents.
  • Fonctionner en flux à l’extrême. Le revers du flux, ce de ne porter son attention sue sur des petits bouts.

Alors quelle solution ?

image

Le Lean Startup offre une partie de la solution, mais il n’offre pas de réponse aux points de vue antagonistes, ni à la résolution des contraintes. Régis préfère orienter son regard vers le Lean Engineering, où un chef d’orchestre (et un seul) porte la vision du client (vous avez dit « product owner » ?). Bien. Mais quels caractéristiques, quelles aptitudes doit posséder ce chef d’orchestre.

Si l’on regarde les grands chief engineers, on voit que l’une de leur caractéristique commune est leur capacité à dire « non ». Mais comme on s’en doute, cela ne suffit pas. L’orateur évoque pour nous trois compétences clé.

Trois compétences

Positionner le challenge : c’est le chief engineer qui donne la direction et place la barre. S’il ne le fait pas, les personnes de l’équipe se trouveront individuellement leur propres challenges ! Positionner le challenge, c’est aussi identifier les paramètres clé, ceux que l’on aura déterminés en allant voir sur le terrain.

Cultiver le désaccord : Lister les options s’offrant à nous de manière crédibles et les attaquer de front (set based design).

Dénicher les erreurs : En ayant un niveau d’exigence élevé, obligeant à voir et revoir sans cesse les solutions adoptées. La voie empruntée ici est celle de la résolution des problèmes.

image

Ce que j’en ai pensé

C’est toujours un plaisir d’écouter Régis. Et ses interventions sont toujours d’excellente qualité. Je ne peux qu’abonder dans le sens qu’il évoque, même si je trouverais certains autres points à appuyer, comme l’importance du feedback (bien couvert par le Lean Startup dans ce cas).

Cela ne révolutionne pas non plus mon image du product management, j’y trouve les éléments que j’avais déjà, à l’exception sans doute du « cultiver le désaccord » qui donne un peu à réfléchir. Curieusement ce point sera aussi abordé dans une autre session ! Mais c’est aussi un aspect que l’on retrouve aussi dans le design thinking…

Le mot de l’organisation

Avant d’aborder la suite du programmes, nous avons droit aux pitches de la première journée : 30 secondes par orateur, c’est vraiment court ! On a aussi le mot de l’association, par la voix de son président, Emmanuel Gaillot.

image

L’an dernier, Emmanuel nous avait gratifié d’une tirade pour le moins asez sèche, assis sur une chaise. Pas terrible. Je ne sais s’il a lu mon compte-rendu, mais cette année c’est débout qu’il s’est exprimé, avec un verbe moins acerbe et nettement teinté d’humour, et avec le même message. Ca change tout ! Kudo, Emmanuel !

Il est temps de rejoindre la session suivante. Moi, je ne change pas de salle car Pascal Van Cauwenberghe fait son talk avec Jacques Couvreur dans celle-ci.

La simplicité : Pas facile !

Je ne savais pas à quoi m’attendre pour cette session (dont je n’avais même pas pris la peine de lire le résumé). La simplicité, ce n’est effectivement pas facile, car elle nécessite avant tout de définir ce qu’est la simplicité !

Pour nous aider dans notre quête, Pascal et Jacques vont plonger dans la substance proposée dans deux ouvrages.

The Laws of simplicity

Le livre de John Maeda nous propose 10 lois que nous passons revue.

1 – La réduction : Ne laisser apparents que la fonction et le message.C’est donner une apparence de simplicité.

2 – Organisation : Ranger les éléments pour donner une impression de simplicité.

3 – Lutter contre les temps d’attente : l’attente donne une impression de complexité. Exhiber un élément dynamique comme une barre de progression atténue cela.

4 – L’apprentissage : Elle couvre deux niveaux :

  • L’apprentissage immédiat : c’est permettre la découverte.
  • La maîtrise, qui intègre une notion de dynamique.
image

5 – La différence (Jacques est resté sec là dessus)

6 – Le contexte : un concept difficile à saisir, mais qui tempère d’un « ni trop, ni trop peu » cette notion de simplicité.

7 – L’émotion : La simplicité est aussi un facteur non rationnel.

8 – La confiance : C’est offrir un contexte sécurisé, permettant de faire et défaire sans crainte.

9 – L’Echec : Parfois, on ne peut pas tout simplifier. Mais essayer permet d’apprendre.

10 – La loi cardinale : Moins d’évidence et plus de sens.

Bon, je reste un peu sur a fin avec cet énoncé de concepts. Certains éléments de la liste me parlent un peu, mais cela manque de substance. Passons au second opus.

The Laws of Substraction

Le livre de Matthew E. May livre à son tour 6 règles.

1 – Ce qui n’est pas là est parfois plus important que ce qui est là. Pascal rapproche ce point de la loi de Conway. Améliorer l’environnement (en éliminant des barrière) peut améliorer le produit.

2 – Les règles simples produisent les expériences les plus productives. Pascal nous propose deux choses à essayer en ce sens :

  • Quelles règles (qui protègent) peut-on supprimer ?
  • « abandonner » l’application aux utilisateurs.

4 – Ajouter des contraintes. Pour déclencher de nouveaux comportements, on peut par exemple : réduire la durée des itérations, réduire la durée entre 2 commits, etc..

5 – Parfois, il faut casser pour percer. Ne pas avoir peur des crises…

6 – Parfois, ne rien faire c’est mieux !

Je sais, il me manque l’item numéro 3 : désolé !

Ce que j’en ai pensé

Je suis un fan des présentations de Pascal. Cette fois, je suis resté sur ma faim. Mais néanmoins, je serais bien là aux prochaines présentations de Jacques et Pascal !

Le prochain créneau nous propose des lightning talks. Mon choix est fait depuis longtemps !

Tim Gallwey ou comment le coaching a commencé

Christophe Keromen nous a proposé une session une session de 20 minutes passionnante commençant par un échec : celui de Tim Gallwey, alors champion de tennis, ratant la balle de match d’une demi-finale de championnat (et le match par la même occasion). Ainsi commence le constat : nous sommes tous nos propres saboteurs ! Nous avons du potentiel, mais nous faisons moins que ce que nous sommes capables de réellement faire. D’où l’équation :

Performance = potentiel – interférences

Quand « self 1 » gêne « self 2 »

Nous interférons avec nous-même.

image

Notre « self 1 » représente l’égo, le moi rationnel, tandis que « self 2 » représente le corps et l’inconscient. Lorsque nous laissons « self 1 » interagir, nous provoquons un ralentissement, une diminution de notre probabilité de réussir. Ce point est appuyé par les neuroscience qui affirment que la quasi-totalité des informations dont nous disposons est inconsciente.

A quoi cela peut-il me servir ?

Christophe nous propose deux axes.

L’apprentissage. Les images sont supérieures aux mots. On apprend mieux par mimétisme sans chercher à décrire ou à rationaliser ce que nous faisons (sinon nous rappelons « self 1 »).

Les habitudes. Nous créons des habitudes pour répondre à un contexte qui est souvent la marque du passé, bien que répondant à une intension positive. Il faut remplacer ces habitudes par de nouvelles, répondant aux mêmes intentions, mais adaptées au contexte présent.

Ce que j’en ai pense

Christophe a superbement abordé le sujet. Me voici avec encore un sujet à potasser. Je retiens dans l’immédiat la prédominance de l’exemple sur la formulation littéraire.

Pas la peine de bouger de place pour la prochaine présentation qui se déroulera dans la même salle. Tant mieux pour moi, car ça se bouscule !

La rétrospective continue

C’est en duo et dans une salle comble que Régis Médina et Antoine Contal nous ont proposé leur session. Toutes les places sont prises et une partie du public est debout !

image

Evidemment, comme on peu s’y attendre, Antoine et Regis nous parleront de Lean. La clé des retrospectives réussies, celles qui progressent au lieu de s’enliser se situe hors des rétrospectives : c’est créer un environnement où l’équipe progresse. Continuellement.

Dans ce cadre, le rôle du coach devient celui du coach sportif : il aide à poser le challenge.

Le challenge !

Forcément, sur un projet, le challenge est un concept plus flou que pour un sportif. Mais c’est posible en prenant en compte ce qui est important pour le projet. Il n’y a pas de recette miracle.

  • Le sourire du client
  • Le lien avec l’argent. Le flouze, quoi !
  • La stratégie
image

Pour un manager, les dimensions à prendre en compte pourront être :

  • Qualité du code.
  • Délai de livraison.
  • Productivité (même si ce facteur est à prendre avec prudence).

Finalement, il faut trouver le moyen de rendre ce challenge visuel (indicateur, progression…).

Un apprentissage individuel

Une fois posé le challenge, il faut le décliner en petits exercices d’amélioration individuel : chaque action d’amélioration doit avoir son porteur. Ce porteur devient expert du sujet, et il profite ensuite des rétrospectives pour partager son savoir !

Chaque action d’amélioration se décline en expérimentations suivant le cycle PDCA : ce sont des Katas.

image

Finalement une bonne nouvelle, mais…

La bonne nouvelle, c’est que l’on peut garder les rétrospectives. Elles deviennent un lieu d’échange des nouvelles pratiques.
Il y a aussi un prix à payer :

  • Ecouter les managers
  • Ecouter la réalité plutôt que ses envies
  • Persévérer

Les bénéfices en contrepartie :

  • On peut avoir un impact
  • Quand ça marche, le comportement des personnes change.

Enfin, Antoine et Régis nous proposes des exercices à faire en rentrant

  • Aller voir et écouter le client
  • Construire le modèle économique du produit
  • Questionner un directeur sur les objectifs stratégiques
  • Mettre en place un indicateur
  • Commencer avec un problème dont nous (en tant que coach) connaissons la réponse.

Ce que j’en ai pensé

Comme d’habitude, avec Antoine et Régis, c’est du lourd comme disent les jeunes. On prend cher au passage aussi : leur sessions sont aussi intéressantes que déprimantes. Mais ça tombe bien, les actions d’amélioration sont au centre de ce que j’ai à faire en ce moment !

Pause déjeuner

Je ne reviens pas sur la qualité de la la restauration d’Agile France, j’en ai déjà longuement parlé l’an dernier !

Le déjeuner, c’est surtout l’occasion d’échanger avec les personnes que l’on apprécie (il y en a beaucoup !). Ce midi, ce sera avec Nathaliel Richand et Jean-Luc Lambert. Bien sûr, nous évoquons un peu le Printemps Agile, mais nous parlons surtout enseignement : Nathaniel voudrait développer des MOOCs agile, ce qui est dans les tendances du moment, mais peu compatible avec un enseignement de plus en plus par le jeux et « from the back of the room »…

image

Sans doute il y a-t-il complémentarité entre les deux modes, en utilisant les MOOCs pour des sujets plus étroits, pour lesquels il serait difficile d’organiser des sessions, donc plus avancés.

Voilà, ce sera tout pour aujourd’hui. Je vous donne rendez-vous très bientôt pour le déroulement de l’après-midi.

Agile France 2014 : J’y serais, et vous ?

On est encore un peu loin de la date fatidique, mais c’est bien maintenant que le programme se construit pour les 22 et 23 Mai au traditionnel rendez-vous du Chalet de la Porte Jaune !

Je cours en seconde division cette année : je présenterais une version “Lightning Talk” de ma session de Grenoble : User Stories, what else ?

La version 45 minutes était déjà pas mal dense, il va me falloir être pas mal créatif pour en faire une version 15 minutes sans assasiner l’auditoire tout en n’abdiquant pas sur le contenu : beau challenge !

Moi qui voulait ralentir un peu le rythme en faisant (comme mes confrères) un peu de réutilisation de mes présentations, il semble que cela devra attendre un peu ! Il faudra que je fasse quelques statistiques sur le sujet, la ratio de mes “présentations exclusives”, donc celles que je ne donne qu’une seule fois, dépasse largement les 50%. Et je n’ai jamais servi aucune d’entre-elle plus de deux fois.

Et le teasing, alors ?

Bien sûr, vous n’y échapperez pas ! Le voici.

Les users stories sont rapidement devenus la formulation convenue du besoin. Mais est-ce la seule ? Est-ce toujours la meilleure ? On dit que quand on a un marteau, tout ressemble à un clou. Notre communauté agile tend à ignorer ce qui vient d’ailleurs. Pourtant ce qu’on appelle l’ingénierie des exigences est un domaine riche de plusieurs décennies de connaissances et de techniques. Certaines peuvent être utilisées directement, d’autres doivent être adaptées ou peuvent servir d’inspiration.

Au cours de ce Lightning Talk, nous allons passer en revue plusieurs techniques et concepts du recueil des besoins et les regarder par le prisme de nos pratiques agiles, afin d’évaluer comment elles peuvent renforcer nos pratiques actuelles.

Je vous rappelle le lien vers le site de la conférence Agile France.

A très bientôt !

Agile France 2014 : J’y serais, et vous ?

Agile France 2013, bonus track

J’ai couvert tout ce à quoi j’ai assisté … mais il y a en a beaucoup auxquelles je n’ai pas assisté. J’ai essayé de rassembler ici le matériel éparse sur lequel j’ai pu mettre la main.

J’en rate beaucoup, j’en suis sûr. Si vous avez d’autres liens, faites suivre ! Je les ajouterais.

Blogs et autres liens utiles

Les autres présentations

Ne cherchez pas un ordre corrélé au programme, ce n’est pas le cas. Have fun !

L’agilité en maintenance logicielle

Communautés de pratiques en pratique

Sport et théatre avec Christophe Keromen

Christophe nous proposait 2 présentations. Tout d’abord, ce que le sport m’a appris de l’agilité

Puis la même déclinaison à propos du théâtre

Peter Stevens : Agile values, French values

Les paradoxes du leadership

Les articles qui parlent des autres présentations

Retours sur Agile France 2013, dernière partie (en images)

Dernière ligne droite pour cet Agile France 2013 !

Pour ceux qui n’auraient pas suivi les épisodes précédents, nous avons :

Les épisodes du Jeudi :

Pour le vendredi :

Projetons-nous directement au début d’après-midi où nous avons rendez-vous avec …

Laurent Bossavit : L’art d’avoir tort

Il manquait à notre main la quatrième carte de mon carré d’as. La voici. Il ne devrait pas être la peine de présenter Laurent Bossavit qui fut non seulement un des membres fondateurs de cette conférence, mais aussi une des figures marquantes de l’agilité en France depuis 12 ans ! Evangéliste, auteur, infatigable chercheur et bien d’autres choses encore, il est aussi à l’origine de l’institut Agile qui est aujourd’hui, selon ses propres mots, plus un hobby qu’un travail.

agileFrance2013-15Bossavit01

Laurent nous promet pour cet atelier :

  • 3 exercices interactifs (en fait, nous n’en ferons que deux, pour des questions de temps).
  • 1 super-pouvoir
  • 2 sites Web
  • 1 page de pub

Commençons par une question: pourquoi la question des estimations donne-t-elle lieu à tant de discussions enflammées (pour ne pas dire plus) ? Parce que l’on voir le monde en noir et blanc !

Le but de cet atelier est de sortir de ce mode de pensée binaire pour rentrer dans une logique probabiliste. C’est aussi grâce à ce mode de pensée que l’on va pouvoir se diriger vers une logique d’amélioration en travaillant sur nos intervals de confiance.

Assez pour l’introduction. Au boulot !

1er exercice

Ce premier exercice est largement inspiré d’un exercice de Steve McConnel extrait de cet ouvrage. L’objectif est de donner des réponses aux questions posées avec un interval de confiance de 90%. Allons-y !

agileFrance2013-15Bossavit02

En tant qu’informaticiens aguerris, nous savons que nous avons tendance à être optimistes. Plus amusant : en sachant cela et sachant même que l’exercice veut montrer cela, nous donnons dans le panneau. En relevant les copies, l’interval que nous avons voulu de 90% se révèle plutôt être de 50%. Votre serviteur n’a pas échappé à la chose : je n’ai réussi qu’un médiocre 5/10 !

Quel est notre problème ? C’est ce que Laurent appelle un “problème de calibration du hardware” !

Connais-toi toi-même

Voilà donc où il faut travailler : apprendre à connaitre notre propre cerveau : MON incertitude m’intéresse plus que les faits !

Dans son ouvrage “Expert Political Judgment”, Philip Tetlock présente des tests de pronostiques politiques auprès d’experts mondiaux reconnus. Les résultats parlent d’eux-mêmes:

  • 15% des évènements qualifiés “d’impossibles” par ces experts ont effectivement eu lieu.
  • 27% des évènement jugés par ces mêmes experts “d’absolument certains” ne se sont pas produits.

Le problème est un problème de calibration de l’écart de confiance. Dans le principe, il est facile à adresser: il suffit d’élargir l’interval de confiance !

Calibration = %confiance – %fausses réponses

Second exercice

Dans ce second exercice, Laurent nous propose une série d’affirmations. Nous devons nous prononcer sur celles-ci avec un pourcentage de confiance. On jauge nos réponses en utilisant le “score de Brier” originellement utilisé en météorologie. On obtient le moins de points en donnant réponse juste avec un pourcentage de confiance élevé, mais un maximum de points dans le cas contraire.

image

Le but est d’obtenir le minimum de points. On peut connaitre notre capacité de résolution à partir de là :

Résolution = %réponse vrais / %réponses fausses

En fait, ces deux exercices nous guident vers des directions qui peuvent paraître divergentes :

  • Je suis bien calibré : je ne me mouille pas dans mes estimations
  • Je veux m’améliorer en résolution : je dois me mouiller.

En travaillant sur ces deux fronts, nous allons acquérir notre super-pouvoir : SuperGeek !

super-geek2

Conclusions et références recommandée

Pour aller plus loin, il faut travailler, comme toujours ! Laurent nous propose de le faire via deux sites :

  • Pour enregistrer et suivre nos prédictions : predictionbook ; ça, c’est pour l’approche “fun”.
  • Philip Tetlock mène des études très sérieuses à l’aide de groupe de travail. On peut s’y joindre sur goodjudgement mais c’est visiblement assez prenant.

L’un des effets de bord positif de cet approche, de l’expérience même de Laurent, est qu’elle permet de prendre de la distance par rapport à un évènement à venir. Dans le cas de Laurent, un jugement au tribunal !

Quelques références bibliographiques :

C’est vrai, Laurent nous avait aussi promis une page de pub ! Elle concerne son livre paru sur LeanPub

Pour finir, qualques posts sur la même présentation, faite cettefois-ci lors du ScrumDay :

Alfred Almendra : Un peu d’UX pour innover efficacement

Alfred nous propose un atelier pour imaginer un MVP à la Lean Startup, en utilisant un peu d’UX !

Cet atelier est inspiré d’un atelier réalisé par Ariadna Font. Nous allons avoir un temps très limité pour réaliser une première ébauche de notre MVP. Plutôt qua de rentrer dans de longues explications, jetons-nous dans le bain ! 6 étapes en tout et pour tout. Et ça rigole pas ! Enfin si, quand même un peu…

Etape 1 : La carte d’empathie

On avait le choix entre deux sujets. Je suis très fier d’avoir convaincu les personnes de mon groupe d’avoir choisi un autre sujet : nous allons réaliser Funky Shirt, un service permettant de réaliser des chemises uniques et custosmisées … et bien sûr, Funky !

agileFrance2013-16Almendra04

La carte d’empathie nous permet de parler aux émotions : ce qu’on pense et ressent, ce que l’on entend, ce que l’on voit, ainsi que les problèmes et les besoins. Nous avons 10 minutes pour cela. C’est un peu court et c’est un peu le rush.

Etape 2 : Le pitch

En utilisant le fameux “elevator statement. Il pouvait servir de base à notre pitch … ou nous pouvions utiliser autre chose. C’est ce que nous avons fait. La clé étant de mettre en avant la proposition de valeur essentielle et l’aspect différenciant.

agileFrance2013-16Almendra03

Les 10 minutes étaient aussi un peu serrées, mais c’était déjà moins la panique qu’à l’étape précédente.

Etape 3 : Prototypage

C’est une application mobile ! Donc à nous de réaliser la "landing page” de cette application, plus une ou deux autres. Mais si possible une seule autre. 15 minutes pour ça !

Etape 4 : Test utilisateur

Une personne de chaque groupe va tester l’application d’un autre groupe. Elle se tient à bonne distance, le groupe reste silencieux et observe le testeur. Celui-ci décrit à haute voix ce qu’il observe et la façon dont il réagit.

Etape 5 : Prototypage

Sur la base de ce feedback, nous avions le droit de faire 1 modifications. En fait, on en a bien fait 2 ou trois. Hum… 5 minutes de modifications et nouveau cycle de feedback !

Etape 6 : Test utilisateur

Cette fois, c’est moi qui fait le beta testeur sur un autre MVP. Une ergonomie meilleure que chez nous, je dois dire …

Ce que j’en ai pensé

J’aime bien l’idée de ces ateliers en cycle court. Cet atelier-ci était probablement un peu surpeuplé pour qu’Alfred puisse en faire une facilitation efficace. J’ai bien aimé que nous ayons essayé de développer une idée originale ! Je retiens toutefois que :

  • On pouvait essayer de travailler sur une idée existante, pas nécessairement super-originale et faire quelque chose de potable dans le timing.
  • Ou l’on pouvait essayer d’être beaucoup plus original et alors le timing devenait un peu plus contraignant.

Bien sûr, la seconde idée me semble plus porteuse, mais il aurait fallu 1,5 ou 2 fois plus de temps…

En prime, voici le support d’ariadna Font dont Alfred s’est inspiré.

Remy-Christophe Schermesser : Tester autrement, le guide du testeur intergalactique

Ca sent la fin de cet Agile France : j’ai eu du mal à me décider sur la dernière session. Et en plus j’arrive en retard, largement en retard. L’orateur a commencé depuis un bon moment.

agileFrance2013-17Tests01

Remy-Christophe nous propose de nous détacher un moment de nos problématiques de langage “tel langage se teste mieux que tel autre…” et de reflechir à l’expressivité de nos tests.

JUnit, c’est bien mais on en atteint rapidement les limites, surtout en terme de lisibilité. Et surtout en terme d’expressivité quand on veut tester un comportement.

Il y a-t-il un espoir de ce côté ? Oui, il s’appelle RSpec ! Le DSL de RSpec permet de décrire ce qui est attendu !

Autre problème : le test des combinatoires. Nécessiare à une bonne couverture, il l’est aussi au traitement des différents cas sur les tests fonctionnels. La réponse s’apelle ici : mutations ! Ecrire un test et le faire muter, cela peut se faire avec Javalanche. La création de ces mutants peut toutefois conduire à des explosions combinatoires allongeant de manière exagérée la durée d’execution des tests. Il faut tuer sans pitié les combinaisons inutiles ou redondantes.

3ème volet : le property testing. ScalaCheck permet la génération automatique de cas de tests en se basnt sur la description des propriétés au sens mathématique du terme ! A n’utiliser que pour les sections de code critique, car là aussi l’inflation des temps d’execution des tests nous guette au tournant !

This is the end

Ici s’achève pour moi l’édition 2013 d’Agile France où j’étais présent cette année en touriste. J’aimerais l’être moins l’an prochain, nous verrons ce que l’édition 2014 nous réservera !

agile-france-4-1691