Agile et TBM : optimiser l’activité informatique par la transformation

*Dean Leffingwell est le créateur du Scaled Agile Framework (SAFe) et cofondateur de Scaled Agile, Inc. Il travaille avec des entreprises qui font évoluer Agile de quelques équipes à des dizaines, voire des centaines d’équipes développant des systèmes et des solutions logicielles à grande échelle. 

Selon le mot juste d’un analyste IT : « Il y a peu, les entreprises s’essayaient à l’Agile et engageaient des dépenses de 5 à 10 millions de dollars américains dans des projets Agile. Du point de vue de l’investissement et de la gouvernance comparés, la façon dont les fonds étaient utilisés ou leur destination n’avait pas une grande incidence. C’était une expérience intéressante, et les résultats leur ont plu. Cependant, ils considèrent à présent des programmes qui demanderont un investissement de 50 à 100 millions de dollars américains ou supérieur et qui seront exécutés avec Agile. Cela change tout. »

Cette dimension capte l’attention du comité de direction, car les DSI et les directeurs financiers, en particulier, prennent conscience qu’ils ne peuvent plus négliger Agile : cette démarche est sur le point de s’imposer à la plupart des processus de l’entreprise. Faute d’adopter de nouveaux modèles financiers et de gouvernance sans tarder, ils risquent d’être dépassés.

Actuellement, les résultats commerciaux des entreprises qui ont déployé avec succès le développement Agile sont visibles à travers des publications plus fréquentes, des délais de commercialisation accélérés, une qualité accrue et une implication accrue des employés. La productivité peut augmenter considérablement, disons de 30 à 50 %, ce qui réduit généralement les délais de mise sur le marché de deux à trois fois, voire plus. La motivation des employés progresse car ils voient leur code être commercialisé plus vite et reçoivent des commentaires plus rapides de leurs utilisateurs.

En fait, Agile n’est pas une mode. C’est une évolution de grande ampleur qui est en train de transformer les entreprises – et le domaine de l’informatique – en l’améliorant.

Aujourd’hui, Agile nécessite un type d’engagement différent au sein de l’entreprise. Auparavant, l’équipe informatique pouvait dire : « OK, voici ce que vous avez demandé. » L’entreprise peut répondre à la livraison (un an plus tard) et dire : « Ce n’est pas tout à fait ce qui a été demandé. Par ailleurs, les besoins de l’entreprise ayant évolué, il nous faut quelque chose d’autre maintenant. »

L’informatique suivait traditionnellement une logique claire : collaborer avec les analystes métier, consigner les spécifications, réaliser l’étude de rentabilité, développer la solution, puis passer à la tâche suivante.

Cependant, la réalité est tout autre. Pour l’informatique, la réalité est la suivante : votre solution est pertinente seulement si vos responsables métiers le confirment. Que vous l’ayez conçu conformément aux spécifications n’y change rien. La seule chose qui compte, c’est que le responsable métier affirme que cela résout son problème et qu’il souhaite continuer à collaborer.

Place à Agile. Les personnes des secteurs d’activité qui bénéficient de ces applications doivent s’impliquer et rester impliquées dans le développement de la solution. Il n’est plus question de « rédiger le cahier des charges, payer et s’en aller ». Désormais, l’impact sur l’entreprise est significatif, mais le niveau d’engagement requis est également plus élevé. Il n’y a qu’une seule voie pour élaborer une solution : la collaboration.

Le modèle Agile à l’échelle implique directement le responsable métier dans les commentaires, la prise de décision éclairée, la priorisation continue du travail et tout ce qui est nécessaire pour garantir que le résultat corresponde au besoin actuel. Le transfert traditionnel a évolué. Le développement de solutions Agiles n’est ni une fonction cloisonnée ni une suite de spécifications. Ce n’est pas une analyse de rentabilité qui prouve le bien-fondé théoriquement. Il s’agit davantage de personnes collaborant tout au long du processus de développement.

Hélas, les modèles de financement classiques par projet ne sont pas adaptés à Agile. Ces projets génèrent un « travail ponctuel pour des employés ponctuels », et bien que ce soit une méthode commode pour structurer votre pensée concernant les nouvelles activités, elle ne soutient pas un flux de valeur constant.

Dans Agile, vous gérez le travail différemment. Il ne s’agit pas d’une tâche individuelle et de son temps d’exécution ; c’est au moyen de petits segments de valeur que vous désirez voir progresser dans le système en temps réel. On constate immédiatement l’impact lorsque quelqu’un explique que son entreprise est organisée par fonctions, qu’elle initie des projets et qu’elle évalue l’utilisation.

Le mantra Agile, c'est les produits, pas les projets. Cela marque un tournant majeur dans la façon dont l’entreprise aborde les investissements, les finances et le rendement, et cela implique des outils orientés sur la valeur plutôt que sur les tâches. Une part importante de ce qui prévaut aujourd’hui dans la comptabilité classique concernant le travail par projet – feuilles de présence, enregistrement et saisie – représente un obstacle majeur au flux de valeur.

La méthode Agile est axée sur la réponse au changement plutôt que sur le suivi d’un plan. Et cela requiert une transition vers des données objectives : commentaires rapides, indicateurs avancés et prévisibilité. Les équipes Agiles ont-elles accompli les tâches prévues dans un calendrier précis ? Si un responsable métier désire changer d’orientation, les équipes Agiles peuvent-elles s’ajuster ?

Dans l’ensemble, le modèle évolue du ROI vers un développement basé sur des hypothèses et un produit minimum viable (MVP). La notion théorique de ROI est aussi séduisante qu’un chiffre concret, mais le ROI n’est qu’une estimation du rendement potentiel si tout se déroule comme prévu. Et les choses se déroulent rarement comme prévu. Même lorsque cela se produit, les données ne sont accessibles qu’une fois qu’il est trop tard, car le ROI ne donne aucune indication pendant le développement.

Afin d’évaluer l’efficacité d'Agile, nous nous intéressons à des indicateurs préliminaires et à ce que l’on nomme des mesures de comptabilité de l’innovation. Nous déterminons les indicateurs d’une valeur positive, et ces indicateurs précèdent largement le ROI. En fin de compte, les systèmes doivent être conçus non seulement pour les coûts, mais aussi pour la valeur que reçoivent les utilisateurs.

La première discussion concernant l’investissement aborde l’hypothèse en premier lieu, puis la façon de la vérifier. Et, naturellement, quel est le coût pour arriver à cette première étape. Généralement, cela correspond à une petite partie de l’investissement total, car les équipes peuvent recevoir des commentaires sur le MVP dans un intervalle de temps prédéfini (comme quelques semaines ou mois). Pour finir, une discussion s’engage sur la question de maintenir l’investissement ou de se réorienter vers une autre voie.

L’avantage est que ce modèle allégé est largement immunisé contre les coûts irrécupérables. Dans le modèle traditionnel, si vous avez déjà engagé un investissement de 5 millions de dollars américains, il faut absolument qu’il soit fructueux. Les parties prenantes n’aiment pas parler de gaspillage ou d’expérimentation. Des mécanismes de protection peuvent se manifester, comme l’autorisation d’un investissement supplémentaire de 10 à 20 millions de dollars américains pour faire perdurer l’illusion, indépendamment de la valeur réelle.

L’entreprise Agile ne procède pas ainsi. Le financement progressif, les MVP, le fait de ne pas tenir compte des coûts déjà engagés et la prise de décisions fondées sur des mesures objectives issues de la comptabilité de l’innovation – c’est ainsi que l’entreprise Agile mène ses activités, une hypothèse après l’autre.

Avec le développement Agile, l’attente ne dure jamais des années. Lorsqu’on envisage un projet d’envergure, les éléments probants se révèlent au cours des six à douze premières semaines. Après quelques incréments de programme, les preuves indiqueront s’il faut poursuivre sur cette voie plus longue ou non.

Les indicateurs indirects et directs peuvent contribuer à mesurer la valeur des produits fournis par Agile. Indirectement, on peut évaluer la vélocité ou la quantité d’histoires ou de points d’histoire que les équipes sont en mesure d’accomplir sur une période donnée. Plutôt que d’analyser l’organigramme des tâches, vous pouvez évaluer comment des travaux similaires antérieurs ont utilisé cette capacité.

Il est important de rechercher d’abord la prévisibilité : avez-vous fourni la valeur sur laquelle vous vous étiez engagé dans les délais impartis ? Vous pouvez ensuite ajuster la question et entamer des conversations sur les raisons pour lesquelles cet objectif est beaucoup plus important que les autres. Vous pouvez aussi vérifier simplement un élément à l’aide d’un score NPS pour évaluer les résultats auprès des chefs d’entreprise. Quel est votre niveau de confiance ? Recommanderez-vous les équipes évaluées à d’autres ?

L’évolution du modèle en cascade vers l’Agile soulève des questions quant au traitement habituel des dépenses en capital (CapEx) et des dépenses d’exploitation (OpEx). Conformément aux règles du FASB, dès que la faisabilité est avérée et que la direction a donné son accord, la main-d’œuvre peut être capitalisée et amortie sur la durée d’utilité du projet, impactant ainsi les revenus.

Avec le modèle Waterfall, une fois les besoins et la conception définis et acceptés, on peut procéder à la capitalisation. Dans l’approche Agile, une telle étape de validation n’existe pas. La solution est développée progressivement, mais la capitalisation demeure envisageable.

Il reste de nombreuses tâches liées à l’innovation, à la recherche, à l’infrastructure et à diverses activités qui ne concernent pas directement l’ajout de fonctionnalités au système. Cela ne fait toujours pas l’objet d’une capitalisation. Cependant, dans Agile, il existe des « récits utilisateurs » qui mettent en œuvre de nouvelles fonctionnalités. Si vous avez un récit utilisateur pour une fonctionnalité telle qu’un nouveau système de connexion unique, la capitalisation est possible. Et il se pourrait même que vous n’ayez pas besoin de feuilles de présence pour cela. Or, la capitalisation exige une justification, une conversation qui doit se tenir.

Actuellement, l'agilité à l'échelle influence les parties prenantes responsables de la gouvernance et des investissements. Comme les services informatiques fonctionnent souvent avec une transparence des coûts réduite, l’image de la gestion financière de l’informatique peut être : « Voici notre important centre de coûts. Voici les dépenses, et au fur et à mesure, nous obtenons différents résultats commerciaux, et oui, il nous est très difficile de les mettre en relation avec l’investissement. Nous répartissons les coûts ailleurs. »

Dans le but de mettre en évidence la valeur qu’ils procurent, la transformation Agile demande aux responsables informatiques de savoir comment mesurer l’incidence financière et la valeur du développement continu, à quel moment capitaliser la main-d’œuvre et comment assurer la transparence des initiatives financées. Un niveau de transparence approprié est nécessaire pour déterminer si vous investissez dans les domaines pertinents et de manière adéquate au sein de l’IT. C’est là que les responsables informatiques utilisent la gestion des affaires technologiques (TBM).

Le TBM est une discipline qui optimise les résultats commerciaux en dotant les organisations d’une méthode uniforme pour traduire les investissements technologiques en valeur ajoutée pour l’entreprise. Le TBM définit les outils, les processus, les données et le personnel requis pour la gestion des activités technologiques. Il repose sur une taxonomie et un cadre TBM standardisés qui organisent les problèmes que les leaders technologiques et commerciaux cherchent à résoudre, y compris le financement de l'agilité à l'échelle.

Le TBM propose une taxonomie et des rapports standardisés, indépendamment des modèles Waterfall ou Agile. Ces fonctionnalités permettent aux entreprises de fournir une visibilité sur les indicateurs financiers pour le développement d’applications basé sur Agile et d’organiser les ressources et les résultats en activités propres aux flux de valeur. On obtient ainsi un alignement sur les résultats de l’entreprise et une croissance de la valeur commerciale.

Certaines des plus grandes entreprises au monde emploient quelque 10 000 informaticiens, et il arrive que 5 000 ou 6 000 d’entre eux soient affectés au développement d’applications, un poste de dépense important. S’agit-il d’un centre de coûts ou d’un centre d’investissement ? Tout dépend du point de vue, mais maîtriser le suivi du développement Agile est indispensable pour comprendre où va cet argent. Ce processus nécessite de prévoir la manière dont vous allez lancer, financer et évaluer les produits Agile.

Pour se positionner comme un partenaire à valeur ajoutée, il est essentiel de comprendre le flux de valeur autant que les dépenses en données et communication. Bien que ces préoccupations soient importantes, le débat s’oriente davantage sur la manière d’être compétitif face aux nouvelles solutions.

On comprend l’envie que tout soit prédictif, rattaché à un plan et corrélé aux budgets futurs, mais conjugué aux dépenses, cela s’avère restrictif.

En effet, vous voulez savoir à l’avance ce qui est inconnu et garantir le ROI sur cet inconnu, et ce n’est pas réaliste. Lorsque vous êtes en mesure de vous présenter au conseil d’administration et d’expliquer les investissements et les résultats actuels aux parties prenantes au lieu de vous engager sur des plans pluriannuels, vous avez toutes vos chances.

Ce qui est positif, c’est qu’Agile permet de remplacer ces suppositions sur le ROI par des faits concrets en temps réel. Au lieu de fonctionner avec des besoins définis sur deux ans, on détermine la première étape et on la livre. Immédiatement.

Le principal avantage d’Agile est la possibilité de prendre cette initiative considérable, de la scinder en éléments et de générer de la valeur presque immédiatement. L’inconvénient, mais aussi l’avantage, c’est que vous savez si vous êtes sur la bonne voie rapidement.

La rapidité de l’évolution technologique signifie qu’un plus grand nombre d’entreprises doit adopter les méthodologies Agile, comme le framework Agile à l’échelle (SAFe), afin de réagir promptement aux changements des modèles d’affaires, des marchés et de la technologie. De ce fait, il leur faut gérer leurs dépenses technologiques en hausse et obtenir une visibilité claire sur les coûts de l’informatique. Les entreprises ont la possibilité d’utiliser TBM et SAFe ensemble pour fournir davantage de valeur – avec une transparence accrue – et ainsi parvenir à une agilité métier supérieure et à un partenariat renforcé avec l’activité commerciale.