Quand l’agilité s’invite à la production (3/5)

Après la genèse d’une équipe OPS (épisode 1) et les premières expérimentations build+run en mode tournant (épisode 2), il est temps d’explorer une variante de cette organisation, toujours inspirée du framework scrum.

Episode 3 : J’ai testé pour vous “L’OPS entre build et run sur un sprint”

Le modèle d’organisation

Petit rappel de l’organisation des OPS testée lors de l’épisode 2: sprint de deux semaines sur du build, et un rôle quotidien tournant. Chaque OPS doit faire du run au moins 1 à 2 jours par semaine, et passer le relai le lendemain de de son jour de run.

Une autre variante de cette organisation s’est imposée, quand le nombre de demandes et de priorités de build a augmenté, que le switch au quotidien n’était plus évident (des ressources qui partaient, des nouveaux qui arrivaient, des consultants qui n’étaient pas à temps plein).

Nous avons opté pour 1 OPS sur le run pendant tout un sprint (2 semaines). Les autres OPS travaillaient sur les tâches de build du backlog produit. Nous partagions les rituels (daily, planning, review et retro) pour être toujours au courant de ce qui se passait, pour débloquer l’opérationnel sur le RUN en cas de besoin. La review de l’équipe consistait à faire la démo des développements effectuées par les OPS sur le build au clients (infra / archi / responsable du pôle/ dev).

Les avantages

Cette organisation permet de rester concentré sur le run, de voir un peu toutes les demandes de différents projets sur une bonne période (nous avons expérimenté des sprints de 2 semaines).

De plus, le fait de faire du run pendant un sprint procure un certain confort dans le traitement des tickets et une polyvalence renforcée dans toute l’équipe. Le constat est le même en ce qui concerne le build. On se projette mieux sur une période plus importante qu’un sprint, on estime mieux la capacité à produire les évolutions sur la période donnée, et on tient mieux ses engagements envers ses clients (les dev). Tout le monde en sort content puisque le run est traité en temps et en heure et par la même personne sur la période donnée, tout en ayant des évolutions du socle qui avancent et qui sont développées en parallèle.

Les prérequis à cela sont un niveau de qualité de service et un respect des SLA malgré le peu de ressources dédiées au run, donc un engagement et une forte implication de la part de l’OPS qui fait le run, des process bien partagés au sein de l’équipe et une rigueur et une autonomie très importantes.

Les limitations

La personne qui traite du ticket et de l’incident durant un sprint, n’en fait pas pendant 3 sprints successifs (6 semaines dans l’expérimentation que nous avons faite), puisque c’est un rôle tournant sur toute l’équipe OPS.

On peut perdre un peu la main et avoir du mal à reprendre le fil des tickets de demande et d’incidents. Le contexte très agile et en mode « startup » ne facilite pas la tâche puisque les changements techniques étaient très fréquents.

En cas de congés, de maladie, de changement de priorités le RUN peut se prolonger pour la personne qui le traite. Même si l’équipe est de bonne volonté, enchaîner des semaines de ticketing n’est pas le métier de rêve pour des profils experts plus habitué à traiter des demandes de niveau 3. Une alternative serait de déléguer certaines demandes standards documentées aux équipes de développement ou à une équipe de support dédiée à ce type de tickets.

Enfin en cas de forte demande, ou de complexité de demandes, cela nécessitait l’intervention de quelques jours d’une deuxième personne en renfort, ce qui pénalisait fatalement le build et réduisait la vélocité de l’équipe et sa capacité à réaliser les user story dans les délais communiqués aux projets. Encore une fois, le côté aléatoire des demandes et incidents rendent la planification et la disponibilité des ressources difficile à anticiper au plus juste.

Un bilan provisoire des trois premiers épisodes (par rapport au contexte client)

La première conclusion va vous étonner, car non évoquée dans ce chapitre : La présence d’un scrum master est indispensable ne serait-ce que pour prendre du recul sur notre façon de nous organiser ou de traiter les demandes (est-ce que c’est du build ou du run ? comment prioriser les demandes ? comment faire du switch de contexte en permanence et avancer quand même sur les réalisations significativement ?).

Nous ne réalisions pas de rétrospectives, nous n’avions pas de backlog au sens propre du terme, mais avec un scrum master tous ces aspects Scrum au prime abord fastidieux et coûteux en temps se sont révélés essentiels.

C’est un vrai facilitateur et un interlocuteur qui a le recul nécessaire pour sortir un OPS de son quotidien de jongleur entre divers sujets.

Avoir quelqu’un d’extérieur à l’équipe de réalisation et qui soit « neutre » apporte de nouvelles idées aux contraintes des OPS, permet de réguler les frustrations entre build et run et aide le PO à canaliser les sollicitations directes.

Ce premier retour d’expérience nous pousse à conseiller fortement dans une organisation de ce type un rôle de scrum master, même à temps partiel et limité dans la durée. Idéalement une personne extérieure à l’équipe (pas le PO, pas un opérationnel et surtout pas le client ou le manager !).

La deuxième conclusion est plus évidente : dédier du temps au build et formaliser ce dernier sous forme d’un ou plusieurs produits, d’incréments, prioriser les tâches sous forme de sprints, ce n’est que du « bonheur » pour une prod orientée satisfaction client !

En effet, le travail en équipe est favorisé, l’autonomie est acquise rapidement, les avancées sont notables, et aucun produit n’est laissé de côté. L’amélioration continue est réellement en place.

Attention à l’idéalisation, ceci suppose au préalable encore une fois avoir une équipe polyvalente, prête à monter en compétence et à proposer des solutions techniques à des problèmes complexes. D’ailleurs, nous avons du rapidement nous séparer d’une personne arrivée dans l’équipe à un moment, car elle ne répondait pas à ces prérequis et restait dans un état d’esprit d’exécutant : j’attends des procédures et je les applique. Faire du build ne nécessite pas forcément des profils très pointus (tout dépend des projets de prod dont on parle bien évidemment), mais un minimum d’envie d’améliorer son quotidien, et celui des autres.

La troisième conclusion est liée au sprint review : le fait de présenter des réalisations de Build au client, c’est bien. Le fait de présenter des réalisations de RUN au client, c’est assez extraordinaire !

Le travail de l’OPS est souvent méconnu, sous-estimé, méprisé (assimilé au clic-bouton ou au simple exécutant qui lit une procédure et la suit sans comprendre les enjeux derrière). En ayant des instances régulières de revue avec les développeurs et les managers, avec une présentation du bilan des tickets traités, des blocages, des demandes récurrentes, du top 3 des tickets coûteux en temps ou en effort, cela a permis de mettre la lumière sur les tâches de production et sur la charge que cela peut représenter, mais surtout sur leur aspect « nécessaire et indispensable » pour les projets.

Par exemple, cela a sensibilisé les projets à prendre des user story techniques pour automatiser et fiabiliser leurs livraisons, ou à rajouter des tests dans leurs chaînes de déploiement.

La dernière conclusion de ce bilan provisoire (et sans doute la plus importante) : toutes ces conclusions ne sont pas atteignables sans une équipe motivée et volontaire. Si l’équipe n’a pas envie de changer, si l’équipe n’a pas envie d’investir du temps pour se former, pour sortir de sa zone de confort, pour se challenger, pour se tromper et recommencer, il est plus sage de ne surtout pas essayer une vraie transformation vers ce modèle. Cela ne servira qu’à créer de la frustration, du rejet de la méthode et de l’abandon des bonnes pratiques. On n’y verra que le côté « réunions » et « perte de temps » et non pas l’apport que cela peut avoir sur le quotidien. Il ne s’agit pas d’une montée en compétence, d’une formation ou d’une prime pour réussir cette transformation, il s’agit ici d’une volonté de sortir du quotidien de l’OPS. C’est une posture qui ne convient pas à tout le monde, et qui demande un temps de mise en place et d’adaptation.


Publié

dans

, , ,

par

Étiquettes :

Blog at WordPress.com.