Chapitre 8
La production de biens physiques
Dans ce chapitre :
Prendre ses distances avec la cascade- Améliorer les projets de construction de bâtiments
- Appliquer des solutions Scrum à la production manufacturière
- Développer du matériel avec Scrum
« Une erreur peut s’avérer être une étape nécessaire pour réussir. »
Henry Ford
Connaissant les origines de l’agile et de Scrum, on serait facilement tenté de penser que leur usage est réservé au développement de logiciels. En fait, rien n’est plus éloigné de la vérité. L’article de 1986 de la Harvard Business Review, « Le nouveau jeu du développement d’un nouveau produit » mentionné aux Chapitres 1 et 7, a été écrit en réaction à des expériences conduites dans les industries manufacturières. Cet article se fondait sur des études de cas d’ingénierie de produits matériels, électroniques et automobiles d’entreprises telles que Fuji-Xerox en 1978, Canon en 1982, Honda en 1981, et d’autres.
Le développement et la production de produits physiques s’accordent merveilleusement à Scrum, et je vais montrer comment.
La situation et le produit peuvent varier énormément, mais les outils et les techniques restent les mêmes. En suivant le même cadre de procédures que j’ai décrit plus tôt, vous verrez facilement comment Scrum peut s’intégrer à presque n’importe quel projet. Tout ce dont vous avez besoin, c’est d’une liste d’exigences qui peuvent être priorisées.
La chute de la cascade
Comme vous l’avez vu au Chapitre 7, le développement de produits doit adopter un rythme toujours plus soutenu. Et cela ne se limite pas au secteur des logiciels. Des activités manuelles qui s’étalent dans la durée comme tailler et empiler des pierres pour faire une pyramide, poser des rails dans les prairies, et même tracer de nouvelles autoroutes profitent de la technologie pour gagner en productivité.
Les cycles de développement dans la plupart des industries sont plus courts et plus rapides du fait des économies de temps et d’argent que la technologie permet de générer. Des entreprises telles qu’Apple – dont les produits sont bien tangibles – sortent des produits de nouvelle génération plusieurs fois par an.
Certains prétendent que le cadre de Scrum ne peut être appliqué à des produits physiques. « Nous ne pouvons pas être en train de construire le dixième étage au moment où nous réalisons qu’il faut modifier le cinquième ! ». Parfois, ils ont raison.
Des questions comme celles-là sont tout le temps soulevées, y compris quand il est question de développement de logiciels. Un changement dans la conception peut être si coûteux qu’il ne serait pas réaliste de le mettre en œuvre, et d’autres options doivent être étudiées – notamment, ne rien changer. Peut-être qu’une base de données différente serait préférable, mais c’est trop onéreux, et le propriétaire du produit décide donc de repousser l’idée.
Scrum consiste à prendre de bonnes décisions sur une base empirique, et non à changer les exigences à chaque saute d’humeur du client. Qu’il s’agisse de logiciels comme d’avions, de trains ou d’automobiles, les fondations de Scrum s’appliquent : organiser une équipe Scrum avec les rôles appropriés, procéder à des points fréquents pour évaluation et adaptation, et forcer la prise de décision au dernier « bon » moment (c’est-à-dire, planifier à différents niveaux de détail pour faire les bonnes choses au moment opportun).
Du fait de la boucle de retour, le client a prise sur les décisions par l’intermédiaire du propriétaire du produit. L’équipe de développement n’a pas besoin de tout savoir sur le marché et le client pour prendre les bonnes décisions business. Le propriétaire du produit filtre tout le « bruit » généré par les parties prenantes pour que les développeurs ne passent leur temps que sur les exigences prioritaires. Faisant équipe, le propriétaire du produit et les développeurs travaillent pour trouver des solutions aux problèmes qui leur sont soumis par le propriétaire du produit. Lorsque tout le monde poursuit les mêmes objectifs, on cherche moins les coupables puisque la responsabilité est partagée.
Des clients impliqués sont plus satisfaits que ceux qui attendent qu’on leur livre ce qu’ils veulent. Avec Scrum, les boucles de retour sont régulières, consistantes et aussi fréquentes que possible, si bien que les clients obtiennent ce qu’ils veulent pour le prix qu’ils sont disposés à y mettre. Cela permet de garder les clients impliqués et l’équipe de développement sur les rails. Les obstacles peuvent être identifiés et éliminés tôt, et la responsabilité est partagée par ceux qui font le travail et ceux qui prennent les décisions, dont les clients.
La construction immobilière
Les recours à Scrum dans le vaste monde des biens tangibles sont extraordinairement nombreux. Il est possible d’accélérer le temps de mise sur le marché et de générer des économies sur les coûts dans le logiciel comme dans d’autres domaines. Le secteur du bâtiment en offre un excellent exemple.
Rappelez-vous : Scrum fonctionne avec tout projet, pourvu que vous puissiez lister et prioriser le travail à accomplir. À l’évidence, les projets de construction le permettent. Toutefois, comme pour toute industrie, il faut composer avec des enjeux spécifiques. Il ne s’agit donc pas de dire que « Oh, Scrum ne marchera pas avec ça parce que X, Y et Z ». À la place, il faut penser « Voici les défis auxquels nous sommes confrontés, et voyons comment Scrum va les résoudre et nous permettre de commercialiser plus rapidement et à moindre coût. »
Dans les sections suivantes, je mets en évidence les enjeux spécifiques au bâtiment, et je décris comment Scrum s’y adapte. Vous verrez comment des problèmes traditionnels – ceux auxquels vous vous êtes heurtés toute votre carrière durant dans le bâtiment, et que vous pensiez toujours devoir rencontrer – sont résolus avec Scrum.
Réussir dans les appels d’offres
La compétition pour les projets de construction est féroce, et rien ne laisse penser qu’elle va se tempérer. Combinez cela avec un accroissement régulier des coûts de construction, et vous avez les ingrédients pour inciter à prendre tous les raccourcis, quitte à sauter des étapes essentielles.
Rien de tout cela n’est bien nouveau dans l’industrie du bâtiment. Votre offre peut être parfaite et répondre à tous les besoins du client à un prix raisonnable, mais vous savez que les offres de vos concurrents pourraient être plus intéressantes parce qu’ils vont ignorer des choses dont vous savez que le client aura besoin. Scrum peut vous aider, vous et le client. Après tout, à la fin, mieux vous servez le client, meilleur est le résultat, plus vous consolidez votre business et plus vous attirez de prospects.
Scrum apporte les choses suivantes :
Transparence : Laissez le client décider où il veut mettre son argent. Il peut apporter des changements, évaluer et adapter tandis que le projet avance. Mais il sera complètement informé à chaque étape, car il participera à des revues de chantier régulières lors des revues de sprint, où il donnera son retour et posera des questions.- Adaptabilité : Scrum permet à l’équipe d’identifier et de corriger des erreurs tôt. Même lorsqu’il s’agit de réaliser une construction jusqu’à son terme, il vaut toujours mieux résoudre les problèmes identifiés en terminant une seule maison que les découvrir une fois que dix maisons le sont. Mieux encore, tenir compte du retour du client trouvant un mur porteur mal placé est bien plus facile à régler quand l’électricité, la plomberie et les plaques de plâtre n’ont pas encore été installées.
- Coordination du Scrum quotidien : Mettre en place une instance où les problèmes peuvent être soulevés limite les goulots d’étranglement et permet d’éviter que les petites questions ne dégénèrent en gros problèmes. La plomberie Durand n’a pas livré les matériaux requis ? Le Scrum Master traite le problème tout de suite – s’assurant au passage qu’il ne surviendra pas de nouveau – et non à la fin de la semaine lorsqu’il en est question à l’occasion du point d’avancée hebdomadaire.
Dans le Chapitre 1, j’ai présenté les trois piliers de l’amélioration de l’agile : la transparence, l’évaluation et l’adaptation. Quoique les trois vous rendent bien service dans Scrum, la question de la transparence est de loin celle qui importe le plus dans les processus d’offre et de construction.
Les rôles Scrum dans le bâtiment
Dans la gestion de projet traditionnelle, le rôle de chef de projet endosse de lourdes responsabilités. Elles sont générales et inclusives, et trop souvent, trop conséquentes pour reposer sur les épaules d’une seule personne. Le chef de projet porte tant de casquettes – il doit assurer la coordination de toutes les parties en présence – que l’efficience et la qualité peuvent en pâtir.
Scrum propose des rôles différents, clairement désignés, pour répartir les responsabilités. L’équilibre est assuré du fait que les membres de l’équipe Scrum s’organisent de la manière suivante :
- Le rôle de chef de projet disparaît.
- Le propriétaire du produit représente le client et les parties prenantes. Il peut s’agir d’une personne qui était jusqu’alors chef de projet, d’un architecte ou d’un ingénieur du projet, selon la manière dont les rôles sont définis dans l’organisation. Le rôle est toujours le même : dire le « quoi » et le « quand » du produit en cours de fabrication.
- Le Scrum Master facilite la communication et les interactions, supprime les obstacles que rencontre l’équipe de développement, s’assure que chacune des personnes impliquées comprend le processus, et que l’environnement permettra à chacun de réussir dans son travail. Cela ressemble à un travail de chef d’équipe, non ?
- L’équipe de développement est composée de sous-traitants, d’ingénieurs, d’architectes et de commerciaux.
Les sections suivantes de ce livre montrent comment Scrum peut être appliqué dans différentes industries ; vous pouvez constater que les rôles qui font l’efficacité de Scrum s’appliquent facilement à tout type de projet.
L’implication du client
Vous vous rappelez que le changement est traditionnellement mal vu dans les projets ? Comme vous le savez, dans Scrum, je recherche le changement, car c’est la preuve que je suis en train d’élaborer un meilleur produit, plus en ligne avec ce que mon client peut vouloir.
Dans les projets de construction traditionnels, vous trouvez une tendance (comme dans nombre d’autres domaines) à impliquer les clients le moins possible pour limiter les changements au minimum. C’est toujours cet état d’esprit comme quoi le changement, c’est mal. Toutefois, comme vous l’avez vu, plus le client est impliqué tôt et fréquemment, moins les changements sont coûteux et plus vous avez de chance de bâtir quelque chose que le client va apprécier.
À l’autre extrémité, il faut éviter l’extension incontrôlée du périmètre. Tandis que le client voit que les choses prennent forme, il veut toujours ajouter plus de fonctionnalités, ce qui étend le périmètre du projet, ce qui génère des coûts imprévus. Or, avec Scrum, nous souhaitons réduire les coûts, pas les accroître.
Comment Scrum prévient-il cela ? En restreignant le périmètre par le coût, et donc le temps, plutôt que par des discussions sans fin sur la bonne manière d’interpréter une exigence écrite. Le client peut formuler une nouvelle exigence alignée sur la déclaration visionnaire, mais toute exigence de ce type est compensée en disqualifiant une autre exigence moins prioritaire, à moins que cette exigence moins prioritaire ne soit financée par une rallonge budgétaire.
Scrum facilite le processus d’implication du client des manières suivantes :
- En structurant le retour de l’utilisateur aux étapes clés du projet, comme évaluer l’électricité ou la plomberie avant de poser les plaques de plâtre pour s’assurer que les fixations sont bien placées là où le client les attend. Cela permet de procéder aux ajustements requis avant qu’il ne soit trop tard. Le client inspecte le travail achevé au terme de chaque sprint et peut fournir un retour précieux.
- En permettant l’appropriation du projet, en prenant des décisions pilotées par le coût et le retour sur investissement lors de ces boucles de retour.
- En donnant aux demandes de changement du client une visibilité au long du projet, en montrant comment elles vont impacter le reste du planning et ce qu’il va en coûter au client.
À la fin, la transparence, l’évaluation et l’adaptation permettent une meilleure communication. Lorsque toutes les parties en présence disposent de l’information dont elles ont besoin, l’environnement pour prendre d’excellentes décisions est en place.
Le dilemme du sous-traitant
Depuis la construction des pyramides en Égypte, les chefs de projet et les sous-traitants rencontrent des difficultés pour se coordonner. Les problèmes surviennent encore trop fréquemment, et ils sont liés au cadre dans lequel ces deux parties collaborent.
« Les maîtres d’ouvrage et les sous-traitants dans les projets de construction traditionnels ont une telle propension à travailler pour leurs propres intérêts qu’il est presque impossible de les faire travailler ensemble », Journal of Construction Engineering, Volume 2013 (2013), Article 281236.
Les défis sont multiples. Traditionnellement, le processus du projet s’est avéré difficile à coordonner, car les sous-traitants sont nombreux, alors que les maîtres d’ouvrage ne le sont pas. Il en résulte un manque de coordination, de communication et donc d’appropriation, les parties cherchant chacune à tirer leur épingle du jeu plutôt que de contribuer au projet comme un seul homme. C’est la nature humaine.
Chaque sous-traitant est considérablement spécialisé, si bien qu’il faut beaucoup s’investir pour les coordonner entre eux, ainsi qu’avec les parties prenantes et les clients. Mais la méthode de la cascade ne permet pas de créer un tel environnement collaboratif. Scrum y parvient.
Voici quelques manières par lesquelles Scrum aide à faciliter la relation entre le maître d’ouvrage et le sous-traitant :
- Des évènements Scrum réguliers et structurés (Scrums quotidiens, revues de sprint, rétrospectives de sprint) améliorent la communication et favorisent un retour précieux pour toutes les parties.
- Les sprints et les livraisons sont fréquents, et leurs durées encadrées, chaque partie sachant exactement ce qui est attendu et quand c’est attendu à chaque étape.
- Les sous-traitants disposent d’une vision de la quantité de travail qu’ils peuvent accomplir durant un sprint (des données empiriques fondées sur ce qui a été accompli lors des sprints précédents dans des durées limitées). Les maîtres d’ouvrage peuvent donner leur avis sur les priorités, mais la décision finale revient à ceux qui font le travail.
- Les sous-traitants disposent non seulement d’une vision générale de leur rôle, mais ils sont de plus encouragés à partager leur connaissance et leur expérience pour rendre le processus plus efficient (les équipes auto-organisées élaborent toujours les meilleurs concepts).
- Les maîtres d’ouvrage obtiennent des informations de ceux qui font le travail – les sous-traitants.
- Les sous-traitants peuvent pointer les problèmes et les inefficiences tôt (lors des rétrospectives de sprint). Ce retour est essentiel pour lever les obstacles.
- Les questions d’achats sont plus facilement coordonnées, car tout le monde travaille de concert, conduisant des échanges de personne à personne.
- La qualité est améliorée grâce à une meilleure coordination.
- La livraison de matériau est plus facilement coordonnée (grâce à l’affinage du backlog du produit et la planification des sprints, dont la planification des exigences).
Ce qu’il faut retenir avant tout, c’est qu’un ensemble de rôles jusqu’alors dissociés sont dorénavant combinés au sein d’une équipe Scrum communicante et coordonnée. Avec Scrum, vous avez un organisme vivant. Chaque partie dépend des autres et se développe en symbiose.
Un sous-traitant peut mettre Scrum à profit pour s’organiser et organiser son travail, mais qu’en est-il de l’équipe projet en général, qui est composée de plusieurs sous-traitants ? Comment parvenez-vous à les faire travailler tous comme un seul homme ? Eh bien, il n’est peut-être pas réaliste de réunir toutes les équipes de sous-traitants dans une même pièce chaque jour, mais il devrait être possible de réunir ainsi leurs responsables pour coordonner les priorités du jour, identifier les obstacles, puis s’entraider pour les lever afin que le travail puisse continuer.
La sécurité du travailleur
Les enjeux de sécurité pour les travailleurs sont toujours importants, mais ils le sont devenus encore plus avec la multiplication des projets qui se déroulent dans des zones très fréquentées et très peuplées. Il convient donc plus que jamais de communiquer clairement sur les risques et les solutions. Des vies en dépendent.
Scrum contribue à la sécurité du travailleur des manières suivantes :
- Les règles en matière de sécurité sont plus exigeantes et pertinentes que jamais. Les intégrer à la définition de « terminé » signifie que des mesures de sécurité documentées et validées peuvent être mises en place, prêtes à être passées en revue en cas d’audit.
- Des rétrospectives de sprint fréquentes et régulières permettent aux travailleurs eux-mêmes de soulever des questions de sécurité et de trouver des solutions. Les bons Scrum Masters peuvent faciliter ce processus et s’assurer que les bons sujets sont évoqués.
- Des travailleurs expérimentés peuvent partager leur expérience pour élaborer des solutions qui aident tout le monde.
- Les Scrums quotidiens peuvent donner l’occasion de soulever des enjeux urgents.
Il est probable que tout cela ait déjà été fait de différentes manières. La transparence des enjeux de sécurité est la clé, ainsi que l’existence d’un mécanisme pour évaluer et mettre des actions en place pour s’adapter.
La construction d’un échangeur à Bangalore
Voici un exemple de processus Scrum en action dans le secteur de la construction. Le projet consistait à construire un échangeur routier à une intersection très fréquentée à Bangalore, en Inde. Des entreprises de high-tech avaient implanté des sites importants dans le secteur. L’histoire est basée sur un article de Scrum Alliance intitulé « Un exemple réel de livraison agile et progressive d’un projet d’infrastructure à Bangalore, en Inde » (juillet 2014).
Normalement, un projet d’échangeur routier de cette ampleur prendrait 18 mois. À cette occasion, des routes temporaires seraient construites sur les côtés, tandis que les deux échangeurs seraient bâtis simultanément. Naturellement, le trafic serait ralenti durant la construction, étant déporté sur les routes temporaires. Et aucun pont ne serait disponible avant la toute fin, lorsque les deux échangeurs seraient ouverts.
Toutefois, dans ce cas, le projet a été conduit avec Scrum, en procédant par étapes. Voici quelles ont été ces dernières :
- L’exigence prioritaire a été identifiée : un des côtés de l’échangeur pour la première livraison (produit minimal viable). C’est pourquoi une route temporaire a été construite en utilisant un des côtés de la route principale. Simultanément, la construction de l’échangeur du côté opposé de la route a commencé.
- Au terme de la construction du premier échangeur, ce dernier a été ouvert au trafic dans les deux directions, et la construction de l’échangeur opposé a commencé. Le trafic étant toujours retardé, mais ce délai avait été réduit, car un des échangeurs était entré en fonction. L’achèvement du premier échangeur a aussi créé un premier produit « livrable ». L’essaimage s’est concentré sur ce côté de l’échangeur uniquement.
- La même route temporaire a été utilisée durant la construction du second échangeur comme elle l’avait été lors de celle du premier. Du temps et de l’argent ont été économisés, car aucune nouvelle route n’a été construite. Peut-être qu’une seconde route temporaire aurait été planifiée si le projet avait été conçu en une fois, mais après avoir utilisé la première route temporaire, cette dernière a trouvé son usage durant la seconde phase. Évaluer et s’adapter permet d’éviter le gaspillage.
- Le second échangeur a été terminé, et les deux étant désormais ouverts, le trafic a été redirigé sur la route principale. La route temporaire a été fermée. Le second produit minimal viable était terminé, et l’objectif de la feuille de route était atteint.
Cela semble simple, non ? C’est Scrum. Voici quelques résultats :
- En procédant à cette livraison progressive d’un échangeur à la fois, le temps de construction a été réduit de 18 mois à 9 mois (un temps de mise sur le marché réduit de 50 %).
- La congestion du trafic existe toujours, mais elle a été réduite lorsque les échangeurs ont été mis en service.
- Une seule route temporaire a dû être construite.
- Aussitôt qu’un échangeur a été opérationnel, le risque d’échec a été réduit. Par exemple, que se serait-il passé si le financement avait été coupé de moitié en cours de route ? Comme un côté était fonctionnel, cela n’aurait pas été un désastre, alors que si les deux côtés de l’échangeur avaient été à moitié terminés, ils auraient été inutilisables. Les enjeux à plus haut risque ont été traités dès le début.
- L’efficience globale a été améliorée, car il a fallu moins de mouvements sur le chantier.
La construction d’une maison avec Scrum
Une maison peut être conçue, planifiée, estimée et construite avec Scrum. La première rencontre avec le constructeur a pour objet de découvrir le type de maison que vous recherchez (nombre de chambres, type de propriété et nombre de garages), la qualité des finitions et du plancher, le jardin, le montant que vous comptez approximativement investir, et votre fenêtre temporelle. Cela donne au constructeur un très bon niveau de connaissance de ce que vous recherchez (la vision et la feuille de route). Cela prend approximativement une heure.
Dans les semaines qui suivent cette première rencontre, les acheteurs rencontrent un architecte pour rentrer dans les détails des plans, comme la configuration des pièces, des sols, de la cave, le terrain, le parquet, l’ébénisterie. Des éléments de conception tels que les couleurs, les appliques et les fixations ne sont pas encore choisies. Il ne s’agit de décider que de ce qui est nécessaire pour évaluer le coût de la maison et fournir des plans masse et des facades. Ce sont les éléments les plus à risque qui sont les plus coûteux à modifier par la suite (le backlog du produit).
À partir de là, il est présumé que les choses les moins risquées changeront, si bien que les décisions les concernant sont repoussées jusqu’au dernier moment raisonnable. Toutefois, les risques potentiels sont évoqués, comme les surprises que creuser le sol pourrait révéler.
Le budget de chaque caractéristique, comme les meubles de rangement, est basé sur la description donnée par l’acheteur pour préciser ce qu’il attendait du constructeur au début. Dans les limites de ce budget, lorsqu’arrive le moment d’installer les meubles de rangement, l’acheteur détermine exactement ce qu’il souhaite. C’est là que les compromis peuvent être faits, ou la coordination de la couleur en regardant la maison bien réelle plutôt que des images dans une brochure consultée dans un bureau. Même si une certaine qualité de bois avait semblé parfaite durant la planification, l’acheteur peut changer d’idée et opter pour une option moins onéreuse et investir les économies dans autre chose, ou simplement réduire son investissement.
Scrum est une réalité dans la construction. Il y est de plus en plus utilisé et produit des résultats aussi impressionnants que dans d’autres industries, telles que celle du logiciel. C’est un exemple, mais d’autres existent. Essayez, et vous serez peut-être la nouvelle success story.
Last Planner
Last Planner est un système de planification utilisé dans la construction qui tire parti des pratiques de Scrum, et qui a été partiellement inspiré par des expériences « sur des sites bien gérés par des entreprises d’ingénierie et de construction respectables » qui ont mis en évidence que « seulement 54 % (une sur deux) des tâches planifiées pour la semaine suivante étaient réalisées la semaine suivante. »
La décentralisation des prises de décisions, les coûts réduits de constructions spéciales, et la découverte rapide des mauvaises nouvelles sont quelques aspects parmi d’autres qui permettent d’assurer une meilleure qualité à moindre coût, dans des délais plus serrés.
Last Planner s’oppose aux systèmes traditionnels push qui produisent généralement des aberrations comme lorsque ceux qui installent le plafond interviennent avant que l’électricité soit posée.
Cinq éléments sont au cœur de Last Planner :
Master Scheduling, qui consiste à planifier la feuille de route.- Pull Planning, qui consiste à identifier les dépendances et les obstacles, comme lors des Scrums quotidiens.
- Make Work Ready Planning, qui consiste à affiner le backlog du produit.
- Learning, qui englobe les revues et les rétrospectives de sprint.
La production manufacturière
Il est intéressant de constater que les frontières entre logiciel et matériel s’estompent. Ce sont encore des domaines différents, mais les produits physiques contiennent de nos jours une dose étonnante de logiciels. La voiture que vous conduisez, le réfrigérateur qui préserve vos légumes, la liseuse que vous utilisez pour lire un roman, tous ces objets sont pleins de programmes.
Selon un livre blanc d’IBM produit en 2012, la quantité de code dans une automobile a progressé de 400 % entre 2004 et 2010. Dix millions de lignes de codes aident maintenant à conduire un produit bien tangible qui s’appelle la voiture. Et IBM estime que le logiciel est à la base de 90 % des innovations dans l’automobile.
Cela signifie que le processus manufacturier doit faire face à de nouvelles demandes, car il ne s’agit plus seulement d’assembler deux pièces. Il faut entrelacer et intégrer des systèmes complexes, la plupart basés sur du logiciel. En fait, le logiciel est devenu critique pour le succès de nombre de produits manufacturés.
Tout cela signifie des projets de développement plus vastes et plus complexes, et l’incorporation d’équipes ayant des talents très divers. Cela signifie donc aussi plus de complexité dans l’incorporation de familles de produits (pas seulement les produits individuels), un risque accru de défauts tandis que la complexité s’accroît, et de nouveaux standards et réglementations auxquels il faut se plier.
Cela signifie Scrum.
Lean avec Toyota
Dans les années 1940, un constructeur automobile relativement inconnu nommé Toyota a élaboré un plan pour produire des voitures, tout en contrôlant étroitement ses coûts. Plutôt que de donner dans la procédure classique d’assemblage à la chaîne, qui génère des frais généraux gigantesques, l’entreprise a inventé le processus « juste à temps ».
Au lieu de produire tout en une fois, Toyota a choisi de ne produire que ce qui est requis pour le projet. Tout comme un supermarché remplace les articles qui n’ont pas été vendus, Toyota ne fabrique ou ne se procure que les pièces détachées dont il a besoin à l’instant donné. Pas de stock énorme, donc des coûts réduits.
Cela montre que Scrum puise une de ses racines dans la production manufacturière.
Le premier qui commercialise survit
L’une des clés pour gagner la course aux parts de marché, c’est d’être le plus rapide sur le marché. Ce n’est pas un nouveau paradigme du vingt et unième siècle. Toutefois, il est tout aussi important de conserver sa position et même d’être à la pointe de l’innovation – surtout quand l’innovation suscite les besoins et les désirs du client.
Les nouvelles technologies qui arrivent sont étonnantes : robotique, intelligence artificielle, impression 3D et nanotechnologie, pour n’en nommer que certaines. Dans chacun de ces domaines, la production atteint des nouveaux niveaux de complexité. Scrum et les cadres agiles sont idéaux dans de tels contextes.
Les nouvelles technologies permettent d’obtenir un retour plus rapidement. Par exemple, plutôt que de créer un nouveau moule onéreux pour fabriquer un prototype de pièce détachée, une impression 3D fera l’affaire pour une fraction du coût, en une fraction du temps.
Vous ne pouvez être le plus rapide sur le marché que si vous bouclez et rebouclez pour obtenir des retours utilisateurs, tout en développant les fonctionnalités prioritaires et les plus risquées. Tester précocement contribue à la qualité. Scrum permet ainsi de mettre sur le marché de meilleurs produits.
Maximiser la valeur pour l’actionnaire
Les bureaucraties hiérarchiques traditionnelles de l’industrie manufacturière mettent l’accent sur l’efficience, la réduction de coûts et la maximisation de la valeur pour l’actionnaire – plutôt que de créer de la valeur pour le client. C’est leur talon d’Achille. Les entreprises qui excellent sont celles qui cherchent d’abord la valeur pour le client.
Scrum et son cycle itératif mettent l’accent sur la valeur pour le client et la nécessité de valoriser son avis. Vous l’avez vu au fil des chapitres précédents. Après chaque sprint, vous disposez d’un produit fonctionnel « livrable » que vous pouvez montrer aux parties prenantes et aux clients.
Comme précisé dans les principes du Manifeste Agile, la première mesure du succès est un produit fonctionnel mis dans les mains du client au plus tôt et fréquemment. Scrum fait les deux.
La gestion stratégique de la capacité
Dans la fabrication de biens tangibles, il se peut que vous ne disposiez pas de la dernière pièce à assembler à la fin d’un sprint d’une semaine. Pas de problème. Souvenez-vous simplement que vos progrès doivent pouvoir être démontrés et que le cycle de retour doit être aussi bref que possible.
L’idée est d’obtenir un retour régulier et fréquent des utilisateurs finaux. Les spécificités dépendront de chaque produit. Gardez le cycle de retour aussi court que possible, et tâchez de le réduire chaque fois que vous en avez l’opportunité.
Intel
Intel a une longue histoire de gestion de projet en cascade du fait de son histoire manufacturière. Durant des années, cela a bien convenu à l’entreprise. Toutefois, elle ne peut elle aussi ignorer les réalités.
L’entreprise a décidé de tester Scrum la première fois sur « le travail de mise à disposition et de développement de l’infrastructure pré-silicium ». L’idée était que si Scrum fonctionnait ici, Intel pourrait le déployer dans d’autres domaines de l’entreprise et d’autres processus industriels.
Pour tester Scrum, et voir si ça pouvait correspondre à sa culture et à ses produits, Intel s’est offert les services d’un coach Scrum. Comme vous le savez, je suis un grand partisan du recours aux coaches Scrum lorsqu’il s’agit de faire la transition depuis la cascade. Il va vous aider à identifier et à remettre en question les vieilles habitudes, en intégrer de nouvelles, et généralement comprendre le cadre de Scrum correctement.
Toutefois, en dépit du coaching, la transition a soulevé des problèmes. Tous les managers seniors n’ont pas participé aux réunions Scrum, le soutien des personnes importantes a fait défaut, et les exemples qui auraient permis de démontrer le bon fonctionnement de Scrum n’ont pas été identifiés.
Pour finir, la lumière s’est faite au bout du tunnel. Qu’est-ce que l’entreprise a découvert ? La meilleure manière pour que ses équipes mettent en place Scrum et en tirent profit était d’appliquer Scrum à la lettre.
Pat Elwer, l’auteur d’une étude de cas intitulée « Les projets de développement agiles chez Intel : Une odyssée Scrum » a désigné les équipes Scrum polyvalentes comme « une force d’intervention sans situation de crise ! »
L’étude de cas rapporte que l’équipe a découvert que Scrum aidait les projets de quatre manières distinctes :
- Un temps de cycle réduit de 66 %.
- La performance est toujours au rendez-vous, tous les engagements étant respectés ou presque.
- Le moral des salariés est meilleur. Ironiquement, l’équipe dont le moral était au plus bas s’est avérée la plus performante.
- Une transparence accrue, qui a permet d’identifier des obstacles et des habitudes improductives.
Une fois que les équipes et le management ont adopté le processus, Scrum a fait les preuves de sa puissance.
Le développement de matériel
Comme dans la production manufacturière, il existe de nombreuses similitudes entre la mise en œuvre de Scrum dans le cadre de projets de logiciel et de matériel. Peut-être avez-vous entendu dire que les différences entre ces types de produits sont trop importantes ; Scrum ne pourrait s’appliquer aux deux. C’est faux. Je le répète, la base de Scrum, c’est que si vous pouvez encapsuler le travail à réaliser et le prioriser, vous pouvez utiliser Scrum pour votre plus grand bénéfice.
Un élément clé avec les projets de matériel et Scrum, c’est la focalisation sur le retour précoce et fréquent, comme pour les projets manufacturés. Vous ne pourrez peut-être pas trop travailler de cette manière au début, mais tâchez de vous y tenir malgré tout. Continuez de produire des incréments fonctionnels à la fin de chaque sprint, et l’ensemble de ce que vous pourrez montrer à vos clients et parties prenantes prendra de plus en plus d’importance… tout en tenant compte de leur retour.
Ce qui m’amène à mon autre point : le changement. Dans les projets de matériel, il est aussi inévitable. Vous serez mieux servi si vous l’acceptez, et que vous en faites un avantage. Le refus du changement ne vous mènera nulle part. Fort heureusement, le changement d’un projet de conception et de développement de matériel peut parfaitement être pris en charge dans le cadre de Scrum.
Identifier précocement les exigences à risque
Si vous pouvez trouver un moyen de découvrir les défauts et les problèmes précocement, cela vous économisera du temps, de l’argent et des difficultés. Avec la cascade, le test était repoussé en fin de projet. Maintenant que vous en avez beaucoup appris sur Scrum, je suis certain que vous réalisez à quel point c’est aberrant. Pourquoi ne tester qu’à la fin alors que vous pouvez tester tout au long et corriger les défauts plus tôt ?
Scrum contraint à intégrer plus étroitement le firmware et le logiciel. Scrum aide à dépasser les silos fonctionnels, faisant travailler les ingénieurs ensemble pour résoudre les problèmes, plutôt qu’ils se confrontent plus tard, lorsque les problèmes sont découverts.
Lors du Scrum quotidien, qui ne dure pas plus de 15 minutes, on peut procéder à un bilan coordonné de ce qui a été réalisé, de ce qui reste à faire et des obstacles. Une telle réunion doit se dérouler au sein des équipes, et entre elles lorsqu’elles dépendent les unes des autres.
Lorsqu’il s’agit d’adopter Scrum pour un projet dont le nombre de membres dépasse la dizaine, il est d’usage de diviser l’équipe en plus petites équipes, d’au plus 7 membres (à +/- 2 membres près). Chaque équipe Scrum tient son Scrum quotidien, puis des représentants de chaque équipe se réunissent pour un Scrum de coordination quotidien, désigné comme le Scrum des Scrums. Le format est le même qu’un Scrum quotidien d’équipe. Ainsi, la direction, les dépendances et les obstacles peuvent être identifiés de manière coordonnée et traités dans la journée. Reportez-vous au Chapitre 12 pour plus d’informations sur le Scrum des Scrums.
Le matériel open source est du pain béni pour l’ingénierie. Tandis que ce type de matériel se développe, les organisations qui en tirent parti peuvent plus rapidement concevoir des concepts et des architectures qui leur permettront de mettre leurs produits plus tôt sur le marché.
La réalité du développement de matériel
Dans les sections suivantes, je vais présenter trois exemples de mise en œuvre de Scrum réussie dans le cadre de différents projets. Chaque cas est unique, mais vous remarquerez que les principes et les pratiques de Scrum restent les mêmes. Pour l’essentiel, quel que soit le projet, Scrum peut être utilisé pour développer plus rapidement et plus facilement un matériel de plus grande qualité.
CubeSat de Johns Hopkins
Le laboratoire de physique appliquée de l’université John Hopkins a utilisé Scrum lors du projet Multi-Mission Bus Demonstrator (MMBD) consistant à construire deux satellites CubeSat. Le programme était sponsorisé par la NASA.
Trois éléments ont été identifiés comme essentiels au succès du projet :
- Les équipes Scrum : Elles étaient composées pour réaliser des sous-systèmes. Tous les membres d’une équipe étaient colocalisés et bénéficiaient d’un accès direct à un représentant de la NASA, le propriétaire du produit (qui était lui aussi sur site), pour prendre des décisions rapidement.
- L’accent sur un système fonctionnel : Seule une revue de conception a été financée, et des modèles conçus par ordinateur ont été utilisés pour simuler et manipuler les designs. Des revues informelles entre pairs ont aussi été conduites tout au long du projet. La documentation était minimale.
- Le changement était bienvenu et pris en compte : Des Scrums quotidiens se sont tenus pour la coordination et l’identification des meilleurs moyens de traiter les exigences prioritaires. La planification à long terme a été écartée pour faire face plus rapidement aux réalités.
Le véhicule modulaire de Wikispeed
Wikispeed est un projet bénévole de véhicule écologique. En formant des équipes auto-organisées utilisant Scrum, l’entreprise a construit un prototype fonctionnel pouvant parcourir 100 kilomètres avec 2,3 litres de carburant. Les équipes ont aussi gagné des courses régulièrement, car leur voiture est complètement modulaire. Ils peuvent changer des composants en fonction des caractéristiques de la course, de la piste et de la météo du jour. Leurs compétiteurs n’ont pas la même flexibilité. Joe Justice, qui a fondé Wikispeed en partenariat avec Scrum inc., a tiré quatre leçons exportables de l’expérience de Scrum, qu’il enseigne dans les entreprises qu’il coache désormais :
- Les clients, les clients et les clients : Les équipes ont reçu un retour régulier des utilisateurs finaux. Ils ont testé tout ce qu’ils pouvaient chaque semaine.
- Des sprints et des revues : Des cycles réguliers de sprints ont été conduits, avec des réunions à la fin pour faire le point sur ce qui s’était bien et mal passé.
- La transparence : Chacun connaissait les objectifs, et pouvait faire des suggestions.
- La communication entre pairs : L’auto-organisation : personne n’était le chef, tout le monde était égal et a contribué pour atteindre l’objectif du sprint quotidien.
Telefonica Digital
Telefonica Digital a commencé en fabriquant du matériel en se fondant sur une gestion de projet en cascade. L’entreprise a développé toujours plus de logiciels, au point que c’est devenu son activité essentielle vers le milieu des années 90. L’approche du développement de logiciel était d’abord aussi fondée sur la cascade, mais au fil des dix dernières années, Telefonica Digital a adopté totalement Scrum et l’agile.
Toutefois, les orientations technologiques et stratégiques de l’entreprise ont encore évolué, et elle est revenue à la production de matériel. De manière intéressante, comme elle avait acquis une expérience de Scrum au fil des années, elle n’a eu aucune envie de revenir à la gestion de projet traditionnelle, quoique le produit ait changé. Telefonica voulait rester avec Scrum. C’est pourquoi elle a appliqué Scrum à la gestion de ses projets de matériels.
Le premier enjeu a été de relocaliser toute la fabrication pour que les employés soient colocalisés. L’entreprise a compris la valeur de la proximité, et s’est donc arrangée pour l’assurer. Telefonica a aussi créé un système permettant de se procurer facilement l’équipement et le matériel le jour même où il en était besoin : juste à temps.
L’entreprise a utilisé des équipes Scrums et développé la polyvalence. Elle a testé précocement et fréquemment, allant même jusqu’à utiliser l’impression 3D pour prototyper des technologies et accélérer leur test. Cela a permis de progresser si vite que l’entreprise en est même arrivée à prendre de l’avance sur les équipes de logiciel.