Cette définition m’est venue aux oreilles et elle m’a beaucoup plu. De quoi s’agit-il ? Un gouverneur de l’Ohio, Potter Stewart, avait lancée une croisade contre l’industrie pornographique. Mais lors des procès qu’il avait engagé quand on lui a demandé comment il définissait la pornographie il répondit : “Quand j’en vois, je sais que ç’en est”.

C’est une définition très intuitive, très émotionnelle, qui se définit par une rupture. A y réfléchir si je devais donner une définition rapide de l’agile, ou du moins répondre à la question : “est-ce que nous sommes agiles ?”, cette réponse me satisferait assez.

Intuition & rupture

Il faut bien percevoir que l’agile est en rupture complète avec la façon dont on a envisagé les projets, le management, depuis plus de 20 ans (ok, je ne généralise pas totalement). Le changement, c’est l’agile. Et c’est une nouveauté fracassante, choquante donc pour certaines personnes. Donc oui à la question “est-ce que nous sommes agiles ?”, on devrait pouvoir s’interroger facilement : “Quand j’en vois, je sais que ç’en est (ou pas)” d’une façon très intuitive et émotionnelle. Posez vous la question. L’évidence, la rupture devraient apparaître naturellement (ou pas). Je me répète, cette réponse met en avant la façon flagrante dont nous nous sommes fourvoyés concernant la gestion projet, le management, depuis des années.

Merci Nathalie pour cette intuition.

Sur ce, je retourne m’occuper d’une série rose digne de M6 des années 80 qu’il me faut rendre plus épicée.

Vive le printemps comme dirait Bruno avec qui j’aurais le plaisir  d’animer un atelier à haut risque lors du prochain Sudweb 2012 (le 26 mai à Toulouse). Cet atelier est à haut risque car c’est un jeu, et un jeu cela a besoin d’être rodé. Et c’est un jeu ambitieux : 1h30 autour d’un scénario machiavélique à la façon de “livre dont vous êtes le héros”.

Pour en savoir plus l’article de Bruno ou la description de l’atelier :

On compte sur vous pour venir participer et avoir votre avis. Cet atelier se déroulera dans le cadre de la journée “élaboratoire”  : faisons le constat que la majorité des gens sont saturés des powerpoint et qu’il faut un apprentissage participatif !

A cette occasion voici le petit texte pondu pour Sudweb (je le replace ci-dessous) : http://sudweb.fr/2012/cette-drole-de-journee-quest-lelaboratoire-vue-par-pablo-pernot/

Aux idées, citoyens

Quand Sébastien ou Frank du staff Sud Web évoquent avec moi la journée participative du samedi, je ne peux que jubiler. Une journée d’ateliers, de participation, de co-création, une promesse d’énergie, de plaisir, et peut-être d’innovation brute. Dans la mouvance des barcamps, code/coach-retreat ou desopenspaces les formats participatifs ont le vent en poupe car, pas de secret, ils proposent un très bon environnement pour apprendre :

Tell me, and I will forget. Show me, and I may remember. Involve me, and I will understand.
– Confucius, 450 B.C

Il faut donc se plier à une condition : faire participer.

Essayons de bien distinguer 3 états :

1. L’écoute passive : un orateur avec des slides.
2. La participation : l’orateur fait participer le public, et du coup le contenu de son discours n’est plus prédéterminé.
3. Enfin la co-création : il n’y a plus de différence entre l’orateur et le public. On passe d’un état très prédictible à un état très imprévisible. (C’est d’ailleurs la crainte de certains : comment ne pas prendre le risque de finalement ne déboucher sur rien. Cela arrive rarement et si cela doit arriver prenez vos deux pieds et changez de session).

Pour cette journée participative que Sud Web a décidé de joliment donner le nom d’ “élaboratoire” on oubli donc l’état 1, l’écoute passive de slides. Cela ne nous intéresse pas dans ce cadre (je n’ai pas dit : pas de slides, je suggère : pas majoritairement “d’écoute passive”). Ce qui intéresse Sud Web c’est que vous veniez avec des idées de formats répondant à des objectifs de participation ou co-création (les coding-dojo sont finalement un exemple).

A mes yeux le meilleur véhicule est probablement le jeu, une approche ludique. Il pose des contraintes claires, partage un problème avec les participants, laisse s’établir des relations sociales au sein du groupe, les aspects répétitifs et le feedback constant en fond une source de progression palpable. C’est aussi le terreau de l’innovation : un monde complexe (non prévisible) au sein d’un conteneur : des “contraintes libératrices” comme dirait Paul Valery.

Mix-it 2012

Plus tôt, dès cette semaine (le 26 avril à Lyon, mais toutes les places sont prises il me semble) j’aurais l’occasion de donner une session à Mix-It 2012. Un évènement qui allie plusieurs centres d’intérêts : Agility,Techy,Trendy,Gamy,Weby. Mélangeons ! il en sort toujours quelque chose d’intéressant. J’essayerai de donner une petite suite à “Anatomie d’une mission agile”, une saison 2 en quelque sorte. Session que j’avais d’ailleurs proposé en 2011 à … Sudweb.

A ce sujet Romain de Mix-It me propose quelques questions concernant le buzz agile actuel… : http://www.mix-it.fr/article/13/rencontre-avec-pablo-pernot-coach-agile

Je reproduis l’article ci-dessous.

Agilité & Buzz

Rencontre avec Pablo Pernot, coach agile

Nous nous sommes entretenus avec Pablo Pernot qui animera la session “Anatomie d’une mission agile, saison 2″

 L’équipe Mix-IT : Peux-tu nous dire qui tu es ?
Pablo Pernot : Qui suis-je ? ouh là. Euh … dans le contexte de Mix-IT je suis surtout un intervenant “agile” qui vient faire part de son expérience, d’une expérience en tous cas. Mais sinon je suis plutôt un homme heureux, père de deux merveilleux enfants, amoureux de sa femme, ayant beaucoup de plaisir à cultiver une attirance pour quelques instruments “has been” comme la flute irlandaise ou le banjo old time. J’ai eu la chance d’avoir un parcours atypique qui m’a permis de faire des lettres et de la philosophie plutôt que des maths ou ce genre de trucs. En ce moment je concrétise la liberté que j’ai pu gagner en faisant grandir une petite société de conseil avec Christophe Monnier & Gilles Pommier Smartview.

L’équipe Mix-IT : L’agilité vient de dépasser la phase de buzz, mais tout le monde ne choisit pas ces méthodes. Quels sont encore les freins que tu rencontres au quotidien ?
Pablo Pernot : Attention, si le succès de l’agile a fait disparaître certains freins il en a fait apparaître d’autres. L’effet de mode est source de confusion. Cependant il est certains que le succès aidant, nous sommes allés plus loin avec agile. Et donc des questions plus vastes se posent : comment concilier l’état d’esprit agile avec l’organisation, sous-entendu comment changer le management ou quels sont nos rapports avec les aspects budgétaires à grandes échelles : actionnariat, plan 3/5/7ans, stratégie d’entreprise, etc. ?
Au quotidien la question que je me pose le plus fréquemment actuellement est : comment motiver les gens, ou plutôt comment changer l’état d’esprit des gens (“agile is a mindset”), et encore : faut-il vouloir changer l’état d’esprit des gens, n’est-ce pas là une intrusion trop violente ? Donc où s’arrête la méthode orientée vers la réussite des projets, où commence une forme de manipulation psychologique pas forcément très/toujours judicieuse …

L’équipe Mix-IT : Quels sont pour toi les facteurs de réussite d’une transition agile ?
Pablo Pernot : Mais c’est l’un des sujets de ma session :) passez voir. En quelques mots : de véritables raisons pour prendre le chemin agile, une réelle sensibilisation et un soutien fort du management, du piment pour provoquer le changement : du sang neuf, un œil extérieur, etc. Mais le terme “réussite” est souvent un piège. Ce n’est pas soit une réussite soit un échec, c’est toujours plus “gris”, et surtout ce n’est jamais définitif : c’est en mouvement constant.

L’équipe Mix-IT : On entend parfois que “l’agile ce n’est pas possible dans mon contexte”, que leur réponds-tu ?
Pablo Pernot : Pour l’instant je n’ai jamais rencontré, ni entendu évoquer un contexte qui ne serait pas réalisable en agile. Je caricature : “Waterfall” (modèle en cascade) estime que le monde est parfait (puisque l’on peut tout préparer, anticiper), et agile que le monde n’est pas parfait (puisque l’on devra/pourra s’adapter). Donc si vous avez un monde parfait je veux bien croire que agile ne s’y prête pas.
Posté par   Romain Couturier le 10/04/2012 à 08:30

Voilà un livre qui a eu un impact sur moi. Il ne s’agit que d’une critique, violente, exclusivement à charge, contre les coachs.

“Nous avons accumulé suffisamment d’éléments à charge , nous disent les auteurs, dans notre dossier sur le coaching pour éviter de tomber dans le piège de la critique nuancée. Les coachs sont les premiers à avancer que le coaching comporte des dérives, qu’il faut savoir distinguer entre les bons et les mauvais coachs. Il n’est pas de pire moyen pour combattre le coaching que de dire qu’il faut faire acte de vigilance contre ses mésusages, comme s’il existait une essence pure du coaching seulement souillée del’extérieur par quelques imposteurs. Nous préconisons, quant à nous, le rejet en bloc de cette soupe sportive remixée à la sauce managériale”.

Pour moi, lire ce livre c’est comme si j’avais demandé à un ami proche connaissant bien mes activités de mettre en exergue tous les aspects négatifs, les risques ou les dérives de celles-ci. Cet ami proche ne prend pas de gant, il m’assène des arguments indéniables, il ouvre des plaies qui auront du mal à se refermer. Nonobstant mon côté sado-maso, quel plaisir, ou plutôt quelle source d’amélioration ! Voici dressés à moindre coût bon nombre d’écueils dans lesquels j’ai pu tomber, ou que j’aurais à éviter. C’est donc une lecture que je recommande à tous ce qui ont un lien de près ou de loin avec le coaching, en l’occurence dans mon cas le coaching agile.

Si je résume la pensée des auteurs, le coaching n’est finalement qu’une sorte de mystification psychologico-managériale dont l’objectif caché est une uniformisation néolibérale des personnes sous couvert d’une pseudo émancipation humaniste.Rien que ça.
“Un conditionnement individualiste au service d’un conformisme généralisé” nous disent les auteurs.
Ou encore (je cite là les titres de chapitres) “Le coaching comme falsification du rapport éthique à autrui”. Et encore “la croissance individuelle soluble dans la croissance économique”. Ou pour finir: “La question de fond est de savoir si le coaching n’est pas un remède pire que le mal qu’il prétend conjurer”.

Ce qui est très perturbant dans cette lecture c’est que les explications, analyses, cas concrets mis en exergue par les auteurs me sont familiers. Comme si ils analysaient une partie de mon travail mais uniquement sous un aspect négatif. C’est passionnant, je ne peux pas démentir que leurs analyses soient fausses, mais elles sont exclusivement négatives.

Nuançons

Car il faut nuancer. L’un des tords de ce livre est justement qu’il n’est qu’à charge, à sens unique, qu’il ne place en exergue que les aspects négatifs. Or même si les auteurs insistent pour ne faire qu’une critique à charge et surtout de ne pas laisser une once de crédit à ce rôle, on reste dubitatif devant un tableau aussi noir. Si oui j’ai pu tomber dans les travers évoqués par moment, et à mon corps défendant, cela s’accompagnait aussi de pas mal de choses positives (j’ose espérer). Donc il faut peut-être nuancer malgré tout (relisez la première citation en début d’article pour voir que je ne suis alors pas d’accord avec les auteurs).

La deuxième chose sur laquelle apporter de la nuance c’est justement la définition du coach. Dans l’esprit des auteurs me semble qu’ils interpellent les “vrais” coachs. Ceux qui sont coachs avant d’être autre chose. Pour ma part je suis agiliste, ou informaticien, bien avant d’être coach. Coach n’est que la formulation qui jusqu’avant la lecture de ce livre me semblait convenir le mieux à cette glue qui s’étend tout autour du coeur de mon métier : valeurs et principes agiles.

Et puis oui nous sommes là pour aider des organisations à réussir leurs projets.

Enfin le discours est un peu affaibli par le côté revanchard qui perce concernant les aspects financiers. L’un des auteurs (Gori), psychanalyste, ne cesse de fustiger les tarifs exorbitants des coachs (et rien qu’en lisant les tarifs je sais du coup que je ne suis pas vraiment un coach). On devine une vraie rancoeur sur cette “psychanalyse de comptoir à l’américaine” (c’est mon expression pas celle du bouquin) qui se paye cher et détourne des “clients” de la vraie psychanalyse. C’est dommage.

Psychologie & conformisme

L’un des reproches forts du livre est l’annexion du domaine de la psychologie par les coachs

A mon avis oui il faut aborder dans notre métiers les aspects psychologiques mais avec beaucoup de précaution. Peut-on s’en passer ? probablement pas. Il s’agit de relations humaines, donc de psychologie et pas d’autres sciences plus froides. Mais ce n’est pas mon métier, il faut donc faire très attention et surtout ne pas devenir un apprenti sorcier.

Un autre reproche fort est celui de gommer les différences au profit d’un conformisme pratique aux entreprises. Je suis très en phase avec cette critique. Il faut accepter la différence, et surtout la préserver. Halte au conformisme.

Philosophie

J’ai apprécié les rappels philosophiques (le deuxième auteur est philosophe -Le Coz-): le relookage de la maïeutique de Socrates par les coachs. Oui il faut connaitre cela quand on fait de l’agile. Ou les rappels autour de Descartes, Nietszche ou Heidegger : l’importance du langage. C’est sur dernier point que je souhaite -comme le livre- conclure.

Puissance du langage

Je cite le livre :  “L’homme, écrit Heidegger, se comporte comme s’il était le créateur et le maître du langage, alors que c’est celui-ci au contraire qui est le et demeure son souverain”. Gori & Le Coz complètent : “Le langage est la matrice et non l’outil de la pensée”. ou plus loin ils citent Victor Klemperer : “[...]Les mots peuvent être comme de minuscules doses d’arsenic : on les avale sans y prendre garde, ils semblent ne faire aucun effet, et voilà qu’après quelques temps l’effet toxique se fait sentir.”.
Les mots, le langage construisent notre monde. Ils nous y enferment aussi potentiellement. Ils peuvent l’empoisonner donc.

Il faut s’interroger sur le mot coaching ou coach et ce qu’il renferme. Pour ma part j’y vois une inversion des objectifs : Si je suis seulement coach j’ai perdu le sens de mon action. Le sens de mon action c’est d’essayer d’appliquer les valeurs et principes agiles. Pourquoi : pour que les projets réussissent. Et un projet qui réussit se mesure aussi et naturellement au plaisir et à la satisfaction et à l’émancipation de toutes les parties prenantes.Toutes.

J’espère être agile avant d’être coach. Et ce livre me pousse à penser que coach n’est plus le mot adapté. Et d’ailleurs “agile” l’est-il aussi encore compte tenu de la confusion qui l’accompagne désormais avec l’engouement dont il est le sujet ?

Bref je vous recommande chaleureusement la lecture de cet ouvrage. Il ne peut que vous pousser à vous interroger si vous êtes dans ma situation. Ce n’est donc que bénéfique. Pour ma part je me lance dans la quête des bons mots, du bon langage.

Vous reprendez bien encore un peu de lance-flammes ?

“Une analyse critique du phénomène du coaching doit déboucher sur une attitude d’insubordination radicale. Délivrons nous des coachs ! serait l’expression naturelle qui nous inspire cette nouvelle potion idéologique aux senteurs opiacées. La présente contribution appelle à un sursaut d’orgueil collectif. Elle entend provoquer un vrai débat de société sur le sujet. Il y a bien des raisons de se montrer sans concession à l’égard du coaching. A commencer par cette sinistre anthropolgie managériale qu’il véhicule derrière sa prétention à prendre appui sur une psychologie humaniste”.

Bonne lecture.

Non. il est très important -à mes yeux- de ne pas faire de parallèle entre  les points user story et des jours hommes.

Pourquoi ?

La gestion des jours hommes est une vieille pratique obsolète mais profondement ancrée dans notre culture qui nous renvoie directement au projet au forfait et à son mensonge historique : il serait possible de respecter une promesse à triple visage qui consiste en un engagement simultané sur la date, le scope, le coût. (Pour l’agile c’est un mensonge notoire). Sur le terrain j’observe que dès que l’on parle de jours hommes cela implique de facto tout un ensemble d’autres informations particulièrement nuisibles : une cristallisation autour de cette hydre (scope,coût,date).

Imaginons 2 cas de figures concernant un manager bien intentionné qui décide de compter en jours hommes :

Cas de figure 1

Il observe les précédents sprints et en déduit une équivalence entre les points user story et les jours hommes. Or lors du sprint suivant l’équipe s’engage d’après ses calculs sur 40 jours hommes alors que si il observe le temps de présence de l’équipe (sprint de 2 semaines, 6 personnes, soit ~60 jours), celle-ci pourrait s’engager sur bien plus. Que va faire le manager bien intentionné. A minima il va s’en émouvoir. Et comme c’est un manager son émotion a de l’influence, cela risque d’entre être fini des prérogatives de l’équipe qui aura beaucoup de mal a justifiée de ne pas s’engager “à la bonne hauteur”. Et c’est en fini de l’agilité. Fini. Basta. On est retombé dans un système de “command & control” autant obsolète que néfaste.

Cas de figure 2

Un manager bien intentionné demande à son équipe de chiffrer en jours hommes directement plutôt que d’utiliser les points user story. Là, le message est immédiat. Comment dire à son manager que l’on souhaite s’engager sur 40 jours hommes alors que l’équipe a la capacité d’en réaliser 60 ? La sortie de route est rapide : soit l’équipe va gonfler ses estimations pour faire coïncider la capacité de l’équipe et engagement. Soit elle va effectivement s’engager sur 60 jours au détriment de la qualité de réalisation. On retombe dans le mensonge de l’engagement au forfait : sauvons les apparences ! en fait l’objectif de l’équipe a implicitement changé : il ne s’agit plus de s’interroger sur la véritable estimation des éléments, sur sa véritable capacité, mais de réussir à faire coincider deux valeurs (quelque soit le fond). On a perdu le fond pour la forme. Finie l’agilité.

Dans les deux cas l’introduction des jours hommes a rendu les estimations caduques. Dans les deux cas on est revenu à une relation de “command & control” néfaste au projet.

C’est aussi pour cette raison que je déconseille vivement l’utilisation des “jours ideaux”.

Pourquoi les estimations de l’équipe diffèrent-elles de sa capacité de réalisation ?

Car il est très difficile d’estimer en jours hommes, voire impossible. Il y a trop de critères, donc trop de complexité, donc trop peu de prédictibilité pour que ces calculs soient bons. Dans la réalité les gens qui réussissent à estimer en jours hommes ne se basent pas sur un calcul mais ils reproduisent et s’inspirent de leurs expériences passées, c’est agile : il reproduise une cadence qu’ils ont observés dans un contexte similaire. La difficulté étant justement de retrouvé un “contexte similaire”, il y en a peu. très peu. très très peu. Par contre des réalisations dans un projet : il y en a beaucoup et elles sont présentes dans notre esprit car récentes. L’estimation agile se base donc beaucoup sur une comparaison des différents éléments du projet. Cet élément est-il plus dur, complexe, long à faire que celui-ci ? La comparaison, et la triangulation (3 éléments) est la base de l’estimation agile. Si j’introduis la notion de “jour homme” la comparaison est comme empoisonnée. On a fait entrer un élément parasite qui rappelle de nombreuses autres contraintes. Le “jour homme” a une capacité d’attraction fatale assez phénoménale. Prononcer le mot “jour” ou “heure”, et la personne s’enferme d’elle même dans un piège dont elle sort rarement gagnante.

L’engagement est différent de l’estimation !

Je demande aux équipes agiles d’occulter les points user story lors de leur engagement. Il faut qu’elles se basent sur leur ressenti : celui-ci a de la valeur car les équipes viennent de réaliser plusieurs itérations à la durée strictement identique. Comme ci-dessus : on compare. Et on compare ce qui est comparable : les itérations entre elles, ou les user stories entre elles, mais pas une itération à une user story, et donc l’engagement du sprint est une expérience différente que la simple somme de points user story. (La vélocité peut servir d’indicateurs mais n’intervient pas dans l’engagement).

A quoi peuvent servir les jours hommes ?

Dans les deux cas évoqués plus haut (notamment le premier) vous pouvez me répondre : ce manager bien intentionné peut aussi ne faire subir aucune pression à l’équipe même si il décide de compter dans son coin en jours hommes et garder cette information pour lui ? Pour moi ce cas de figure est extrêment rare : pourquoi compter en jours hommes ET garder l’information pour soi ? A quoi cela servirait-il ? Et du moment qu’il évoque les jours hommes il risque de rendre caduque les engagements et les estimations. Donc autant ne PAS le faire.

En fait ce monsieur cherche a projeter une planification, un planning release, savoir a priori quel sera le scope cible pour telle date afin de lui permettre de faire des arbitrages. C’est la bonne raison (c’est notamment le désir du product owner) : est-ce que nous sommes dans les clous ? est-ce que nous sommes dans le budget ? Est-ce que nous pouvons enisager sortir ce scope à cette date ? Quel scope pouvons nous sortir à cette date compte tenu de notre capacité ? L’agile dit : voici une projection, cette projection est d’autant plus fiable qu’elle se base sur la cadence que nous avons observé sur le terrain, mais cela demeure une projection. Cette cadence est observée en user story ou en autre chose (potentiellement simplement en user story). Mais surtout pas en jours hommes pour les raisons évoquées plus haut.

On ne calcul pas un budget avec la suite de Fibonacci monsieur !

Je me suis entendu dire l’année dernière : “On ne calcul pas un budget avec la suite de Fibonacci monsieur !”
C’est vrai. C’était rigolo comme réplique, mais fondé. Vous voulez savoir combien vous devez engager, ou combien vous avez engagé, c’est normal. Rien ne vous empêche de compter VOUS en jours hommes. Mais il ne s’agit pas d’estimation et d’engagement : ça c’est le rôle de l’équipe ou des équipes. Vous pouvez par exemple estimer que si on place 2 équipes de 6 personnes pendant 1 an sur un projet celui va “coûter” ~2500 jours hommes (216*12, 216 étant de mémoire le nb de jours ouvrés moins les 5 semaines de vacances d’une année). On peut ainsi se projeter en jours hommes ou faire des bilans mais comme vous l’aurez compris on comptabilise un engagement de moyens : combien de personnes, combien de temps ? et pas un engagement forfaitaire : combien de personnes, combien de temps … et quel scope. Et la personne qui s’autorise à compter en jours hommes pour “budgetiser” ne fait pas parti de l’équipe, sinon de nouveau comme évoqué plus haut elle va rendre caduque les estimations.

Le point de user story peut muter, le jour homme est immuable.

Autre effet pervers : le point de user story peut évoluer au fil du temps. L’équipe s’améliore, elle connait de mieux en mieux son périmètre et donc ses contraintes et ses facilités, son estimation va donc naturellement évoluer. Hypothèses : ce qui était facile au début du projet on sait désormais que c’est dur car on a découvert les anguilles qui se cachaient sous les roches, à l’inverse ce qui était dur au début du projet est peut-être désormais grandement facilité (par exemple par tout le code qui a été généré, par la connaissance que l’on a désormais des problématiques, etc.). A quel moment les personnes qui souhaitent faire un lien entre les points user story et les jours hommes adaptent-elles leur taux de change ? rarement ? c’est donc que le jour homme n’a pas la bonne valeur. Souvent ? mais donc si la valeur du jour homme change constamment…

Pour finir,

Vous pouvez déterminer le nombre de lignes de code générées par l’itération. En associant un taux de lignes de code par jour vous devriez pouvoir en déduire la marge générée par le lot 1 de votre contrat si il ne s’agit pas d’un appel d’offre publique et si vous ne faites pas de offshore. Sinon vous devez multiplier le tout par 2,75. Pour cette dernière recommandation, bon courage (et naturellement c’est une plaisanterie… dire que je me sens obligé de préciser…)

Fuyez le jour homme avant qu’il ne vous dévore.

Concernant les estimations elles-mêmes je vous renvoie à mon feedback sur Agile Open Sud 2012.

Quelques retours à chaud sur les activités auxquelles j’ai pu participer :

Les estimations sont-elles nécessaires ?

Surtout par le dialogue et processus qu’elles induisent. Elles permettent la discussion, la confrontation (sens apaisé), elles dévoilent des surprises. Peuvent permettre (ou pousser) à tous de s’exprimer. Elles valident une convergence. Nous oblige à découper, designer, envisager les travaux de façon plus fine. Elles permettent de nous projeter au travers d’une planification. Mais elles ne constituent pas un engagement, et ne doivent pas être prise à la lettre (enfin, au chiffre), ni de façon isolée (triangulation, comparaison).

Scrum & XP sont sur un bateau

Une discussion animée autour de nos débats vifs et amusants concernant Scrum & XP. Même si chacun continu de défendre naturellement ses aspirations nous sommes tous assez d’accord. Notre combat est ailleurs, vers la dénaturation des méthodes agiles. Voilà, pas plus. Certains voient dans Scrum un cheval de Troie qui permet l’introduction de l’agilité, tous sont ok pour confirmer que même une introduction, ou une application partielle c’est mieux que rien, une porte d’entrée, un point de départ. Pour ma part j’apprécie particulièrement de taquiner mes camarades sur ces sujets (ils me le rendent bien) car cela nous permet (même au travers de rires) une constante remise en question, une constante réflexion sans douleur.  A ce sujet je vous soumet ma proposition de changement du manifeste : “Je préfère un logiciel opérationnel plutôt qu’un long débat technique”.

Le scrummaster est-il inutile ?

Théoriquement l’auto-organisation devrait mener à ce constat. Mais alors est-ce motivant de s’enticher d’un rôle dont l’objectif est de devenir inutile ? Le scrummaster veille à l’application de Scrum, à éliminer les obstacles, à faciliter le travail et l’organisation de l’équipe, à protéger l’équipe. Quand tous ces objectifs sont atteints que devient-il (ou quand l’équipe est assez mature pour faire cela toute seule) ? Qu’est ce que l’on constate sur le terrain : cela n’est jamais complètement le cas (ou alors avec des équipes assez réduites). Donc c’est assez rare. Quand c’est le cas et si c’est possible le scrummaster peut devenir petit à petit un coach agile : il prend de la hauteur et de la distance, il peut prendre une position de facilitateur au sein de sa structure. Il peut aussi encadrer plusieurs équipes simultanément ou faire un travail plus transverse en se regroupant avec plusieurs Scrummasters. Mais c’est assez rare (qu’il devienne véritablement inutile). Quand est-ce que cela se produit ? lors des phases de releases. Lors des phases de re-constitution des équipes.

Pour conclure : le scrummaster est (très) utile. Il peut avec le temps le devenir beaucoup moins ce qui est la marque de la réussite de son action. Mais nous constatons que sur le terrain il ne disparait que très rarement. Et qu’il difficile d’expliquer aux gens (ah les gens…) qui veulent devenir scrummaster que l’objectif est l’effacement -en partie- de leur job.

Skull & Roses

A l’instar des “Loup Garous de Tiercelieux”. Nous avons fait une partie de Skull & Roses, un petit jeu de bluff fort sympathique. Le jeu demande de mentir, d’être fourbe, de piéger tous les autres participants, de mentir encore, de jubiler lors de l’échec d’un autre. Bref un grand moment de plaisir qui permet d’en savoir long sur certains. 2 enseignements : il faut comprendre la règle pour gagner, par inversion anti-agile : le jeu montre les travers de l’individualisme.

Agilité, rupture ou effet de mode ?

Gros débat qu’il est difficile de résumer (à chaud dimanche matin qui plus est). Je vous livre en vrac : Il y a trop de méconnaissances des valeurs, de la culture de l’agilité. C’est à dire qu’il y a un vrai schisme entre l’application des pratiques et les valeurs et principes qui en sont le fondement. Cependant en appliquant les pratiques (sans se soucier des valeurs) on peut arriver à mieux comprendre celles-ci (valeurs) et finalement les retrouver. Il y a une vraie frontière entre l’application de l’agilité sans valeurs, sans culture et avec. Nous craignons naturellement qu’il arrive à l’agilité ce qui est arrivé à Lean (un détournement). Nous pensons même qu’il est peut-être déjà trop  tard, et que le mot agilité est déjà perdu. Pour le retrouver -peut-être- cela passe par un réel évangélisme, un bon enseignement (nous soulignons le mal fait par certains apprentissage autour de l’agilité, et nous soulignons aussi que de nombreuses approches “agiles” pré-existent depuis longtemps dans l’informatique  et auraient pu être plus soutenus : par l’enseignement, par l’apprentissage, etc.)

Pour soutenir notre effort il faut aussi ne pas hésiter à montrer son adéquation avec les attentes du “business”. Pour résumer par un exemple un chouïa réducteur : le respect des gens les rend plus performants (donc c’est bon pour le business). Ou encore, le déploiement de pratiques techniques soutenues par l’agilité (intégration continue, tdd, pair programming, etc.) rend les applications de meilleure qualité (donc c’est bon pour le business).

Pour lutter contre cette dénaturation : nous préconisons de toujours rappeler clairement les choses : “nous devions, ceci n’est pas agile”, etc. Mais naturellement cela ne veut pas dire que nous refusons le job ou la participation : il faut du temps pour acquérir tout cela. Donc oui nous vous accompagnons et nous ne ferons peut-être pas tout bien tout de suite (ni jamais, c’est une destination, nous y tendons). Mais nous signalons constamment les deviances. Si, avec du temps, nous voyons qu’il n’est pas possible d’appliquer l’agilité il faut songer à arrêter ou à quitter la mission (mais c’est à la fin d’un parcours). Par contre il faut constamment garder sa neutralité, et rappeler les écarts avec la cible.

Voilà il s’agit de mes souvenirs livrés à chaud, par mon prisme. Ne pas oublier la petite séance de banjo & guitare avec Olivier. Un moment très agréable.

Seul regret : c’est trop court. Et je n’ai pas réussi à formaliser assez les idées qui ont émergées (je ne parle pas de compte rendu, je veux dire : sur les lieux). Mon avis : prendre une vraie retraite de 4 jours (dans les Cevennes ou en Tunisie).

Le retour de Thierry : ici

Le retour de Claude : ici

Le retour de Jean-Baptiste : ici

Le retour de Fabrice : ici

Le retour de Rui : ici

Le retour d’Alexis : ici

Le retour de Jérôme : ici

Ce que j’attends de

Agile Open Sud (Conférence ouverte sur l’agile dans le sud)

16-17 mars, Banuyls sur Mer

D’abord

rencontrer des copains, des amis, des connaissances, de nouvelles têtes dans un lieux qui a l’air fort sympathique : l’hôtel des elmes (oui oui c’est çà sur la photo). Cela sera j’espère un bon moment d’échange et de détente. Accentué par la présence d’un ou deux matchs de rugby qui nous permettront de nous libérer de certaines toxines et par la célébration de la Saint Patrick (le 17 mars) qui nous permettra de récupérer ces toxines perdues (et de souffler dans les whistles).

Ensuite

j’espère que nos discussions, brainstorming, etc (car il s’agit d’un openspace, donc difficile d’anticiper le programme en détails par avance, mais pour ceux qui ne connaissent pas ce format je vous assure que cela densifie le contenu) seront constructifs. En cela j’aimerais beaucoup arriver à un résultat. C’est à dire ? Que l’on s’engage. “Voilà ce que nous pensons de tel et tel sujet”. Naturellement les réponses ne seront pas monolithiques, elles exprimeront notre diversité. Naturellement nous pouvons nous tromper sur de nombreux sujets. Mais j’aimerais (je ne le vois pas assez dans les manifestations autour de moi) un engagement clair sur les idées qui seront exprimées durant ces heures. Voilà ce que nous avons dit à ce moment sur ces sujets. Sans s’embarrasser des “qu’en dira-t-on”. Je vais proposer cela aux autres participants et essayer de trouver un format/support pour capitaliser ces informations.

Je serai ravi de vous y croiser. Il reste des places disponibles. Cela coûte 164,5 euros. Le prix comprends les repas du vendredi soir au samedi midi et la chambre pour la nuit. (Il reste moins de dix places -sur trente max quota de l’hôtel-).

Pour s’inscrire : prendre sa carte bleue, fermer les yeux, cliquer ici.

Quelques articles sur le même sujet de Antoine, de Thierry, de Claude, Fabrice.

Le tag sur tweeter est #aosud.

Malgré tout le respect et l’amitié que j’ai pour eux, sur ce point, à mon avis, ils se plantent.

Je comprends cependant leur désarroi.

Agile (et Scrum),

c’est le buzzword. Et comme l’écrit Comte-Sponville : “lorsque la mode s’en mêle cela se paie ordinairement d’un certains nombres de confusions”. C’est ce qui nous arrive avec “agile”. Les vingt pages du livret du site scrum.org de Jeff Sutherland qui permettent de s’emparer du sujet et de jouer aux apprentis sorciers.

Pour ces camarades aux profils ou aux désirs très techniques (dans le sens très noble du terme, d’ailleurs je n’en connais pas d’autres sens) une des façons de ramener ces moutons égarés à la raison est de monter le prix du “ticket d’entrée” de l’agile. En rappelant tout le savoir faire technique nécessaire au bon déroulement d’un projet agile (extreme programming, ou craftsmanship). D’où aussi la fatwa contre Scrum qui permet de dire que l’on fait de l’agile sans même faire de code. Qui permet à chacun de se lancer (souvent n’importe comment). Imaginez Kanban…

Si je pense qu’ils se plantent c’est que j’estime que leur réponse est trop réductrice, et qu’ils se trompent de cible. Sinon ce qu’ils disent n’est pas faux, et qui plus est très intéressant. Ils ont la bonne question, mais la mauvaise réponse, ou une réponse très incomplète.

Leur réponse est trop réductrice : en voulant ramener les fondements de l’agile à un approche du logiciel pour le développeur ils se restreignent à un mouvement agile parmis d’autres, ni le premier, ni le dernier, ni le fondement, ni le but ultime. L’agile ne se réduit pas à un seul mouvement. C’est une philosophie, ou *des mouvements* de pensées constitués par plusieurs branches, plusieurs écoles avec des croisements, des recoupements, des bifurcations, etc. Je comprends en tous cas le soin qu’ils ont à vouloir anoblir le développeur c’est un rôle rarement estimé à sa juste valeur (la faute à qui : c’est un autre débat).

Ils se trompent de cible en visant Scrum. Si Scrum marche autant là où extreme Programming a échoué ils devraient s’interroger. Pour ma part j’envisage dans un projet informatique que les deux soient plus que complémentaires, qu’ils soient indissociables. Quand les XPistes expliquent que XP a déjà tout (sous entendu toutes les bonnes pratiques), je m’interroge à nouveau : pourquoi donc un échec quelques années auparavant (échec dans le sens où l’on a pas connu le même succès que Scrum) ? Probablement car ce “tout” est mal exprimé pour la majorité des auditeurs (le terme “rétrospective”, l’expression “définition de done” c’est scrum, même si cela existe d’une façon différente dans XP). Le contenu de XP est aussi à mon avis mal équilibré (Extrême…).Donc ils se trompent de cible à mon avis. Ils contournent le problème au lieu de le traiter. Le traiter c’est mieux communiquer, mieux appréhender ou palier aux difficultés engendrées par le “ticket d’entrée” de scrum. Mieux expliciter les relations fortes entre ces deux approches et les nombreux points de convergences, les reformuler si besoin, etc.

Pas de fausse querelle

J’adhère complètement à leur analyse et je soutien leur action : le ticket d’entrée de Scrum est une faiblesse (mais j’ajoute que c’est aussi une force). Oui ils ont raison de mettre en avant tous les bienfaits et la nécessité dans le cadre informatique des pratiques Extreme programming ou Craftsmanship. Oui l’agile dans bien des cas a été dénaturé (mais pas dans de nombreux autres cas).

Mais je dirais plutôt : nous souffrons du succès de l’agile. Tant mieux, mais nous devons redoubler d’effort. Oui tout le monde craint le “retour de baton” d’une trop grande dénaturation et donc incompréhension de l’agile. Mais qui sommes nous pour nous ériger en gardien du temple ? Je pense agile comme une philosophie ou un état d’esprit. Il n’appartient donc en aucun cas à un petit nombre.

Pour finir, écrire (comme j’ai pu le lire) “l’agile est mort” est pour moi juste un aveu d’échec ou d’impuissance. La critique est trop facile. Soyez plus constructif. Soyez agile quoi.

Je vous remercie de la lecture de ces quelques lignes (I Thank You une reprise de Sam & Dave par les barbus sur leur meilleur album, Degüello)

ZZTop, I Thank You

Car contrairement à ce que beaucoup de gens imaginent : éduquer les gens à l’agilité c’est évoluer dans un monde complexe. Scrummaster c’est s’assurer que les contraintes libératrices nécessaires à l’émergence des pratiques agiles sont présentes et adaptées. C’est ordonner (ordre et rigueur dans l’agile) le conteneur qui va permettre au système et à ses agents (à l’organisation et à ses membres) de “co-évoluer” (pour reprendre le terme de Dave Snowden, vidéo de ALE 2011).

Souvent je suis confronté à des futur scrummasters très impliqués ( dans un sens très opérationnel) dans les projets,. Souvent car ces personnes connaissent parfaitement leur organisation, leurs projets et qu’elles ont un avis -souvent bon- sur beaucoup de choses. Tout cela est positif mais  finalement peut beaucoup nuir à leur rôle, toutes ces compétences et connaissances seront peut-être trop envahissantes.

Pour mieux appréhender ce nouveau rôle de scrummaster je peux leur conseiller ce petit jeu : essayez pendant quelques minutes d’être moi. Vous êtes moi (je m’amuse mais ce n’est pas un exercice pour amplifier encore mon égo démesuré). C’est à dire quelqu’un qui va être coach, scrummaster, facilitateur, dans une société qu’il ne connait pas (imaginez que vous ne connaissiez ni la structure, ni son passé, ni les gens, etc.. je sais c’est dur, le conditionnement est un ennemi implacable).
Donc, vous êtes moi débarquant chez vous :

En quoi suis-je légitime pour savoir quel est le besoin du product owner ? (mon rôle est d’accompagner le product owner à mieux/bien exprimer son besoin).

En quoi suis-je légitime pour m’engager à la place de l’équipe sur le scope qu’elle va délivrer ? (mon rôle est de m’assurer que l’équipe s’est engagé en toute connaissance avec honnêteté, au plus juste).

En quoi suis-je légitime pour avoir un avis sur les estimations de l’équipe ? (mon rôle est de m’assurer que l’équipe fournit les estimations qu’elle juge réalistes, potentiellement de m’assurer que tous les membres de l’équipe ont pu s’exprimer -et encore là je touche une limite-)

En quoi suis-je légitime pour arbitrer certains choix durant l’itération ? (mon rôle est de m’assurer que les rôles et responsabilités de chacun des acteurs sont bien respectés, ou dans le cas contraire que ces choix ont été connus, analysés, validés par les acteurs du projet en toutes connaissances de cause).

En quoi suis-je légitime pour affecter des tâches à certains membres de l’équipe ? (je n’ai aucun rôle à ce sujet, généralement je leur suggére de décrire les tâches nécessaires à la réussite du projet, de l’itération, de l’objectif car cet effort de “design” est reconnu comme une aide depuis les règles de la méthode de Descartes)

etcetera etcetera

Cette distanciation aide à mieux appréhender le rôle de scrummaster. Elle est nécessaire pour véritablement libérer les équipes. Et le plaisir que vous aurez à observer cette libération est plus bien agréable que le plaisir plus simple et plus immédiat d’un passage à l’acte en lieu et place de l’équipe.

Voici un petit retour sur le contenu, puis le contenant et le feedback.

Le contenu

J’ai essayé de découper mes slides (ils sont plus bas) en trois parties : la première met en avant le socle “cynefin” et “cynefin dynamics”. Ce framework a pour qualité de bien mettre en évidence les différences entre le domaine ordonné (compliqué ou simple), et le domaine complexe. Je vous encourage à commencer par voir cette vidéo ou à en lire plus ici et là. Mais pour simplifier à l’extrême c’est dans le domaine complexe que l’émergence des pratiques “agiles” va se produire, et c’est en les faisant basculer dans le domaine ordonné que l’on va vraiment pouvoir les répandre au sein de l’organisation. La dynamique de ces pratiques qui passent de “nouvelles” à “émergentes” ou “bonnes” ou “meilleures” est aussi la source de freins. Quand j’essaye de fixer une bonne pratique je suis confronté à des freins. C’est la deuxième partie de cette présentation. L’idée que je souhaite soutenir est que le freins ne sont pas un problème en tant que tel. Ils sont la manifestation que l’on est en train de travailler sur nos pratiques, ils sont nécessaires, ils sont la preuves de nos progrès. Si on souhaite citer la théorie des contraintes de Goldratt, on  peut aussi dire (toujours très simplifié) que les freins sont la plus grande source d’amélioration. Mais si les freins sont trop nombreux, trop récurrents, trop gros nous ne franchirons pas cette étape d’amélioration. Elle sera insurmontable. C’est la troisième partie de ma présentation : si on ne souhaite pas être submergé par les freins (taille, nombre) il faut une bonne conduite du changement. Pour cela je me réfère à un acronyme que je trouve très efficace : ADAPT. Awareness, sensibilisation, si les gens ne savent pas ce qu’est l’agile, difficile de réussir. Desire, envie, maintenant qu’ils savent ce qu’est l’agile, en ont-ils envie ? (avaient-ils envie de quelque chose qui n’était pas l’agile ?). Enfin Ability, capacité, en fonction de la nature de votre organisation, du contexte mais aussi donc de la sensibilisation à l’agile de votre organisation et de son envie, comment adapter votre parcours agile.   (Je ne traite pas “Promotion & Transfer” les deux derniers qui sont là pour “fixer” le changement). Donc, différente capacité, différents parcours, différentes méthodes agiles, différentes possibilités, il y a de nombreuses voies, il faut en choisir une qui soit bien adapté à sa capacité sinon on va générer trop de freins. Il n’y a pas de meilleure capacité.

Pour résumer et en inversant la chronologie de la présentation : si vous vous donnez les moyens d’une bonne conduite du changement, vous éviterez d’avoir trop de freins, ou de trop gros freins. Mais des freins sont nécessaires car ils sont la preuve que le changement est en cours, ils sont aussi la preuve que l’on fait émerger de nouvelles pratiques en adéquation avec ce qu’est votre organisation. Pour bien comprendre ces dynamiques il me parait très intéressant de se plonger dans le framework cynefin.

Les slides chez Slideshare :

 Le contenant et le feedback

J’ai pu donc donner cette présentation dans deux lieux jusqu’à maintenant. Lors d’un petit déjeuner dans les salles de formation de Smartview. J’ai aussi pu donner cette présentation grâce aux efforts de Karine & Eric (@viaxoft) et de l’association Esprit Agile à Marseille. Merci à eux ! (A Marseille nous avons fait 40mn de présentation et 1h30 de discussions…).

La réception a été bonne, mais pas mal chahutée (j’ai appris beaucoup)  :

“c’était trop théorique, pas assez concret”.

Oui mais je crois qu’il faut parfois asseoir une analyse théorique pour mieux appréhender le concret. Cette remarque est recevable naturellement. J’ai cependant la prétention de penser qu’il faut poser une graine sur ces aspects théoriques considérés complexes et laisser murir. Mais oui c’est assez théorique, et surtout *trop* théorique pour les gens venus chercher des clefs concernant l’agile, des novices ou débutant (ceux qui sont venus chercher des réponses “meilleures pratiques” à une checklist de freins : justement nous sommes loin d’être dans ce cas de figure, ce n’est pas ainsi qu’il faut l’appréhender). J’aurais du préciser dans le programme que ce n’était pas pour des novices. Les agilistes (ou les gens endurcis à la conduite du changement) ont su raccrocher mon discours à l’expérience, une partie des autres non.

“cela s’applique à tout, pas seulement à l’agile”.

Oui c’est vrai. Mais si l’on considère (comme moi) que les freins sont le résultats des collisions, des frottements explicités par cynefin dynamics et que l’on estime que l’agile a une forte adhérence avec le domaine complexe et les pratiques émergentes, alors même si ce discours s’applique à beaucoup de chose, il est particulièrement important pour l’agile.

Une présentation à méditer pour moi. Il est clair que je n’ai pas encore assez réussi à clarifier le discours que je souhaite voir passer. Mais d’un autre côté les réactions provoquées me laissent penser qu’il y a vraiment une base de travail très intéressante.

Merci à Jacques Rouxel & Claude Pieplu pour ces inestimables Shadoks ! Merci aux gens présents et aux riches discussions qu’ils ont provoqués.

D’abord

un détail (mais le diable se cache dans les détails) “code retreat” a deux significations : tout le monde a en tête la “retraite” (“retreat”) car les mots dans les deux langues sont très proches. Retraite spirituelle d’un groupe de personnes dans un lieu isolé pour méditer ou se retrouver. Mais c’est aussi et originellement la “re-treat”, traiter à nouveau. On prend un sujet et on le traite, le re-traite, le traite à nouveau. Voilà une ambiguïté levée.

Ensuite

un point que j’ai relevé dès le début de notre journée. Nous nous sommes projetés sur des situations imaginaires, même si on les savait très proches de la réalité. N’est ce pas dommage ? Je m’interroge. Pourquoi choisit-on des situations imaginaires ?

Hypothèse 1 : pour ne pas se focaliser sur la situation de certains ? Ne pas les stigmatiser, ne pas les mettre mal à l’aise, ne pas révéler leur situation (on est  entouré de concurrents même si le niveau de confiance est bon) ? Personnellement cela ne me génerait pas de parler précisément de certaines de mes situations quitte à me mettre en porte à faux : l’enseignement n’en serait que meilleur. Quant à la question de la concurrence, je peux ne pas prononcer le nom de mes clients, si les gens veulent savoir, ils savent.

Hypothèse 2 : pour ne pas s’enfermer dans une situation bien précise qui ne parlera réellement qu’à celui qui l’évoque ? Nous avons fait du dot-voting sur ces situations imaginaires, nous aurions pu le faire sur des situations connues pour être réelles. Quoiqu’il en soit je ne crois pas qu’une situation ne m’intéresse pas même si je ne l’ai jusqu’à présent jamais croisée. Je pense que l’on retrouve toujours un enseignement, un point intéressant que l’on peut mettre en parallèle avec son expérience. Enfin l’évocation d’une situation réelle portée par un “product owner”  me parait bien plus tangible et puissante.

Hypothèse 3 : (qui rejoint l’hypothèse 2) les réponses évoquées, envisagées, dans une situation concrête ne seront valables que pour celle-ci. Le contexte étant fondamental. Oui. Et alors ? Ce qui m’intéresse ce n’est pas tant les réponses envisagées, que la façon d’envisager ces réponses. Quel positionnement, quel raisonnement, quel mécanisme d’analyse mettons nous en oeuvre, quelles actions proposons nous ? Voilà la raison de cette retreat/re-treat. Pour ceux qui me suivent sur Twitter je suis très influencé par Cynefin ces temps-ci. Ce qui m’intéresse c’est donc les bonnes pratiques ou les meilleurs pratiques que mes camarades ont pu faire émerger ou utiliser (et c’est d’ailleurs aussi ce que l’on nous a proposé durant la journée : “clickrewind”, “solution focussed”, “crucial confrontations”, “appreciative inquiry”, etc. sont des bonnes pratiques). Les moments où ils ont bousculés les habitudes de leurs clients pour les placer dans un environnement émergent. Pourquoi, comment, effets observés, succès, échec. Discutons-en. Sur du concret même si je sais qu’il n’est pas reproductible c’est la façon de faire (de coacher) qui m’intéresse.

J’ai profité du “Freeplay: no rules. You do as you wish” pour proposer au groupe d’avoir une approche plus concrête. Pour essayer. Je ne sais pas si cela est réellement profitable. Mais j’ai fait choux blanc.

Enfin,

pour finir, l’éternelle question sur le positionnement coach ou consultant est revenue plusieurs fois sur le tapis. Si je caricature (volontairement), sommes nous des coach qui murmurons à l’oreille de nos clients lesquels intègrent, digèrent comme ils le souhaitent, si ils le souhaitent ? Ou sommes nous des consultants qui indiquons la meilleure marche à suivre, les processus à déployer, les positionnements à prendre ? Nous sommes les deux. Dans l’absolu (=joker) oui il faut murmurer à l’oreille de ses clients : nous ne pouvons décrêter qu’ils sont convaincus, ou motivés. Nous ne sommes pas en mesure non plus de connaitre la meilleure réponse. C’est lui qui la connait et qui doit l’exprimer. (J’ai pu -dans une conférence- oser le rapprochement entre le coach et le psychanalyste). Mais comme les équipes que nous accompagnons nous avons des “deadlines”, des attentes des clients (qui nous sollicitent) et un produit opérationnel à proposer à intervalles réguliers, des processus à déployer. Ne cherchons pas à séparer ces deux facettes de notre métiers. Coach ? Consultant ? Je ne crois pas que l’on puisse avec Agile être soit l’un, soit l’autre sans y perdre quelque chose.

Merci à Oana (que j’adore) pour l’organisation de cette belle journée, merci à Yves pour sa présence.