L’arrivée de l’agile à OCTO 3/6 : Laurent Brisse

Cette interview fait partie d’une série, vous trouverez les autres à cet endroit.

Le 26 mars 2018

Laurent Brisse est un des architectes historiques d’OCTO. Il a quitté l’entreprise l’an dernier et il est désormais coordinateur architecture chez Lectra.

Comment s’est passée l’arrivée de l’agile à OCTO ?

J’étais centré sur l’architecture donc l’agile n’était pas dans mes préoccupations principales. Mes premiers souvenirs portent plutôt sur les nouvelles façons de faire et les nouvelles méthodes de coaching que sur les aspects purement agiles. Je me suis appliqué ces méthodes pour réduire la boucle de feedback et travailler plus sur l’équipe que sur les personnes : travailler de manière collaborative, faire mieux participer nos clients aux ateliers…

Au niveau d’OCTO, ce que je retiendrais de la fusion entre l’agilité et l’architecture, c’est le passage du dossier d’architecture générale (DAG) au Cadrage 360°. C’est l’aboutissement des échanges entre des architectes qui voulaient poser un cadre dès le début et des agilistes qui voulaient immédiatement commencer les développements.

L’idée du cadrage 360° est que le seul engagement qu’on peut prendre au lancement d’un projet agile est de pouvoir faire une première estimation – même si pas définitive ou engageante – en deux ou trois semaines. Une des forces d’OCTO a été de dire qu’on ne ferait pas de développement agile sans commencer par ce type de cadrage, et c’est devenu un réflexe.

Comment s’est passé le changement pour les clients ?

Jusqu’à ce moment, nous faisions de l’architecture, des POCs ou des projets techniques. L’agilité est arrivée en même temps que la volonté de faire du développement projet. Vendre du coaching agile était alors compliqué car les clients n’étaient pas prêts, c’est grâce au développement qu’on a pu vendre de l’agile et plus tard de l’UX.

Qu’est-ce qui manque encore aujourd’hui à l’approche agile ?

La gestion des moyens. De mon expérience, on travaille toujours avec un budget et il faut un minimum de prévisibilité. Les réticences des agilistes face aux estimations sont cohérentes : leur objectif premier est d’apporter de la valeur.

Mais un projet c’est aussi des priorités budgétaires et des personnes avec des carrières, je ne peux pas juste avancer de deux semaines en deux semaines. Pour moi la manière de s’y prendre en agile n’est pas encore très claire, le no estimates pourrait être une façon d’en sortir en estimant le minimum de choses nécessaires, mais cela reste très difficile de convaincre nos interlocuteurs.