Bien qu’initialement conçu pour les équipes de développement de logiciels ou d’application web, Scrum est maintenant devenu populaire dans de nombreux autres domaines, du marketing à la gestion de projet. Dans cet article, nous expliquerons les bases que chaque débutant Scrum doit savoir, y compris ce qu’est la méthodologie Scrum, et comment la mettre en œuvre pour exécuter et gérer vos projets.
Scrum est l'un des frameworks de la méthode Agile. Il a été utilisé à l'origine pour développer des logiciels de manière efficace et flexible en équipe. Il s'est déjà avéré très pratique dans le monde de l'informatique, mais le cadre Scrum est maintenant appliqué dans les départements commerciaux tels que le marketing, les ventes, les ressources humaines et les finances.
L'objectif de Scrum est d'optimiser la livraison de valeur. Maximiser la valeur pour le client est plus importante que de réaliser un plan préconçu. Il aide les clients et les utilisateurs finaux à fournir le produit le plus précieux dans les limites du temps et du budget.
Les avantages de la méthodologie Scrum comprennent :
Une équipe auto-organisée et stable constitue le cœur du cadre Scrum. Ensemble, l'équipe travaille sur un produit ou un service. Tout le monde participe à la planification, au repérage des obstacles et à la répartition des tâches. Scrum suppose que les connaissances nécessaires pour réaliser le produit de bout en bout sont présentes dans l'équipe elle-même.
Pour éviter toutes incompréhensions, il est utile de clarifier les termes Scrum et Agile, en les mettant l'un à côté de l'autre.
Agile est une mentalité, un ensemble, presque une philosophie. C'est un ensemble de valeurs et de principes cohérents. Ces valeurs et principes sont consignés dans le Manifeste Agile.
C'est une façon de penser et d'agir qui implique d'être capable de réagir rapidement, de travailler brièvement de manière cyclique, de livrer de manière itérative, de recevoir des commentaires, une amélioration continue, une collaboration, une interaction et de fournir la valeur et la qualité le plus élevé possibles pour les besoins client.
Agile est une philosophie basée, entre autres, sur la transparence, la maximisation de la valeur pour le client, un travail cyclique court et une amélioration continue. Cependant, Agile n'a pas de rôles, d'artefacts, d'événements ou de règles: c'est une ligne de pensée.
Agile n'est donc pas quelque chose que vous faites, mais quelque chose que vous êtes.
Pour devenir Agile en tant qu'organisation ou équipe, il existe différents cadres qui peuvent être appliqués. Des frameworks tels que Kanban, XP, Crystal, LeanStartup, et donc Scrum, s'intègrent également sous l'égide Agile.
Scrum n'est donc pas la même chose qu'Agile. C'est l'un des cadres par lequel cette philosophie peut être appliquée dans la pratique, en respectant les "méthodes agiles".
Le Scrum Guide vous en dit plus sur le sujet. En bref, il faut retenir que Scrum est une approche axée sur la valeur qui aide à fournir le produit le plus précieux pour le client et les utilisateurs finaux dans les contraintes de temps et de budget.
Le framework Scrum est basé sur le concept d'empirisme, une théorie d'après laquelle nos connaissances viennent de l'expérience. Pour le cadre Scrum, ce concept repose sur trois piliers qui permettent un contrôle empirique des processus :
Ce cycle se répète aussi souvent que nécessaire pour détecter les écarts, les découvertes inattendues et les opportunités potentielles qui émergent à mesure que le travail est effectué. Cela n'arrive pas une fois par an ou lorsque le projet est terminé, mais en continu sur une base quotidienne, hebdomadaire ou mensuelle.
Plutôt que de prendre des décisions basées sur des hypothèses sur les futurs potentiels, vous prenez plutôt des décisions sur les données que vous avez collectées jusqu'à présent. C'est de l'empirisme.
Dans la suite de cet article, vous découvrirez comment tout dans le cadre Scrum est conçu autour de ces piliers. Le fait de rendre transparent ce que vous faites, d'inspecter le résultat ensemble (comme le développement de l'équipe) et ajuster les choses si nécessaires pour vous améliorer continuellement. Le feedback est essentiel pour faire un bon produit !
Maintenant, que nous savons ce qu'est Scrum et pourquoi son cadre est bénéfique, examinons les différents composants de Scrum. Ceux-ci incluent les artefacts, les événements et les rôles Scrum.
Le premier pilier du contrôle empirique des processus est la transparence. Afin d'inspecter fréquemment l'avancement de votre travail sur un produit et de prendre des décisions qui s'avèrent nécessaires, nous avons besoin de quelque chose que nous pouvons inspecter. En rendant le travail sur un produit transparent, nous entendons le rendre disponible sous une forme qui permet aux personnes qui ont un intérêt dans le produit de le regarder, de valider les hypothèses avec lui et de générer de nouvelles idées à partir de celui-ci.
Le cadre Scrum exige des équipes qu'elles rendent au moins trois éléments de leur travail sur un produit transparent. Nous appelons ces « artefacts » dans Scrum, et ce sont les principaux vecteurs de collecte des données et des expériences dont nous avons besoin pour éclairer notre prise de décision sur l’avenir.
Le premier artefact est le Product Backlog. Il rend transparent tout le travail qui reste à faire pour le produit. Chaque idée, question, hypothèse, fonctionnalité, bug ou autre travail est représenté dans le Product Backlog comme un élément individuel. Certains seront très larges et peu clairs tandis que d'autres seront petits et spécifiques. Tous les articles sont commandés en fonction de leur pertinence par rapport aux ambitions du produit et des parties prenantes (le client). Au fur et à mesure que le travail sur le produit, est effectué, le Product Backlog change continuellement pour refléter les nouvelles perspectives et opportunités qui émergent pendant ce travail.
Un produit n'a qu'un seul Backlog de produit, quel que soit le nombre d'équipes qui y travaillent. Sinon, la transparence en souffre, car il n'y a pas de source de vérité unique sur le travail nécessaire et l'ordre dans lequel cela doit être fait.
Le deuxième artefact est le Sprint Backlog. Il s'agit de la sélection d'éléments qu'une équipe de développement tire du Product Backlog au début du Sprint et qu'elle juge nécessaires pour atteindre son objectif de Sprint. Le Sprint Backlog rend transparent tout le travail sur lequel une équipe de développement travaille ou va travailler dans le Sprint actuel. Chaque équipe Scrum a son propre Sprint Backlog, même lorsqu'elle travaille avec plusieurs équipes sur un seul produit.
Le Sprint Backlog n'est pas statique et change à mesure que les équipes en apprennent davantage au cours du Sprint. En étroite collaboration avec le Product Owner (chef de projet), les équipes de développement peuvent ajouter ou supprimer des éléments en fonction du temps restant dans le Sprint et de la pertinence ou de la nécessité de ces éléments par rapport à l'objectif de Sprint.
Le troisième artefact est l'Incrément. Il représente la collection de tous les éléments du Product Backlog - comme les nouvelles fonctionnalités, les corrections de bugs et autres ajustements - qu'une équipe a terminé au cours d'un sprint.
Le but de l'incrément est de valider les hypothèses sur le travail qui a été effectué à ce jour. Les personnes qui ont un intérêt dans le produit peuvent l'examiner et déterminer s'il répond à leurs besoins, s'ils comprennent comment il fonctionne, et s'il répond à leurs attentes. L'Incrément est un moteur de nouvelles idées, car avoir quelque chose de tangible avec lequel interagir est un excellent moyen pour les gens de voir de nouvelles possibilités.
L'incrément est le principal moyen par lequel vous pouvez exercer un contrôle de processus empirique pour des problèmes complexes. Chaque incrément commence par une intuition, une hypothèse ou une idée potentiellement précieuse de la façon dont le produit peut être rapproché de ses ambitions. C'est ce qui est capturé dans l'objectif de Sprint. Le travail nécessaire pour atteindre cet objectif est enregistré dans le Sprint Backlog.
Si plusieurs équipes Scrum travaillent sur un seul produit, elles s'assurent d'intégrer leur travail dans un seul incrément à chaque sprint.
Afin d'éclairer vos décisions sur la marche à suivre, vous devez fréquemment donner un sens au Backlog Produit, au Backlog Sprint et à l'Incrémentation avec tous ceux qui y ont un intérêt. C’est ce que signifie « l’inspection ». Cela prend de nombreuses formes.
Nous pouvons donner un sens au Product Backlog en l’examinant et en tirant des conclusions, comme :
Nous pouvons donner un sens à l’incrément en faisant appel à des utilisateurs et en validant nos hypothèses avec eux, comme :
Et nous pouvons donner un sens au Sprint Backlog en nous assurant qu'il est faisable et reflète notre plan pour le Sprint actuel. Quelle que soit sa forme, l'inspection offre la meilleure base de décision lorsqu'elle se fonde sur quelque chose de tangible et de concret. Dans le cas du développement de produit, l'inspection d'une fonctionnalité terminée et déployée est le meilleur moyen de valider véritablement vos hypothèses sur cette fonctionnalité et la façon dont elle est utilisée.
Le cadre Scrum propose que pour travailler de manière empirique, les équipes devraient avoir au moins cinq moments de répétition pour que l'inspection ait lieu. Chacun d'eux a un calendrier spécifique et offre une perspective spécifique sur le travail qui est effectué.
Découvrons maintenant les cinq événements Scrum.
Le premier événement est la timebox (une planification) du Sprint lui-même. Tout comme vous résolvez un puzzle complexe en commençant sur une zone plus petite, le but de chaque Sprint est d'essayer de résoudre une partie d'un problème complexe. Cette solution partielle est représentée par une version incrémentielle du produit. L'incrément, qui peut être inspecté ensemble pour décider de ce qui doit se passer ensuite. Cet incrément devrait au moins être dans un état où il peut être communiqué aux parties prenantes directement après le sprint.
Les sprints doivent toujours être de la même longueur pour créer une cadence et une prévisibilité pour l'équipe et ses parties prenantes. Lorsqu'un Sprint devient trop long, de précieuses opportunités sont perdues pour valider les hypothèses et s'assurer que le travail progresse toujours dans la bonne direction. Au fur et à mesure que la durée des sprints augmente, le risque de perdre du temps à construire les mauvaises choses augmente également.
Le Framework Scrum ne spécifie pas de durée pour les Sprints, sauf qu'ils doivent être inférieurs à un mois. C’est à l’équipe de décider à quelle vitesse elle peut et veut apprendre. De manière générale, les Sprints doivent être aussi courts que possibles tout en permettant à l'équipe de développement de fournir une nouvelle version significative du produit qui atteint l'objectif d'un Sprint.
Ainsi, alors que le Sprint est une opportunité limitée dans le temps pour explorer une partie particulière du problème complexe du développement d'un produit, les quatre autres événements Scrum représentent des opportunités spécifiques au sein du Sprint pour promouvoir l'inspection et l'adaptation.
Chaque Sprint dans Scrum commence par un moment où l'équipe Scrum établit un plan de base pour le prochain Sprint. Ceci est une réunion de planification. La première et la plus importante des questions, est de savoir quel sera l'objectif de ce Sprint. Sans objectif, il n'y a pas de but clair qui encourage les membres à s'unir et à se rassembler pendant le Sprint.
Un objectif pour un Sprint peut être de fournir un ensemble cohérent de fonctionnalités qui résout un problème particulier. Il peut s'agir de répondre à un besoin d'un groupe de parties prenantes. Il peut également s'agir d'une hypothèse ou d'une hypothèse critique qu'un Product Owner souhaite vérifier avec l'incrément qui sort du Sprint.
Bien que le Product Owner fasse bien d'entrer dans la planification de Sprint avec un objectif en tête, l'équipe Scrum travaille ensemble pour affiner cela en un objectif à la fois précieux et réalisable dans le délai d'un Sprint. L'équipe de développement travaille avec le Product Owner pour sélectionner le travail du Product Backlog qui doit avoir lieu dans le Sprint pour atteindre cet objectif, en réorganisant le Product Backlog si nécessaire. Cette sélection devient le Sprint Backlog. Parce que l'équipe de développement fait le travail réel, elle possède et a le dernier mot sur ce qui se passe dans le Sprint Backlog.
La planification du sprint se termine lorsqu'il y a un aperçu du sprint à venir et un plan plus détaillé pour les deux premiers jours. Ce plan est généralement capturé dans une décomposition du travail pour les premiers jours du Sprint. Au fur et à mesure que le Sprint progresse, l'équipe de développement traduit les grandes lignes - telles que définies par l'objectif de sprint et le backlog de sprint - en un plan plus concret sur la manière de travailler ensemble pour y parvenir.
Le Daily Meeting, aussi appelé la mêlée quotidienne, a lieu toutes les 24 heures pour permettre à l'équipe de développement de naviguer dans les complexités d'un seul Sprint. Ils inspectent les progrès de leur travail vers l'atteinte de l'objectif de Sprint, tel que rendu transparent grâce à leur Backlog Sprint, et effectuent des ajustements en conséquence.
Par exemple, ils peuvent rencontrer des problèmes inattendus qui nécessitent une collaboration étroite ou découvrir qu'ils doivent ajouter du travail au Sprint Backlog, ce qui est nécessaire pour atteindre l'objectif de Sprint. Ils peuvent se heurter à des problèmes qui les empêchent d'atteindre l'objectif de sprint et qui sont au-delà de leur capacité à résoudre.
Cette réunion quotidienne ne devrait pas durer plus de 15 minutes. C'est une occasion courte et minimale de coordonner la collaboration pour les prochaines 24 heures. Si plus de coordination est utile, les équipes de développement peuvent le faire tout au long de la journée. Le cadre Scrum ne prescrit pas comment faire un Daily Scrum efficacement, et les équipes de développement sont encouragées à trouver le meilleur moyen de faire fonctionner le Daily Scrum pour elles.
Le Sprint Review a lieu à la fin d'un sprint. Son but est d'inspecter le travail qui a été fait à ce jour et de décider quelles prochaines étapes ont du sens en fonction de ce qui en a été tiré. La Sprint Review est au moins un moment pendant le sprint où les personnes qui construisent le produit et les personnes qui y participent se réunissent pour inspecter les résultats du Sprint.
Les Sprint Reviews ne devraient pas prendre plus de 4 heures pour un Sprint d'un mois. Plus le Sprint est court, plus le Sprint Review a tendance à être court. Le résultat du Sprint Review consiste en des ajustements du Product Backlog en fonction de ce qui a été appris.
Cela peut inclure de nouvelles idées qui émergent lors des revues de sprint, des bugs découverts, des modifications d'éléments déjà sur le Product Backlog ou une nouvelle commande du backlog de produit lui-même. Dans un sens, le Sprint Review consiste à répondre à la question :
Sur la base de ce que nous avons appris ce Sprint, quelles sont les prochaines étapes ?
Cela fournit une contribution précieuse pour la planification de Sprint et les objectifs de Sprint potentiels pour les Sprints à venir.
Pour bien cerner ce que sont les Sprint Reviews, nous aimons rappeler que c'est une présentation de ce qui a été fait par l’équipe de développement. Cela ne veut pas dire une inspection d'une démo par exemple. En fait, inspecter l'incrément signifie l'essayer ensemble et donner des commentaires/feedbacks. Les Sprint Reviews ne sont pas la première fois qu'un Product Owner voit ce que l'équipe de développement a fait. Au lieu de cela, le Sprint Review est un moment important et répétitif où le Product Owner invite les parties prenantes à inspecter le produit ensemble.
La revue de Sprint, a lieu à la fin du sprint, généralement juste après la Sprint Review. Il est suivi par toute l'équipe Scrum. Son but est d'inspecter comment l'équipe Scrum a travaillé ensemble pour atteindre l'objectif de Sprint, et ce qui peut être amélioré lors du prochain Sprint.
Le Sprint Review est plus axé sur le produit et le contenu du travail effectué. La revue de Sprint vise à inspecter le processus de réalisation de ce travail. Pour les Sprints d'un mois, la revue de Sprint ne devrait pas prendre plus de 3 heures. Mais plus le Sprint est court, plus le délai a tendance à être court.
Sur la base de ce que l'équipe Scrum a appris de l'inspection de leur collaboration, ils peuvent décider de faire des ajustements pour travailler plus efficacement. Cela peut impliquer une mise à jour de la définition des tâches, la recherche de nouveaux outils ou technologies, une modification des accords de travail ou une composition d'équipe différente. Au moins une amélioration va directement au Sprint Backlog pour le prochain Sprint.
Pour accompagner la revue de Sprint, le projet peut-être illustré par un tableau couramment appelé "Burndown Chart".
Ce tableau montre l'effort total par rapport à la quantité de travail pour chaque itération. Le Burndown Chart est plus un graphique qu'un tableau, c'est un outil visuel à destination de l'équipe Scrum, qui sert tout au long du sprint pour voir où on en est par rapport à la charge de travail embarquée lors de la planification du sprint (Sprint Planning). Il permet de visualiser le travail restant pour l’équipe, et ce, tout au long d’un Sprint.
Afin de faciliter une collaboration sur un projet, et de réduire la complexité de la communication et de la prise de décision, le cadre Scrum se limite délibérément à trois 3 rôles : le Scrum Master, le Product Owner et l'équipe de développement.
Plutôt que des rôles au sens hiérarchique, où l'on a autorité sur les autres, chacun représente une perspective différente qui doit être incluse au minimum pour travailler empiriquement. Ensemble, les trois rôles sont suffisants pour travailler empiriquement dans n'importe quel environnement. Aucun autre rôle n'est nécessaire (et honnêtement, ils risquent de gêner).
Le Product Owner inclut la perspective de ce qui est précieux (et de ce qui ne l'est pas) en ce qui concerne les ambitions du produit. Alors que l'équipe Scrum passe son temps et son argent à travailler sur le produit, le Product Owner est là pour s'assurer que cet investissement rapportera de la valeur aux parties prenantes (pour le client).
Il est en collaboration avec les personnes concernées par le produit, ainsi qu’avec l’équipe de développement, pour décider de ce qui est précieux et de ce qui ne l’est pas. Le Product Owner ne dirige pas la rédaction des User Stories, il en est responsable, mais peut déléguer cette tâche à l'équipe Scrum. Pour rappel, une User Story est une description bien formée, courte et simple d'une exigence logicielle du point de vue d'un utilisateur final.
L'équipe de développement est le groupe de personnes qui est principalement responsable de fournir un nouvel incrément du produit à chaque Sprint qui atteint l'objectif de Sprint. Parce que le développement de produits est un travail complexe, même le futur proche d'un seul Sprint est difficile à prévoir.
Il est tout à fait probable que des défis et des problèmes surgissent qui entravent la capacité de l'équipe à fournir cet incrément. Il est également probable que de nouvelles idées apparaîtront pendant le Sprint sur ce qui devrait être inclus ou exclu de l'incrément selon l'objectif du Sprint. Effectivement, en cours de Sprint, ce qui va décider de l'inclusion ou l'exclusion d'une nouvelle User Story, se décide en fonction de son impact sur l'objectif du Sprint. Si elle va dans le sens d'atteindre cet objectif ou Sprint goal, on l’inclut, mais si elle met l'objectif du sprint en péril, on l'exclu.
Cette nature imprévisible, même d'un seul Sprint, a trois exigences importantes pour la façon dont les équipes de développement travaillent et s'organisent.
1- La première exigence est qu'ils travaillent dur pour minimiser leurs dépendances vis-à-vis d'autres personnes, services et compétences qui ne font pas partie de leur équipe mais qui sont souvent nécessaires pour fournir une augmentation effective. Chaque dépendance est quelque chose sur lequel ils ont un contrôle limité et peut les ralentir ou les bloquer complètement dans leur capacité à fournir un incrément effectué à chaque Sprint. Cela a un impact négatif sur leur capacité à travailler de manière empirique. Les dépendances peuvent être minimisées de différentes manières, de l'automatisation (par exemple pour le déploiement et les tests) à la formation de nouvelles compétences ou à l'inclusion de personnes possédant les compétences nécessaires dans l'équipe de développement.
2- La deuxième exigence est que l'équipe de développement réduise les difficultés dans la façon dont les compétences sont réparties au sein de leur équipe. Il vaut mieux avoir un seul testeur dans une équipe de développement que ne pas en avoir du tout. Mais si le testeur est embourbé dans le travail, toute l'équipe ralentira en conséquence. Il en va de même pour d'autres compétences, telles que le développement back-end, la conception et l'analyse. L'équipe travaille dur pour s'assurer qu'un ou plusieurs des autres membres de l'équipe sont capables de faire un type de travail particulier. L'objectif ici n'est pas que tout le monde soit également capable de faire ce travail. C'est évidemment irréaliste et irrespectueux par rapport aux compétences que les gens ont développées pendant des années. Mais de faire en sorte que d'autres puissent aider ou prendre le relais au besoin.
3- La troisième exigence est que l'équipe de développement doit souvent s'appuyer sur son intelligence et sa créativité pour surmonter les nombreuses choses inattendues qui ne manqueront pas de se produire pendant un Sprint. C'est pourquoi les équipes de développement devraient être autogérées dans la mesure où elles peuvent prendre des décisions sur la façon de travailler et ce qu'il faut améliorer dans la façon dont ce travail est effectué. Dans les équipes autogérées, il n’y a pas de boss désigné qui prend ces décisions pour l’équipe. Toutes les personnes qui font le travail, c'est-à-dire l'équipe de développement, travaillent ensemble pour prendre des décisions dans les limites du cadre Scrum.
Le Scrum Master inclut la perspective du contrôle de processus empirique et la qualité par laquelle la transparence, l'inspection et l'adaptation prennent forme dans et autour de l'équipe Scrum. Le Scrum Master est là pour donner vie aux éléments du Framework Scrum au sein de l'équipe et de l'organisation au sens large. Pour cela, les Scrum Masters adoptent un certain nombre de postures, en fonction de la situation dans laquelle ils se trouvent :
Les Scrum Masters sont des Leaders au service du collectif. Plutôt que d'attirer l'attention sur eux-mêmes, ils aident les autres à être aussi efficaces que possible. Ils montrent à l'équipe la voie à suivre, en leur disant quoi faire ou comment le faire. Il a le rôle de support, ou de servant leader. Le seul domaine dans lequel Scrum Masters devrait prendre une position forte est celui des décisions qui ont un impact négatif sur le processus empirique ou la sécurité dans l'équipe Scrum.
L'équipe de développement, auto-organisée et inter-fonctionnelle, possède toutes les compétences nécessaires pour livrer un Incrément de produit terminé potentiellement libérable à la fin de chaque Sprint». Les membres de l'équipe ne détiennent aucun titre et personne, y compris le Scrum Master, ne leur dit par exemple : comment transformer le backlog de produit en incréments de fonctionnalités potentiellement disponibles.
Ensemble, les trois rôles représentent une équipe Scrum. Ils ont toute autorité pour prendre toutes les décisions relatives à leur produit.
Le Product Owner décide comment utiliser le budget disponible pour maximiser la valeur pour les parties prenantes. L'équipe de développement décide comment construire ce produit et possède toutes les compétences nécessaires pour le faire. Et le Scrum Master garantit que cela est fait d'une manière qui maximise l'empirisme. Aucun autre rôle n'est nécessaire !
Il peut être tentant d'ajouter des rôles, des règles, des pratiques et une structure au cadre Scrum, car vous pensez que votre organisation est différente. Et bien que certaines situations puissent justifier cela, maintenir une forte concentration sur la simplicité des choses est vraiment la meilleure façon d'avancer dans des environnements complexes. C'est notre bon conseil !
Jusqu'à présent, nous avons couvert les mécanismes et les principes du cadre Scrum. Bien qu’ils fonctionnent à merveille pour permettre un contrôle empirique des processus, ils ne feraient pas beaucoup de différence s’il n’y avait pas de comportement qui le soutienne.
Il est difficile de travailler de manière empirique, surtout dans les organisations qui n'y sont pas habituées. Afin de donner aux équipes et à leurs parties prenantes quelque chose pour conduire ces décisions, le cadre Scrum met spécifiquement l'accent sur cinq valeurs directrices. Pour chaque décision prise, les équipes peuvent se demander comment leurs options impactent les cinq valeurs :
Apprendre à épouser ces valeurs dans le comportement quotidien est un parcours de toute une vie. Plus les équipes seront compétentes, plus la transparence, l'inspection et l'adaptation fréquentes seront efficaces. La bonne nouvelle est que le cadre Scrum fournit un excellent ensemble de limites pour apprendre et grandir en adoptant ces valeurs.
Pour conclure, Scrum est un cadre simple pour naviguer dans des problèmes complexes et adaptatifs. Il prescrit uniquement ce que les équipes doivent faire pour travailler de manière empirique, mais pas comment elles doivent le faire. Parce que chaque équipe, chaque produit et chaque organisation sont différents. Les équipes doivent trouver leur propre moyen de faire en sorte que cela fonctionne pour elles. Lorsqu'elles le font, elles peuvent réduire le risque d'un travail complexe, et commencer à offrir de la valeur à leurs parties prenantes plus tôt et devenir plus réactifs !
Une question, un doute, un retour d'expérience ou un simple "coucou", nous lisons et répondons à tous vos messages.
