Désapprendre pour mieux réapprendre : Évolution de projet à produit

Par Benjamin Lallement, conseiller DevOps

« À travers les BootCamp DevOps que j’ai animés avec mon collègue Nicolas Duperré, une question revenait sans cesse… en tant que Dev, QA, PM, Ops, comment puis-je changer la culture si ma gestion ne m’aide pas à le faire ? Et la question prend tout son sens dans une transformation DevOps, le gestionnaire fait partie de l’équation, le changement de culture vient des individus mais encore faut-il leurs faire de la place ! »

Dans cet article, nous soulignons l’importance d’une gestion d’ensemble adaptée au DevOps ainsi qu’aux défis qu’elle présente au gestionnaire. Une transformation DevOps d’une organisation opérant en silo fonctionnel représente un défi de taille, à la fois technique et émotif pour les équipes de développement et d’opération. Conséquemment, le rôle du gestionnaire doit aussi se transformer pour devenir un facilitateur plutôt qu’un directeur.

Résumons d’abord le défi des équipiers : non seulement doivent-ils acquérir plusieurs connaissances techniques, changer leurs méthodes et adapter leurs comportements, ils doivent en plus se défaire d’automatismes et d’habitudes acquises et appliquées depuis de nombreuses années. Plus important encore, ils doivent apprendre à être autonomes et pleinement responsables de la livraison de leur travail. Invariablement, cette période est difficile et souvent meublée de détresse psychologique principalement causée par le doute de réussir.

Depuis des temps immémoriaux, le savoir des travailleurs se transmettait par le jumelage d’experts à de jeunes apprentis. Une fois l’expertise acquise, leurs connaissances demeuraient relativement immuables. Bien sûr, de nos jours les moyens d’apprentissage ont énormément évolué, mais en revanche, le rythme des innovations s’est accéléré exponentiellement. Il n’en demeure pas moins que l’apprentissage théorique ne peut transmettre à l’avance tout le savoir que l’expérience apporte. Bref, on a beau suivre une recette de pâté chinois à la lettre, on découvrira immanquablement des petits ajustements à apporter pour la prochaine, et la prochaine…

Chaque initiative de développement impose aux praticiens qu’ils apprennent et comprennent les tenants et aboutissants des exigences du produit en plus de les intégrer aux innovations technologiques en constante évolution. En résumé, si les méthodes d’apprentissage ont évolué, c’est sans aucune mesure avec les exigences de savoir.

Essentiellement, le défi de tous les acteurs équipiers et gestionnaires se résume comme suit :

Apprendre (ou réapprendre) son travail et le faire en même temps est la recette infaillible pour échouer dans les deux cas.

Lao Tseu…

Gestion monarchique 1.0

Project kick-off meeting… le prince de projet présente à tous les membres des silos fonctionnels et parties prenantes d’affaires, un plan détaillé ayant une forte ressemblance à un agenda au jour le jour pour les 6-8 prochains mois (ou plus), souvent incomplets, mais invariablement insufflé d’une forte dose de pensée magique. Survol succinct de l’édit d’architecture globale et de la brique biblique des exigences d’affaires, des rôles et responsabilités de chaque participant (en évitant évidemment de spécifier les prérogatives, exclusivement réservées aux membres de la cour), et présentation des ducs et comtes de silo. Petit pep-talk énergique en conclusion avec un tonitruant « LETS GO » pour fouetter les troupes.

En général, les monarques d’affaires sont satisfaits, sinon impressionnés par le « leadership sonore » du prince, mais trop souvent, il en va autrement pour les équipes de réalisation. En effet, ils sont, pour la plupart, parfaitement au courant que toute cette préparation de plusieurs mois axée sur des livrables, coute très cher et n’ajoute aucune valeur au produit final… si produit il y a.

Ce contexte implique que toutes les décisions considérées importantes concernant les pratiques, méthodes, implémentations, etc. sont prises par l’équipe de gestion, souvent basée sur des considérations n’ayant rien à voir avec le projet (ex : projet doit être complété pour campagne marketing dans 6 mois), d’où la référence monarchique. Le personnel technique est ainsi relégué au rôle d’exécutant ce qui, pour certains désabusés, signifie une libération de leurs responsabilités. Pour la plupart cependant, c’est un signal que leurs connaissances et compétences ne sont que de peu d’intérêt et une puissante source de démotivation. Bien sûr, les gestionnaires nieront ces interprétations, mais peu d’équipiers seront convaincus, car les actions parlent plus fort que les paroles.

Alors, pourquoi durant les 50 dernières années avons-nous recherché les meilleures méthodes de développement et d’opération ainsi que les meilleures techniques de stabilité et de sécurité de nos infrastructures et plateformes tout en laissant sous le tapis la recherche des meilleures approches de leadership, d’organisation du travail et de soutien de ces efforts ??? Encore et toujours cette même recette de pâté chinois… sans sel, sans beurre, sans gout et sans intérêt.

Gestion holacratique 2.0

Il est maintenant grand temps de faire évoluer nos pratiques de leadership et de gestion. Si les futurs praticiens DevOps doivent désapprendre pour réapprendre, il en va de même pour les gestionnaires qui les encadrent. Et cette transformation peut s’avérer encore plus difficile pour eux que pour les équipes de terrain. Voyons voir…

Gestion des équipes

Traditionnellement, les équipes sont découpées en silos de spécialistes fonctionnels soit les développeurs, administrateurs de données, spécialistes de réseau, sécurité, opérateurs, architectes, etc. Les travaux en cours passent d’une main à l’autre, ce qui implique des délais à chaque étape, sans compter les erreurs d’interprétation. En général, ces équipes sont gérées par un gestionnaire qui détermine le flot, les assignations et les méthodes.

La culture DevOps par contre requiert des équipes multifonctionnelles composées de toutes les spécialités nécessaires à la réalisation et l’opération en production des produits qu’elles développent et opèrent. Chaque équipe est capable d’entreprendre et est responsable de compléter les tâches qu’elle choisit selon ses priorités et dépendances. Elle s’en acquittera en utilisant les outils technologiques de leur choix ayant le plein contrôle de leur fonctionnement interne sans quoi, ils rencontreront les mêmes embuches que les méthodes actuelles imposent.

Afin de créer un environnement propice au DevOps, certaines transformations minimales des approches de développement et d’opération sont essentielles :

  1. Le déploiement et la supervision manuelle et réactive des produits dans les divers environnements doivent faire place à des méthodes automatisées et proactives…
  2. Conséquemment, le « gating » d’approbations successives, lentes et inefficaces doit faire place à une validation des artéfacts par tests unitaires, d’intégration, de charge, etc., déclarés avec les exigences et entièrement automatisées.
  3. L’assignation du travail et l’évaluation des délais par le gestionnaire doivent faire place au plein contrôle de l’équipe sur ses travaux en cours.
  4. Le traintrain des exigences d’affaires imprécises et arrivant au compte-goutte par des intermédiaires agissant comme proxy d’affaires doit faire place à l’accès direct des équipes aux utilisateurs afin d’éliminer les ambigüités et obtenir de rapides rétroactions.
  5. Les lunch and learn organisés par la direction doivent faire place au plein contrôle de l’équipe sur ses choix d’expérimentation et d’apprentissage…

La culture DevOps requiert des équipes autonomes et autogérées, chacune ayant une grande latitude dans le choix des moyens, technologies et approches de réalisation. Cela signifie que le gestionnaire doit respecter et surtout faciliter l’application des décisions internes des équipes sous sa responsabilité. Mais alors… il sert à quoi le gestionnaire ??

Gestionnaire 2.0

Bon, bon… j’entends déjà les gestionnaires pousser de haut cris ou pire encore, rire aux éclats. Je les invite cependant à un peu de retenu et poursuivre leur lecture.

Bien que les déclarations précédentes puissent laisser présager la disparition du gestionnaire, la réalité, bien au contraire, est que le gestionnaire devient beaucoup plus important pour les équipes tout en se libérant de ses responsabilités de livraison. N’oublions pas que les équipes sont formées par les individus les plus compétents pour accomplir leurs tâches de création et d’opération et ils n’ont pas vraiment besoin qu’on leur dise comment faire. Si on leur fournit les moyens qu’ils jugent nécessaires, ils seront capables de livrer et d’opérer leurs produits.

Cependant, leur travail de production accapare toutes leurs énergies et leur temps. Conséquemment, ils n’ont aucun intérêt ni prédisposition à assister à des « meetings » d’avancement des travaux de la direction, écrire des rapports et répéter incessamment les mêmes requêtes budgétaires, etc. Tout cela et un peu plus reviennent au gestionnaire dont le rôle passe de décideur/directeur à facilitateur/communicateur.

La première responsabilité du gestionnaire 2.0 consiste principalement à s’assurer en tout temps que l’ensemble des équipes sous sa supervision partagent une compréhension commune de l’ensemble projeté du système global. Dans un monde de microservices et de livraison continue, les équipes sont souvent organisées autour d’importantes composantes fonctionnelles dont les interactions exigent une coordination entre les équipes du développement et des opérations. Conséquemment, le gestionnaire 2.0 doit s’assurer que cette coordination est bien établie entre les équipes, sans intervenir dans le choix de leurs méthodes à moins, bien sûr, qu’ils lui en fassent la demande.

Passer de Gestion 1.0 à Gestion 2.0

Note : La gestion 1.0 fait référence à une gestion de type transactionnelle ie une gestion qui s’aligne entièrement sur le statu quo des méthodes tandis que la gestion 2.0 s’aligne sur une approche évolutive des méthodes et orientée vers l’avenir.

Nous verrons dans de prochains articles en quoi les gestionnaires doivent eux-mêmes prendre en charge l’évolution de leurs méthodes pour les adapter à Gestion 2.0. Cette coordination couvre divers domaines entre autres la sécurité psychologique des praticiens, les mesures de performance, la qualité continue, l’alignement de l’architecture et des pratiques techniques et surtout, l’évolution de la culture. Encore une fois, il ne s’agit pas ici que le gestionnaire prenne les décisions, mais bien qu’il établisse un encadrement général et les liens de communications entre les acteurs concernés.

Allez !!!, un peu de rétroaction de votre part dans la section des commentaires. Êtes-vous prêt à définir l’avenir et relever le défi 2.0 ???

À bientôt donc.

Benjamin Lallement, conseiller DevOps et associé Gologic.

Avec la collaboration de Jacques Ledoux, jcq@ledx.com

Références :

Accelerate : Forsgren, Humble, Kim 2018

Wired to connect: Andreatta 2018

Wired to grow: Andreatta 2015

The DevOps Handbook: Humble, Kim et al 2016

Suivez-nous et partagez

Laisser un commentaire