Lors de la première partie de notre série de 3 articles, nous nous étions focalisés sur les risques liés à la phase de déploiement d’un framework d’agilité à l’échelle.
Dans cette deuxième partie, nous nous pencherons sur l’implication des parties prenantes, que ce soient les sponsors ou les acteurs de la transformation agile, en particulier afin de mettre en place un processus d’innovation qui nous semble indispensable.
Écueil #3 : L’innovation n’est pas une option
L’innovation est l’un des piliers de l’état d’esprit Agile (& Lean !). Elle peut même être un facteur différenciant pour tirer la meilleure performance d’un projet en méthode Agile.
Un point de vue est justement disponible sur le site de Mews Partners autour de la thématique « Agilité et innovation, du mythe à la réalité » :
- Agile et innovation, les amis ennemis
- Freins à l’innovation : les démystifier grâce à l’agile
- Comment franchir le pas et structurer l’innovation Agile ?
Il est malheureusement trop rare que l’on laisse la place adéquate à une démarche d’innovation, qu’elle soit structurée (IP Innovation dans le framework SAFe️) ou, à défaut, plus opportuniste et décousue.
L’exemple le plus flagrant, que nous avons rencontré maintes fois chez les industriels avec qui nous avons pu travailler, consiste tout simplement à ne pas mettre en place ces itérations d’innovation et de planning au nom de la sécurisation d’une roadmap sur laquelle l’équipe ou le management s’est engagé.
« Pourquoi perdre mon temps à travailler sur ces sujets qui sont accessoires par rapport à la valeur que je dois livrer à court terme sur mon projet ? »
Les articles ci-dessus peuvent remettre en lumière la vertu de cette démarche. De notre côté, concentrons-nous sur les recommandations que nous pouvons faire pour sécuriser cette démarche d’innovation.
Evidemment, le plus simple reste de mettre en place cette démarche structurée d’innovation lors de chaque PI (Planning Interval), en incluant systématiquement des itérations d’innovation. Cela assure un temps dédié aux équipes pour adresser ces sujets qui bien souvent leur tiendront à cœur, et leur donneront envie de se dépasser.
Cela nécessite selon nous trois prérequis :
- Une mise en condition pour que les équipes se sentent libres de faire émerger des idées innovantes, disruptives, et parfois même complètement en dehors du champ d’application de la MFT. La livraison du backlog et des engagements est la priorité pour les équipes, et cela peut générer une pression, qui doit être levée autant que possible lors de ces phases d’innovation. Il faut alors sacraliser un temps dédié, pris en compte dans l’estimation du backlog, que ce soit lors du PI Planning (agilité à l’échelle type SAFe), ou lors de l’itération planning (Agile Scrum).
- Un support spécifique, souvent externe, qui peut prendre la forme d’un « agitateur » d’idées : ce n’est pas trivial de faire de l’innovation, et les équipes n’ont parfois pas d’appétence avec cette notion. Il existe des méthodologies spécifiques afin de tirer le meilleur des équipes et de leurs compétences, telles que le Design Thinking, le Lean Startup ou l’Open Innovation.
- En faire un élément de reconnaissance pour l’équipe, voire pour l’individu. Cet élément, piégeux, peut rester relativement simple : s’assurer que l’équipe a l’occasion de présenter les sujets sur lesquelles elle a travaillé à minima à ses pairs, et idéalement à un panel de décideurs. Ils pourraient alors choisir d’investir du temps et des ressources sur les propositions les plus intéressantes. La mise en place d’un processus d’innovation, voire d’un évènement dédié de type “hackathon”, nécessite bien-sûr du temps et de l’expérience. C’est pourquoi une aide extérieure spécifique peut être nécessaire.
- Enfin, ce processus d’innovation doit prendre en compte l’intégration et le déploiement des initiatives retenues, afin que celles-ci ne restent pas lettre morte, ce qui serait un facteur démotivant pour les participants, et compromettrait le renouvellement de l’expérience.
Avouons tout de même qu’il parait plus simple d’avoir une démarche d’innovation globale dans une logique de développement software qu’hardware, tout simplement car les résultats sont souvent visibles instantanément et génèrent donc une valeur et une satisfaction immédiate. Toutefois, comme évoqué dans cet article, l’innovation peut prendre de nombreuses formes, et ne consiste pas nécessairement en une rupture technologique.
Écueil #4 : une implication insuffisante de ses clients (ou Business Owners)
Le framework SAFe n’est pas un écosystème évoluant en autarcie et hermétique aux interactions extérieures.
Il ne peut évoluer correctement sans l’apport des Epic & Business Owners (BO) qui sont les représentants des clients finaux, orientent la priorisation et jugent si le produit apporte la valeur attendue. Etant donné que leur responsabilité est en jeu, ils se doivent d’une part de participer activement aux échanges avec les équipes et les Agile Release Trains (ART) et d’autre part de prendre des décisions qui les engagent directement. Or, le manque voire l’absence d’implication des BO sont souvent des causes d’échec de développement d’un produit ou d’un service qui ne répondrait pas aux attentes.
Cela peut s’expliquer par le fait qu’ils sont initialement mal identifiés, avec le mauvais niveau de responsabilité, de connaissances ou d’investissements (financier comme technique). Il est donc primordial d’accorder une attention particulière à l’identification des BO, en se posant des questions comme :
- Qui est responsable in fine des résultats business ? Qui a la légitimité de parler au nom des clients finaux ?
- Qui peut donner l’orientation à un train (ART) pour développer une bonne solution ?
- Qui doit participer à l’élaboration de la feuille de route, à la planification des activités, à la résolution de problèmes ?
- Qui peut aider à coordonner les activités avec les autres départements ou organisations de l’entreprise dans une logique bout-en-bout ?
Les réponses à ces questions permettront d’affiner le choix des BO les plus pertinents pour la mise en place du framework. La multiplication des BO, représentant différents métiers et parfois différents intérêts, nécessite d’instaurer un mode de gestion pour recueillir leurs données d’entrée, échanger sur l’avancement, collecter leurs feedbacks. Cela peut se faire soit individuellement soit collectivement.
Notre conviction est de mettre en place une communauté de BO, en instaurant si possible un rituel d’échange entre eux. Cela permet de confronter les points de vue et les intérêts et de chercher une solution ou un compromis.
Une méthodologie de Voix du client peut être mise en place pour s’assurer de capter les besoins des clients. Elle permettra in fine un backlog refinement.
La gestion des ressources joue également un rôle primordial dans la bonne implémentation d’un modèle SAFe. Le framework est en effet très clair sur les différents rôles à avoir et leurs responsabilités associées permettant de couvrir tout le spectre de l’entreprise. Dans la méthodologie agile Scrum, il est par ailleurs recommandé d’avoir des équipes agiles fixes avec le bon nombre de ressources (5-12 personnes) et les bonnes compétences représentées pour livrer la valeur attendue.
Or on constate parfois, sous couvert d’allocation dynamique des ressources, que des équipes voient leurs effectifs varier au milieu d’un PI pour réaffecter des membres à d’autres équipes sur d’autres projets, mettant à risque la livraison sur laquelle les équipes s’étaient engagées au démarrage de l’incrément.
Nous constatons que ces changements radicaux de ressources sont souvent causés :
- Par des arbitrages financiers, laissant penser que la gestion budgétaire n’a pas été suffisante
- Par des constats de sous-performance, dus au sous-staffing, et qui sont compensés en ajoutant des ressources.
Dans tous les cas, des adaptations dimensionnantes des ressources en milieu de PI ne sont pas acceptables et vont à l’inverse des fondements de l’agilité.
Revenons alors aux bonnes pratiques Agile : une allocation dynamique des ressources n’est acceptable qu’en étant raisonnée et à fréquence limitée (tous les 2 PIs maximum).
Des deltas importants d’un PI à l’autre doivent résulter d’évènements exceptionnels, en particulier des changements de stratégie importants, mais rares, impliquant des croissances ou réductions de périmètre majeures.
La stabilité des équipes est primordiale sur des horizons temporels courts (~2 PI) : ce sont bien les activités qui doivent être allouées dynamiquement, et non l’inverse.
Lors des 2 premières parties de notre série de 3 articles, nous avons insisté sur les risques liés au déploiement du framework à l’échelle, ainsi qu’à l’implication des parties prenantes, qu’ils soient sponsors ou acteurs de la transformation Agile.
Dans la troisième et dernière partie, nous nous pencherons sur les risques liés à l’environnement, souvent non-agile, dans lequel cette transformation a lieu et en tirerons des recommandations.
Lire les autres articles
