Dans l’article précédent nous avons exposé les mantras qu’il faut assimiler pour cheminer vers le devops. En accompagnement, des modèles d’organisation existent pour la mise en œuvre et l’exécution. Ces modèles sont véritablement disruptifs, et sans doute perturbant, par rapport aux modèles anciens. Il n’y a pas d’obligation particulière à les imposer en mode bing-bang pour transformer une structure IT. Néanmoins l’idée de la complémentarité des modèles ne permettra pas de tirer les bénéfices d’une organisation agile, car il faut choisir entre les paradigmes autonomie/équipes dédiées vs command and control/compétences mutualisées. La recommandation sera donc plutôt de procéder par itération mais sur des périmètres ou des produits ou l’autonomie sera complète, from build to grave !
Ci-dessous quelques modèles d’organisation qui permettent de démarrer une réflexion.
Dans le monde SAFe tout d’abord. SAFe propose probablement le chemin le plus en douceur vers le devops. Il faut expliquer quelques concepts clés de SAFe pour comprendre :
- L’organisation SAFe s’articule autour de Trains, qui sont un assemblage d’équipes SCRUM développant des systèmes dans un périmètre fonctionnel cohérent et reliés à une chaine de valeur business spécifique.
- Les équipes qui composent le train ne sont pas des équipes autonomes, c’est le train dans sa globalité qui porte l’autonomie
- Les trains doivent intégrer les principes devops, dont la capacité de livrer des versions complètes à la demande.
- Pour cela ils s’appuient sur une infrastructure as a service.
Cette organisation par train peut s’étendre à la granularité d’une solution, qui représente un ensemble de train synchronisés dans le temps en termes de sprints et de livraison d’incréments.
Pour répondre à ces caractéristiques SAFe introduit une System Team qui propose tous les services d’intégration technique des produits pour toutes les équipes d’un train. La system team peut même être partagée au sein d’une solution entre ses différents trains. Les initiés parlent d’équipes cross-trains ..
La solution a le mérite de permettre aux équipes techniques de production de rester dans leur domaine de compétence. A contrario elle tend a mutualiser cette compétence et nous ramène vers un silotage par expertise, et donc au final par la formation de goulots d’étranglement pour l’ensemble des équipes scrum qui deviennent dépendantes de la system team. Il est donc très important d’associer la system team d’un train à la responsabilité de résultat global.
De son côté le DASA propose une approche plus tranchée mais qui d’un point de vue Agile a beaucoup de sens. Les concepts que le DASA souhaite mettre en avant dans son approche organisationnelle sont en effet un peu différents :
- Les équipes agiles sont compléments autonomes. C’est un principe fort du devops vu par le DASA. Le point de mire est de s’assurer que pour délivrer son objectif, une équipe ne doit être dépendante d’aucun autre service.
- Pour cela elle s’appuie sur une infrastructure as a service qui est explicitement fournie par une platform team dédiée. Cette platform team peut offrir une infrastructure in-house ou des services de niveau 3 vers le cloud.
- Les membres de l’équipe sont facilement interchangeables bien qu’ayant chacun un domaine de prédilection technique (test, ops, dev). C’est ce qu’on appelle le T-shape des compétences.
- L’organisation devops doit être simple. Cela répond au fameux principe qu’une organisation construit les systèmes qui lui ressemblent : une organisation simple construit des systèmes simples et maintenables et à l’inverse une organisation complexe construisent des systèmes complexes (le plus souvent aux allures d’usines à gaz).
L’organisation DASA est donc simplifiée : Chaque équipe (feature team), intègre un ops et un architecte technique (ou les deux en un), qui assument les besoins de l’équipe pour fournir les environnements et assurer le déploiement de l’application. Ils s’appuient sur la platform team pour provisionner les ressources techniques et fournir un niveau 3 de support. Ils transfèrent une partie de leurs compétences vers les autres membres de l’équipe afin de ne pas être le goulot d’étranglement du delivery et participent aussi aux autres activités de l’équipe (dev et test).
Cette solution convient parfaitement à une équipe produit sur une échelle réduite. Par ailleurs elle correspond bien à l’esprit Craftmanship et à l’idée qu’un ingénieur informaticien généraliste se fait de la conception d’un produit. Pour exemple, le modèle “full cycle developer” présenté par NETFLIX se rapproche vraiment de cet esprit.
En revanche il est évident que cela nécessite une profonde remise en question de la gestion des RH pour les grands comptes qui sont habitués aux silos et aux carrières axées sur l’expertise ou le positionnement hiérarchique. Cependant le DASA ne dit pas grand-chose des besoins à l’échelle lorsqu’il y a un fort besoin de synchronisation entre différentes équipes produit.
A bien regarder ces deux propositions d’organisation, on peut imaginer une petite adaptation du côté de SAFe qui viserai à prendre en compte l’idée de l’autonomie complète des équipes. Dans chaque train, plutôt que de créer une équipe ops mutualisée, il serait intéressant d’intégrer dans chaque équipe un ops qui la rende autonome, et qui potentiellement peut prendre en charge des taches de test et pourquoi pas de développement sur des couches basses des applications développées. Nous verrons également ci-dessous que le modèle SPOTIFY propose un rôle intéressant au travers du system owner qui devient une sorte de garant technique et pourrait s’adapter facilement à un train.
Il est donc utile de positionner le modèle proposé par SPOTIFY dans son retour d’expérience, qui date maintenant de quelques années et qui a peut-être évolué. Dans son modèle d’organisation à l’échelle, SPOTIFY reprend comme le DASA l’impératif d’avoir des équipes le plus autonome possible. Cependant son modèle se rapproche plutôt de celui de SAFe.
- En effet si la squad représente la feature team autonome, la Tribe représente plutôt le Train.
- Il y a donc une ops squad dans chaque tribe qui rend un service ops partagé pour l’ensemble des dev squad.
- Les équipes infrastructures sont également dissociées, sorte de tribe à part entière offrant un service d’infrastructure provisionnable à la demande et évoluant en fonction des besoins des ops squads.
- Le modèle Spotify propose également un rôle que nous développerons dans la prochaine partie, à savoir le system owner. La vision de spotify est d’avoir une personne présentée comme le “go to person” pour les besoins techniques et architecture pour un system.
L’idée du périmètre “System” est un peu perturbante car ne correspond à aucune entité dans l’organisation SPOTIFY et cela ramène donc à un rôle très transverse. En revanche cela s’adapterai très bien avec le concept de train dans SAFe qui est généralement accolé à un système complet. Dans le domaine DASA cela correspond bien également à l’idée d’associer un architecte system directement dans l’équipe mais qui aurait des compétences plus larges.