L’arrivée de l’agile à OCTO 6/6 : Dominique Buinier

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

Le 3 avril 2018

Dominique Buinier est entrée à OCTO en juillet 1999. Elle y a exercé différents métiers : consultante, ingénieure d’affaires, directrice des opérations, directrice commerciale, directrice de l’assurance puis de l’entité banque-assurance. Depuis deux ans, elle occupe à nouveau des responsabilités transverses, notamment dans la Skool facilitant l’intégration des juniors.

Pour toi qui n’a jamais été dans aucun des deux groupes (architecte ou agiliste), comment s’est faite l’arrivée de l’agile ?

Je ne crois qu’on avait planifié de faire une transformation vers l’agile ! À l’époque, on ne savait pas faire d’agile, donc on testait une nouvelle démarche et ce n’était pas si facile que ça. On avait des convictions, on trouvait que la démarche avait du sens mais on ne savait absolument pas si allait réussir à faire basculer nos clients. On sentait que c’était une piste très intéressante mais on ne le conceptualisait pas en se disant "c’est notre stratégie, on y va à fond".

De mon point de vue, plusieurs plusieurs faisceaux se sont rejoints.

D’abord l’intérêt autour de l’eXtreme Programming (XP) de la part des architectes, avec en particulier les tests unitaires automatisés qu’on commençait à mettre en œuvre.

Ensuite, à cette époque, on faisait du conseil en architecture, des POCs, des développements de frameworks, mais pas de développement projet. Et on voyait les équipes de delivery chez nos clients qui souffraient et les projets qui n’aboutissaient pas. On entendait parler de nouvelles méthodes qui pouvaient répondre à ce type de problèmes : pourquoi ne pas les appliquer et faire aussi du projet chez OCTO ?

Le dernier, c’est l’embauche de personnes qui étaient très inspirées par ce qui se faisait aux États-Unis.

L’arrivée des coachs s’est-elle bien passée ?

Il y a eu une confrontation assez forte. D’un côté, ce qu’ils apportaient était intéressant.

Mais d’un autre côté, on n’arrivait pas à leur trouver de missions. Ils avaient des postures très marquées, donc on les percevait parfois comme des donneurs de leçons hors-sol alors que les architectes étaient sur le terrain et faisaient "bouillir la marmite".

Je me souviens avoir fait de nombreuses avant-ventes où l’on expliquait aux clients ce que c’était l’agile pour qu’ils essaient : qu’il n’y avait plus besoin de phases de spécifications longues et laborieuses, qu’on faisait des cycles itératifs où on déployait en production à chaque fois. Et les clients nous répondaient "intéressant…, mais pas chez moi".

Comment s’est trouvé l’équilibre entre architectes et agilistes ?

L’équilibre est arrivé quand des architectes se sont mis à faire de l’agile, c’est à dire quand petit à petit des gens ont commencé à faire le pont entre les deux sans posture trop forte.

L’équipe des premiers agilistes était inspirante dans la théorie, mais les concepts de l’agile se sont vraiment diffusés quand on a commencé à avoir des gens qui étaient des faiseurs sur des projets. C’était l’époque où on commençait à aller plus loin avec les clients que simplement de la prestation de conseil.

À entendre les différentes personnes, j’ai l’impression que les architectes se sont plus rapprochés des agilistes que les agilistes des architectes, est-ce le cas ?

Les agilistes ne se sont pas beaucoup déplacés car ils s’étaient déplacés avant : dans l’ensemble, ils avaient un background technique et avaient découvert l’agile et le coaching. La technique n’était donc plus vraiment leur sujet.

Rétrospectivement, qu’auriez-vous pu faire pour que ça se passe mieux ?

On aurait pu faire ça beaucoup plus facilement avec les outils d’animation dont on dispose aujourd’hui. Faire des rétrospectives, provoquer le fait que les gens échangent, étudier les douleurs… Mais on ne les connaissait pas à l’époque.