Changer notre mentalité d’ingénieur pour redevenir des constructeurs

Je travaille chez Buffer depuis 2014, et même avant mon arrivée, j’ai toujours été impressionné par la culture produit et d’ingénierie de l’équipe Buffer : la rapidité avec laquelle ils ont apporté des améliorations et la proximité de chacun avec les utilisateurs (il n’est pas rare de voir des ingénieurs répondre à commentaires sur Twitter !).

J’ai trouvé cette attitude « can-do » inspirante et contagieuse, et c’est incroyable quand les choses cliquent de cette façon. Bien sûr, à mon arrivée, nous étions une équipe de 24 personnes ; nous avons tous porté plusieurs chapeaux et n’avait pas de gérants.

Au fur et à mesure de notre croissance, nous avons commencé à adopter la création de structures d’équipe et de processus pour mieux nous soutenir et gérer cette croissance. Mais bien sûr, faire évoluer la collaboration tout en maintenant la vitesse est un art en soi, et des points de friction ont commencé à apparaître : les projets se heurtaient plus souvent à des goulots d’étranglement et les équipes se bloquaient les unes les autres. Puisqu’il faudrait plus de temps pour publier des fonctionnalités, nous essayions de les faire « correctement » en passant plus de temps à rédiger les spécifications de ce que nous essayions de construire, mais bien sûr, plus les projets étaient volumineux, plus il fallait de temps pour les livrer.

Nous étions coincés dans une boucle auto-amplifiée : s’il fallait des mois pour construire quelque chose, cela rendait extrêmement difficile le suivi rapide et l’itération car nous aurions également d’autres priorités à respecter ! Cela n’a fait que renforcer le besoin de faire plus et mieux et a continué à créer plus de pression pour « bien faire les choses ».

L’année dernière, nous avons réalisé que nous voulions changer certaines habitudes et dynamiques chez Buffer pour revenir fréquemment à ces premiers jours d’expédition : plus nous expédions régulièrement, plus il est facile de gérer ces changements (car ils sont plus petits). C’est plus sûr même si ce que nous expédions tombe en panne, ce qui crée une plus grande sécurité psychologique pour notre équipe. C’était clair : nous voulions redevenir des bâtisseurs et adopter notre esprit d’entreprise et notre culture de l’inaction.

Les métriques qui nous aident à définir le mode constructeur

Comment saurons-nous que nous sommes en mode constructeur ? Que nous agissons plus rapidement, expédions plus souvent et resserrons nos boucles de rétroaction avec nos clients ? Certaines mesures sont utiles pour nous guider dans ce voyage : temps d’un cycle, débit de demande d’extractionet taux de défaut. Voici un aperçu de la signification de ces statistiques et de la manière dont nous les mesurons :

Temps d’un cycle
Puisque nous voulons réduire notre délai de mise sur le marché, nous voulons mesurer à quelle vitesse et à quelle fréquence nous apportons de la valeur à nos utilisateurs. Le temps de cycle est, pour nous, le temps entre le moment où nous commençons à travailler sur une fonctionnalité ou une amélioration (le premier changement que nous effectuons dans la base de code pour cela) et le moment où un Demande d’extraction avec les modifications est fusionné et mis en production.

Débit de demande d’extraction
Les demandes d’extraction sont les artefacts que nous générons en tant que développeurs pour commencer le processus de fusion des nouvelles modifications de code avec le code actuel qui s’exécute en production.

Nous pouvons considérer chaque demande d’extraction comme une unité de travail qui apporte de la valeur (par exemple, une nouvelle fonctionnalité, une correction de bogue ou toute autre amélioration de la base de code). C’est pourquoi le nombre total de demandes d’extraction fusionnées (et déployées en production) peut être un indicateur de la valeur fournie.

Taux de défaut
Bien sûr, aller plus vite n’améliore rien si cela signifie que nous expédions plus de défauts et de bugs à nos clients !

Le taux de défauts agit comme une mesure de contrôle pour nous, où nous mesurons combien de modifications de code que nous effectuons corrigent des bogues qui ont été introduits lors de modifications antérieures.

La dynamique que nous avons mise en place pour conduire ce changement de mentalité d’ingénierie

Tout comme les habitudes sont essentielles pour façonner notre identité en tant qu’individus, elles sont fondamentales pour faire évoluer notre état d’esprit et notre culture d’entreprise.

Sachant ce que nous voulions atteindre et comment le mesurer, nous avons commencé à réfléchir à de nouvelles dynamiques qui, au fur et à mesure que nous les adoptons, nous aident à construire notre identité de bâtisseurs. De plus, nous avons gardé les yeux ouverts sur les habitudes existantes qui nous gênaient et nous empêchaient d’atteindre ce niveau supérieur.

Journées d’ingénierie client
Un élément crucial pour tout constructeur est d’être en contact avec ses clients : interagir directement avec nos clients est essentiel pour mieux comprendre les questions qu’ils posent, les besoins qu’ils ont et les points faibles qui se font sentir dans nos systèmes.

Avec les journées d’ingénierie des clients, chaque équipe d’ingénierie affecte un ingénieur à chaque cycle en association avec un avocat pour une journée qui répond aux tickets dans la boîte de réception et fixe ensemble des gains rapides. C’est une excellente occasion pour les ingénieurs de poser des questions à nos défenseurs des clients sur nos clients, nos fonctionnalités et nos produits, et pour les défenseurs de partager leurs expériences et de fournir d’excellentes informations sur nos clients !

Supprimer autant que possible les Pull Requests bloquantes
Alors que nous adoptons une culture d’accélération, l’une des premières choses qui a attiré mon attention a été le processus de révision pour intégrer les modifications dans la production : certaines équipes auraient une règle appliquée qui obligeait un autre développeur à réviser leur code avant de mettre une modification en ligne. Les benchmarks et les recherches de l’industrie ont montré des résultats surprenants : les processus d’approbation des modifications de code ne sont pas corrélés avec les performances de livraison des logiciels.

Nous voulons supprimer le contrôle d’accès pour les modifications, promouvoir la propriété et permettre aux gens de rester dans un état de flux, de sorte que les équipes ont commencé à s’éloigner de la valeur par défaut pour ouvrir les demandes d’extraction et attendre l’approbation, et utiliser une méthode hybride nommée « Expédier/Montrer/Demander »:

• Bateau veut juste dire ça ! Inutile de demander une révision, faites simplement le changement et déployez-le en production.
• Spectacle est idéal pour obtenir des commentaires asynchrones ou partager de nouveaux modèles et apprentissages avec l’équipe, mais sans attendre d’obtenir l’approbation avant de l’expédier en production.
• Interroger est l’approche traditionnelle dans laquelle vous avez besoin d’une révision du code avant la fusion et l’expédition en production.

Être clair qu’il existe des alternatives et des approches différentes pour différentes situations signifie que les équipes peuvent déterminer quel équilibre trouver et voir si elles sont trop en « mode demande » alors qu’elles pourraient pousser davantage vers « expédier » ou « montrer ».

Travailler plus petit
Bien sûr, si nous nous concentrions uniquement sur les pratiques précédentes, nous aurions l’impression de demander simplement aux équipes de travailler plus et plus rapidement. Ces objectifs et pratiques sont pour nous de remettre en question et d’améliorer notre façon de travailler, et non pas combien nous travaillons !

Un élément clé pour garantir cela, et un contributeur majeur pour devenir une équipe plus performante, est travailler plus petit: si nous décomposons notre travail en fonctionnalités qui permettent un développement rapide au lieu de projets plus gros et plus complexes qui sortent rarement.

Pour cela, les équipes d’ingénierie adoptent l’utilisation de bascules de fonctionnalités (également appelées bascule de fonctionnalité) comme moyen de déployer en production de nouvelles fonctionnalités encore en cours de développement sans impact négatif sur l’expérience utilisateur. Cela élimine les grosses versions qui contiennent de nombreux changements, et à la place, nous pouvons publier de nouvelles fonctionnalités pour nos utilisateurs lorsque nous les avons déjà expérimentées en production.

Travailler en plus petits lots génère une plus grande sécurité psychologique pour nos ingénieurs, puisque le risque de déployer des changements cassants qui impactent tout le monde est fortement réduit.

Changement de rôle des responsables de l’ingénierie pour devenir aussi des constructeurs
Bien que le rôle du directeur de l’ingénierie dans les différentes équipes se soit principalement concentré sur la gestion des personnes, la croissance de carrière des ingénieurs et la coordination des méthodes de travail, leur principale responsabilité est de s’assurer que nos équipes offrent de la valeur en construisant notre produit et nos équipes d’une manière qui correspond à la fois à nos objectifs produits et techniques.

Donc, pour vraiment diriger avec cet état d’esprit de constructeurs, nos responsables de l’ingénierie doivent également devenir des constructeurs ! Nous avons redéfini le rôle du directeur de l’ingénierie et nous visons maintenant qu’il passe au moins 25 % de son temps à travailler au sein de l’équipe. Cette « pratique » peut prendre plusieurs formes, telles que :

• Plongée dans l’analyse des données pour le lancement d’une nouvelle fonctionnalité.
• Travailler sur des tâches non critiques.
• QA’ing de nouvelles fonctionnalités.
• S’engager avec les clients.

Cela leur donne un meilleur contexte et un meilleur aperçu des décisions techniques et des compromis auxquels leurs équipes sont confrontées et crée un sentiment d’appartenance partagé au sein de l’équipe dans la mesure où nous contribuons tous à notre manière à publier plus souvent.

Les résultats : Avons-nous adopté l’état d’esprit constructeur ?

Nous avons commencé ce voyage de changement d’état d’esprit il y a 9 mois et cela a été un chemin incroyable d’alignement entre les équipes : le nombre de fonctionnalités et d’améliorations que nous avons livrées au cours des derniers mois est le reflet de tous ces changements. Nous continuons à nous demander « comment pouvons-nous expédier la prochaine chose plus tôt et avec une meilleure qualité ? ». Nous se sentir il y a un changement de motivation et d’énergie.
Maintenant, si nous revenons aux mesures que j’ai partagées plus tôt dans ce post, nous pouvons voir que :

• Le temps de cycle a considérablement diminué : de 94,8 heures en moyenne en 2021 à 55 heures en 2022 jusqu’à présent.
• Le débit des relations publiques a augmenté : 4 155 requêtes d’extraction déployées en 2021 contre 3 687 déployées en 2022 jusqu’à présent (1 816 requêtes d’extraction de plus qu’au second semestre 2021 !).
• Le taux de défauts a diminué : de 18 % du temps consacré à la correction des défauts en 2021 à 16 % en 2022 jusqu’à présent.

Cela signifie que l’équipe d’ingénierie publie en effet plus rapidement et plus souvent et que la qualité n’est pas en contradiction avec la rapidité de livraison.

Il y a d’excellents projets techniques en cours qui accéléreront l’ensemble de l’équipe d’ingénierie au cours de la seconde moitié de l’année, alors nous ne faisons que commencer ! Y a-t-il des habitudes que votre équipe a prises qui l’ont aidé à augmenter son rythme d’expédition et à se rapprocher de vos clients ? Alors que nous continuons sur cette voie pour devenir des bâtisseurs, je suis ravi de continuer à partager nos apprentissages et nos progrès en cours de route.

N’hésitez pas à me contacter sur Twitter à @msanromanv pour partager vos expériences !