[vc_row][vc_column][vc_column_text]
Transformation numérique/agile – Partie 2
Cet article complète celui du mois dernier : « La face cachée de la transformation numérique » qui laisse certains aspects fondamentaux dans l’ombre : la valeur, les nouveaux paradigmes (l’expérience client, l’agilité, et gestion par « produits » vs « projets ») et les nouveaux rôles dans l’organisation (ex. Responsable de produit – Product owner : PO), etc.
Cette deuxième partie essaie de donner des réponses à ces questions qui souvent passent sous le radar de la transformation.
Illustration : Xplore – une sonde en route pour la Lune
NDLR Ces notions sont transposables à d’autres métiers que ceux des TI. La transformation numérique/agile concerne tout le monde (notamment : la fabrication, la conception de produits, l’ingénierie) – pas le choix !
D’abord l’agilité : un remède miracle ?
L’agilité serait-elle la panacée à tous les maux de l’organisation ? À en croire certains, sa seule évocation permet pratiquement de tout régler. C’est comme dire que dans un monde agile, on a (presque) plus besoin de penser. Évidemment… il y a de l’exagération dans ces propos. Il faut savoir que même si notre exécution est devenue agile, on doit continuer de réfléchir en amont sur nos projets, leur finalité et les intentions réelles de l’organisation.
On a encore besoin d’évaluer les opportunités avec une vision globale, d’analyser des scénarios et d’évaluer des coûts. Dans leur état actuel, bien qu’on y travaille, on doit reconnaître que les modèles d’agilité à l’échelle semblent manquer de maturité au niveau stratégique pour répondre adéquatement aux exigences d’une gouvernance d’entreprise.
L’architecture continue d’avoir un rôle, comme l’analyse d’affaires ou la nécessité de gérer les projets. Comme pour les « produits », des adaptations sont requises pour en arriver au minimum viable. À cet effet, les grands joueurs des méthodes commencent à produire des documents « refondus » au mode agile (ex. TOGAF avec O-AAF).
Photo : Zimparfaites.com
Avec une meilleure maîtrise des pratiques agiles dans les organisations, de nouveaux défis émergents. Si les méthodes recommandent de former de petites équipes auto organisées qui travaillent en parallèle, rapidement et de façon agile – leur multiplication oblige à en revoir la gestion afin de conserver une vue d’ensemble du portefeuille des projets (ce qu’on appelle « à l’échelle » et qui n’est pas simple). Nos anciens repères sont mis à rude épreuve (reddition de comptes surtout basée sur le budget, les efforts, les délais). Dorénavant, on ajoute la notion de valeur aux résultats livrés. Ces petites équipes sont comme de mini-usines dont la cadence et le fonctionnement sont à synchroniser. Le travail de les coordonner ne doit pas en réduire l’efficacité. Pas si évident!
On s’interroge sur nos métiers : qui ferait un bon PO ? Qu’advient-il de nos chargés de projet ? (Absent dans les nouvelles approches de livraison). Que devient le bureau de projet ? Quel est le rôle de l’architecture et de l’analyse d’affaires ?
La transformation numérique impose une réflexion
Avec le passage du mode « projets » à « produits » et le virage agile des organisations, il faut clarifier et revoir les rôles des contributeurs : à commencer par celui des équipes.
Dans les modèles agiles, plutôt que de former des équipes ad hoc selon les projets, on cherche la stabilité (et l’efficience) en amenant les projets vers des équipes multidisciplinaires stables et dotées d’un noyau minimal à qui on peut ajouter d’autres compétences (ce peut être un scrum master, un architecte agile, un PO et l’équipe des développeurs). On reste matriciel et les gestionnaires assignent toujours les ressources.
Hausser les contributions directes à la création de valeur
En agilité on veut livrer de la valeur rapidement, à partir de pettes équipes et une gestion réduite. Ce qui mène inévitablement à revoir les structures d’encadrement. L’idée est d’augmenter le ratio des contributeurs directs à la création de valeur vs investir dans l’encadrement du processus. Au final, on aplanit les structures et l’effectif global requis.
Figure1 : Un modèle de livraison Agile
Des rôles disparaissent (chargé de projet, gestionnaire d’équipe) et d’autres sont requis (ex. scrum master, gestionnaire de produit, architecte agile).
Suivant ce modèle, certaines études, dont celle de Gartner, suggèrent que le taux de contribution directe des ressources à la création de valeurs augmente d’au moins 50 % (Gartner : « Build Support for Moving From Projects to Products and Agile », Bill Swanton, 2019). On observe aussi différentes zones d’interactions et de partage d’influence entre disciplines liées aux affaires et/ou aux TI.
Responsable de produit (PO) et Gestionnaire de produit (Product Manager – PM)
Votre organisation aura beau exécuter des projets en mode agile, il faut s’assurer que le résultat livré (ou services rendus) donne de la valeur à vos clients (on se souvient qu’elle n’est pas tant une quantité qu’une relation avec un besoin). Plus globalement, la mesure de l’agilité à l’échelle demande d’ajuster la perspective.
Au final, il faut créer des rôles qui couvrent autant les projets individuels (Product Owner – PO) et celui d’un ensemble de projets regroupés dans un portefeuille : c.-à-d. le rôle de gestionnaire de produit (Product Manager).
Responsable de produit (Product Owner ou PO)
La fonction de PO vise à régler la question de la l’arrimage du résultat livré aux besoins d’affaires. Quelqu’un doit s’occuper de garder l’alignement du contenu du projet avec sa finalité. À ce titre, il gère le backlog, c.-à-d. l’ensemble des fonctionnalités recherchées pour un produit. Le terrain de jeu est défini : la portée du projet (itération) peut varier, mais le budget et les délais sont fixes.
Qui devrait occuper la fonction de PO et de PM?
Figure 2 : bien choisir
Les bonnes pratiques s’accordent pour dire qu’ajouter au gestionnaire d’une ligne d’affaires la fonction de PO ou PM, n’est pas idéal. Ses obligations et contraintes font qu’il doit s’attarder à la capacité de faire, plus qu’à ce qui va en résulter.
En réalité, souvent le PO d’une ligne d’affaires en est issu. Le problème est que la personne tend à se limiter au projet à livrer, sans vision plus large et se concentre sur le backlog. Elle agit un peu à la manière des pilotes de systèmes qui raisonnent souvent en termes de contraintes vs d’innovation. Au point où on aurait tendance à leur préférer des candidats externes.
On recrute parfois d’anciens chargés de projet pour la fonction de PO. Bien sûr ces personnes sont habituées à livrer la marchandise et… ils veulent encore le faire. Ils ont tendance à se concentrer sur le respect des délais convenus. Loin d’être un défaut, cela peut parfois faire que la date l’emporte sur le besoin réel.
En fait, le poste doit être pourvu avec soins et exercé avec une vue horizontale des services de l’organisation. Minimalement, il faut connaître finement les besoins des clients et disposer d’un pouvoir de recommandation auprès de la gestion. Par haleurs, une même personne pourra superviser plusieurs produits.
Avec le nombre des produits, la complexité augmente. Pour gérer cet effet d’échelle (i. e coordonner plusieurs PO et assurer d’un alignement optimal des réalisations), il faut prévoir un rôle supplémentaire : celui de PM (ex. le modèle SAFe, comme DA annonce cette fonction). Comme pour les PO, il doit se concerter avec l’architecte agile. En passant, à des fins de planification, croyez-vous qu’il soit pertinent de prévoir qui pourrait occuper ces différentes fonctions ?
L’architecture dans un monde agile
Figure 3 : Le dilemme
Si c’était simple, tout le monde saurait quoi faire! En ces temps de ruptures, différents défis surgissent, dont ceux de devenir numérique et agile. Cette transformation implique notamment la conciliation de systèmes bâtis et utilisés depuis des décennies avec les exigences du modèle numérique – qui impose de nouvelles technologies et approches. Quelque chose qui ressemble à un carré dans un rond ?
Dans ce contexte, l’architecture est en mutation (certains architectes disent avoir perdu leurs repères). N’empêche, force est de constater que l’architecture d’entreprise classique semble en voie de disparition – où, à tout le moins, est remise en cause. Malgré cela, la nécessité de gérer et faire évoluer nos technologies ainsi que de répondre aux besoins des lignes d’affaires, demeure.
Plusieurs organisations tentent de livrer une architecture adaptée au nouveau contexte d’affaires agile à partir de pratiques… dépassées. Même les référentiels les plus robustes tentent d’évoluer (ex. TOGAF avec O – AAF [Open Group – Agile Architecture Framework], PMBOK avec la version 7 qui s’en vient…) et sortir du « tout ou rien », à partir d’approche de conception plus modulaire.
C’est une bonne nouvelle et il faut croire que ça va réussir. Cependant que l’arrimage aux fondements de l’architecture d’entreprise (ici illustrée selon TOGAF) reste pour l’instant assez nébuleux. On y reviendra certainement.
Figure 4 : Les fondements de l’architecture (TOGAF)
TOGAF : 4 volets et 2 segments (s’ajoute un volet global pour les éléments communs)
L’intention est aujourd’hui de définir, à l’instar des produits, une architecture minimale viable (AMV). En agilité, la livraison de la valeur passe par une adaptation rapide aux changements. L’architecture doit évoluer pour soutenir et orienter efficacement l’action vers ce résultat. Paradoxalement, sa simplification se traduit par la nécessité de se relier à d’autres disciplines, a priori, jugée sans liens directs: le marketing, les finances, l’ingénierie logicielle et d’autres… L’approche devient holistique et demande à ses praticiens d’évoluer vers de nouveaux paradigmes. Comme l’équivalent d’une fragmentation de l’architecture d’entreprise traditionnelle vers une architecture d’affaires et d’intégration.
Il faut dire que l’architecture d’affaires (réf. le BIZBOK) se situe surtout dans les chaînes et flux de valeur, l’étude des capacités et le modèle organisationnel. Le « comment technique » pour faire le lien entre les affaires et les technologies n’est pas son objectif. Sa perspective cherche à traduire l’intention d’affaires en solutions technologiques (le comment faire). C’est une direction très porteuse.
Pourquoi cette évolution ? Dans un monde agile les produits et systèmes évoluent de façon incrémentale et avec des cycles d’apprentissage courts. Plus une entreprise devient agile, plus son cycle d’apprentissage s’accélère. Conséquemment, ses délais de mise en marché (time to market) deviennent moins longs et la qualité s’améliore (on corrige le tir plus vite). Cette transformation s’appuie principalement sur deux vecteurs clés : l’expérience client et le passage du mode « projets » à « produits ». Qui sont, en passant, des incontournables!
Le métier de chargé de projet
Ces changements ont des effets sur les besoins en main d’œuvre. On s’en doute, la transformation numérique demande de planifier les profils requis pour livrer les solutions de demain. La question est: vos actuels champions (ceux qui ont façonné l’organisation), sont-ils toujours adaptés aux nouveaux besoins ? Je vous laisse deviner la réponse.
- Exemples : scientifique des données, architecte infonuagique, spécialiste DevOps, UX Designer, gestionnaire de produit, architecte agile, gestionnaire de portefeuille agile… Ces nouvelles compétences sont requises – dès maintenant, et en fonction de l’évolution de vos « produits ».
Chargé de projet
On sait qu’avec l’adoption des méthodes agiles, la fonction de chargé de projet est rarement définie. Les équipes sont auto- organisées et collectivement imputable des résultats. Néanmoins, quelqu’un doit faciliter le travail des équipes et bloquer les événements qui font diversion. Ce qui explique qu’on observe souvent la migration du chargé de projet vers celui de Scrum master (avec les attitudes nécessaires). D’autres possibilités existent, telles qu’illustrées ci-dessous. On prend également en compte que la gestion de projet demeure pertinente, ne serait-ce que pour l’imputabilité budgétaire.
Figure 5 : Parcours évolutif du chargé de projet
Adaptation d’une présentation Gartner : « Is the Project Manager Role Dead in Digital Delivery? », Kristin Mettraux, janvier 2020.
La profession va-t-elle disparaître ? NON… mais elle doit évoluer, quitte à porter un autre nom ou être bonifiée. Peu importe la méthode, on a encore besoin de bases en gestion de projet. Qu’est-ce qu’un délai, un budget une portée. Ajoutez à cela les notions agiles et vous aurez un profil des plus attrayant. Exemple : une pratique qui émerge veut que le chargé de projet coordonne le travail de plusieurs Scrum master ou devienne analyste ou architecte d’affaires.
Cela ne surprendra personne qu’un chargé de projet livrant un produit ait une compréhension satisfaisante de ce pour quoi il est prévu – ce qui relève de l’analyse d’affaires. Cette connaissance lui permettra de s’assurer que le projet reste aligné sur ses exigences. En outre, parmi les 10 habiletés requises en numérique, trois d’entre elles sont nouvelles : l’intelligence émotionnelle, l’attitude centrée client et un réseau professionnel bien garni. Pour durer, la pratique doit évoluer et devenir plus stratégique et agile- tel que le préconisé par le PMI.
L’effet d’échelle et les défis du bureau de projet 2.0
À l’échelle de l’organisation, avec le mode agile, les petites équipes autonomes se multiplient et travaillent parallèlement suivant des cycles de réalisation courts. Globalement, cela induit une complexité difficile à gérer pour bien des organisations. Nos bureaux de projets étant surtout centrés sur la reddition de compte financière et temporelle. Ils doivent s’adapter à la transformation.
Le nouveau modèle d’affaires agile pour l’organisation implique :
- l’adaptation à un modèle de fonctionnement décentralisé;
- la quantité et la fréquence des demandes qui arrivent augmentent;
- le passage du mode projet à produit;
- la vélocité accrue liée à la fluidité des modes de livraisons.
Pour le bureau de projet, le mode de fonctionnement adaptatif l’oblige à revoir ses façons de faire s’il veut obtenir un portrait d’ensemble de ses projets et identifier les problèmes de capacité. Réussir dans ce contexte implique un alignement stratégique avec la gestion (l’architecture a un rôle très clair d’arrimage entre les affaires et les TI). Les petites équipes s’alignent sur les mêmes priorités stratégiques. Ces priorités communes sont utilisées pour établir les carnets de commandes. À tire d’exemple, suivant l’approche SAFe, on vérifie aux trois mois, si l’ensemble est toujours aligné avec ce que l’on prévoyait (on ajuste au besoin).
Figure 6 : l’agilité à l’échelle (image Freepik)
Ce modèle vise la livraison de fonctionnalités viables avec le minimum de ressources (dont le temps). On réalise que la reddition de compte qui repose uniquement sur le triangle habituel (délais, budget, portée) est inadaptée à la façon de travailler. Nous sommes dans un monde où la portée peut varier et où le carnet de commandes peut être réajusté.
Pour le bureau de projet, différentes questions se posent : en mode « valeur », comment alimenter les équipes ? Comment faire « élire » les projets et gérer l’argent ? Dans l’approche SAFe, le financement est établi par groupe de livraison (souvent nommé « train ») et revue à chaque 10 semaines (cadence). Les délais et budgets sont fixes, tandis que la valeur est changeante. La planification repose sur un parcours « roadmap » qui inclut des cibles de date (ce sont des hypothèses).
Comment sont créés les projets qui découlent du « roadmap » ? En fait, cela résulte de la collaboration préalable de trois équipes : stratégique, exploitation et livraison. Ce sont eux qui génèrent ce que l’on nomme des ÉPICS et STORY qui composent le carnet de commandes. Vous souvenez-vous avoir entendu parler de ces rôles auparavant ? Probable qu’ils sont passés sous le radar?
En gros, le processus de planification pour un groupe de livraison se réalise comme suit : chacun des hauts dirigeants de lignes d’affaires arrive avec son « roadmap ». Cette liste est celle à partir de laquelle se déroule l’événement est appelé PI planning (Product Increment planning). On décide de ce que qui composera le backlog possible pour la prochaine livraison.
- Exemple : si on a une capacité de 15 trains de livraison – comment répartir le backlog ? Ensuite à chaque 10 semaines, on revalide le tout.
Processus budgétaire
En agilité, la sélection des projets repose l’utilisation de critères additionnels auxquels on accorde un poids relatif (ex. : Dette technique, Expérience client, Produit). Les projets sont choisis selon ces paramètres et en considérant les contraintes et opportunités. Le budget est alors établi sur la base de la répartition de sommes entre les différents trains de livraison.
Nouveaux rôles du bureau de projet ?
L’approche agile implique le recours à de nouvelles compétences pour faire le lien entre les équipes et la gestion de l’organisation. Voici quelques exemples :
- Piloter le flot : contenu des différents sprints, « roadmap » – Épics- valeur – Objectifs PI planning…)
- Fournir de l’expertise : comment faire un « roadmap », synchroniser les équipes, concevoir des Épics, collaborer et déterminer les bons indicateurs ?
Le bureau de projet devra s’adapter graduellement. Durant un certain temps, il naviguera dans l’ambiguïté pour rendre compte de la performance et des avancées. En parallèle, la notion de valeur s’établira. Il cherchera dès maintenant à bâtir son équipe autour des nouvelles compétences requises pour être prêt au moment opportun.
Responsabilité de gouvernance
On aura beau souhaiter prendre le virage numérique/agile, ce ne sera pas facile pour les dirigeants, car ils devront eux-mêmes acquérir des compétences en agilité et en comprendre ce qu’implique numérique. C’est le prix à payer pour devenir meilleur et réussir ce passage.
Conclusion
La transformation numérique/agile comporte différents enjeux souvent mal expliqués. Il faut s’y préparer adéquatement, car c’est complexe. Sans cela, on risque d’échouer. Comme pour tout projet, une transition doit être planifiée. Il faut la considérer comme une opportunité, plutôt qu’un problème. Le mieux est de former une petite équipe qui proposera un cheminement adapté aux capacités de votre organisation, tout en étant soutenu par la haute gestion. Quand on prend en compte les aspects moins connus de la transformation numérique/agile, on est mieux préparé pour la réussir. Bon voyage.
Présentation de l’auteur
Monsieur Marc Lafontaine PMP, PSM
Conseiller senior en architecture d’affaires, Alithya
Monsieur Lafontaine cumule plus de 30 années d’expérience en gestion des TI dans les secteurs public et privé. Son savoir-faire a été mis à profit à titre de chef de projet ou architecte d’affaires dans de nombreux dossiers technologiques d’envergure ou projets de transformation.
Actuellement, il exerce comme conseiller senior en architecture d’affaires au sein de l’équipe Alithya. Il est également administrateur au PMI Lévis-Québec depuis plusieurs années, conférencier et rédacteur de nombreux articles portant sur les domaines de la gestion de projet et l’analyse d’affaires.[/vc_column_text][/vc_column][/vc_row]