Ce que la plupart des "gourous" de l'Agilité ne comprennent pas à propos du développement matériel

La méthodologie Agile, enracinée dans le monde du développement logiciel, a été saluée comme une force transformatrice dans l'industrie technologique. Cependant, alors que nous nous aventurons dans le développement de matériel et d'électronique, l'adaptation apparemment fluide des principes Agile rencontre un labyrinthe de défis et de malentendus. Dans notre premier volet de cette exploration en trois parties, nous avons analysé les défis Agile découlant des différences entre le développement matériel et logiciel. Dans cet article, nous examinons les mythes propagés par les "gourous" de l'Agile.

Avant de nous plonger dans les subtilités de l'Agile dans le développement de matériel électronique, il est important de préciser que notre intention n'est pas de dénigrer les coachs et consultants Agile. Nous reconnaissons et apprécions leurs bonnes intentions et leur enthousiasme à aider les clients à récolter les bénéfices des méthodologies Agile. Bien que certaines critiques puissent découler d'une compréhension limitée des nuances du matériel, l'intention n'est pas de critiquer mais d'adapter efficacement les principes Agile pour répondre aux exigences spécifiques du développement matériel. Notre focus est d'ajuster les tactiques Agile pour exploiter ses avantages dans ce contexte unique, en modifiant l'approche mais en préservant les principes.

Mythe n°1 : Vous devez rester flexible et vous adapter

Les gourous de l'Agile vantent à juste titre les vertus de l'exécution itérative, des boucles de rétroaction, et de l'adaptabilité rapide qui ont prospéré dans le domaine numérique du logiciel. Cependant, la transition de ces principes vers le paysage tangible du matériel et de l'électronique introduit une couche de complexité non présente dans le spectre purement numérique. Les solutions physiques, contrairement à leurs homologues logiciels, doivent être "terminées" pour commander des pièces, fabriquer des moules et répondre à des besoins de fabrication stricts. L'appel de l'Agile pour un changement constant entre en collision avec la nature impitoyable de l'effet domino du matériel lorsque même de modifications mineures sont nécessaires tard dans le processus.

En réponse, modifier Agile pour le développement matériel nécessite un changement de paradigme. Il ne s'agit pas de modifications incessantes mais d'adaptations stratégiques éclairées et de prototypage. Celles-ci sont basées sur des cycles rapides d'apprentissage et d'exécution qui visent à maximiser la valeur dans les contraintes de temps, de budget et de ressources. La danse entre l'agilité Agile et les exigences de finalité d'un produit physique exige une planification d'itération plus consciencieuse et un engagement profond envers la réduction des risques tout au long du projet.

Mythe n°2 : Vous devez développer un prototype fonctionnel à chaque sprint

Alors que le développement d'un prototype pleinement fonctionnel toutes les deux à trois semaines, souvent propagé par les puristes de l'Agile comme un "must" universel pour être Agile, la faisabilité pratique de cette approche s'effondre face à la réalité du développement matériel et électronique (et du budget). L'idée de construire quelque chose, de démontrer des progrès et d'utiliser ce résultat pour obtenir des retours techniques et commerciaux précieux pour informer votre prochaine itération est juste. Cependant, chaque projet matériel est une entité distincte avec ses propres objectifs, dépendances, contraintes de délai, domaines d'innovation nécessaires et risques. Et chaque projet mérite sa propre approche unique en matière de prototypage et d'apprentissage.

Pour véritablement adopter le développement de produits matériels Agile, les équipes doivent abandonner la mentalité du "prêt-à-porter". Au lieu de cela, elles doivent procéder à un examen minutieux des besoins du projet, puis collaborer pour dériver une stratégie créative, d'apprentissage et de prototypage. Il est important de reconnaître qu'un "prototype" peut être n'importe quelle sortie démontrable allant d'une brochure préliminaire à une maquette en mousse (comme la célèbre maquette de l'iPod de Steve Jobs qui tient "1000 chansons dans votre poche"), et peut même inclure des prototypes partiellement ou entièrement fonctionnels.

Mythe n°3 : Ajouter des Histoires au Backlog et Simplement Commencer

Une force inhérente des méthodologies Agile réside dans leur capacité à démarrer un projet beaucoup plus rapidement que les approches traditionnelles en cascade. En fait, pour les projets électroniques matériels Agile, nous avons constaté une réduction significative de la période allant de l'identification du concept à l'initiation du développement. Cette période, qui s'étendait souvent sur de nombreux mois voire des années sous une approche traditionnelle par phases, a été condensée à une question de semaines ou de jours avec les méthodes Agile. Bien sûr, une partie de ce résultat spectaculaire est la manière dont nous définissons "l'initiation du développement".

Pour les logiciels, c'est simple. Les gourous de l'Agile prônent la rédaction d'Histoires Utilisateurs pour définir les fonctionnalités du logiciel, les prioriser dans un backlog, et lancer un Sprint. Cependant, dans le domaine du matériel, un minimum de planification préalable est nécessaire pour guider le projet dans la bonne direction avec une compréhension de l'architecture, des attributs clés souhaités, des contraintes et d'autres facteurs. Cet effort préalable peut sembler entrer en conflit avec les principes Agile selon lesquels "le logiciel opérationnel est la principale mesure du progrès" et "accueillir les changements de exigences, même tard dans le développement."

La réconciliation réside dans la recherche d'un équilibre en adaptant les tactiques Agile communément comprises au début du développement de produit. La gestion de projet Agile pour le matériel permet une initiation rapide en s'alignant sur l'intention stratégique du projet et en acceptant beaucoup plus d'inconnues que les approches traditionnelles. Les équipes peuvent ensuite collaborer en utilisant l'apprentissage itératif de l'Agile pour définir la solution optimale, couplé à un état d'esprit ouvert aux changements stratégiques qui améliorent la valeur du produit tout en restant dans les contraintes de calendrier et de ressources.

Mythe n°4 : Définir tous vos éléments de travail comme des User Stories

Une directive critique que de nombreux gourous de l'Agile préconisent est que tout le travail de développement devrait être défini comme des User Stories. Le conseil continue en disant que les composants systèmes, les interfaces, les autres ingénieurs, etc., devraient être traités comme des "Utilisateurs". Ce conseil laisse la plupart des développeurs en électronique et en matériel perplexe et en difficulté pour se conformer.

Une raison principale pour laquelle les équipes logicielles ont si facilement adopté les pratiques Agile est parce que documenter les besoins des clients avec des documents de spécifications traditionnels et des cas d'utilisation détaillés était très gaspilleur et ajoutait peu de valeur à l'équipe. Pourquoi ne pas simplement déclarer ce que l'utilisateur essaie de faire, écrire une User Story pour documenter la fonctionnalité, puis traiter cela comme une tâche de développement ? Cela s'auto-documente non seulement, mais si ces histoires sont constamment priorisées et validées avec les clients, nous avons le système en boucle fermée parfait pour répondre au changement et optimiser la valeur. Sympa !

Cette tentative de rédiger directement des User Stories comme éléments de travail pour le développement matériel tout en les reliant à des résultats précieux pour le client est souvent le point de rupture Agile pour de nombreuses équipes matérielles. Définir du matériel est simplement différent de définir du logiciel. Les documents traditionnels de spécifications des exigences produit (PRD) et les spécifications fonctionnelles ne sont pas seulement rassurants pour les développeurs de matériel, mais fournissent également les détails nécessaires pour décomposer et livrer leur travail. Demander aux développeurs d'écrire une User Story telle que : "En tant qu'unité de traitement, j'ai besoin d'une régulation de tension pour assurer une entrée propre..." va à l'encontre de l'objectif de capturer la valeur client à travers les User Stories et ajoute des déchets sans valeur que les développeurs de logiciels étaient si impatients de supprimer avec les principes Agile.

Comme le définit Mike Cohn, un des premiers leaders d'opinion sur l'Agile pour le logiciel : "Une User Story est une description courte et simple d'une fonctionnalité, racontée du point de vue de la personne." Le mot clé ici est "personne". L'Agile pour les équipes matérielles peut tirer une valeur significative de l'écriture des User Stories mais doit les utiliser pour capturer les besoins des clients venant de personnes, et non définir des éléments de travail. Ces histoires doivent ensuite être traduites en attributs de produit et en éléments de travail connexes qui satisfont les résultats souhaités avec des techniques qui ont du sens pour les développeurs de matériel.

Mythe n°5 : Vous devez avoir des membres d'équipe dédiés

Un sondage LinkedIn par Vitality Chicago a montré que 54% des praticiens Agile affirment qu'avoir une équipe Scrum ou Agile dédiée (impliquant des membres d'équipe dédiés) est une règle essentielle de l'Agile. Bien qu'il n'y ait pas de discussion sur les équipes dédiées dans le Manifeste Agile, les gourous de l'Agile traitent souvent cela comme une règle, et il est difficile d'argumenter qu'il n'y aurait pas de nombreux avantages à avoir des membres d'équipe concentrés à 100% sur un projet. Il y aurait peu d'excuses pour ne pas respecter les engagements, rien pour distraire le succès, et personne pour dire : "Cet autre projet est une priorité plus élevée cette semaine !"

Cependant, si vous avez déjà travaillé dans un environnement de développement de matériel, vous savez que disposer de membres d'équipe dédiés serait un luxe que peu d'organisations peuvent se permettre. La nature du développement matériel fait que les architectes, les concepteurs principaux et autres experts en la matière (SME) sont souvent nécessaires sur plusieurs projets. Une entreprise pourrait avoir un expert en fréquence radio qui est sollicité lorsque son expertise est nécessaire, un spécialiste de la mise en page qui est nécessaire à des moments clés, etc. Les équipes de développement matériel peuvent encore adopter et tirer parti des méthodes Agile, mais avoir des membres d'équipe dédiés n'est généralement pas une option. Par conséquent, disposer d'une approche de gestion des ressources soutenant l'Agile est critique pour le succès à long terme de l'Agile.

#Mythe 6 : Agile est la somme de ses rôles définis, rituels, cérémonies et vocabulaire

Deux équipes travaillent côte à côte dans une entreprise : une équipe matérielle utilisant une approche traditionnelle en cascade et une équipe logicielle utilisant les méthodes Scrum. Un développeur matériel passe devant la salle de conférence où les développeurs logiciels sont rassemblés en cercle et entend : "Ok, bienvenue à notre stand-up. Durant le dernier sprint, nous avons eu des difficultés avec les estimations des points des user stories et les critères d'acceptation. Notre Scrum Master a partagé notre dernier burn-up et a facilité une rétrospective pour aborder les problèmes dans notre peaufinage du backlog afin que nous puissions augmenter notre vélocité. Faisons un fist-to-five sur ce que nous ressentons à propos des changements." Une gamme de configurations de poings et de doigts se lève rapidement.

Le développeur matériel, bien qu'intrigué, ne peut s'empêcher de se sentir un peu perplexe face à ce rituel bizarre et à l'abondance de termes inconnus, se demandant comment ces méthodologies Agile pourraient éventuellement se traduire dans son monde de développement matériel tangible. "Suis-je tombé dans une secte ?!" se demande-t-il.

Souvent, les gourous de l'Agile sont tellement imprégnés du langage et de la culture de l'Agile pour le logiciel qu'ils croient que les équipes matérielles doivent adopter les mêmes cérémonies, rôles, outils et langage pour être véritablement "Agiles". Ironiquement, le premier principe du Manifeste Agile déclare, "Les individus et les interactions plus que les processus et les outils." Je pense que nous pouvons développer cela et affirmer en outre, "Les individus et les interactions plus que les processus, les outils, les rituels et le dogme." Bien que s'accorder sur le langage, les formats de réunion et les activités spécifiques pour construire un état d'esprit Agile et une manière de travailler systématique soient tous cruciaux pour le succès, adopter les rituels et le vocabulaire spécifiques de Scrum ou de l'Agile pour le logiciel ne l'est pas. Les équipes matérielles doivent examiner le but et l'intention de chaque élément, cérémonie et rôle Agile et déterminer comment chacun peut au mieux répondre à leurs besoins.

Comblant le fossé entre l'Agile et le matériel

Alors que vous réfléchissez à savoir si une approche Agile est adaptée à vos efforts de développement de matériel et d'électronique, la "sagesse" conventionnelle propagée par des gourous Agile bien intentionnés est souvent insuffisante pour guider l'approche plus nuancée et adaptative nécessaire au développement de produits physiques. Le chemin vers une mise en œuvre Agile réussie dans le domaine du matériel implique un mélange réfléchi de flexibilité, de préparation préalable, de planification itérative et d'une approche consciencieuse pour converger vers la solution la plus précieuse possible dans le plus court laps de temps.

Dans le segment de conclusion de notre série en trois parties, nous approfondirons l'exploitation des avantages d'Agile modifié pour le développement de matériel électronique, tout en respectant les principes fondamentaux de la méthodologie Agile. Êtes-vous intéressé par explorer le sujet plus en détail ? Regardez le webinaire !