Journey to Agile : comment Braze a réinventé son processus de gestion de projet logiciel

Faire un plan

Après réflexion, nous avons décidé d'évoluer vers une méthodologie éprouvée pour les équipes d'ingénierie - nous avons décidé que nous voulions devenir plus agiles.

Pour aborder ce nouveau défi, nous voulions constituer un groupe qui représenterait et tirerait parti des connaissances de l'ensemble de notre organisation de produits et d'ingénierie. Nous avons donc créé un comité de huit membres représentant la gestion des produits, la conception et l'ingénierie. Nous avons inclus à la fois des managers et des contributeurs individuels, ainsi que des personnes ayant différents niveaux d'expérience, d'ancienneté et d'expérience Agile.

Ce comité Agile, comme nous l'avons surnommé, a abordé la situation avec quelques principes clés fermement à l'esprit :

• Nous voulions utiliser des solutions éprouvées dans la mesure du possible, à la fois dans les méthodologies et les logiciels. Il faut beaucoup d'efforts pour être unique et nous voulions être uniques uniquement dans les domaines nécessaires et stratégiques. Nous voulions également que les gens puissent consulter les meilleures pratiques de Google en matière de gestion de leur travail ou, mieux encore, que les gens rejoignent Braze en sachant déjà la plupart du temps comment le faire.
• Nous voulions que les équipes d'ingénierie de produits de Braze soient largement cohérentes dans leur fonctionnement, car pouvoir parler le même langage est précieux.
• Nous ne voulions rien faire de manière dogmatique ou sans y réfléchir. Il ne suffisait pas de choisir une méthode et de suivre le livre; il était important pour nous que le bon sens et une itération réfléchie dominent la journée.

Forts de ces directives, nous avons décidé d'utiliser Scrum, qui est un cadre Agile qui s'est avéré efficace pour de nombreuses organisations. C'est largement connu, c'est évolutif et c'est le choix sûr par défaut lorsque vous cherchez à mettre en œuvre un processus Agile.

Ensuite, nous avons dû prendre deux décisions principales : (1) quels outils nous devrions utiliser pour prendre en charge notre nouveau processus et (2) comment nous devrions déployer les modifications apportées à notre processus. Nous avons discuté, évalué et fait des démonstrations de plusieurs logiciels et, finalement, Jira d'Atlassian s'est avéré être le bon choix pour nous. C'est une solution éprouvée, plusieurs membres de notre équipe avaient déjà l'expérience de son utilisation, et d'autres équipes au sein de Braze l'utilisaient déjà, ouvrant une opportunité pour une meilleure collaboration inter-équipes car nous travaillerions tous dans un seul système.

Lorsqu'il s'agissait de sélectionner un plan de déploiement pour Agile, nous avions quelques décisions clés à prendre. Premièrement, comment formons-nous/habilitons-nous l'équipe ? Nous pourrions embaucher un coach Agile, demander à des personnes expérimentées de l'équipe de former les autres ou demander à des consultants de nous aider. Deuxièmement, devrions-nous faire en sorte que les équipes d'ingénierie qui ont une certaine expérience avec Agile attendent une formation avant de l'implémenter ?

En fin de compte, nous avons décidé de laisser les équipes qui connaissaient Jira et Scrum se lancer dans la mesure où elles s'en sentaient capables, et avons engagé un consultant pour aider à la transition à l'échelle de l'organisation. Nous n'étions pas intéressés à ce que des membres de notre équipe ou un joueur indépendant soient principalement responsables de l'encadrement des membres de l'équipe pendant la transition car :

• Nous ne voulions pas qu'une équipe individuelle s'approprie notre façon de faire Agile et nous avons estimé que la formation serait mieux reçue et que les suggestions seraient plus inclusives si elles provenaient d'un tiers
• Nous pensions qu'une entreprise de conseil serait plus stable et plus fiable qu'un coach Agile individuel
• Nous voulions avoir une formation de base pour l'ensemble de l'organisation d'ingénierie et commencer sans faire d'hypothèses sur les connaissances que les individus membres de l'organisation avaient autour d'Agile
• Enfin, nous voulions que les entraîneurs partent à un certain moment, afin de préciser que tout le monde dans notre organisation était responsable de maintenir le processus à l'avenir.

Exécution du plan

Après quelques mois de planification, nous avions un gros document qui détaillait tout ce que nous avions l'intention de faire et nous l'avons partagé avec l'ensemble de l'organisation pour obtenir des commentaires. Ensuite, après avoir évalué plusieurs fournisseurs, nous avons sélectionné Eliassen pour nous accompagner dans le voyage vers Agile. Ce voyage a commencé par une formation Agile de deux jours dispensée par Eliassen, suivie de trois mois de coaching Agile par un expert avec qui Eliassen nous a mis en contact.

Dès le départ, nous étions assez prudents quant au passage à Jira et Scrum. Internet et les expériences personnelles de notre équipe étaient pleins de récits édifiants sur les dangers des approches trop dogmatiques, sur la façon dont Jira peut en venir à fonctionner comme un « anti-modèle » et sur toutes les façons dont Scrum peut mal tourner dans les organisations. Les personnes que nous avons consultées nous avaient fortement prévenus que ces changements prendraient probablement du temps et qu'il pourrait bien y avoir des difficultés de croissance avant de voir les avantages réels d'Agile.

Heureusement, nous avons immédiatement trouvé de la valeur dans le nouveau processus. L'un des avantages de cette transition est que nous n'avons jamais ressenti de pression pour suivre aveuglément un aspect particulier de Scrum ; pour que les choses fonctionnent mieux, nous faisions une rétrospective sur la façon dont les choses se passaient toutes les deux semaines, puis modifiions ce qui devait être modifié. Et tout au long des trois mois de coaching, nous avons mis en œuvre des changements radicaux dans l'ensemble de l'organisation d'ingénierie :

• Tout le monde a appris à écrire, préparer, pointer, décomposer et ramasser des histoires d'utilisateurs
• Les standups ont trouvé un regain d'attention lorsqu'il s'agissait de terminer le travail à accomplir
• Le produit, la conception et l'ingénierie ont tous appris à parler les mêmes langages et les interfaces étaient de mieux en mieux conçues.

Les résultats

Maintenant que nous sommes de l'autre côté de cet effort d'environ six mois, les changements sont clairs et spectaculaires. Nous avons constaté une réduction significative des problèmes qui ont conduit à cet effort. Avec Agile, nous disposons désormais de mécanismes clairs et faciles à comprendre pour l'approbation, la collaboration, la création de backlog et le toilettage, et nous organisons régulièrement des rétrospectives sur ce qu'il faut améliorer.

Nous avons également des emplacements beaucoup plus cohérents pour les artefacts de conception, ainsi que des attentes mieux alignées sur ce qui est réellement « fait » pour un projet donné. Voir sur quoi travaillent les autres équipes est devenu facile et il est plus simple que jamais pour les gens de comprendre comment bien travailler ensemble.

Quelque chose que j'ai remarqué à la fin de cette transition est que le nombre total de demandes d'extraction ouvertes dans l'organisation à un moment donné avait diminué, même si nous faisions plus et augmentions la taille de notre équipe. En travaillant par petits incréments et en se concentrant sur les finitions, le nombre d'articles en vol a considérablement diminué.

Le succès que nous avons eu dans notre organisation en a également inspiré d'autres. Nous commençons à voir des équipes d'autres départements de Braze commencer leurs propres transformations Agile, donc bientôt plus de gens parleront le même langage et auront les outils dont ils ont besoin pour définir et améliorer la collaboration.

Plats à emporter

Deux éléments principaux de notre effort ont assuré son succès.

Premièrement, le fait qu'il était dirigé par un comité représentatif était essentiel pour obtenir des commentaires de l'ensemble de l'organisation d'ingénierie et d'une variété de perspectives différentes. À l'échelle de l'entreprise, les gens se sont sentis entendus et représentés sur une question qui aurait un impact sur leur travail quotidien. La création ultérieure d'un document détaillé exposant les motivations et les plans d'une transition Agile qui pourrait être partagé avec l'équipe a également été très utile. Nous croyons qu'il est important de montrer comment les décisions sont prises et d'introduire des voies claires pour les commentaires, car cela fournit un contexte et établit un artefact sur lequel donner des commentaires.

Deuxièmement, la décision de faire appel à un tiers pour aider à coacher notre équipe était essentielle. Avoir un partenaire objectif et expérimenté nous a permis d'apporter rapidement de nombreuses améliorations à notre processus. Notre entraîneur savait à quoi ressemblait le bien et était capable de faire des recommandations sans parti pris, un certain nombre de fois nous avons pu demander : "Comment les équipes feraient-elles normalement X ?" et obtenez une solution immédiate et réalisable. Si, d'un autre côté, nous avions utilisé des ressources internes, nous aurions couru le risque que les commentaires que nous recevions provenaient d'une partie biaisée et que les ressources seraient davantage en conflit avec les responsabilités existantes.

Rien d'autre?

Si vous souhaitez en savoir plus sur la façon dont nous pensons à notre produit et sur le travail nécessaire à sa fabrication, consultez Building Braze. Vous souhaitez rejoindre notre équipe? Consultez nos offres d'emploi actuelles.