En janvier 2015, je commence l’année dans un nouveau monde. Comme architecte de solutions chez un joueur de l’industrie du vélo, mes journées tournent autour des dealers, de leurs commerces, pis d’un gros ERP — Dynamics AX — à faire entrer dans la vraie vie. Pis dès mes premières semaines, je retrouve un vieux débat qui me suit depuis des années: l’agile, cette belle idée, qui change de visage dès qu’on essaie de l’étirer à grande échelle.

L’agile en petite équipe, c’est magnifique. Quelques personnes proches, une cadence rapide, des décisions prises en se parlant. Mais quand le projet grossit — plusieurs équipes, un ERP, des dealers qui attendent — l’agile perd un peu de sa grâce. Il se met à ressembler à ce qu’il voulait remplacer.

Quand la grâce se transforme en cérémonie

Le piège, c’est que plus on monte en échelle, plus on ajoute de structure pour « coordonner ». Pis cette structure-là finit par étouffer ce qui faisait la beauté de l’agile au départ.

flowchart TD
    A[Agile en petite équipe<br/>proche, rapide, on se parle] --> G[On grossit:<br/>plusieurs équipes]
    G --> Q{Comment<br/>coordonner?}
    Q -->|Réunion de synchro| C1[Cérémonies]
    Q -->|Rôles de liaison| C2[Comités]
    Q -->|Documents partagés| C3[Paperasse]
    C1 --> R[Réunions de réunions]
    C2 --> R
    C3 --> R
    R --> F[On a réinventé ce<br/>qu'on voulait remplacer]
    F -.le piège de l'échelle.-> A

C’est exactement ce qui me dérange. À force de vouloir faire de l’agile « à l’échelle », on empile des cadres, des cérémonies, des rôles. Pis on se réveille un matin avec des réunions pour préparer les réunions, de la paperasse déguisée en post-it, pis une lourdeur qui ressemble étrangement au vieux modèle en cascade qu’on disait avoir tué.

Ce que je garde, ce que je laisse tomber

Mon approche, comme architecte qui doit livrer un vrai système à de vrais dealers, c’est de revenir à l’essentiel. L’agile, c’est pas un rituel, c’est un état d’esprit: livrer petit, écouter le terrain, corriger vite.

Avec les dealers, ça veut dire montrer quelque chose tôt, recueillir leurs réactions, pis ajuster. Pas leur promettre un grand système parfait dans un an. Un ERP comme Dynamics AX, c’est déjà rigide de nature. Si en plus on l’enrobe d’un agile bureaucratique, on perd sur les deux tableaux.

La leçon que je ramène

Ce que mon expérience m’enseigne, c’est que l’agile à grande échelle réussit quand on protège l’esprit pis qu’on se méfie des cérémonies. La structure devrait servir la livraison, jamais la remplacer. Dès qu’une réunion existe juste pour exister, c’est un signal d’alarme.

Comme architecte, mon rôle, c’est souvent de dire non. Non à la cérémonie de trop. Non au cadre qu’on ajoute par peur plutôt que par besoin. Parce que la vraie agilité, c’est pas une boîte à outils de réunions: c’est la capacité de livrer pis de s’ajuster sans s’enfarger dans sa propre machine.

Ce que je retiens

En janvier 2015, je redécouvre, dans mon nouveau rôle auprès des dealers, que l’agile change d’échelle pis perd un peu de sa grâce dès qu’on l’étire. Plus on grossit, plus la tentation est forte d’ajouter de la structure qui, au final, ramène la lourdeur qu’on voulait fuir.

Mon plan pour l’année: garder l’esprit, couper le superflu. Livrer petit, écouter les dealers, ajuster vite. Pis surveiller comme un faucon le moment où l’agile commence à ressembler à de la bureaucratie déguisée — parce que ce moment-là arrive toujours, pis c’est là qu’un architecte doit avoir le courage de dire « on en fait trop ».