C’est toujours un choc de découvrir à quel point une grosse organisation peut siloter des activités. J’ai récemment été impliqué dans une transformation agile en intervenant exclusivement du côté des opérations. J’ai été surpris que l’on me sollicite pour ce type de mission, plus habitué à l’organisation du développement et à la gestion de produits. Mais je suis toujours plus ou moins intervenu sur la partie opérationnelle, afin de déployer, dimensionner et préparer des infrastructures, mesurer des performances, intervenir sur des incidents ou des bugs de production, évaluer l’entropie d’une application et déterminer les besoins d’évolutions techniques. La réalité est que l’on n’est jamais loin des opérations quand on gère un produit, cela fait partie du job, bien avant même que l’on commence à parler de principes devops !
Mais l’objectif de mon client était justement de transformer son organisation, de casser les silos en place, et j’ai donc profité de cette expérience pour essayer de comprendre comment les pratiques devops pouvaient s’intégrer et devenir le mode de fonctionnement par défaut dans une organisation silotée de longue date.
J’en ai profité pour passer une certification devops afin de m’imprégner à la fois des concepts ayant maturés ces dernières années, et aussi pour comprendre les enjeux des services de production dans les grandes organisations qui sont sur le chemin de l’agilisation. Finalement cette expérience fut riche d’enseignement et m’amène aujourd’hui à ce retour, qui explique entre autres comment l’introduction d’un nouveau rôle, le system owner, nous a aidé à concevoir et matérialiser une direction pérenne vers l’adoption des pratiques devops.
La première partie de ce retour d’expérience reprend le contexte et les écueils rencontrés. Les deuxièmes et troisièmes parties rappelleront le panorama des pratiques devops préconisées par la communauté agile et les organisations types associées, et enfin la dernière partie décrira le dispositif mis en place pour réaliser ce voyage vers le devops.
Cette organisation, comme nombre de grandes organisations, a été biberonnée à l’ITIL . Malgré ce qu’en disent les ardents défenseurs de la méthode, cela introduit naturellement un biais qui tend au silotage. Cela tient pour l’essentiel à trois facteurs :
- ITIL segmente l’activité globale de fourniture d’un service informatique en de multiples services spécialisés (considérant d’ailleurs pour l’essentiel la notion de support au détriment de la valeur apportée).
- Par conséquent, pour faire fonctionner ces différents services entre eux et avec les autres, il faut s’accorder sur des contrats de service qui permettent à chacun de déterminer son périmètre et les moyens qu’il doit mettre en œuvre pour le couvrir.
- Ce qui introduit à son tour une relation de client – fournisseur entre chaque service.
Sur le papier, on comprend que cela répond à un besoin de structuration visant à l’efficacité opérationnelle et l’optimisation des ressources. Mais cela a aussi des conséquences importantes et complètement anti-agiles pour l’organisation :
- Chaque service va tendre à optimiser son fonctionnement sans regarder l’impact sur la valeur produite pour l’utilisateur (ni sur les personnes qui viennent à réduire considérablement leur domaine de compétence tout en amplifiant leur expertise dans un domaine qui tend potentiellement à devenir caduc au fil de l’évolution de l’IT). L’organisation se recentre sur son fonctionnement plutôt que sur le client final.
- Pour fonctionner entre services, il est nécessaire que le demandeur décrive son besoin et le fasse comprendre à l’autre en fournissant une documentation détaillée et en réalisant un transfert de compétence. Le fournisseur devra à son tour qualifier s’il dispose de tous les éléments nécessaires pour comprendre et donc faire. Inévitablement on entre dans une boucle d’échanges et une perte de temps colossale ainsi qu’une perte d’énergie sans fin autour des transferts de compétence.
- Une fois que la demande est envoyée au fournisseur, et quand celui-ci la valide, et bien .. Il n’y a plus qu’à attendre ! Car vous ne savez pas si votre fournisseur dispose réellement de la capacité à faire dans le délai que vous souhaitez et vous allez probablement glisser dans une longue file d’attente.
- Par ailleurs ne vous attendez pas à avoir un peu de compassion de la part de votre collègue, car en fait il ne s’agit plus vraiment de votre collègue mais de votre fournisseur. Ce qui implique une dilution de la responsabilité vis-à-vis du rendu final à l’utilisateur ainsi qu’un jeu malsain de rejet de responsabilité entre services, voir même à l’intérieur des services.
- La posture managériale reflète ces dysfonctionnements et s’oblige à un comportement directif, sanctionnant l’erreur et accentuant le besoin de contrôle et donc une surcharge des effectifs, de la bureaucratie et des outils.
- Et on peut continuer la longue liste de dysfonctionnements liés à ce modèle …
Mais la place de l’IT dans l’entreprise a beaucoup évolué et ce n’est désormais plus un banal service de support. Le numérique est rentré dans la chaîne de valeur ce qui demande aux études de répondre à des exigences toujours plus pressantes et urgentes de la part du métier. La conséquence pour l’organisation est de faire face au fameux mur de la confusion, opposant des opérations attachées à la stabilité et à une barrière d’exigences techniques, face à des études souhaitant maîtriser eux-mêmes le rythme et les conditions des déploiements. Pour autant et face au dilemme, la façon d’aborder le problème n’est pas la même selon les services, et l’on peut dégager trois modèles généraux de fonctionnement :
Modèle 100% V : Il y a d’abord ceux qui affectionnent le cloisonnement habituel et qui fonctionnent généralement en cycle en V. Cela tient soit à l’historique et aux personnes, soit aux projets s’ils sont basés sur des solutions sur l’étagère qui ne s’accordent que difficilement avec la méthode Agile. De façon générale les études sous ce format préfèrent un mode de fonctionnement directif et prédictif. Le niveau d’autonomie, de conseil et d’initiative des opérations est faible ce qui permet d’éviter les discussions. Les opérations aiment anticiper le changement, ce qui la rassure (faussement) sur le risque encouru.
Modèle Agile Ad hoc: Ensuite il y a ceux qui s’agilisent de façon ad hoc, c’est-à-dire en laissant la possibilité au service étude de monter à l’opportunité des équipes agiles autonomes mais qui restent en vase clos, considérant que la production n’est pas réellement dans le périmètre de l’équipe projet. Cela peut répondre à une demande métier ou au souhait d’un chef de projet de changer de méthode. Cette organisation répond bien au besoin d’améliorer le delivery et constitue généralement la première pierre d’une démarche d’agilisation. Mais elle manque l’objectif de l’agilité au sens de l’amélioration du time to market, de l’apprentissage par un retour d’expérience rapide et de l’adaptation au changement lié à la compétition ou aux nouveaux usages.
Modèle Agile à l’échelle : Enfin il y a ceux qui ont réussi à intégrer les équipes, créer des feature teams en mêlant dev, ops et métiers, supprimer le mur de confusion, déployer en continu et à la demande. Mais souvent ce modèle fonctionne en contournant les services traditionnels. C’est le modèle des labs qui poussent un peu partout dans les grosses organisations. Évidemment cela gagne en efficacité et nous arrivons à toucher l’objectif du devops avec un modèle de feature team autonome en responsabilité et en action. Mais cela veut aussi dire que le reste de l’organisation n’apprend pas de ce modèle, qui reste donc une exception. Pire, lorsque le patrimoine applicatif développé par le lab baisse en valeur, il est alors renvoyé vers les services fonctionnels traditionnels qui n’ont alors aucun historique de l’application et bénéficient d’un transfert de connaissance de faible qualité, ce qui finit par dégrader le service rendu.
Pour ce client, ces 3 modèles sont à l’œuvre en même temps ! Dans ces conditions il est évidemment compliqué de répondre efficacement à tous. Le grand écart est permanent et le chef de projet production se perd face à ce que l’on attend de lui. Il devient également difficile de donner les bonnes orientations à des services opérations ballotés en permanence entre la tentation de basculer vers le devops, mais en manquant de vrais expériences positives et marquantes pour le justifier, ou de rester sur un mode traditionnel, plutôt ITIL, demandant aux études de montrer patte blanche pour le moindre correctif à déployer. Évidemment cette dernière option parait suicidaire car elle offre une opportunité objective pour les études de basculer complètement vers le cloud en contournant complètement la direction des opérations.
Mais globalement le constat est plutôt là : il va falloir conserver des chefs de projet et trouver un mode de fonctionnement avec les équipes agiles et les labs. Cela suppose de vivre avec une organisation mutualisant les compétences tout en proposant un mode de fonctionnement qui favorise l’adoption des pratiques devops et puisse à terme muter vers des équipes verticales intégrées par produit, autonomes et polyvalentes.
L’état de l’art agile ne répond que peu à ces configurations hétérogènes qui sont pourtant des situations courantes. Être au milieu du gué n’est pas la situation idéale lorsque l’on cherche des réponses dans des framework méthodologiques, mais il est néanmoins indispensable de comprendre l’objectif et la cible afin de trouver le meilleur moyen d’ arriver sur l’autre rive de la transformation.