Don Reinertsen est consultant indépendant et auteur du Livre The Principles of Product Development Flow paru aux éditions Celeritas Publishing en 2009.
InfoQFR : Alexis pour InfoQFR. Aujourd’hui Don Reinertsen nous fait le plaisir de répondre à nos questions. Bonjour Don, pouvez-vous vous présenter ?
Don Reinertsen : Bien sûr, je m’appelle Don Reinertsen, je suis consultant dans le domaine du développement de produits, depuis 30 ans déjà. Je travaille avec des personnes qui développent des logiciels ou d’autres types de produits. Mon travail met l’accent sur la manière de raccourcir les temps de cycle de développement. Depuis 15-20 ans, je me concentre sur comment bien utiliser, dans le domaine du développement produit, les idées qui ont émergé dans l’industrie et les chaînes de production. Je cherche les idées les plus avancées de ce domaine, et quand elles sont insuffisantes, je m’attache à en chercher dans d’autres domaines.
InfoQFR : Que voulez-vous dire par « comment bien utiliser les idées » ?
Don Reinertsen : Dans les chaînes de production, la plupart du temps, on cherche à éliminer la variabilité parce que quand on répète la même action un million de fois, on veut pouvoir le faire à chaque fois de la même façon. Dans ce domaine, vous continuez à gagner de l’argent à chaque fabrication même si le produit ne change pas du tout. Dans le domaine du développement produit, c’est différent, si on ne change pas le produit, on n’ajoute pas de valeur. Le développement produit, c’est plutôt préparer des recettes pour de futurs produits, que de produire à la chaîne. Si la recette ne change pas, on ne crée pas de valeur. Donc l’idée que tout doit toujours rester figé ne fonctionne pas en développement produit. Ce dont on a besoin c’est de mettre en place des processus qui fonctionnent en présence de variabilité.
InfoQFR : Dans votre livre, vous explorez huit thèmes différents, pouvez-vous nous en dire plus ?
Don Reinertsen : Ces huit thèmes sont autant de façon d’expliquer aux lecteurs les différences fondamentales qui existent entre un développement produit traditionnel et un développement produit en flux. Le premier thème est celui de l’importance d’avoir un modèle économique et en particulier de connaître ce qu’est le coût du délai. Le concept de coût du délai nécessite de comparer les profits générés par le produit sur toute sa durée de vie entre le fait de l’avoir disponible aujourd’hui et de l’avoir disponible seulement dans par exemple 60 jours. La différence entre ces profits, aujourd’hui et 60 jours plus tard, est ce qu’on appelle le coût du délai. Quand on a la possibilité de faire un choix entre passer plus (ou moins) de temps ou faire plus (ou moins) de dépenses sur une fonctionnalité donnée, il est préférable de toujours vérifier si le coût du délai généré par le temps supplémentaire (ou économisé) vaut ce gain. Le coût du délai et le modèle économique sont toujours le point de départ, parce que le monde du développement produit connaît une telle variabilité et que les coûts du délai sont tellement différents, que sans cette analyse, tout le monde fait des erreurs.
InfoQFR : Pouvez-vous clarifier pour les français ce que vous voulez dire par développement produit, car en France c’est souvent compris comme étant uniquement le développement informatique, mais vous semblez l’utiliser dans un sens plus large ?
Don Reinertsen : En effet, je travaille avec beaucoup d’industries différentes, des produits de consommation à l’aérospatial, en passant par l’informatique ou les appareils médicaux et pharmaceutiques. Le cycle de développement produit est le temps qui s’écoule entre la toute première identification du besoin du client jusqu’à ce que le produit soit développé et génère des profits parce qu’on a quelque chose à vendre. Le développement produit est l’ensemble des processus qui sont à l’œuvre pendant cette période. On peut dire que le développement produit est une course, pas une course où tout le monde part en même temps après le coup de sifflet, mais une course où l'on choisit quand on part. Certaines entreprises savent partir bien avant les autres parce qu’elles peuvent contacter leurs clients plus tôt, ou parce qu’elles prennent des décisions plus rapidement, ou encore parce qu’elles savent aligner leurs ressources plus rapidement. Le plus tôt vous vous impliquerez dans cette course, le mieux vous pourrez la gérer. Et peu importe de quel produit il s’agit, la plupart des pratiques de management que l’on doit utiliser, restent valables. Le modèle économique en est un bon exemple, je ne connais aucun produit qui n’en bénéficierait pas.
InfoQFR : Pouvez-vous nous en dire plus à propos des processus et du flux de travail en développement produit ? Avez-vous des conseils à donner sur comment gérer ce flux de travail ?
Don Reinertsen : Quand on veut gérer le flux de travail dans le domaine du développement produit, on rencontre des difficultés très différentes d’une usine de production. En effet, sur une chaîne de production, ce qui circule d’un poste de travail à l’autre sont des objets physiques, on peut les voir, voir leur flux, voir la taille des lots dans le processus. Et donc tout ce qu’on a à faire c’est d’aller dans l’usine pour voir ce qui se passe. En développement produit, le flux c’est de l’information, qui est par essence invisible. Même en allant sur place et en cherchant les niveaux de stock, le flux auquel les stocks s’écoulent, ou encore la taille des lots, on ne verra rien. Et malheureusement, parce que c’est invisible, très peu de personne les ont gérés. Une des premières choses à faire est de montrer que le délai ne s’explique pas parce que les gens travaillent trop lentement, mais plutôt parce que les tâches restent bloquées dans les files d’attente invisibles, entre deux étapes du processus. Il faut rendre le travail visible, et particulièrement les files d’attente, pour que les gens commencent à vraiment comprendre le problème de flux.
InfoQFR : Ok donc la première étape est de rendre le travail visible et particulièrement les files d’attente. Que peut-on faire ensuite pour les gérer ?
Don Reinertsen : En général, on commence par s’interroger sur la taille des files d’attente puis, en utilisant un modèle économique et un coût du délai adaptés au contexte, on peut calculer le coût généré par le temps d’attente. On crée ainsi l’opportunité de choisir entre un coût du délai par exemple de 30 jours d’attente, et l’effort pour supprimer ou réduire ce délai. On peut ensuite chercher les changements à faire dans le processus, par exemple peut-être que si j’avais un testeur de plus, je pourrais réduire une file d’attente, quel est le coût d’un testeur supplémentaire, pour quelle diminution de coût du délai ? On est maintenant en position de proposer des arbitrages intelligibles par le manager en charge du périmètre : « j’ai besoin de tant d’argent pour tel bénéfice ». L’ordre logique à suivre est d’abord de trouver où sont les files d’attente puis de calculer leur coût, ensuite seulement on peut commencer à améliorer les choses. Pour ce faire, je dirais que les deux techniques les plus efficaces sont la réduction de la taille des lots et l’utilisation de contraintes sur le travail en cours, dont les systèmes kanban sont un exemple.
InfoQFR : Est-ce que ces deux techniques ont un lien avec votre conseil d’implémenter des boucles de feedback rapide au sein des processus de développement ? Pouvez-vous nous en dire plus ?
Don Reinertsen : Dans le domaine du développement produit, l’un des bénéfices les plus importants de la réduction des tailles de lot c’est l’augmentation de la vitesse des feedbacks au sein d’un processus. Par taille de lot, je veux dire la quantité d’information qui circule en une fois entre deux étapes d’un processus. Les progrès qui ont été fait en automatisation des tests dans le domaine du développement informatique, en sont un bon exemple. Il y a 20 ans, un développeur informatique aurait codé 90 jours de suite avant de transmettre le logiciel aux tests, il aurait donc eu un feedback 90 jours après avoir écrit le code. Aujourd’hui dans les organisations modernes, les développeurs ont un feedback moins de 24 heures après avoir écrit le code. C’est un véritable bond en avant en terme de productivité car si le développeur fait une mauvaise hypothèse en terme de protocole, ou autre, il s’en rendra compte 24 heures après et corrigera. S’il n’a le feedback que 90 jours plus tard, cette mauvaise hypothèse se propagera à d’autres endroits du code et auprès d’autres personnes qui auront développé d’autres fonctionnalités dépendantes. Cet exemple illustre également comment on peut réduire la taille des lots : en réduisant les coûts de transaction. Il y a 20 ans, mettre en place un test pouvait prendre un ou deux jours. Mais il est impossible de tester toutes les 24 heures si la mise en place d’un test prend un jour. Les progrès réalisés à ce jour en automatisation de test ont diminué le coût de transaction et de ce fait, permettent de tester par très petits lots.
InfoQFR : Réduire la taille des lots et utiliser des contraintes de travail en cours permettent d’améliorer les choses, notamment parce que cela accélère les boucles de feedback. Que pouvons-nous faire concernant la priorisation des files d’attentes ? Quelles techniques recommandez-vous ? Qu’appelez-vous discipline de gestion des files d’attente (NDLR en anglais queuing discipline) ?
Don Reinertsen : Par discipline de gestion des files d’attente, je fais référence à l’ordre dans lequel on dépile les tâches d’une file d’attente. Une façon de faire classique, et largement utilisée en usine de production, est nommée FIFO, premier entré, premier sorti (NDLR First In First Out). FIFO est une excellente technique pour une chaîne de production car chaque produit doit être identique et l’ordre dans lequel les files d’attente sont dépilées importe peu. On ne gagne pas plus d’argent en prenant l’un plutôt que l’autre. Alors que dans le domaine du développement produit, les tâches ont un coût du délai très différent entre elles, on peut avoir un énorme impact économique en choisissant l’une plutôt que l’autre. L’un des exemples les plus simples que je puisse donner est celui des urgences d’un hôpital. Si on décide de gérer les urgences comme on gère une chaîne de production, on prendrait les patients dans l’ordre d’arrivée. Il y a fort à parier que dans cette situation, on n’hésiterait pas à traiter d’« espèce d’idiot » (NDLR en français dans l’interview) celui qui a conçu cela, en effet une attaque cardiaque pourrait parfois être traitée après une simple douleur à l’oreille. Il est beaucoup plus pertinent de prioriser sur la base du coût du délai, c’est-à-dire de traiter les tâches à coût du délai important (crise cardiaque) avant celles à coût du délai faible (douleur à l’oreille). On peut laisser les délais augmenter sur les tâches qui ont un faible coût du délai, mais surtout pas sur les tâches à coût du délai important ! La force de cette approche, c’est qu’avec la même demande et la même capacité, on obtiendra de bien meilleurs résultats économiques. Il arrive parfois de réduire les coûts du délai d’un facteur de 10 ou de 20. C’est un outil très important en développement produit, alors qu’il n’est absolument pas utilisé en usine de production.
InfoQFR : En guise de conclusion, pouvez-vous nous parler brièvement du thème de la décentralisation du contrôle ?
Don Reinertsen : La décentralisation du contrôle est un thème qui connaît beaucoup d’intérêt dans le monde des méthodes Agile, notamment à travers la notion d’auto-organisation des équipes. Mais cette auto-organisation a ses limites, elle fonctionne bien à petite échelle quand les coûts et les bénéfices sont visibles localement par les équipes. Les coûts, les actions ou les efforts réalisés au sein d’une équipe doivent générer un bénéfice perceptible par cette même équipe. Quand on commence à regarder à plus grande échelle, les coûts et les bénéfices ne seront peut-être pas au sein de la même équipe, par exemple quelqu’un demandera l’ajout d’une fonctionnalité à un logiciel qui aidera une autre équipe que celle qui le développe. Il faut trouver des mécanismes pour encourager la résolution des problèmes à grande échelle, au-delà de l’auto-organisation promue par le mouvement Agile. C’est de ces mécanismes dont je parle sous le thème de la décentralisation du contrôle : augmenter la prise d’initiatives au niveau des équipes mêmes (car c’est la seule solution pour être vraiment réactif) tout en gardant un alignement très fort au niveau de l’ensemble de l’organisation. J’utilise principalement des idées issues du domaine militaire pour illustrer ce thème et montrer comment mettre en place un contrôle décentralisé.
InfoQFR : Merci beaucoup Don, avez-vous deux mots à ajouter à cet interview ?
Don Reinertsen : Oui, mes deux mots sont « merci beaucoup » (NDLR en français dans le texte).
Lexique des termes clés :
- Variabilité : en développement produit, la matière première avec laquelle on travaille est l’information, or elle peut être très volatile. Les processus de développement produit doivent donc être efficaces en présence de variabilité. Référence Embracing Variability.
- Coût du délai : différence entre le profit d’un produit sur toute sa durée de vie s'il était disponible maintenant et ce même profit si le produit n’est disponible que plus tard.
- Modèle économique : définition de la valeur attendue par l’organisation, par exemple le profit, et sa variation dans le temps. Référence The Tactical and Strategic Art of Economic Models.
- Files d’attente : accumulation de tâches entre deux étapes d’un processus.
- Taille des lots : quantité d’information qui circule en une fois entre deux étapes d’un processus. Référence The Practical Science of Batch Size.
- Contraintes sur le travail en cours : limiter la quantité de travail en cours soit de manière statique (systèmes kanban) soit de manière dynamique. Référence The Science of WIP Constraints.
- Discipline de gestion des files d’attente : modèle de prise de décision, ordre dans lequel on dépile les tâches d’une file d’attente. Référence The Zen of Product Development.
- Décentralisation du contrôle : augmenter la prise d’initiatives au niveau des équipes mêmes, tout en gardant un alignement très fort au niveau de l’ensemble de l’organisation. Référence Decentralizing Control: How Aligned Initiative Conquers Uncertainty.
Pour aller plus loin :
- Plus de vidéo en anglais
- Livre de Don Reinertsen The Principles of Product Development Flow aux éditions Celeritas Publishing, 2009
- Premier chapitre en Français
- Formation en France avec Don Reinertsen