Retour d’expérience #6: Comment faire face aux contraintes ?

Synergie de groupe

Crédit image: CGE-news

Didier Blanc, responsable du service des bases de données au sein de la direction Services & Cloud nous donne son retour d’expérience sur les méthodes agiles.

Bonjour Didier, pouvez-vous vous présenter ?

D.B: Didier Blanc, responsable du service des bases de données au sein de la direction Services & Cloud depuis juin 2009.

L’équipe est composée de 8 DBA, dont 2 apprentis en alternance à la responsabilité du « Build » et du « Run » des systèmes de bases de données.

itw-dba

L’Agilité est au cœur du fonctionnement du service. Elle est basée sur l’autonomie et l’initiative des collaborateurs, la transmission des connaissances, la solidarité entre les collaborateurs et le développement d’outils permettant la supervision et l’administration des bases de données.

Justement, pouvez-vous nous décrire les méthodes Agiles qui sont utilisées au sein du service ?

D.B: Nous avons travaillé dans un premier temps sur la partie « RUN » en créant les « Tickets Party », qui permettent de travailler collectivement sur l’analyse et la résolution des incidents de production, ainsi que sur les demandes de changement et d’évolution de nos clients. Le bénéfice a été immédiat, aussi bien au niveau du temps de traitement des tickets, que du partage de l’information : connaissance des clients et de leurs projets, transmission des méthodologies de résolution, montée en compétences sur les systèmes de base de données, convivialité, etc… Fréquence actuelle : 1 fois par semaine, 15 à 30mn maximum.

Pierre angulaire de la méthode, nous avons créé des formations internes sous forme de sessions de 5 jours permettant la montée en compétence des collaborateurs du Support N1 sur les principaux systèmes de bases de données, ainsi que sur les supervisions associées.

En ce qui concerne la partie « BUILD », nous réalisons actuellement 2 StandUp par semaine, de 15mn à 30mn maximum, où chaque DBA fait le point en centrant son discours sur les difficultés rencontrées dans son activité de déploiement. L’équipe propose le cas échéant des solutions, qui peuvent être techniques, mais pas seulement. Une rétrospective est réalisée tous les 15 jours permettant à l’équipe de proposer des améliorations.

En parallèle, chaque DBA fait partie d’une team « projet » dans laquelle il réalise également 2 StandUp par semaine, ainsi qu’une rétrospective tous les 15 jours.

Nous utilisons un outil nommé AGILITY développé par des collaborateurs des équipes déploiement. Il est basé sur un « merge » entre la méthode Kanban et la méthode Scrum. Auparavant nous utilisions l’outil Bubble Tool.

Pouvez-vous nous en dire plus sur ces outils ? Pourquoi les avoir développés ?

D.B: Bubble tool est issue de la nécessité d’avoir un outil. C’était un réel besoin. Il devait être:

–    Disponible à partir de tous les sites de production
–    Intégrer toutes les équipes de déploiement et de production
–    Evolutif et intégré facilement aux autres outils en service à la DSC
–    Ergonomique et simple dans son utilisation pour les collaborateurs
–    Permettre l’usage de Kanban via le découpage des projets en tâches unitaires
–    Capable de visualiser le WIP (« Work In Progress »)
–    Permettre de créer des « template » de tâche afin de créer un référentiel déploiement
–    Indépendant d’un outillage ou d’un fournisseur Externe (Google, Microsoft, etc…)

La nouvelle version de l’outil, nommée AGILITY, permet d’intégrer la méthode Scrum via la mise en place des « sprint » et met en œuvre toutes les meilleures pratiques en termes de développement (Framework PHP, base de données MongoDB intégrée, etc…). Il s’agit donc d’une version pérenne de l’outil Bubble tool. A terme, une version mobile permettra la mise à jour des tâches par les collaborateurs qui ne sont pas sur leur poste de travail (actions dans les data center par exemple). Sera également intégré à l’outil AGILITY les rituels agiles (StandUp, rétro …).

bubble

Quand et comment ont-été introduites les méthodes agiles dans le service ?

D.B: Les premières « Ticket Party » ont été initiées en 2011. L’Agilité pour la partie « Build » a débuté en Q4 2012 avec la grande équipe déploiement.

La « bubble team » a été créé en Q1 2013.

Bubble tool est utilisé depuis Q2 2013 au sein de la « bubble team », et depuis Q4 2013 au sein des autres teams projet.

AGILITY est utilisé en recette depuis Q1 2014, et sera passé en production en Q2 2014.

Pourquoi avoir changé de mode de fonctionnement ? Y-a-t-il eu des réticences au changement ?

D.B: Le mode de fonctionnement précédent, en silo, ne fonctionnait plus efficacement au fur et à mesure de l’augmentation du nombre de projet à déployer.

Le changement de méthode dans un environnement de production reste un challenge. Il y a eu peu de réticences au changement au sein de l’équipe DBA. Les difficultés résident dans l’apprentissage collectif des rituels, apprendre ce qu’il y a à dire d’essentiel, en laissant le superflu de côté, savoir écouter les autres collaborateurs. La méthode est basée sur la confiance dans l’autre et sur la bonne foi de chacun.

L’utilisation de l’outil au quotidien reste un challenge à intégrer dans le rituel Agile.

Comment l’équipe a-t-elle perçu ces nouvelles méthodes ?

D.B: Avec enthousiasme car elles permettent à chacun de gérer son travail en toute autonomie, en étant acteur et responsable de ses actions.

Quelles ont été vos motivations ?

D.B: L’absence de scalabilité de la méthode en silo. L’apprentissage d’une nouvelle méthode dans laquelle le rôle du manager intervient plus en tant que « coach » qu’en tant que « chef ».

Quels étaient les problèmes rencontrés avec la précédente méthode ?

D.B: La complexité de la gestion et de la planification des ressources et la concentration de la responsabilité sur certains postes critiques.

Avez-vous rencontré des difficultés lors de la mise en place de ces méthodes ?

D.B: Des difficultés ont été rencontrées sur la mise en place de la méthode dans la partie « BUILD ». Ces difficultés ont été dues aux facteurs suivant:

–  5 équipes interviennent sur le déploiement d’un projet –  Nombre de projet à déployer (60 en moyenne) et complexité de certains projets à déployer –  Dispersion des collaborateurs sur plusieurs sites géographiques (4 sites) –  Nécessité de planification des projets –  Difficulté de réaliser un découpage optimal des projets en tâches unitaires –  Contraintes Client

Une approche globale a été dans un premier temps mise en place, qui était basée sur un tableau Kanban sur le site de production principal, une grande équipe déploiement regroupant tous les collaborateurs de toutes les équipes et la mise en place de stand up quotidienne. Cette méthode a dû être rapidement abandonnée.

En parallèle, une initiative de regrouper des collaborateurs de plusieurs équipes techniques au sein d’une seule et même « team » dédiée à un nombre limité de projet a été lancée. Cette initiative a été nommée « BUBBLE TEAM ».

Là encore nous avons fait face à de nombreuses difficultés. Faire fonctionner les deux systèmes (grande équipe et bubble team) a souvent été un problème. Les managers de production manquaient de visibilité sur les projets en déploiement dans la bubble. La complexité des projets, liée au nombre important de tâche à réaliser a ajouté une difficulté supplémentaire et il a été nécessaire d’intégrer un fonctionnement sous forme de  » sprint « .

Aujourd’hui, le déploiement a généralisé le mode de fonctionnement en team avec la création de 4 autres équipes projets. La grande équipe déploiement a été supprimé et des standup et rétrospectives alternéés entre team projet et équipe technique ont été mis en place.

Quels bénéfices en tirez-vous aujourd’hui ?

D.B: De la satisfaction d’abord, voir ses collaborateurs s’épanouir dans leur travail, avec l’envie d’apprendre et de transmettre leurs connaissances. Une meilleure efficacité au quotidien, une meilleure cohésion d’équipe.

Et donc au final, l’objectif d’une amélioration de l’expérience client, aussi bien dans la phase de « build » que dans la phase de « run » d’un projet.

La mise en place de la Bubble team a également été très bénéfique. La proximité des collaborateurs a crée un environnement plus simple favorable à l’apprentissage des rituels liés aux méthodes Agiles et de ce fait crée une véritable cohésion d’équipe projet. La réduction du temps de résolution des problèmes de déploiement et le  développement d’un nouvel outil nommé « BUBBLE TOOL » pour la gestion des tâches et des projets.

D’après vous, quels sont les prérequis pour intégrer ses méthodes ?

« Le Succès n’est pas final, l’Echec n’est pas fatal, c’est le courage de continuer qui compte » W.Churchill

La mise en place des méthodes Agiles nécessite un engagement fort de la Direction, aussi bien en énergie potentiel qu’en énergie cinétique. Il s’agit bien ici d’un prérequis indispensable. Elles génèrent des attentes fortes de la part des collaborateurs.

Les méthodes Agiles fonctionnent bien avec un retour sur investissement rapide au sein d’une seule équipe et un nombre limité de collaborateurs (« Quick Win »), elles sont plus complexes à mettre en œuvre lorsqu’il s’agit de faire fonctionner plusieurs équipes avec un nombre important de collaborateurs, d’autant plus s’il y a dispersion sur des sites géographiques différents.

Enfin il s’agit bien d’un processus d’amélioration perpétuel et d’une remise en cause régulière.

*Définitions

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *