Quand j'ai cessé de rester dans ma voie
Le tournant s'est produit un soir où j'ai activé le "mode fête" de BMAD.
Le mode "party" permet de créer un groupe d'agents (chef de produit, analyste, architecte, développeur, testeur, Scrum Master) et de les faire participer à un chat partagé. J'ai tapé un concept fou pour une application de coaching de Scrum-stances, j'ai appuyé sur Entrée et j'ai regardé la salle exploser.
En quelques minutes, les agents posaient des questions plus pointues que dans la plupart des réunions réelles :
"Qui est le l'utilisateur qui est l'utilisateur réel - les Scrum Masters en solo, ou les Scrum Masters au sein des organisations ?"
"Qui paie si la direction fait partie du problème ?"
"S'agit-il d'un outil de conseil ou d'un outil de développement de la position ?"
"S'agit-il vraiment d'un SaaS d'entreprise ou d'un outil communautaire open source déguisé ?
Je suis arrivé en testant "simplement" un cadre d'IA. Je suis reparti en réalisant que le système m'avait renvoyé mon propre flou et m'avait aidé à le nettoyer. Il ne s'agissait pas de devenir un ingénieur 10x. Il s'agissait de devenir un personne plus honnête et plus utile pour le produit en s'engageant dans la construction, et pas seulement en la facilitant.
Pourquoi "Business-uniquement" est en train de devenir un handicap
Pendant la majeure partie de ma carrière, je me suis senti responsable en restant du côté des affaires. Mon travail consistait à encadrer, clarifier, établir des priorités et traduire. Lorsque les choses devenaient "trop techniques", je passais le relais à un développeur ou à un architecte et je leur faisais confiance pour combler les lacunes.
Cela avait du sens lorsque la partie construction était le goulot d'étranglement. Les humains écrivaient tout le code. La documentation coûtait cher. Demander "une expérience de plus" signifiait des semaines d'efforts.
L'IA agentique a brisé cette équation. Aujourd'hui :
Un petit essaim d'agents peut rédiger un document d'architecture en quelques minutes.
Un agent de développement peut échafauder une application web complète pendant que vous remplissez votre café.
Un agent analyste peut démonter votre PRD et le reconstruire avec des contraintes plus strictes et de meilleurs benchmarks.
Ce qui est lent, ce n'est plus de taper. Ce qui est lent, c'est la réflexion :
Sommes-nous en train de résoudre un problème réel ou un problème de vanité ?
Nos contraintes sont-elles réelles ou s'agit-il simplement d'habitudes ?
Quel est le coût économique d'"une dépendance de plus" ou d'"un modèle de plus" ?
Si vous restez uniquement du côté de l'entreprise, vous prenez des décisions importantes concernant l'étendue, le risque et la valeur sans ressentir ces décisions dans le code, l'architecture ou les dépenses. Ce n'est pas plus sûr, c'est tout simplement aveugle. Je ne voulais plus être aveugle.
BMAD : Des roues de formation pour Non-développeurs
BMAD enveloppe votre travail dans une forme d'équipe familière :
Personnage de chef de produit pour remettre en question la vision et le champ d'application.
Personnage d'analyste pour les PRD et les briefs.
Personnage d'architecte pour les piles et les contraintes.
Personnage de développeur pour l'implémentation et les refactors.
Le personnage du testeur pour les critères d'acceptation et la couverture.
Le persona Scrum Master pour insister sur le fait que le projet est "prêt pour le développement" ou qu'il ne s'agit pas d'un vœu pieux.
Vous leur parlez en langage clair. Ils répondent par des artefacts : documents markdown, histoires, tests, code, flux de travail. Pour quelqu'un comme moi, cela fait deux choses :
Cela abaisse la barrière à l'entrée. Je n'ai pas besoin de connaître la syntaxe de chaque outil. Je peux dire : "Aidez-moi à concevoir une application de facilitation Cynefin qui supprime les données après 72 heures", et les agents s'occupent de l'échafaudage pendant que je dirige.
Cela place la barre plus haut dans ma réflexion. Les exigences faibles, les utilisateurs flous et la pensée magique du MVP sont rapidement révélés. Les agents ne cessent de poser les questions suivantes : "À qui cela s'adresse-t-il ? À quoi ressemble ce qui est fait ? Qu'est-ce que ce choix signifie pour l'architecture et les tests ?"
BMAD n'a pas fait de moi un ingénieur full-stack. Il a transformé mes instincts de produit en quelque chose de testable, et il a fait en sorte que la partie construction se sente moins comme une boîte noire.
Les mains-Dirty Moment #1 : Une application Cynefin en un après-midi
En tant que facilitateur, j'adore le cadre Cynefin. L'expliquer à l'aide de diapositives me paraissait superficiel. Je voulais une petite application web à utiliser dans les ateliers : capturer des exemples, les classer par domaines, puis effacer l'ardoise.
Avant l'IA, cette idée serait restée sur un tableau "un jour". Avec BMAD, j'ai :
J'ai ouvert un repo propre et j'ai installé le framework.
J'ai dit aux agents ce que je voulais : une simple application React, soutenue par une base de données qui supprime automatiquement les données après ~72 heures.
J'ai laissé les personas dev et architect proposer une pile et câbler les bases.
En un seul après-midi, j'avais :
Un front-end fonctionnel.
Un backend en nuage avec les bonnes tables et la bonne rétention.
Une application légère mais réelle que je pouvais mettre en place, utiliser avec une équipe et démanteler.
Je devais encore revoir le code, peaufiner le texte et ajuster les détails de l'interface utilisateur. J'ai dû en apprendre suffisamment pour corriger le comportement des infobulles et déplacer le texte là où il aidait réellement la conversation.
Mais ma douleur de facilitateur s'est transformée en un véritable produitet pas seulement une histoire d'utilisateur. Une fois que vous avez vu un prototype jetable devenir une application utilisable en une journée, il est plus difficile de demander à une équipe trois sprints sur quelque chose que vous n'avez jamais essayé de mettre en place vous-même.
Les mains-Dirty Moment #2 : Se faire rappeler à l'ordre par mon propre PRD
Dans une autre expérience, j'ai introduit BMAD dans un repo de recherche en friche : un projet de réseau neuronal multimodal. J'avais déjà un PRD. Il semblait solide. J'ai ensuite demandé au personnage de l'analyste de le réviser. Le retour d'information m'a piqué, dans le bon sens du terme :
Des énoncés de problèmes plus clairs, moins de mots à la mode.
Cibles explicites en matière de matériel et de formation : "Sur cette classe de GPU, visez tel nombre d'heures, tel nombre de paramètres, tel type de débit.
Un paysage concurrentiel que je n'avais pas complètement articulé.
Une remise en question d'une dépendance externe "agréable à avoir" qui n'aurait dû intervenir qu'à un stade ultérieur.
Je n'avais pas besoin de devenir un expert CUDA. Je devais accepter que mon PRD original était plus proche d'un mémo de vision que d'un document d'ingénierie. Depuis, je pose des questions plus pointues lorsque quelqu'un me demande de l'aide :
Je pose des questions plus précises lorsque quelqu'un propose "juste une bibliothèque de plus" ou "un modèle de plus".
Je parle des contraintes en termes concrets : temps, mémoire, débit, précision, et pas seulement "plus vite" et "mieux".
Je respecte le coût du "travail de recherche" comme je ne le faisais pas avant de l'avoir vu de bout en bout.
Vous pouvez faire une version plus petite de ce processus pour n'importe quel produit :
Prenez un PRD dont vous êtes fier.
Demandez à un agent de type analyste de le démonter et de le reconstruire.
Ramenez les bords les plus nets à l'affinage et à la planification.
Les mains-Moment désagréable #3 : Transformer Scrum-Scrum en un produit
L'expérience la plus personnelle a été l'application Scrum-stances. En tant que Scrum Master et coach, il m'est arrivé de passer maladroitement d'une position à l'autre. Passer de coach à enseignant, ou de facilitateur à agent de changement, n'est pas toujours gracieux. Cela ne nuit pas toujours à l'équipe, mais vous savez quand cela ne va pas.
Un jour, j'ai laissé tomber cette maladresse pour passer directement à la fête : "J'ai une idée folle pour une application Scrum qui aide les Scrum Masters à pratiquer des positions, et pas seulement à déplacer des cartes. Utilisons scrum.org comme source canonique et construisons ce que j'aurais aimé avoir en passant de PM à Scrum Master". Les agents :
Ils ont formulé un problème autour de l'écart entre la certification et la pratique vécue.
Ils ont souligné à quel point l'accès au mentorat dépendait de la chance.
Ils ont remis en question mon langage de "premier arrivé" et l'ont recadré comme "premier à opérationnaliser le développement de la posture".
Ils ont insisté sur la confidentialité et la sécurité psychologique : les réflexions ne sont utiles que si les Scrum Masters se sentent en sécurité lorsqu'ils les écrivent.
Puis ils ont mis l'accent sur un point que j'avais éludé :
Cette méthode doit être open source, dirigée par la communauté et adoptée individuellement.
Les Scrum Masters devraient pouvoir s'inscrire sans l'aval de la direction.
Le crowdfunding et le sponsoring correspondent mieux à mes valeurs que la recherche de revenus de licence.
En d'autres termes, ils ont transformé mon histoire d'origine en une stratégie de produit. Je ne suis pas reparti avec une application finie. Je suis reparti avec :
Un briefing plus précis.
Une pile qui invite les contributions au lieu de les effrayer.
Une façon plus honnête d'expliquer mon "pourquoi" aux autres Scrum Masters.
Ma maladresse vécue a cessé d'être une histoire de guerre et est devenue une contribution de première classe au produit.
Comment cela a changé mon travail de jour
Je suis toujours un Scrum Master / Product Owner / BA / PM, mais je suis différent maintenant parce que j'ai passé du temps du côté de la construction avec les agents :
Dans le raffinementJe n'accepte pas les histoires ou les critères d'acceptation flous. Non pas parce qu'un livre le dit, mais parce que j'ai vu des agents s'agiter sur des entrées vagues et inventer des solutions que je n'avais pas prévues.
Dans la planificationje parle concrètement de compromis. Je pose la question suivante : "Quel est l'impact de ce choix d'outil sur notre IC ? Pour les autres contributeurs ?" Je ne cherche pas à surclasser qui que ce soit ; j'essaie de comprendre les risques et les coûts que je leur demande d'accepter.
En coachingje ne me contente pas de dire aux équipes de "se rapprocher de la construction". Je peux dire : "Asseyons-nous avec un développeur agentique pendant un après-midi et faisons un petit projet ensemble. Vous verrez ce que des histoires et des contraintes propres peuvent apporter en termes de rapidité".
Surtout, j'ai plus d'empathie. Lorsque les développeurs repoussent la portée, j'ai ressenti cette tension dans mes propres expériences. Lorsque l'assurance qualité demande de meilleurs critères d'acceptation, j'ai vu la différence dans les tests automatisés. Lorsque les architectes demandent "juste une intégration de plus", je peux imaginer l'arbre des dépendances, et pas seulement la feuille de route.
Je suis toujours la personne du côté de l'entreprise qui plaisante sur le fait de "jouer un développeur à la télévision". Mais cet acte a des conséquences réelles : il fait de moi un meilleur partenaire pour les personnes qui vivent dans le code tous les jours.
Pour commencer : Un petit manuel pour les entreprises-Les gens d'à côté
Si vous êtes un Scrum Master, un Product Owner, un BA, un PM ou tout autre membre d'une équipe axée sur les affaires, voici un petit moyen concret de commencer.
1. Choisissez un problème qui vous vous*
Faites en sorte qu'il soit minuscule et égoïste :
Un outil de facilitation (comme l'application Cynefin).
Un micro-tableau de bord dont vous souhaiteriez l'existence.
Un petit compagnon pour un atelier ou une formation que vous organisez déjà.
2. S'engager pour un week-end de construction
Mettez en place un cadre agentique (BMAD ou quelque chose de similaire).
Ne cherchez pas la "pile parfaite". Laissez l'architecte/le développeur proposer une solution par défaut.
Votre objectif n'est pas "prêt pour la production". C'est "quelque chose dans lequel je peux cliquer et apprendre".
3. Appuyez-vous sur les conversations, pas sur le code
Demandez à l'analyste un briefing ou un PRD.
Demandez au PM persona de remettre en question vos utilisateurs et votre proposition de valeur.
Demandez à l'architecte quels compromis vos choix impliquent.
Laissez l'agent de développement s'occuper de l'échafaudage, puis lisez et questionnez le résultat.
4. Rapportez un artefact à votre équipe
Le lundi, présentez-vous avec :
Une petite chose en cours d'exécution, ou
Un PRD/brief plus précis, ou
une vision plus claire des contraintes et des coûts.
Puis dites : "J'ai essayé de construire ce week-end. Voici ce que j'ai appris sur la façon dont nous écrivons des histoires / parlons des contraintes / raisonnons sur les coûts". Vous n'avez pas besoin de devenir développeur, mais vous devez toucher à la construction. Parce qu'en fin de compte, nous sommes des gens qui résolvent des problèmes pour des gens :
Nous sommes des personnes qui résolvent des problèmes pour des personnes.
Nous sommes des personnes qui font des affaires avec des personnes.
Nous sommes des gens qui utilisent l'IA générative pour construire des produits pour les gens.
La confiance change tout.
L'un des moyens les plus rapides de gagner cette confiance est de passer un peu de mon temps dans le monde de l'équipe : les mains sur le clavier, les agents à mes côtés, apprenant en construisant.
Prêt à combler le fossé entre l'entreprise et la construction ? Contactez Improving pour voir comment l'IA agentique peut accélérer vos équipes de produits.
