Les 23 et 24 mai, c'était la 8e édition de l'agile conférence Paris. Toujours à la bucolique porte jaune, dans le parc de Vincennes. Le site a été rénové, nous n'avons plus les peintures soporifiques vertes pâles dans les salles du chalet, et l'extérieur a pris une cure de jouvence colorée.

Le chalet de la porte Jaune

Post-Agile

Travailler autrement

A part le flacon, l'ivresse est venue en ce qui me concerne de l'aspect au-delà-de-l'agile que j'ai retrouvé dans plusieurs présentations. Cela a commencé lors de la keynote où Peter Stevens nous a montré comment un réseau de consultants (Stoos Network) cherchait à faire évoluer l'objectif premier de l'entreprise -rapporter de l'argent à ses actionnaires- vers la satisfaction (et même le régal) du client :

classical_management

radical_management

C'est la tendance gauchiste de l'agilité, mais la démarche semble sincère et cela donne un exemple de nouveau type d'organisation de 2152 collaborateurs, basée sur un réseau de groupes de personnes (satellites) indépendants.

Cela dit, je n'ai pas compris pourquoi le fait d'avoir comme but de faire gagner de l'argent aux actionnaires impliquait le modèle de management de type commande et contrôle, ou encore, la bureaucracie et le blâme dans l'organisation. Un actionnaire qui investit dans une entreprise, sans avoir de rôle opérationnel ne le fera pas par philantropie. En revanche il peut comprendre qu'il ait un intérêt (financier) à ce que les employés soient engagés et autonomes dans leur travail.

Pascal Van Cauwenberghe nous a expliqué les "Real Options: quand et comment (ne pas) prendre des décisions". C'est la métaphore financière : une option a une valeur, une date d'expiration et un coût d'achat/exercice. Au moyen de 3 "histoires belges" qui finissent bien (et une qui finit mal mais qui sert le propos), basées sur des situations qu'il a vécues en tant que coach. Il nous détaille comment décaler les décisions au plus tard : avec des rétro-plannings, le partage d'une stratégie de décision et une tactique visant à créer le maximum d'options envisageables. Par exemple une bonne architecture logicielle est celle qui crée des alternatives. Aux détours de ses exemples, il nous explique les risques de différer des investissements (cost of delay), de ne pas remettre en cause des investissements (sunk cost fallacy), de vouloir faire du générique et nous transmet ses bonnes pratiques : Set based design, DevOps, strike price, retro-planning.

Juste après dans la grande salle, dans un format d'échanges interactifs, Pierre Pezziardi aborde le sujet de la création de valeur. Comment il a pu participer en tant que DSI de la BRED à l'implémentation des normes Bâle II sensées réduire les risques banquaires, et constater que la veille de la faillite de Lehman Brothers tous ces indicateurs étaient au vert. "Agilité : do the wrong thing faster ?" ou pouvez-vous donner des exemples d'utilisateurs à qui vous apportez réellement de la valeur ? La bonne nouvelle c'est qu'on peut changer : on peut chercher un autre travail par exemple dans des structures plus légères. Mais on peut aussi réaliser de petits changements locaux. Pierre a fait appel à l'assemblée pour donner des exemples : proposer au client des améliorations ergonomiques en discutant directement avec lui, ajouter des exciters facilement implémentables, organiser des ateliers pour créer une communauté de praticiens.

Pierre Hervouet et Pascal Van Cauwenberghe nous emmènent dans le domaine de la comptabilité/contrôle de gestion avec "Vous pouvez ignorer les contrôleurs de gestion; les contrôleurs de gestion eux ne vous ignoreront pas!". En partant d'un atelier de fabrication de cocktails et du calcul du cout de revient par verre, ils nous amènent à la procédure budgétaire puis à Beyond Budgeting. C'est une méthode de gestion budgétaire qui a une dizaine d'années, et qui permet de mieux adapter le budget aux changements. Elle se base sur des principes assez proches de l'agilité (transparence, travail en équipe, autonomie et confiance, feedback).

Ce qui m'a interpelé ici, c'est le mouvement en parallèle de ce type de changement d'organisation vers la décentralisation. Vers plus d'autonomie pour des équipes transparentes et responsables. Vers plus de respect et de considération pour les humains qui constituent une organisation qui doit produire des biens ou services. L'intérêt est d'être plus efficace, d'avoir un fonctionnement plus rentable et plus durable. On pourrait aussi parler des SCOP ou de ces cadres de grands groupes qui décident de se mettre à leur compte quitte à changer d'activité. Et d'ailleurs, certains grands groupes commencent à réorganiser leurs entreprises en ce sens pour éviter des départs importants de salariés.

Enfin, Christian Fauré prend du recul avec l'"Anthropologie de l'Agile". Il nous explique les apports de l'agile et aussi ses limites. Pour lui le lean est de l'hyper-taylorisme, en ce sens qu'il crée la prolétarisation des collaborateurs car il enlève la connaissance des salariés. L'agile reste pour lui dans la gestion du court terme. Pour passer à l'échelle du moyen et long terme il faut passer respectivement à la recherche-action et à la prospective. Pour plus de détails, voir son article sur le sujet. Je n'ai pas compris pourquoi il considère que le lean produit de la perte de connaissance des collaborateurs. Je me demande si on ne retrouve pas la critique du côté sombre du lean, le cost-killing, la branche de Thierry Breton (entre autres).

Lean pour la résolution de problème et le développement des individus

Antoine Contal : Coacher les manager

Toujours dans le post-agile, nous avons tous entendu ou nous même déploré ce management qui ne comprend rien à nos manières de travailler, à nos difficultés, etc. Qu'avons-nous changé ? Antoine Contal nous donne des leviers pour cela avec "Coacher des managers". Il s'appuie sur le Toyota Way (amélioration continue et respect for people). Pour lui, un manager est un entraineur, un développeur de talent. Il progresse s'il améliore les performances de son entreprise ou les conditions de travail de ses équipes. En mode "open kimono" il nous donne les apprentissages qu'il a faits :

  • définir le succès pour une personne, de manière mesurable, c'est déjà faire du coaching
  • et puis c'est savoir guider vers les sujets qui payent
  • dépasser les frontières d'une organisation c'est une compétence à travailler
  • le coach peut utiliser l'outil des 3R (Relate, Repeat, Reframe) du livre d'Alan Deutschman: Change or Die

Dans la même mouvance lean, Regis Medina "Encore plus d'agilité avec le lean : trois pratiques pour commencer" montre le chemin à parcourir depuis des organisations Tayloriste/Fordiste, vers des organisations Lean. En effet, même si ces modèles ont beaucoup apporté à l'industrie, ils montrent leurs limites :

  • dans leur faible adaptation au changement
  • par des divergences entre le process et la réalité du terrain
  • par un manque de feedback

L'énorme challenge que représence ce changement peut-être abordé par l'apprentissage, dans le sens amélioration des compétences (par opposition à l'acquisition d'information). Par une pratique délibérée : comment transformer l'entreprise en dojo ? Avec 3 pratiques :

  • la visualisation du challenge de l'équipe et de ses problèmes
  • l'amélioration continue (résolution de problème par PDCA)
  • la pratique du terrain (go and see)

Ce qui m'a plu dans ces 2 présentations, c'est qu'on a dépassé l'académie du système lean -qui peut décourager d'une certaine manière tant c'est un domaine vaste- pour bénéficier de l'expérience d'Antoine et Régis qui en ont extrait des concepts, des pratiques adaptables à nos environnements de développement logiciel, et au delà de l'agilité. Pourquoi post-agile ? Car finalement, l'agile est une boite à outil. C'est à dire des solutions :

  • les itérations pour des besoins sujets à changements fréquents
  • le product backlog pour prioriser les besoins
  • la rétrospective pour l'amélioration continue
  • le daily pour la coordination du travail en équipe
  • les démos pour la diminution de l'effet tunnel et l'amélioration de la collaboration avec le client
  • les tests automatiques pour la diminution du coût de non régression
  • les tests d'acceptance automatiques pour la diminution du coût de la conformité aux besoins
  • le TDD pour le design logiciel

Chez mon client, on adore ce mot de solution. Tout est solution. Et quand on demande une solution à quoi, souvent on a des réponses au mieux de type écrans de fumée, au pire inexistantes. Pour l'agilité c'est pareil. Les débats scrumban v.s. scrum v.s. kanban v.s. XP c'est comme tournevis plat v.s. cruciforme. C'est encore pire quand c'est pour résoudre un problème inexistant. Le lean met au premier plan la résolution des problèmes et le développement des personnes, c'est en cela que la complémentarité avec l'agile fonctionne.

On n'entend que ce que l'on écoute

Adaptation opportuniste de la citation de Maurice Merleau-Ponty "On ne voit que ce que l'on regarde". En effet, ce n'est pas forcément une thématique que d'autres participants reconnaîtront à la conférence, mais les deux présentations suivantes ont eu une certaine résonnance pour moi.

Celle de Florence Chabanois "Mais pourquoi y m'écoute pas ?". Florence constate que l'écoute attentive est assez rare, même dans nos projets agiles. Pourquoi écouter ? Pour que l'autre recoive mon message et pour que je reçoive le sien. Pour être plus efficace. Pour cela elle conseille de travailler sa posture d'écoute (se taire, regarder dans les yeux), de s'adapter à l'autre (par exemple avec l'aide du modèle DISC), et de reformuler (acquiter, répéter, décrire).

Christophe Thibaut : Des métaphores qui nous transforment

Et puis celle de Christophe Thibaut "Des métaphores qui nous transforment". Le genre de présentation qui vous ouvre les écoutilles, vous rend plus intelligent. Les métaphores sont omniprésentes dans notre langage (nous en faisons 6 par minute!). Nous en utilisons beaucoup dans l'informatique :

  • le logiciel en tant que bâtiment : architecture, urbanisme
  • le code en tant que texte : code illisible, pas la bonne librairie
  • le code en tant qu'organisme : tout pourri, méthode propre
  • la communication en tant que force : résistance au changement, aligner les équipes
  • et bien d'autres, vous pouvez vous amuser à les chercher

L'idée est de les explorer, pour cheminer dans le langage du client, et faire du sens avec ce que l'on met en relation. Il présente le Clean Language, conçu par David Grove dans les années 80 comme outil de psychothérapie. Le but recherché est de changer grâce à ces métaphores pour mieux écouter l'autre.

Technique et fun

Emmanuel Gaillot et Jonathan Perret en binômage

C'est plus à voir que raconter. Emmanuel Gaillot et Jonathan Perret "le serveur qui fait ping". C'est un spectacle pour geeks avec du tmux, du minecraft, nodejs en coffeescript, TDD, vim, socket, décodage de trames binaires dedans. Et une autre session de live coding de refactoring avec "Du légacy au cloud en moins d'une heure" par David Gageot.

Heureux donc de relever un peu la tête, de se retrouver dans cette communauté d'agiliste. Une bonne édition qui fait plaisir à voir et donne à réfléchir.