DevOps – Où s’arrête la responsabilité d’une feature team ?

Une équipe agile doit être autonome et responsable de bout en bout, voilà le casse-tête qu’il faut se préparer à résoudre quand on se lance dans une organisation en Feature Teams. Autonome ne veut pas dire libre ! Quand on oublie le monde des start-ups et qu’on cherche à appliquer ce modèle organisationnel dans une grande entreprise, la confrontation à la réalité est dure. Afin de rendre ce modèle possible, il faut construire des équipes au service des Feature Teams : bienvenue dans une organisation « as-a-service ».

Une équipe capable de livrer un incrément de valeur

Nous parlons régulièrement de Feature Teams sur le blog de Xebia. Prenons la définition du framework agile LeSS qui définit une Feature Team avec les caractéristiques suivantes :

• elle a un backlog orienté fonctionnalité
• elle est cross fonctionnelle et cross composant
• elle est stable et durable
• elle est capable de livrer un incrément de valeur.

Ces caractéristiques vont donner de l’autonomie à l’équipe, moins il y a de dépendances, plus l’équipe sera en mesure de limiter les temps morts et les blocages. La complexité des plannings sera réduite par la même occasion.

Les responsabilités d’une Feature Team

Quand on parle de responsabilités, ça commence à se compliquer. Il vous est peut-être arrivé d’entendre un ops dire après un week-end d’astreinte :  » c’est pas le dev qui va se lever la nuit quand un serveur tombe ! « . Dans une organisation en Feature Team, il faut assumer le revers de la médaille : pour aller plus vite, il faut endosser plus de responsabilités. Si je veux choisir une stack technique plus spécifique ou un OS différent des standards de l’entreprise, je ne peux pas attendre de support d’une équipe tierce : il faudra l’assumer soi-même. Réduire ses dépendances est alléchant mais il faudra accepter les inconvénients de cette stratégie.

Les Platform Teams, une nouvelle organisation des « ops »

Pour que les Feature Teams ne deviennent pas des usines à produire des fonctionnalités impossibles à maintenir, il faut les aider. L’importance des fournisseurs « as-a-service » dans le modèle d’organisation en Feature Teams est fondamentale. Pour aller vite, une Feature Team cherchera sans doute à prendre le service le plus simple pour pouvoir le rendre spécifique à son besoin. C’est le IaaS (Infrastructure as a Service) : « un serveur et les clés du camion ».

Certains fournisseurs vont plus loin et proposent des services plus évolués avec une garantie de maintien en service : le PaaS (Platform as a Service). Ils se peut que les Feature Teams soient heureuses d’utiliser ce service. Attention ! Ce service devra être construit en collaboration pour favoriser l’expérience utilisateur des membres de la Feature Team. Sans ce pré-requis les Feature Teams se tourneront vers le IaaS. Oublier ses utilisateurs en interne a les mêmes répercutions que de ne pas écouter ses clients : ils s’éloignent. Il faudra alors obliger l’utilisation des services PaaS pour des raisons stratégiques ou sécuritaires… Mauvaise idée !

Dernière possibilité, le SaaS (Software as a Service). Une solution dans laquelle les Feature Teams utiliseront un logiciel clé en main, avec les garanties et bien sûr les contraintes. Les Platform Teams pourront soit développer et proposer la solution logicielle, soit acquérir une solution et la proposer. Dans tous les cas, il s’agit de solutions en libre-service mises à disposition sur une plateforme.

Appelons ces équipes des Platform Teams. À l’instar des Feature Teams, ces équipes sont cross fonctionnelles, cross composant, stable et durable. Elles fonctionnent de manière agile et travaillent avec un product owner. Si vous êtes familier du modèle spotify, elles portent le nom d’infrastructures squads et elle ont le rôle de « enable and support » (permettre et supporter). Ces équipes ops « as-a-service » sont des pièces importantes d’une organisation qui se veut devops.

Définir une limite de responsabilité

Afin que les Feature Teams et les Platform Teams puissent travailler ensemble sans se marcher dessus, il faut définir la limite de responsabilité de chacune. C’est le point de découplage. Les Platform Teams doivent livrer sur une plateforme self-service. Ce produit “as-a-service” requiert de la maintenance, de l’innovation et des responsables. Ce modèle permet aux Feature Teams de développer des produits dont elles vont pouvoir garder la responsabilité du cycle de vie en entier. Elles bénéficieront de services avec un support, d’une stack technique et de configurations validées par l’entreprise. Par exemple des distributions d’OS validées, des serveurs avec les patchs de sécurité à jour.

Quelles Platform Teams pour mon organisation ?

Derrière chaque service qui fonctionne avec un système de ticket, il y a sans doute la possibilité de créer une ou plusieurs Platform Teams. Cela implique des changements. Le premier est de passer d’une activité de run à une activité de mise à disposition de service. Ceci se fait concrètement par la production d’API’s qui seront mises à disposition des Feature teams. Par exemple, des DBA’s qui proposent une API de refresh des bases de données ou des administrateurs systèmes qui proposent une API pour redémarrer des serveurs automatiquement. A chaque action automatisée et « APIsée », le temps gagné devra être réinvesti dans la transformation en équipe « as-a-service ». Chaque service de ce type mis à disposition permettra aux Platform Teams de se libérer du temps. Temps qu’il faudra mettre à profit pour étudier les besoins des Feature Teams et proposer des services à forte valeur ajoutée, comme n’importe quelle équipe agile. Peu a peu les Platform Teams apprendront à comprendre leurs utilisateurs pour gagner le badge « build the right thing » en plus de « build the thing right » dans le challenge du continuous delivery.

A la recherche du point D

C’est maintenant le moment de faire une introspection sur votre système d’information. Il n’y a évidemment pas de réponse universelle dans le choix de votre ou vos point(s) de découplage. Par culture, de nombreuses organisations sont très prescriptives et vont vouloir tout encadrer (PaaS voir SaaS) mais est-ce bénéfique dans un contexte agile où les équipes gagnent en autonomie et en responsabilité ? Est-ce que l’énergie, et donc le budget, investis en valent vraiment la peine? Dans ce cas, un point de découplage IaaS donnera sans doute la possibilité de commencer dès demain. Autre exemple, si le service n’est pas critique ou différenciant pour votre métier, le SaaS sera sans doute une alternative intéressante. Développer son outil de post-it virtuel ou son pipeline de déploiement est rarement une stratégie gagnante. Il vous reste donc à vous lancer dans votre transformation en Feature Team avec la définition des responsabilités à l’esprit.