En 2015, la division Logiciels et Informatique d'Agilent était en difficulté. En plein lancement d'un nouveau produit majeur, l'équipe allait rater sa date de livraison. Et ce n'était pas une première : dans 20 % des cas environ la division ne respectait pas ses délais de livraison.
Les retards de livraison mettaient une pression énorme sur les équipes de développement logiciel. « Lorsque les équipes sont sous pression, elles prennent de mauvaises décisions », explique John Sadler, vice-président et directeur général de la division Logiciels et Informatique d'Agilent. « Elles sacrifient la qualité et finissent par le payer en bout de chaîne. De manière générale, le moral de l'équipe n'était pas bien haut, et elle avait du mal à livrer quoi que ce soit dans les délais. »
Une partie du défi résidait dans le fait que la division Logiciels et Informatique d'Agilent comprenait 150 employés sur deux continents qui collaboraient avec des sous-traitants sur un troisième. Il s'agissait d'une division tentaculaire composée de professionnels de l'ingénierie, du marketing, de l'assurance qualité, du support technique et des ventes. L'entreprise avait besoin de mettre en place de nouvelles pratiques d'équipe pour l'aider à créer de la valeur plus rapidement, avec une meilleure qualité et une meilleure prévisibilité, et à mieux répondre au changement. Bref, ils avaient besoin d'une transformation Agile.
Entamez votre transformation Agile
En 2015, Agilent a planifié une transformation Agile avec les objectifs suivants :
- Mettre l'accent sur la prévisibilité
- Développer une cadence de livraison fiable
- Créer un cycle de livraison reproductible
- Promouvoir l'amélioration continue
L'approche Agile place la qualité en premier, une cadence reproductible en second et le périmètre en troisième. « Lorsque les équipes ne respectent pas ces priorités, elles accordent souvent la priorité au périmètre, le calendrier est imposé sous la forme d'un délai et la qualité se fait attendre », explique John Sadler.
Agilent souhaitait mettre en place des processus Agile qui intègrent des priorités dans le développement de ses logiciels. Faire de l'amélioration continue une valeur fondamentale a entraîné un changement culturel qui a créé un contexte propice à la transformation. Mettre la qualité au premier plan signifie améliorer la satisfaction des clients externes et internes. Agilent était prêt à sacrifier le périmètre afin de répondre aux attentes de ses clients sur le terrain.
La deuxième priorité était que la division crée un cycle de livraison prévisible qui pourrait être affiné au fil du temps. Un cycle de développement plus court et plus fiable signifiait que l'équipe pouvait éviter les problèmes et limiter les risques très tôt afin de permettre un temps de réponse adéquat.
Transformation Agile : étape par étape
À partir d'août 2015, Agilent s'est associé à cPrime, une société de conseil expérimentée dans l'assistance aux organisations dans le cadre de transformations Agile, et plus tard avec TCGen, un cabinet de conseil de premier plan en développement de produits.
La première étape a consisté à implémenter l'outil de gestion de produit Agile, Jira. Jira fournit désormais un système d'enregistrement unique pour toutes les tâches de développement d'Agilent, au sein d'équipes réparties dans le monde entier. Il crée de la transparence grâce à une version unique de référence qui révèle les fonctionnalités à l'ordre du jour, quand elles sont attendues et ce qui a déjà été accompli par les équipes.
Adapté avec la permission de cPrime, Inc.
La formation Agile était la prochaine priorité, avec pour objectif d'enseigner les principes et les concepts Agile et d'établir une terminologie commune. cPrime a présenté ses recettes pour le modèle de gouvernance Agile dans l'entreprise (RAGE). Ce modèle décrit les cérémonies clés, notamment les réunions de planification des livraisons, les réunions Scrum de Scrums de l'équipe, les réunions Scrum de Scrums des Product Owners, les réunions de préparation du backlog de livraison, la revue des livraisons et les réunions de rétrospective des livraisons.
Agilent a également défini des rôles de Product Owner de Domaine et de Program Manager et a mesuré l'avancement à l'aide de graphiques Burnup. Agilent a également adopté des techniques de prise de décision légères, organisé des cérémonies, utilisé des artefacts Scrum Agile et adopté d'autres pratiques Agile.
Agile en action
En novembre 2015, la division Logiciels et Informatique d'Agilent a organisé Sprint Zero, une session de planification Agile de deux semaines avec quatorze équipes formées. Une planification des versions de produit a été élaborée sur une période de huit mois pour le système de données chromatographiques OpenLAB.
Les activités de Sprint Zero se répartissaient en trois catégories :
- Former les équipes sur les objectifs techniques et métier, les motivations et les exigences de haut niveau d'OpenLab par le biais de présentations et de posters.
- Utiliser les techniques nouvellement apprises pour développer des exigences et estimer des stories, des epics et des défauts.
- Établir des stories, des epics et des défauts sur le tableau de planification des versions et marquer toutes les dépendances entre équipes.
Agilent a rapidement découvert que ses améliorations Agile s'étendaient au-delà du projet pilote. L'un des premiers indicateurs de réussite était interne. « Parce que nous devions travailler en partenariat avec d'autres divisions d'Agilent, il était extrêmement important de faire ce que nous avions promis de faire », explique John Sadler.
Agilent a également vu ses performances externes s'améliorer. Les commentaires des clients ont joué un rôle déterminant dans la réactivité accrue des équipes Agilent aux changements du marché. En incluant les clients dès le début du processus de développement, Agilent a amélioré la qualité des logiciels tout en réduisant les risques liés au marché et à l'intégration.
L'une des idées d'Agilent a été d'inclure dans la notion de « Terminé » le fait que les stories de mise à niveau soient incluses dans chaque epic Agile. Babita Jain, directrice de la qualité des logiciels, et Stefan Weiss, responsable de l'intégration logicielle chez Agilent, ont dirigé la mise en œuvre de la transformation et ont aidé les équipes à comprendre le périmètre global du projet. « Nous n'avons pas considéré que l'epic était terminée à moins qu'elle n'inclue les mises à niveau », explique Babita Jain.
La transformation Agile a non seulement amélioré la qualité, mais également la fiabilité. En 2016, le système de données de chromatographie OpenLab a été livré dans les délais. Depuis la transformation Agile, Agilent a livré des logiciels à une cadence constante et les défauts signalés par les utilisateurs ont diminué.
Mesurer la réussite
Agilent définit et mesure la réussite de son initiative Agile avec « de faibles taux d'échec sur le terrain et une fidélité élevée de la clientèle », selon les termes de John Sadler. La fidélisation des clients est également essentielle. Sur le marché mature et concurrentiel du secteur des sciences de la vie, la perte de clients est un danger. La possibilité de vendre un nouveau système à d'anciens clients est essentielle.
Voici quatre métriques essentielles que permet le modèle de capacité basé sur Jira d'Agilent :
Graphiques Burndown/BurnUp
Agilent mesurait auparavant le travail en heures d'ingénierie, en jours-personnes ou en story points. Désormais, tout le monde utilise des graphiques Burnup pour suivre le travail terminé et la quantité totale de travail. Les graphiques Burndown indiquent la quantité de travail restante.
Pourcentage de capacité livrée sur le marché (charge utile)
La capacité de modéliser et de suivre la capacité joue un rôle essentiel dans la façon dont Agilent mesure la réussite. Jira a permis à Agilent de créer un modèle de capacité détaillé. « Ce modèle nous a permis, pendant la phase de planification, de dire au marketing la quantité de story points avec laquelle ils devaient travailler pour une livraison. Le marketing doit hiérarchiser le backlog en fonction de cette capacité », explique Sadler.
Nombre et délai médian pour la livraison des correctifs
Le modèle de capacité a fourni une vue plus granulaire qui a permis à Agilent de voir la capacité utilisée pour corriger les défauts critiques ou graves signalés par les utilisateurs par rapport aux défauts que l'équipe qualité a découverts et signalés.
Pourcentage de temps passé à corriger les défauts découverts par des tests manuels
Le modèle de capacité aide Agilent à mesurer le temps passé à créer des fonctionnalités appréciées par les clients par rapport au temps consacré à la maintenance ou à la durabilité des produits existants.
En un peu plus de trois ans, la division a plus que doublé le pourcentage de la capacité axée sur le travail à valeur ajoutée, en la faisant passer de 30 % à 65 %. Plus la qualité des logiciels s'améliorait grâce à la nouvelle approche Agile, moins il y avait de défauts à réparer par la suite.
Un an après le début de leur processus de transformation Agile, les membres de l'équipe Agilent décrivent différents scénarios « avant » et « après » :
 | Avant : les performances étaient mesurées en heures d'ingénierie, en jours-personnes ou en story points. |
|---|---|
 | Avant : les équipes ayant différents niveaux de formation Agile définissaient de manière différente les epics, les stories et les sous-tâches. |
 | Avant : les Scrum Masters écrivaient le code, dirigeaient les réunions d'équipe et évaluaient les priorités des fonctionnalités. |
 | Avant : les fonctionnalités présentant des bugs pouvaient être approuvées, ce qui entraînait des défauts dans les phases de développement ultérieures. |
 | Avant : des problèmes se produisaient souvent au tout dernier moment, entraînant panique et retards importants. |
 | Avant : il n'existait aucun instrument permettant de mesurer la capacité de travail d'une équipe. |
L'avenir d'Agile chez Agilent
Comme toute culture qui valorise l'amélioration continue, la transformation Agile chez Agilent n'est en aucun cas terminée. Les prochaines étapes consistent à poursuivre la réduction de la durée des cycles et à affiner la capacité à obtenir des informations précoces à partir des commentaires du marché, des éléments clés des métriques DevOps.
Agilent a déjà considérablement réduit la durée de cycle, en répartissant les versions annuelles en deux cycles de six mois, même si l'entreprise commercialise les versions chaque année. L'entreprise prévoit de réduire de nouveau la durée de cycle de moitié et de passer à une cadence trimestrielle.
L'implication précoce et fréquente des clients dans le processus de développement est également un sujet d'amélioration continue. John Sadler rapporte que son groupe constate qu'il y a moins d'arbitrage entre les intérêts concurrents dans les discussions sur le périmètre du produit lorsque des preuves claires ressortent des commentaires du marché. Le maintien de la qualité et de la facilité d'utilisation pour les clients sur le terrain est une priorité permanente. De plus, l'engagement continu avec les utilisateurs contribue à maintenir les priorités de l'entreprise : la qualité d'abord, puis la cadence des versions et le périmètre.
Enseignements
John Sadler attribue la réussite à son équipe, en particulier aux dirigeants Babita Jain et Stefan Weiss, qui ont su adopter le développement Agile comme moyen de favoriser une amélioration rapide et continue. Les bons outils, tels que Jira et Confluence, ont permis à l'équipe de regrouper le travail en un seul endroit et de mesurer l'avancement.
Agilent a découvert qu'une transformation Agile nécessitait un sponsor afin de superviser la recherche et le développement, le marketing entrant et la qualité. « Si vous ne pouvez pas transformer les trois, vous n'y arriverez pas », explique John Sadler. « Il n'est pas possible de réussir une transformation Agile uniquement grâce à la recherche et au développement. » Le plus important n'est pas le travail effectué au sein des fonctions, mais les moyens utilisés pour permettre leur collaboration.
Agilent a également découvert qu'il était essentiel d'arrêter avec l'idée qu'une compréhension parfaite des besoins des clients se trouvait à l'intérieur des locaux. Une approche Agile consiste à lancer des produits selon une cadence fiable, puis à recevoir directement les commentaires des clients. Cette approche exige de considérer les dates de sortie comme sacrées, et que lorsque la cloche sonne, l'équipe doit livrer le produit tel qu'il est.
Pour conclure, John Sadler ajoute que le framework Agile permet de mettre les problèmes en évidence, par exemple en exposant les lacunes en matière de capacité. Il fait apparaître les parties du processus sans valeur ajoutée qui entraînent des retards et sont révélatrices des défauts de qualité. Le passage d'une approche en cascade à une approche Agile nécessite non seulement des changements dans la façon de travailler des équipes, mais également un changement de culture. Agile favorise une culture d'amélioration continue qui est franchement contagieuse.
