Rachel nous à proposé un panorama honnête de 4 frameworks actuels de passage à l'échelle.

Au-delà de la présentation de haut vol dont nous avons profité (oui, je suis fan de Rachel et je l'assume), je retiens en particulier :

• La définition d'un passage à l'échelle selon le Scaling Agile Manifesto de 2019 :

• L'enjeu d'un passage à l'échelle :
  • l'alignement et la synchronisation des équipes
  • la gestion des dépendances
  • évidemment, le tout se base sur un focus client, de l'amélioration continue, une approche empirique, et surtout, sur les méthodes ou frameworks agiles déjà connus
  • le tout, dans une structure qui grandit à la façon de fractales mathématiques
• Les succès rencontrés lors d'une mise en œuvre de LeSS sur 6 mois, et les limites d'un focus trop court-termiste
• Son enthousiasme autour de l'approche Open Space Agility, et sa frustration d'avoir eu à accueillir des équipes le choix d'adopter une approche finalement beaucoup plus structurante (SAFe)
• Son retour sur la mise en œuvre de SAFe à très grande échelle, et l'honnêteté quant aux coûts impliqués
• L'idée d'un train d'académie pour former les gens
• Les limites qui ont émergées lors de la mise en œuvre du "Spotify Model" (qui n'en est pas un) par Spotify et que l'important ne ce situait pas dans cet article, mais dans les posters "Spotify engineering culture" part 1 et part 2
• La sagesse du message "Si vous pouvez éviter de passer à l'échelle, EVITEZ"

Pablo nous a proposé une présentation du modèle Cynefin de Dave SNOWDEN.

J'ai particulièrement apprécié :

• les rappels sur les principales caractéristiques de chaque domaine du modèle, à travers les questions :
  • Est-ce que l'on sait faire ? / Est-ce que l'on a la réponse à la question ?
  • Est-ce que l'on est sûre de réussir ?
  • Est-ce que l'on sait comment on va faire ?
• les 4 types de réactions attendues :
  • Simple : On observe et on catégorise
  • Compliqué : On observe et on analyse
  • Complexe : On essaye et on observe (vive l'empirisme)
  • Chaos : On réagit (pas le choix) et on observe
• ce repère sur la prise de décisions :

Et quelques idées à creuser :

• Red Team Defense : site du ministère de la défense sur le type de catastrophes auxquelles ils se préparent
• Les univers Cyberpunk : projections qui commencent à émerger. Et hasard du calendrier, Humble vient juste de sortir un pack contenant une référence Cyberpunk

Nico et David nous propose une réflexion sur la course effrénée à la nouvelle fonctionnalité et sur l'impact de cette course sur la qualité de votre produit, à l'instar de la dette technique qui - non entretenue - fera sombrer votre produit.

J'en retiens en particulier :

• Le boulot d'un PO est-il vraiment de toujours créer plus de nouvelle valeur ?
• Il est indispensable de TOUJOURS valider ses hypothèses et savoir faire le deuil rapidement des fonctionnalités qui n'ont pas répondues aux attentes. (Attention au biais des coûts irrécupérables)
• Occuper les équipes à tout pris est une hérésie. Laissons leur le temps de faire le ménage, c'est indispensable. Et oui, cela ne se fera pas sans y investir du temps ! (Mais c'est rentable sur le moyen/long terme)
• L'importance de réfléchir en termes d'impacts
• L'importance de mettre en place des mesures ET de les suivre (A minima, identifier et suivre la North Star de notre produit)
• Un 1er tableau de bord, même rudimentaire, nous apportera beaucoup pour un investissement qui ne devrait pas excéder 1/2 j d'effort à mettre en place
• N'oublions pas le Gemba Walk ! Allons voir sur place les vrais pain points. Valorisons les équipes tech !
• Comme la dette technique, la dette fonctionnelle est inéluctable. Alors traitons-la !

Hélène nous propose une réflexion sur l'impact de nos produits, et sur le monde peu réjouissant dans lequel nous évoluons. Que ce soit d'un point de vue sociétal, environnemental, politique, ou écologique, force est de constater que nous ne sommes pas au top. Et évidemment, nous avons notre part de responsabilité dans ce constat.

Mais elle avait prévenu, "Spoiler : sur les 10 premières minutes, je vais souligner combien nous sommes des co######"

Mes highlights sur cette présentation :

• "Vous êtes responsable de ce que vous injectez dans le monde" (Victor PAPANEK)
• L'exemple de Duolingo qui a mis en place des stratagèmes très efficaces pour que ses clients se connectent régulièrement. Voire même les fait culpabilisés s'ils ne se connectent pas quotidiennement
• Cherchons-nous vraiment à rester étiques dans nos choix et dans les fonctionnalités que nous poussons en production ?
• La roue des futurs possibles (non, ce n'est pas un film), pour se pousser à imaginer tous les impacts possibles d'une fonctionnalité (Cf. "futures Wheel" de Jérome C. Glenn - 1972)
• Garder l'esprit critique face à l'opportunité de développement d'une nouvelle fonctionnalité
• Le principe de "kill de feature" pour éviter de maintenir des fonctionnalités obsolètes, inutiles, voire nocives.
• La proposition d'évolution du format Connextra des US en y intégrant "en limitant …" ou "en veillant à …"
• L'écoresponsabilité n'est pas à opposer à l'opportunité business. Bien au contraire, il s'agit de plus en plus (mais pas encore assez) d'un avantage concurrentiel.
• Hélène propose une newsletter sur ces sujets ainsi qu'une nouvelle chaine youtube.

Johnny et Yves nous ont proposé un atelier vraiment surprenant. L'ouverture se fait sur une question d'engagement vraiment anodyne :

Vous êtes des groupes de 5 à 6 personnes.
En combien de temps pensez-vous être capable de résoudre collectivement un puzzle de 9 pièces ?

A ce stade, autant dire que nous avons été dubitatifs. Mais ça, c'était sans compter sur le caractère joueur de Johnny et Yves.

Si nous n'avons pas vraiment galéré (à notre table) sur l'auto-organisation, croyez-moi, point de intelligence collective, cela a été beaucoup plus galère .

Perso, je me questionne encore sur cet atelier et la difficulté d'illustrer l'intelligence collective lorsque si peu de personnes ou de groupes sont en mesure de refaire ledit puzzle. J'en retiens par contre le décalage terrible qu'il y a entre un intitulé d'engagement qui semble si simple, alors que l'on est à minima dans un domaine compliqué (selon Cynefin).

Maxime nous a proposé sa vision des transformations agiles à travers une illustration cinématographique à base de "nanars".

A titre personnel, j'en retiens que :

• je ne cautionne pas de placer Zardoz, Sharknado, 2001 l'odyssée de l'espace, et Avatar sur un même niveau à travers l'étiquette "nanars"
• Tous les process que vous allez mettre en place, il faut vous dire qu'à un moment ils vont sauter. Cela commencera par la doc, puis les tests, puis etc. Seule la culture restera. MAIS la culture, c'est dur à faire émerger.
• Attention aux processus qui fragilisent la culture.
• On cherche souvent des transformations qui ne font pas mal. Pas de bol, une transformation ça demande des efforts et ça fera mal.
• Au lieu de contractualiser la vélocité, on devrait contractualiser la qualité (Alfred Almeria)
• Si on veut créer de grands produits, nous avons besoin de gens formidables. Si nous voulons attirer et garder des gens formidables, nous avons besoin de grands principes (Jim Highsmith)

Ceux qui me lisent savent que j'ai déjà suivi un certain nombre de conférences de Rachel sur ce sujet. Pour autant, ces opportunités sont toujours enrichissantes. Parmi tout ce qui a été partagé, voici ce que je choisi de mettre en relief :

• Le focus doit être fait sur les 2 posters (1 et 2), pas sur le PDF ! (Spolier, c'est ce que la majorité des implémentations dites "du Spotify Model" ont retenues)
• Les posters se nomment d'ailleurs "Spotify engineering culture", et non "Spotify Model". Ce n'est pas un détail.
• Pour Spotify l’engineering c'est le business (ce n'est pas au service du business)
• Chez Spotify, on veut les meilleurs mais on ne veut pas de divas
• Les "Squads" se nomment à présent des "Teams" ou "Product Teams"
• Les équipes sont très stables, ou en "dynamic reteaming" pour des missions courtes
• Les équipes gèrent tout, et sont donc en frontal direct avec le client
• Les équipes ont une culture XP forte, mais il n'y a pas de prescription agile au sein de Spotify
• Les "Chapters" ont sauté parce que la double matrice était ingérable
• Les "Tribes" sont devenues des "Studios"
• Les priorités sont gérées en P0 > P1 … P3. MAIS la dette technique passe toujours en P0 !!!
• On ne peut pas releaser sans qualité
• Les pratiques d’engineering ne sont pas négociées. Elles sont un pré-requis.
• Le train de release est poussé en prod tous les vendredis. Que les équipes aient finies ou pas !!! Les équipes désactivent ce qu'elles n'ont pas fini. Mais quoi qu'il arrive : ça part !
• Et 2 chiffres qui ont de quoi impressionner :
  • 7% de l'humanité utilise Spotify
  • 3% de l'humanité paye un abonnement Spotify

Frédéric fait parti de ces rock stars qu'il faut aller voir sur scène !!! (C'est un kif systématique !)

Et bien au-delà de la prestation scénique, les messages méritent d'être entendus par le plus grand nombre.

En voici quelques-uns :

• A titre personnel, un logiciel inefficace, on le change. A titre professionnel : il faut uniformiser pour faire des économies d'échelles.
• Le planning est une source d'informations inutiles aujourd'hui, et obsolète à partir de demain.
• Si on essayait la priorisation … par priorités.
• "Le passé s'arrête au début de cette phrase." (Frédéric Leguedois)
• Un exemple d'organisation efficace sans planning : Les urgences médicales. Il existe un process "global", mais l'ordre de prise en charge ne dépend pas exclusivement de l'ordre d'inscription. Ainsi, il n'y aura pas d'investissement chronophage à rééditer un planning à chaque nouveau patient, mais un process général permettant de prendre en charge tout le monde de la façon la plus fluide et efficiente possible pour le service (même si les patients non-critiques ont l'impression de perdre du temps).

Thomas nous a délivré son approche du BDD (Behaviour Driven Development) pour une mise en œuvre à la hauteur des enjeux en 2025.

Voici quelques éléments retenus :

• L'exemple est là pour lever les ambiguïtés
• Il faut partager le même vocabulaire, et utiliser un maximum le vocabulaire du domaine
• Le BDD permet de réduire le rework lié à (la mauvaise) interprétation par les dev ou aux incompréhensions
• Le BDD intervient tout au long du cycle de vie d'une US :
  • lors de l'élaboration de l'US à travers sa description et l'identification des tests d'acceptation
  • lors de la formalisation de l'US et de ses tests d'acceptation
  • lors de l'automatisation des tests d'acceptation
  • lors de l'écriture effective du code de production correspondant aux tests d'acceptation
• L'example mapping est une pratique efficace de co-construction d'une US
• Thomas prône l'idée que l'automatisation n'est pas obligatoire. Je respecte ce point de vue mais n'oubliez pas une chose : Il n'y a QUE ce qui est automatisé qui sera toujours repassé. Personnellement, s'il n'y a pas d'automatisation, je n'ai pas confiance.

Dans le cadre de l'Open Space (une nouveauté de cette année), Alexandre nous a proposé un atelier de découverte du modèle de Schneider pour analyser l'organisation d'un service ou d'une entreprise. Il va falloir que je creuse un peu le sujet (par ici par exemple), mais au moins j'ai un pointeur et un avant-gout. Merci Alex !

Que serait un Open Space sans une session de Keep Talking and Nobody Explodes ?

Je me suis donc fait un plaisir de proposer cet atelier dans une version "altered" (je n'avais pas les supports de démineurs imprimés).

Mais c'était sans compter sur Jean-Noël qui est beaucoup plus organisé que moi, et qui a proposé la même session. Nous avons donc naturellement fusionné nos sessions.

Puis Nicolas, qui avait un PC équipé de la même version que Jean-Noël s'est joint à l'organisation de la session.

Cet atelier est toujours un kif. Mais en plus, partager avec Jean-Noël et Nicolas nos différentes approches de l'atelier nous a positionné dans le coeur de cible d'un Open Space : le partage et l'enrichissement réciproque.

Spoiler : Il y a actuellement une offre imbattable directement sur le site https://keeptalkinggame.com/ à travers Humble Store : Ne serait-ce que pour vos soirée en famille : foncez ! Ca vaut le coup

En conclusion, encore une belle édition d'Agi'Lille ! Il n'y a pas à dire, ils savent accueillir dans le Nord !

J'en suis reparti avec des nouveautés, des idées, des souvenirs, de l'énergie. Il s'agit donc d'un traitement dont le renouvellement annuel est fortement conseillé.