Compte-rendu du Comptoir Agilité@OPS

Filant la métaphore d’un vol pour mener l’agilité auprès d’équipes OPS (Infra, Prod, Sécu… donc pas les équipes de dev), Claude Camus, executive coach et coach d’organisation et Gilles Masy, coach d’organisation endossent respectivement les rôles de steward agile et steward OPS.

Basé sur leurs retours d’expérience d’une transformation agile dans le secteur OPS d’un grand groupe bancaire, le vol auquel nous invitent Claude et Gilles comporte plusieurs escales :

• la piste de décollage : l’analyse de l’existant
• la destination de rêve : le cap de la transformation
• le décollage : les étapes d’une transformation agile adaptée à ce secteur
• les take-aways

Avant de suivre ce plan de vol, Claude et Gilles nous partagent les remontées terrains de ces équipes OPS : difficultés à prioriser car aux mains des managers, charge de travail conséquente, manque de temps pour “faire correctement” les choses. Par conséquent, beaucoup d’appréhensions sont formulées par les personnes accompagnées avant d’embarquer dans une transformation agile, se rajoutant comme un truc supplémentaire à faire. Nos deux stewards partagent également leur observation selon laquelle l’agilité pour les OPS n’est pas la même que pour les DEV : des dépendances multiples et l’inexistence d’un produit, mais plutôt de multiples activités et demandes.

La piste de décollage est encombrée de multiples projets démarrant et n’atterrissant que peu, une exigence PROD-FIRST afin de maintenir à tout prix le système en conditions opérationnelles, additionné de la nécessité d’intégrer (voir anticiper) les futures évolutions technologiques.

La destination de rêve proposée aux équipiers est de retrouver une certaine maîtrise dans la gestion de leur activité, tout en travaillant sur la qualité à la fois des demandes entrantes et à la fois des livraisons d’équipes. L’agilité dans ces équipes OPS est également utile pour rendre visible leur charge de travail et toutes les activités menées en leur sein. C’est une nécessité pour pouvoir ensuite prioriser les tâches, en prenant en compte à la fois les contraintes techniques et les besoins.

Néanmoins dans ce décollage, transformer une équipe seule expose à des risques avérés de crash. Il est donc primordial :

• d’organiser le flux de demandes
• d’identifier les dépendances entre équipes pour pouvoir en minimiser la portée
• de piloter par la valeur ou par les effets recherchés, comme par exemple avec la roadmap à 3 mois matérialisant les propositions de priorisation des activités du delivery
• last but not least, d’embarquer les managers dans le dispositif, faire pivoter leur façon d’appréhender l’activité réelle des équipes, et éviter qu’ils en demandent toujours plus. MIeux vaut terminer plutôt que démarrer

Pour éviter les perturbations éventuelles pendant le vol, il faut prendre le temps de lever le crayon, se poser les bonnes questions, et émettre quelques hypothèses :

• quel modèle d’agilité est mobilisable et souhaitable ?
• comment personnifier la priorisation ?
  En introduisant un rôle de Product Owner. Ou mieux : un rôle de Service Owner.
• parallèlement comment personnifier la qualité ?
  En introduisant un rôle de Tech Lead
• comment visualiser le périmètre d’activités de l’équipe ?
  A l’aide d’un story mapping et d’un gestion de portefeuilles par département et pour l’ensemble de l’organisation
• comment impliquer et rendre exemplaires l’ensemble de la chaîne managériale et la DRH ?

L’expérimentation permet ensuite de vérifier ces hypothèses et de les adapter le cas échéant.

Une fois tous ces éléments posés, le premier pas adapté au contexte OPS est le plus important. Aussi, il faut considérer l'entièreté de l’activité (Build et Run), et identifier la répartition moyenne de ces activités. Ce qui est réalisé doit être de qualité. C’est à partir de là qu’il est possible d’identifier les problèmes principaux et récurrents de ces équipes :

• trop de demandes
• des plannings intenables

Par conséquent, la première étape est d’apprendre et d’accepter de ralentir pour comprendre quelle est la capacité à faire de l’équipe, amenant naturellement à la seconde étape : le focus se porte sur l’approche “service centric”, ou comment fournir le bon service au bon moment.

Le plan de vol proposé par Claude et Gilles se rythme sur 3 mois :

• Le premier temps du vol se focalise sur une formation généraliste et calibrée (c’est-à-dire prenant en compte les contraintes de production de l’équipe), sur l’accompagnement du manager aux principes du changement, sur l’identification et la préparation de l’équipe aux rôles agiles
• Le second temps se concentre sur l’objectif de comprendre le système dans lequel l’équipe évolue, de réaliser un premier sprint pour commencer à visualiser le travail fait. Et au fur et à mesure, la capacité de l’équipe à prendre en charge du Build se dessine. Cela s’accompagne par l’introduction de rituels agiles pérennes : démonstration aux clients et parties prenantes, rétrospectives pour l’amélioration continue de l’équipe, et initier un pilotage de l’équipe par des indicateurs pertinents.
  Par exemple : l'indicateur de vélocité factualise de sprint en sprint l'écart entre ce qui est engagé en sprint planning et le terminé à la fin de celui-ci. Cet histogramme met en lumière la réalité sans ambiguïté de ce que peut réellement réaliser l'équipe.
• La dernière étape consiste à accompagner l’ensemble de l’équipe dans la prise en main des méthodes agiles pour rendre les équipes autonomes, organiser la gestion de la demande comme 2ème objectif, identifier et commencer à assumer les dépendances avec les autres équipes

A l'atterrissage de ce vol, il est important de procéder à une vérification de son déroulement pour l’apprécier et l’adapter le cas échéant. Pour ce faire, le mieux est :

• d’obtenir les feedbacks des équipiers, afin d’évaluer l’utilité de l’apport
• d’identifier les actions d’amélioration
• de mettre en place un système d’auto-évaluation de la maturité agile, ritualisé dans le temps, afin de soutenir l’effort de transformation dans le temps
• et enfin de recueillir le feedback des utilisateurs et des clients, pour évaluer si l’accompagnement apporte une différence

C’est à l’occasion d’un vol dans le monde bancaire que Claude et Gilles ont pu analyser et tester leur plan. En amont du décollage, ils ont testé l’agilité auprès d’équipes

-pilotes tout en sensibilisant les membres du COMEX eux-mêmes à l’agilité. Sur la piste de décollage, c’est la phase de design de l’équipe agile, des formations à suivre et du dispositif d’accompagnement. Au moment du décollage, le ciel comprenait 150 équipes à accompagner avec 25 équipes pour le 1er incrément, et un modèle d’agilité à l’échelle testée dès le 3ème incrément. Au cours du vol, s’appliquer à soi-même les principes de l’agilité et recueillir les feedbacks d’un échantillon de personnes accompagnées (Managers, PO, clients etc.). C’est nourris de ces retours d’expérience que le plan de vol a été adapté tant pour le contenu des formations, les ateliers du Bootstrap et l’implication (à la hausse) des managers.

Ce qu’il semble indispensable selon nos deux stewards, c’est d’insister sur le terminé (start finishing, stop starting, principe selon lequel, l’important est le travail fini et livré de manière qualitative plutôt que la multitude de demandes démarrées, s’accumulant au fil des années). C’est également de faire pivoter la chaîne managériale pour que celle-ci connaisse et comprenne le sens et les apports des méthodes agiles en introduisant l’importance de la prise en compte des clients et un pilotage utile et chiffré.

Enfin, se baser sur l’impact (effet) qu’aura une demande ce qui implique des renoncements (choix).

Selon moi, les take-aways parlent d’eux-même: aussi, je préfère les partager !