Agile Hardware , est-ce vraiment possible?

Quels sont vos retours d’expérience concernant l’Agilité au sein des équipes qui développent des produits comportant du Hardware ?

Mon xp : formé / accompagné de manière courte LaCie, créateurs de disques durs.

Dans le hardware il y a 3 parties quand on crée un produit, qui ne vont pas à la même vitesse :

  • Le software
  • Le firmware
  • Le hardware

Avec du recul, j’ai vite compris que c’était potentiellement des cycles assez long de création de nouveau produit. On a opté plutôt pour Kanban, avec 3 swimlane : une software, une firmware, une hardware. Et on a essayé de découper fonctionnellement plutôt que techniquement.
Ca leur a beaucoup plu, et ils ont pu le faire pour un nouveau DD cette approche. Ca a augmenté au moins les discussions entre les 3 équipes, grace à un seul board commun.

Par contre clairement Scrum, pour leur besoin, était pas forcément la meilleure approche. On a opté pour un mélange entre une réponse domaine « compliquée » (du lean avec Kanban / Juste à temps) et une réponse domaine « complexe » (plus de feedbacks entre les 3 équipes, et on essaye de découper pour avoir un premier prototype).

2 « J'aime »

Salut,
Merci pour ta réponse.
Si je comprends bien c’est l’aspect communication et silo que tu as réussi à améliorer.
En revanche, la construction de valeur produit par incrément n’est pas quelquechose de faisable selon toi.

Manu

Hello,

J’apporte mon petit grain de sel.
Alors ce n’est pas mon xp propre mais celle d’un collègue coach qui a travaillé chez Pellenc.
Pellenc est un constructeur de machines agricoles, et notamment des tracteurs viticoles (pour les vignes quoi)
Et bien, non seulement ils travaillent en mode agile (scrum), mais en plus, ils ont un prototype de tracteur qu’ils améliorent sprint après sprint, avec démo et essais utilisateurs. Et quand le client est satisfait, ils lancent la prod

Dans le nucléaire, on envisage de passer par la réalité virtuelle pour la conception. Cette VR permettra des démos aux « clients » et de collecter un maximum de feedback en un minimum de temps

Je dirais qu’en adaptant un peu en fonction des contextes, la construction de valeur produit par incrément est possible dans le domaine industriel en général.

Merci pour ton retour.
Peux-tu donner des exemples d’incréments produit sur les tracteurs ainsi que la durée des sprints ?

Merci

Durée des sprints : 1 mois
Exemple d’incrément : adaptation du système de vendange aux vignes américaines (espacement plus large)

C’est évidemment faisable, et au final c’est ce qu’on a fait. Juste que le cadre Scrum n’était pas adapté et qu’on a préféré une approche cadencée avec Kanban.

C’est donc une modification mécanique ou un réglage paramètrable via software ?

Ce qui pose problème dans cet exemple, c’est pas tellement que ça soit du hardware, mais la différence de volatilité entre les 3 aspects du produit. On peut se demander si ça ne justifie pas de découper en 2 ou 3 produits séparés d’ailleurs. Pas sûr qu’il soit souhaitable de fournir des incréments hardware à chaque évolution du software.

Il y a également une question qui se pose pour les projets où le produit est corporel, c’est l’articulation entre le cycle de vie du produit du point de vue de sa conception contre celui du produit du point de vue de son utilisation. Un sprint d’un mois, c’est pas la même chose si on peut prototyper un incrément en 1 jour ou en 3 semaines. Mais un sprint d’un mois c’est aussi pas la même chose si on se parle d’un produit qu’un utilisateur va renouveler en moyenne au bout d’un an ou au bout de 25.

Je comprends pas du tout ton message… Justement, tous les problèmes que tu donnes ne sont pas arrivés dans mon exemple ? On a justement pas fait d’incrément hardware à chaque evol de software, mais l’inverse : à chaque incrément de hardware il y avait une evol de firmware et de software qui arrivait. Pas l’inverse…

Pareil, on a pas fait de Sprint. Les protos mettaient parfois moins d’un mois, parfois bien plus, en fonction du produit et de la partie (SF / HW / FW). C’était très variable, d’où le fait que Scrum ne répondait pas au besoin du tout à cause de la variance entre les 3 parties.

Il y a deux aspects, à mon message précédent.

Sur les 3 composantes

Si les différentes phases (au sens chimique du terme) sont livrées chacune à leur propre fréquence, indépendamment les unes des autres, on n’est pas dans un fonctionnement d’un produit à 3 composants, mais d’un bundle de plusieurs produits. Donc normalement chacun son PO et son PB. La synchronisation entre les équipes relève de la coordination entre produits. Mais limiter cette coordination à faire se parler les 3 PO n’est probablement pas suffisant. En revanche, si les livraisons sont par nature synchrone (on livre les 3 composantes ensemble, même si parfois 1 ou 2 composantes ne changent pas), j’ai l’impression que vous êtes tombés dans le trou du silo.

Si vous avez des devs SW qui bossent sur le SW, pendant que des devs FW bossent sur le FW et les devs HW font de même sur le HW, on est finalement dans le même schéma qu’un produit purement SW avec des silos de codeurs, testeurs, sysadmins, dba, etc … On ne peut pas garantir que l’équilibre entre les différents aspects de du travail soit toujours cohérent avec l’équilibre des capacités spécialisées de l’équipe.

Si on prend l’équipe comme un tout hétérogène mais avec des gens qui peuvent passer d’une composante à l’autre de manière plus ou moins fluide en fonction des besoins, alors on peut parfaitement s’organiser en sprints avec Scrum, je pense. On peut aussi jouer avec les composantes, et résoudre une limitation SW par une évolution HW ou inversement. C’est un peu ce qu’explique JP dans la dernière vidéo RETEX de ScrumLife, où une équipe composée uniquement de personnes du marketing a réussi à faire un incrément sans toucher au code.

Sur les cycles de vie matériel

Le logiciel étant incorporel, il est facile de le remplacer par une nouvelle version. C’est aussi ce qui a fait la popularité et l’intérêt des solutions de type SaaS ou encore des appstores. Ces approches servent à résoudre le problème historique du versionnement des logiciels. C’est aussi ce qui avait poussé Microsoft à tenter de faire de Windows 10 la « dernière version » de Windows.

Pour des composantes matérielles, c’est peut-être plus compliqué, parce que le remplacement du produit par son itération suivante nécessite une logistique plus importante que pour du logiciel. Pourtant, ce n’est pas impossible, mais ça peut être plus ou moins compliqué en fonction du turnover et du temps de cycle.

Par exemple, pour que les utilisateurs remplacent fréquemment (ex le smartphone dans les années 2010), on va plutôt adopter une approche par remplacement, type consommable. Pour des produits que les utilisateurs gardent longtemps (ex la voiture), on va plutôt leur proposer un remplacement ou des « kits évolution ».

1 « J'aime »

Modification mécanique