Accompagner une équipe qui adopte BMAD

Une équipe qui adopte BMAD ne change pas seulement d'outil. Elle change la façon dont elle réfléchit, décide et se répartit le travail. C'est un changement d'organisation à part entière, et il s'accompagne comme tel.

La posture

• Rester en posture bassePosture de l'accompagnant qui se place en retrait : il questionne et laisse l'équipe trouver ses réponses, au lieu de prescrire.. Le coach n'a pas à devenir expert de BMAD. Son rôle est d'aider l'équipe à regarder ce qu'elle en fait.
• S'intéresser aux interactions plus qu'à l'outil. Qui relit les documents produits par l'IA ? Qui ose les contester ? Qui reste à l'écart ?
• Remettre l'humain au centre. Le premier principe du Manifeste agile, « les individus et leurs interactions plus que les processus et les outils », n'a jamais été aussi d'actualité.

Les questions à poser

Ces questions suivent les quatre familles de l'entretien de Karl Tomm : comprendre, voir les liens, puis ouvrir des possibles.

Pour comprendre la situation

• Sur quels travaux utilisez-vous BMAD aujourd'hui ? Et sur lesquels pas ?
• Qui relit le PRD et l'architecture produits avec l'IA ? Combien de temps y passe-t-il ?

Pour voir les liens

• Quand l'agent propose une architecture, que se passe-t-il ensuite dans l'équipe ?
• Depuis que l'IA rédige les stories, comment ont évolué vos échanges avec le métier ?
• Qui est le plus à l'aise avec l'outil ? Et le moins ? Qu'est-ce que ça change entre eux ?

Pour ouvrir des possibles

• Si vous deviez supprimer une étape de BMAD, laquelle ? Qu'est-ce qui vous retient de le faire ?
• Si un utilisateur lisait votre PRD, qu'est-ce qui le surprendrait ?
• Dans six mois, à quoi verriez-vous que l'IA vous a rendus meilleurs, et pas seulement plus rapides ?

Les pièges et leurs solutions

Le piège	Le signe	Une piste
La cascade déguisée	Tout passe par les quatre phases, les retours utilisateurs arrivent tard	Revenir à la juste dose : quel est le plus petit parcours suffisant pour ce travail ?
La validation en pilote automatique	Les documents sont acceptés sans être lus	Instaurer une vraie relecture à deux, et utiliser l'élicitation avancéeOutil BMAD qui « pousse » un brouillon pour le sortir de la réponse la plus probable : pré-mortem, avocat de l'autre camp, questions socratiques, audit des hypothèses… pour challenger
Le cargo cultReproduire les rituels d'une méthode sans en comprendre le sens, en espérant obtenir les mêmes résultats.	« On fait un PRD parce que BMAD le demande »	Demander à quoi sert chaque document, pour qui, et ce qui se passerait sans lui
L'équipe-miroir	Le party modeMode de BMAD qui réunit plusieurs agents dans une même conversation : ils répondent chacun dans leur rôle, se contredisent et rebondissent sur les idées des autres. remplace les échanges avec le métier ou les utilisateurs	S'en servir pour préparer les questions, puis aller voir les vraies personnes
Le savoir qui s'évapore	Plus personne ne comprend vraiment le code ni l'architecture	Revues de code humaines, présentations de l'architecture, binômes
La course aux versions	L'équipe passe plus de temps à suivre l'outil qu'à livrer	Choisir une version stable et planifier les mises à jour
Les rôles qui s'effacent	Le Product Owner ou le Scrum Master ne savent plus où est leur place	Clarifier ensemble ce que l'outil fait, et ce qui reste humain

Démarrer en douceur

1. Choisir un terrain d'essai limité : une fonctionnalité, pas tout le produit.
2. Partir d'un vrai besoin : on n'adopte pas BMAD pour adopter BMAD.
3. Faire une rétrospective dédiée au bout de deux ou trois semaines : ce que l'outil apporte, ce qu'il coûte, ce qu'il change entre nous.
4. Décider ensemble de continuer, d'ajuster ou d'arrêter.

Le pense-bête

Le coach…	…plutôt que…
questionne l'usage	expliquer l'outil
regarde les interactions	regarder les documents
cherche la juste dose	appliquer toutes les phases
fait venir les vrais utilisateurs	se contenter des agents
fait décider l'équipe	décider à sa place