Troisième volet de mon retour sur l’agile Nantes (les parties 1 et 2 sont là et là), voici le programme de l’après-midi

Le paradigme de l’ingénieur dans un imaginaire ubiquitaire

Cette keynote originale nous était présentée par des membres de la compagnie “La Machine” qui, de projets en projets, construit des mécaniques savantes en faisant collaborer ensemble de multiples corps de métier en les faisant interagir en permanence, à l’image de ce que nous faisons dans nos projets agiles, par opposition à l’entreprise traditionelle où règne le “product lifecycke management”.

Le fil conducteur de l’entreprise ne sont pas les projets, mais une vision d’ensemble insufflée par son créateur et directeur artistique François Delarozière : l’imaginaire !

Les machines, comme des êtres vivants passent par 3 phases:

• La prototype. la machine est assemblée pour en faire fonctionner les différentes parties … avant d’être désassemblée pour être finie, traitée, peinte, etc…
• L’adolescence. La machine est utilisée dans des manifestations et des spectacles, manipulée et montée par des membres de la compagnie.
• L’autonomie (le machine de ville). la machine est revue afin de respecter les normes lui permettant d’être accessible par le public.

A la base de l’entreprise, il y a un meneur, François Delarozière que nous avons déjà nommé. C’est lui qui initie les différents projets. Et au départ de chacun d’entre eux il y a une histoire qui inspire dessins et mises en mouvements.

Une fois le concept posé et les premières idées arrêtées, il y a des réunions avec les différents corps de métier. L’équipe de réalisation est une équipe intégrée regroupant tous les corps de métier : Ingénieurs structure, mécaniciens, hydrauliciens, menuisiers, soudeurs, etc… Il y a une transparence totale sur les travail effectué par les différents membres. On ne parle plus de stand-up quotidien mais de boucles de feedback en continu, toute la journée.

Cet esprit d’équipe est résumé de manière humoristique “on collabore et on travail vraiment en équipe : on ne finit jamais complètement nos tâches, on en laisse pour les autres !”. Pourquoi un ingénieur structure devrait-il donner des précisions sur la réalisation d’une soudure ? Le soudeur connait son travail, mieux même que l’ingénieur ! Il saura poser des questions d’il a besoin de précisions. De toute manière à quoi bon spécifier les détails ? Ce que l’on fera au final sera différent !

L’équipe n’est pas seulement collaborative, elle est aussi plurielle et pluridisciplinaire : ceux qui conçoivente et construisent les machines seront aussi ceux qui les manipuleront et les monteront. Tous ! Comme le disent si bien les membres de la compagnie “on n’a pas vraiment le choix” !

Chaque réalisation de La machine est quelque chose de différent, un nouveau challenge, dont on ne sait pas au départ comment il sera adressé ! Mais tout ceci se réalise plus facilement quand on travaille tous ensemble, dans le même bureau.

PO et culture Agile: potion magique du succès de l’entreprise !

Frédéric Dufau-Joel nous a proposé une session une session au format original : le fish bowl. Frédéric a fait disposer les chaises en cercle, en disposant un petit cercle intérieur de 5 chaises dans lequel il s’est installé. L’un des chaises devant rester vide (la plupart du temps) les autres sont prêtes à acceuillir les personnes déirant poursuivre le débat en posant une question à Frédéric. Quand la dernière chaise est occupée, la personne la plus ancienne dans le cercle doit rendre sa place.

Bref, au lieu d’éliminer du “bottleneck”, on va plutôt en créer afin de réguler le débat. C’est une application du WIP du Kanban, si on veut bien …

Le principal, pour ne pas dire le plus surprenant, c’est que ça marche !

Revenons au thème de la session, c’est à dire le PO en tant que potion magique. Frédéric nous a fait partagé son retour sur l’imporatnce du PO dans le succès des projets au sein de son entreprise. Il identifie plusieurs facteurs de succès.

Les PO viennent des métiers. Cette transition d’un rôle opérationnel vers ce rôle de PO est valorisé et est même un templin pour leur carrière !

Le casting est important. Tout le monde n’a pas le profil pour être PO. La connaissance méier ne suffit pas, car le PO est un agent de changement qui doit aussi travailler très près des utilisateurs. De plus, le formation de binômes sénior / junior aide à la parformance sur les projets, ainsi qu’à la continuité.

Une logique d’amélioration. Frédéric ne parle plus de projets informatiques. Ce sont des projets d’entreprise, des projets d’amélioration. Encore une fois, les PO sont des agents du changements.

Un dernier point que j’ai noté en outre : A la question sur la mesure sur le ROI des projets, Fréderic a dit qu’il n’en faisait aucun, à part le sourire des utilisateurs et des décideurs ! Une belle forme de conclusion.

Apologie du mur

La présentation d’Axel était certainement un peu légère, et j’avoue n’y avoir rien appris. Mais elle était fort bien présentée avec entrain et humour : une touche de légèreté et de différence que j’ai apprécié à cette heure de la journée. En fait je n’ai pas regretté mon choix, ce que je dis plutôt rarement, peut-être même jamais lorsque je pense ne rien apprendre !

Mais revenons sur cette présentation. Elle s’appuie sur 3 histoires vécues présentées de manière vivante et avec humour.

La première histoire est celle d’une équipe s’enlisant dans sa stratégie de test. C’est le prix “pas de bol”. Ca arrive, et ça arrivera encore. Elle s’en est sortie en trouvant finalement le bon outil de test fonctionnel.

La seconde histoire est celle d’une équipe présentant une vélocité affichée n’ayant rien à voir avec la vélocité réelle. Une belle illustration de Death March avec son cortège de conséquences habituelles : bugs, pataches, baisse de la qualité et burn out. C’est le prix “mérité”. Pour s’en sortir, il a fallu un retour aux sources sur la qualité et la définition of done … et essuyer la date pendant un petit moment.

La troisième histoire démarre par un Product Owner fort zélé arrivant avec un backlog simplifié… de 4 items ! C’est le prix “inattendu”. Il a fallu reculer le démarrage du projet afin de pouvoir retravailler le backlog avec l’équipe afin qu’il ait une granularité présentant des items appréhendables.

Quelles leçons retirer de ces histoires ?

D’abord que les murs en gestion de projet prédictive sont dangereux. Ils peuvent même signer la mort du projet.

En mode agile, on a comme premier reflexe de cacher tout autant ces murs que l’on voit parfois arriver et qui font peur. C’est une réminiscence de l’ancien mode. Pourtant ils nous apprenent des choses. C’est même eux qui forment la plus grande part de notre apprentissage. On doit leur faire face et en sortir les enseignements lors des rétrospectives.

Pour résumer, en 4 points :

• N’ayons pas peur des murs !
• De toute façon, on va s’en prendre !
• Evitons quand même les gros murs, ne soyons pas kamikazes !
• Sachons les écouter et affichons (sur des murs physiques cette fois).

Des mots, des maux ? Démo !

Je n’avais pas encore eu l’occasion d’assister à la présentation de ma collègue Caroline Damour et ex-collègue Emilie Franchomme. C’est maintenant chose faite. Mieux encore, elles m’ont donné l’opportunité pour cette “dernière” d’apporter ma modeste contribution. J’y reviendrais.

L’originalité de cette présentation était de reposer entièrement sur un appel à témoignage auprès de la communauté ! D’une part cela témoigne d’une attitude humble de la part de Caroline et d’Emilie, et je dois dire que ce n’est pas le trait marquant de notre communauté (au sein de laquelle je m’inclus) ! Cela nous donne aussi un indicateur fiable sur la façon dont la chose est appréhendée par différentes équipes.

Le premier point qui remonte est : Synecdoque ou comment prendre une partie pour un tout ! On devrait en effet parler de “revue de Sprint” et non de de “démo”, celle-ci n’étant qu’une partie de la revue.

Le second point concerne les facteurs de réussite:

• Ca se prépare
• Avoir une check-list pour ne rien oublier
• Raconter une histoire pour captiver le public

Un aspect stressant qui semble réccurent : éviter la honte devant les clients !

Le point qui m’a le plus interpellé est la dualité démontrer / valider !

Ce “pattern” semble réccurent et source de problèmes et de tensions:

• Cela créer un mur lors des démos (pardon, des revues de Sprint). En effet, on se retrouve plus en climat de client / fournisseurs, voir juge / jugé qu’en situation de collaboration. Chacun s’apprêtant à défendre son camp.
• Cela exacerbe le problème du “scope creep”, où les utilisateurs vont s’evertuer à trouver insuffisant le périmètre montrer afin d’en avoir “toujours plus”.
• Cela sape le rôle du PO qui doit être celui qui valide.

Bref, tout cela laisse bien moins de place à la collaboration !

Un dernier point que j’ai noté (mais ce n’était pas le seul de la présentation, vous n’aviez qu’à venir) : la célébration. C’est très américain, mais pourquoi pas ? Toutefois ce ne doit pas être le but recherché.

Et puis, c’était mon tour !

Caroline et Emilie m’ont proposé d’introduire un nouvel opus de ma saga “en finir avec”. J’avais choisi de faire court, pour ne pas canibaliser la présentation. Trop court et trop léger peut-être, je n’ai pas été très satisfait de moi. Je vais essayer de vous résumer la chose.

La démo, c’est reporter en fin de sprint la revue d’éléments que l’on a fini en cours de sprint ! Alors pourquoi ne pas faire plutôt des “micro démos” qui concluraient chaque story, plutôt que de constituer du stock en cours de sprint ? Voilà du moins la colonne vertébrale de mon propos. Je le reprendrais plus tard de manière plus travaillé et plus détaillé dans un post ici même. Stay tuned !

J’avais déjà posté la présentation de caroline et d’Emilie. Elle est accessible ici.

Partir … revenir ?

Déjà 18h30, notre train est à 20h00 et je serais chez moi à près de 23h00. Il est temps de rentrer (ouais, le campus, il est quand même un peu dans la cambrousse). le temps d’un dernier échange avec les suspects habituels, direction le bus.

Une belle journée avec des sessions donnat matière à réflexion. Mes deux “keepers” de la journée, en plus d’une foule de petites choses, d’idées et de rencontres.

• La session de Tremeur Balbous sur l’immunothérapie au changement. Le premier changement à opérer est en nous et il faut se rendre prêts à l’opérer.
• Le PO “potion magique”. Le Product Owner est un vrai facteur de réussite, mais pas n’importe comment, pas simplement en collant une étiquette au revers de son veston. Il doit d’abord et avant tout être un agent du changement et non un scribe !
• Mélanger présentation et validation lors d’une démo, c’est pas une idée de génie.

Alors c’est vrai, Nantes ce n’est pas à proprement parler à côté. Pourquoi aller là-bas alors que l’Agile Tour Paris est à 200 mètres de mon lieu de travail ? Pour les rencontres, tout d’abord. la communauté Parisienne, je commence à connaître. L’ambiance est un peu différente des rendez-vous de la capitale où l’on a peut-être plus tendance à pavaner, même malgré nous… Et puis j’avais rencontré quelques personnes de la communauté Nantaise lors de l’Agile Games France. Il me tardait de les revoir à nouveau. Bon allez j’avoue, c’est la raison principale.

Il est un peu tôt pour affirmer que je serais là l’an prochain. Mais cela me tente bien…