Scrum pour le développement matériel : adapter le cadre
Scrum a été développé dans le contexte du développement logiciel. Le développement matériel viole plusieurs de ses hypothèses implicites : les composants ont des délais d'approvisionnement, les environnements de test prennent des jours à configurer, un prototype ne peut pas être complété en quinze jours. Et pourtant, des équipes matériel chez des entreprises comme Saab, BMW, Boston Scientific et John Deere ont réussi à adapter Scrum. La clé est de comprendre ce qui se transfère directement, ce qui nécessite une adaptation, et ce qu'il vaut mieux laisser de côté.
Adapter la durée des sprints
Le sprint de deux semaines standard en développement logiciel est souvent impraticable pour le travail matériel. Un cycle de construction-test pour un prototype physique peut nécessiter trois à six semaines. Le Guide Scrum ne mandate pas les sprints de deux semaines -- il spécifie des sprints d'un mois ou moins. Les équipes matériel utilisent typiquement des sprints de trois à six semaines, calibrés sur leur cycle réel de construction-test.
Définition de Fini spécifique au matériel
La Définition de Fini doit refléter les réalités physiques du domaine : fichiers de conception mis à jour dans le système de gestion de versions, nomenclature réconciliée, prototype construit selon les spécifications, tests spécifiés complétés et résultats documentés, modes de défaillance examinés, vérifications de conformité pertinentes effectuées. Le piège à éviter : une DoD si ambitieuse qu'elle ne peut être atteinte qu'à la fin du programme de développement entier.
Gérer les stocks physiques comme des travaux en cours
Les pièces en commande, les composants en attente d'assemblage et les prototypes à divers stades de construction sont tous des travaux en cours au sens lean -- des éléments qui ont consommé des ressources sans encore livrer de valeur. La planification de sprint pour les équipes matériel doit tenir compte explicitement des délais d'approvisionnement. Le backlog doit être séquencé non seulement par valeur et priorité, mais aussi par la disponibilité des matériaux physiques nécessaires à l'exécution de chaque élément.
Ce qui fonctionne sans modification
La planification de sprint : la discipline de sélectionner un périmètre de travail délimité et de s'y engager en équipe.
Le Daily Scrum : quinze minutes suffisent; les mêmes trois questions; le rythme construit la cohésion inter-fonctionnelle.
La rétrospective de sprint : souvent citée comme l'un des éléments les plus précieux par les équipes matériel.
L'autorité du Product Owner : une seule personne avec l'autorité de prioriser le backlog élimine la dynamique d'approbation comité par comité.
Ce qu'il faut éviter
L'erreur la plus fréquente est de forcer les durées de sprint logiciel sur le travail matériel. Un sprint de deux semaines qui ne peut pas produire un incrément significatif de matériel testé n'est pas un sprint -- c'est une mise à jour de statut bihebdomadaire avec une surcharge de processus supplémentaire. Si l'équipe ne peut pas produire quelque chose de démontrablement différent à la fin de deux semaines, la durée du sprint doit être ajustée.
XNM Conseil aide les organisations d'ingénierie et de développement de produits à mettre en oeuvre des pratiques agiles et Scrum adaptées à leur contexte.