Pour ce dernier épisode de la saga de l’organisation Agile à la prod, nous allons nous pencher sur une des expériences les plus abouties en termes de transformation et qui se base sur un contexte avec des contraintes très fortes en production.

J’ai testé pour vous “L’OPS 100% dédié au Build : entre rêve et réalité”

Le modèle d’organisation

Enioka ITTS a effectué une étude du processus d’intégration applicative chez un de ses clients.

La production est constituée de plusieurs équipes, dont une équipe d’exploitation (niveau 2 ITIL). Les exploitants subissaient les délais des projets, découvraient les applications en environnements de recette quand il était déjà trop tard pour intervenir sur les choix d’architecture, l’implémentation des normes et standards de la production, ou sur la mise en place de l’outillage nécessaire à la bonne exploitabilité de l’application en production.

Notre rôle a été de proposer une démarche d’amélioration de ce processus d’intégration des applications en production, en constituant et accompagnant une équipe d’intégration applicative dédiée à cet effet.

Certains projets de développement ont été formés au Framework Scrum et l’utilisaient, par conséquent, nous avons proposé à la DSI d’en profiter et de le déployer dans cette nouvelle équipe.

En plus de porter le plan d’action de la démarche et de le suivre au quotidien, nous avons joué le rôle de Scrum Master de l’équipe, en plus d’un rôle de formation du nouveau Product Owner dans la priorisation du backlog, la collecte de besoin et la rédaction des user story.

Les avantages

Avoir des OPS dédiés au build, qui n’en a pas rêvé dans sa DSI !

Construire des socles automatisés avec Ansible ou Terraform, déployer via des pipelines tous propres avec des outils comme Jenkins ou Azure DevOps, concevoir avec les projets avec les équipes architectures, accompagner efficacement les équipes de développement en dédiant le temps nécessaire. Tout cela a été possible grâce à « peu » de ressources polyvalentes, un fort engagement de l’équipe et une volonté d’évoluer et devenir un acteur majeur de la mise en place de l’application et de son déploiement. Un des prérequis pour avoir des OPS qui se chargent du build est la compétence et l’appétence technique, ou du moins la volonté de progresser et d’apprendre de nouvelles technologies, langages de scripting et outils.

Au-delà des avantages du scrum sur l’accélération du rythme des livraisons, la collecte de feedbacks et l’adaptation rapide aux retours client qu’offrent ce mode de réalisation itératif, ou encore une meilleure priorisation et déblocage quotidien des membres de l’équipe sur leurs tâches, un gain en maturité sur l’organisation de travaux de manière générale a été observé. Même s’il n’y avait pas que des tâches techniques à réaliser dans les faits, l’équipe a adopté des réflexes de priorisation, de traçage dans un outil les demandes à traiter plus tard, de présentation à une fréquence régulière.
Nous avons même réussi à insuffler à nouveau une dynamique de partage technique au sein de la DSI à travers de la communication et de la vulgarisation de certains concepts de production.

L’agilité apporte une réelle satisfaction et une gratification du métier de l’OPS. Quand un ops peut faire du build comme il le faut, il ne peut que faciliter le run et l’améliorer efficacement, limitant les tâches redondantes et à faible valeur ajoutée. Et cela est perçu directement par les dév qui voient le temps passé sur les échanges, les déploiements, ou le support en cas d’incident réduit. Le contact rapproché avec les parties prenantes amené par l’agilité et le scrum redonne du sens aux travaux des OPS puisqu’ils sont régulièrement en contact avec leur client premier, le dev, qui se sent lui aussi mieux compris et entendu par l’ops. Les deux arrivent à trouver le bon canal de communication et cette proximité tant espérée. Les deux mondes arrivent à comprendre les enjeux des uns et des autres, les contraintes et les besoins aussi, les délais surtout.

Les limitations

Néanmoins, nous avons observé 3 problèmes majeurs. Le premier est bien connu de toute production : les sollicitations en tout genre. C’est fatalement ce qui a le plus ralenti l’équipe et qui déstabilise l’avancement des travaux. L’enjeu est donc de savoir les canaliser dans ce modèle organisationnel. Comment ? sanctuariser le temps d’ateliers, de travaux d’équipe sur une demi-journée ou une journée par semaine ou par sprint. Pendant la crise du covid et du confinement, nous avions instauré des sessions « OPS » à hauteur de deux demi-journées par semaine durant lesquelles nous nous connections sur une visio, et nous exposions les sujets du moment. Parfois c’était uniquement pour pouvoir se concentrer sur ses tâches, sans forcément échanger avec les autres OPS connectés à la visio. Mais le fait d’avoir ce créneau bloqué dans les agendas des OPS les aidaient à refuser les sollicitations et à les temporiser.

Le deuxième problème est le changement de priorité en cours de sprint, et malgré toute l’anticipation que l’on instaure, des demandes arrivent toujours en retard et parfois non prévisibles (priorité business qui change, un loupé dans une application qui change d’architecture sans prévenir, etc). Pour ne pas démotiver les équipes dev et de prod, nous maintenions le principe d’inscrire et tracer la user story dans le sprint backlog après un challenge systématique de sa priorité.

Le troisième problème constaté est que le rôle de PO ne s’improvise pas de manière générale et encore moins pour des profils « geek » ou techniques. Entre le côté très transverse de ce rôle dans une équipe en frontal de tous les projets de développement, la nécessité de prioriser et de mettre énormément de rigueur dans la rédaction, l’explication et la validation des user story, et enfin la nécessité de « vendre » son produit, en faire la promotion, communiquer les avancées et autre besoin de présentation, le PO est vite submergé s’il n’est pas encadré et épaulé convenablement. Il est indispensable de faire attention à cette adaptation à des rôles Scrum, de bien les expliquer et de bien accompagner la transformation de la production sur la méthodologie. Pour pallier ce problème, nous avions instauré un point PO/Scrum deux fois par semaine pour aider ce dernier à rédiger les user story et surtout à répondre à ses interrogations sur la méthodologie et l’application de cette dernière.

Que retenir de cette série d’articles ?

Que retenir de cette série de retour l’expérience des démarches Agile à la prod ?

Que l’agilité à la production n’est pas un fantasme, c’est tout à fait réalisable et même très vertueux pour elle. Elle apporte une réelle transformation dans la posture, du simple exécutant ou interlocuteur en bout de chaîne à acteur force de proposition et apporteur de solutions techniques adaptées aux besoins de ses clients. Elle responsabilise le métier d’exploitation aussi, à travers une philosophie d’engagement, d’autonomie, de communication directe.

Que l’agilité à la production ne peut fonctionner sans une adhésion des membres à ce changement (quelle surprise). Le temps d’adaptation peut varier en fonction de l’état de la prod, en fonction des compétences des personnes impliquées dans ce changement, en fonction de l’accompagnement que l’on propose. Le management doit être présent durant cette phase.

Que l’agilité à la production ne peut fonctionner sans une certaine autonomie et un sens des responsabilités des membres sur la réalisation. Tous les OPS ne pourront pas faire de l’agilité, il faut en être conscient. Certains mériteront plus d’accompagnement, plus d’adaptation de la méthodologie que d’autres.

Que faire si je veux mettre en place de l’Agile à ma prod ?

Démarrez pour une durée définie par Scrum pour donner un cadre, puis dans un second temps réalisez une transition vers une approche Kanban. Faîtes cohabiter vos travaux de build en conservant une approche ticketing classique d’exploitation .

Qualifiez les demandes. Si c’est de la demande standard, maîtrisée, documentée, partagée, le ticketing reste de rigueur. Si c’est une demande nouvelle, complexe, nécessitant planification, coordination, Scripting, tests : basculer la demande sous forme d’élément de travail dans un backlog tenu par un Product Owner, et informer son client de l’engagement de réalisation

Privilégiez des sprints courts : 1 à 2 semaines maximum. Étaler les réalisations sur le temps n’encourage pas les membres de l’équipe OPS à découper les tâches, et à produire des éléments concrets et à valeur ajoutée pour le client. On a tendance à retomber dans le mode « tunnel » où on essaie de mettre en place toute la solution technique de bout en bout, et à oublier le premier intérêt de cette démarche Agile : avoir des retours souvent, adapter ses réalisations.

Alors même si le build des OPS est difficilement divisible essayez de lister des tâches simples et réalisables en peu de temps. Faites avancer 2 ou 3 sujets en même temps, et non 10 à la fois. Pensez à l’impact d’un avancement significatif sur une équipe, à l’adhésion à une transformation et à la motivation et l’engagement des membres.

Estimez l’effort des user story, jouez à fond le jeu du scrum pour instaurer le maximum de « bonnes pratiques » Agile Scrum avant de basculer sur un mode Kanban qui tiendra la route.

L’activité quotidienne de traitement de tickets doit tourner entre les membres, sans pénaliser les clients, pour cela nous préconisons d’opter pour le modèle 1 jour x ops en run si la connaissance est bien partagée, les procédures documentées, si tout le monde est à l’aise sur le run ou sur le build et si les demandes ne nécessitent pas plusieurs jours de traitement. En revanche, nous suggérons le modèle 1 sprint x ops en run si l’équipe n’est pas assez à l’aise sur les activités build et run, le build est chargé et demande une attention particulière et le run est complexe, les process et les outils ne sont pas encore au point.

Impliquez les projets dans le backlog en leur proposant de participer aux rituels de planning ou de review. Présentez régulièrement à l’ensemble de la DSI les avancées via des release reviews tous les 2/3 mois, et incluez-les dans une séance de priorisation de la release suivante avec un « Must Have / Should Have / Would Have / Won’t Have this Time » pour impliquer davantage les projets. Une autre façon de les impliquer est de partager les backlogs, de proposer des « features » communes, de garder le lien via des points hebdo de suivi des travaux entre les devs et les OPS par projet.

Enfin, une fois la méthode acquise, les réflexes en place, la priorisation plus « simple » pour le PO des OPS, décidez si oui ou non vous souhaitez changer de modèle vers du pur Kanban mais avec un suivi des priorisations et des tâches par un rôle type scrum master a minima et à temps partiel.