Depuis des années, la culture DevOps devient un standard et de plus en plus d’entreprises se tournent vers ce modèle Agile. Est-ce que cette méthode est adaptée aux sociétés de services informatiques qui historiquement font de l’infogérance ?
Une fois cette culture adoptée, nous nous rendons compte de certaines dérives notamment au niveau des délais et des coûts. Ce qui sur le papier semble évident ne fonctionne pas forcément comme décrit : souvent utilisé dans le cadre d’un produit, il est parfois difficile de faire adhérer ses équipes et son organisation lorsque l’on délivre du service ou que tous les outils et compétences ne sont pas déjà présents dans la société. Plus encore, ce changement de paradigme peut coûter cher pour construire l’écosystème le plus efficace possible.
La forte accélération du Cloud Public a rendu cette culture encore plus importante : un meilleur “time to market”, les bénéfices du CI/CD et l’infra “on demand” sont aujourd’hui indispensables pour rester concurrentiels, expérimenter rapidement et délivrer plus vite.
Cependant, nous constatons aujourd’hui qu’il existe un choc de cultures entre ITIL et AGILE. Les deux ayant leurs avantages et leurs inconvénients : alors que l’ITIL prône le contrôle du changement et la maitrise des dates, l’AGILE met en avant l’itératif, l’expérimentation et la vitesse d’implémentation.
En adoptant une approche agile dans le cadre de l’infogérance informatique, nous avons identifié des risques et glissements au niveau planning. L’argument : “vous comprenez, cher client, nous ne pouvons finir le projet dans les temps car la user story a glissé dans le sprint suivant” passe difficilement…
Le métier historique de Cloud Temple est l’hébergement en mode Cloud Privé et l’infogérance selon les standards ITIL. Les compétences autour du Cloud Public et du développement logiciel ont depuis fait leur apparition.
Bien entendu, il a fallu transformer notre organisation pour trouver le meilleur équilibre. Nos experts techniques Cloud Public étant des DevOps, ils sont “par essence” agiles.
Vers une organisation hybride
Pour opérer cette transformation d’entreprise et ainsi combiner DevOps et respect des contraintes de nos clients, nous avons comme beaucoup regardé vers le modèle Spotify bien connu. Après analyse de leur organisation au travers des nombreux articles qui existent, nous avons constaté que la grande majorité des éléments étaient utilisables dans notre contexte mais pas sans de profondes adaptations.
Nous souhaitions également rester agiles mais limiter la multiplication des process, réunions et outils. Nous nous sommes donc tournés vers le Modern Agile qui consiste à épurer l’agile “classique” pour se focaliser sur les valeurs de cette méthodologie.
Notre organisation s’articule donc autour de squads, de guildes et d’un unique outil de pilotage projets : Azure Boards.
Les Squads Cloud Temple
Véritables pôles d’expertise, nous avons choisi de regrouper tous nos experts dans des équipes autonomes et fortes qui s’auto-gèrent sur la partie technique. Ainsi, chaque Cloud Provider Public (Azure, AWS, GCP, Alibaba) a une squad dédiée dont les membres progressent ensemble, s’entraident, se challengent, se reviewent et partagent leurs savoirs et expériences au fil des projets.
Les rôles au sein des Squads sont bien définis : architectes, builders, runners. Mais la proximité des personnes et leur regroupement permettent un partage quotidien des informations et du savoir pour que tout le monde progresse. Ainsi, nous avons créé un véritable esprit d’équipe et de solidarité avec un but commun : progresser chaque jour afin d’avoir une qualité de service en constante amélioration.
Bien entendu, la répartition des activités est claire et nous connaissons notre capacité à produire chaque mois. Néanmoins cette proximité permet à des runners et builders de contribuer aux architectures. De la même manière, nos architectes et builders savent qu’ils feront du run par escalade. Le décloisonnement et l’entraide sont devenues des valeurs fondamentales de notre culture.
Les Guildes, la garantie de conformité
Chaque expert fait donc partie d’une Squad qui l’occupe 80% de son temps pour accompagner nos clients sur nos différentes prestations. En parallèle, chacun fait aussi partie de une à deux guildes qui lui prend 20% de son temps.
Ainsi, les experts des différentes squads (Azure, AWS, etc.) se mélangent pour contribuer à la standardisation, la documentation et l’amélioration des éléments techniques structurant qui serviront tous nos clients (monitoring, backup, template, containers, industrialisation, etc.). Ce temps est géré par chacun de façon totalement autonome en fonction des projets clients ; il nous semblait indispensable de garantir la qualité des standards sur les éléments les plus structurants et d’encourager une démarche d’amélioration continue.
Chaque sujet de guilde est implémenté de façon homogène pour chacun de nos clients. Les phases de build sont ainsi simplifiées et optimisées, se nourrissant des standards produits par les guildes. Le run bénéficie également de ces bonnes pratiques car les implémentations sont uniformes d’un projet à l’autre.
Nous fonctionnons par itérations de quatre mois avec un kick-off qui permet d’établir les objectifs de chaque guilde et la valeur que cela apportera à la société. Un backlog est constitué avec des priorités.
Au fil des sprints plannings de chaque squad, chacun sait qu’il devra prendre des User Stories à hauteur de 20% de sa capacité.
Un point de synchronisation a lieu chaque mois pour faire un état des lieux de l’avancement. Une review se fait en fin d’itération devant les équipes afin de partager le travail réalisé qui servira à tous les projets. La connaissance est donc diffusée lors de la présentation en plus de la documentation technique produite.
Bien entendu, les enjeux de nos clients restent prioritaires et la contribution aux guildes peut ne pas avoir lieu en cas de glissement. Elle sera alors compensée lors d’une période plus calme. L’objectif n’est surtout pas de pressuriser les experts sur la partie guilde (ils ont assez de pression sur les projets clients) mais plutôt de contribuer à faire grandir le collectif et nous rendre tous meilleurs.
Quel rôle pour nos chefs de projets ?
Nous avons également une squad de chefs de projets chez Cloud Temple transverse à toute la société. Ils sont les garants des plannings et du pilotage de nos projets.
Au même titre que les squads techniques, ils sont autonomes dans leur organisation mais la proximité stimule une uniformisation des outils, méthodes et supports utilisés pour les différents projets.
Ainsi, quand un chef de projet est assigné à un projet, il s’aligne avec le leader de la squad technique sur les ressources disponibles et planifie le travail selon les jalons dont il est le garant auprès du client. Nous garantissons ainsi une planification en avance de phase, les sprints étant remplis selon les enjeux du client et moins au fil de l’eau comme dans du Scrum classique.
Bien entendu, hormis si le client a des dates buttoirs dans son planning, les experts techniques restent libres de l’organisation de leur travail tant qu’ils respectent le périmètre du sprint et la planification du projet. Ils conservent cette autonomie agile mais avec un certain cadre, garantissant le respect des enjeux clients. Nous n’avons donc pas de Scrum Master dans nos équipes car les chefs de projet remplissent les sprints en fonction de la capacité, assurant ainsi la faisabilité des opérations.
Azure Boards est notre outil de pilotage de projets. Les User Stories y sont planifiées dès la signature des projets, les dates clés signalées dès le départ et nous avons ainsi une visibilité sur plusieurs semaines pour chaque ressource. Avec la contribution des équipes et quelques tableaux de bord, nous regroupons dans l’outil notre Compte Rendu d’Activité (CRA) et avons une vue claire sur nos projections et notre capacité. Ceci permet de limiter le nombre d’outils et d’avoir un référentiel commun.
Une formule qui fonctionne !
Alors oui, nous avons “tordu” le manifeste agile et le modèle Spotify pour n’en garder que ce que nous voulions. Nous avons fait le choix de nous recentrer sur des valeurs dans lesquelles nos collaborateurs et nos clients se retrouvent, au lieu de copier/coller un schéma pré-établi. Cela nous a permis de développer notre savoir-faire et de mettre en place une organisation efficace.
Nous sommes aujourd’hui convaincus que le modèle que nous avons élaboré pour notre société concilie notre activité avec la culture de nos collaborateurs tout en apportant de la valeur à nos clients. Nos nombreux projets Cloud Public nous permettent tous les jours d’éprouver cette organisation et d’accompagner nos clients dans leurs projets de transformation.
