Le retour du balancier

Les méthodologies associées à la culture agile célébreront bientôt leurs 20 ans, et depuis, le mot « Agilité » est sur toutes les lèvres. Cependant, l’adoption des pratiques agiles ne s’est pas faite de façon uniforme : alors que certaines entreprises ont tourné le dos à la livraison de projets en mode cascade (Waterfall ) pour intégrer à la lettre tous les préceptes de l’Agilité, comme le Scrum et la méthode kanban, d’autres ont eu plus de difficulté à effectuer ce virage. Mais qu’est-ce qui explique cette différence? Le contexte d’affaires? La nature des projets? La gestion du changement? Selon nous, plusieurs facteurs peuvent contribuer au succès mitigé de l’Agilité pure et dure. Nous vous en présentons un tour d’horizon ci-dessous.

Dans l’élan vers l’Agilité qui a marqué les dernières années, beaucoup d’entreprises ont oublié non seulement les fondements de la conception de systèmes d’information, mais aussi les étapes fondamentales à une saine réalisation de projets de transformation de processus et de développement.

En effet, au lieu d’encadrer la façon de concevoir les architectures des solutions à développer, l’Agilité peut nous pousser vers l’hypermalléabilité et l’hyperréactivité au contexte et nous amener à délaisser les paramètres structurants de la gestion et de la livraison de projets en TI, qui sont perçus comme étant trop rigides ou trop limitatifs.

En réponse à ces risques bien réels, nous préconisons une approche hybride : l’Agilité Structurée. L’idée n’est pas de mettre l’Agilité au rancart, bien au contraire! Il s’agit plutôt de revenir à l’essence des méthodologies agiles, qui, au départ, alliaient une saine flexibilité et une rigueur de gestion de projet (dans le cadre de l’échéancier, du budget et de la portée). Les années et les milliers de projets livrés nous ont démontré que rares étaient les entreprises qui étaient réellement prêtes à intégrer l’Agilité pure à leurs ambitions!

L’Agilité, pour qui?

Même si l’Agilité est encore louangée, cette pratique ne convient pas à tous les types de projets. Certains petits projets peuvent être parfaitement conçus en mode cascade, tandis que d’autres, de plus grande envergure, avec des besoins partiellement définis ou de nature évolutive, se verraient mieux exécutés en mode agile.

Certains types d’environnements conviennent mieux à des projets agiles. En effet, un budget relativement flexible, des équipes de développement dédiées et des échéanciers moins rigides constituent des composantes d’un environnement propice à l’Agilité.

Nos observations ont démontré que la plupart des entreprises de développement logiciel (nous n’avons qu’à penser aux logiciels à la demande, aux logiciels de gestion de la relation client, aux applications commerciales, etc.) ainsi que les corporations et les sociétés telles que les banques et organismes gouvernementaux se prêtent davantage à une culture agile. Outre les types d’environnements listés ci-dessous, on remarque qu’ils maîtrisent et hébergent à l’interne les ressources qui sauront mener à bien et livrer leurs projets de TI.

Waterfall

Projets ayant une portée (fonctionnalités, interface, etc.) bien définie, immuable et avec peu d’ambiguïté.

• Des budgets fixes

• Des échéanciers fixes

• Des fonctionnalités définies qui évolueront peu en cours de projet

Agile

Projets dont la portée reste à définir et prioriser, mais dont la livraison incrémentale augmente progressivement le rendement du capital investi (ROI).

• Des équipes de projets internes dédiées

• Un budget et les ressources requises pour réaliser des projets de longue haleine ou en continu (mises à jour, nouvelles fonctionnalités, maintenance)

• Des fonctionnalités qui évolueront en cours de projet

• Une bonne compréhension des méthodes agiles, MVP, MMP

• Un backlog de projet

• Des coûts prévisibles appuyés par un buffet fixe annuel dédié

N’oublions pas qu’en pratique, l’Agilité est un regroupement de valeurs et de principes d’entreprise et non une méthodologie. Une bonne solution pour ne pas avoir à repenser la culture d’entreprise en entier serait de confier les projets de TI à des partenaires technologiques qui pourront vous conseiller sur le mode optimal de livraison compte tenu de votre réalité. Plusieurs autres options peuvent aussi être envisagées, notamment opter pour une équipe agile temporairement logée au sein de l’entreprise, effectuer une externalisation complète du ou des projets dans un centre de développement agile, ou même employer un mode hybride qui combine les deux façons de faire.

Vers une Agilité Structurée

La grande flexibilité qu’octroie l’Agilité est sans doute l’un de ses avantages les plus importants. En effet, notre expérience nous prouve que conserver les pratiques agiles dans la réalisation des projets maximise l’efficience du développement ainsi que le retour sur investissement. Il n’en demeure pas moins que la plupart des projets de TI de la grande majorité des entreprises doivent respecter un budget et un échéancier, en plus de comprendre une série de fonctionnalités définies. L’absence de ce cadre structurant donne à l’initiateur du projet l’impression de perdre le contrôle, bien qu’en théorie, l’Agilité a justement été conçue pour en donner. Avez-vous déjà confié votre carte de crédit à l’initiateur du projet après lui avoir donné carte blanche, sans avoir une idée de ce vous recevrez en retour? Voilà à quoi ressemble l’absence d’un cadre structurant.

L’Agilité structurée se résume donc à conserver les pratiques de développement itératif découpées en sprints, autour desquelles la planification, la création, la validation et l’implantation auront lieu. La différence : l’ajout d’un cadre de gouvernance pour suivre rigoureusement le budget, l’échéancier et la portée. En d’autres mots, le Bureau de projets (PMO) conserve sa raison d’être, assure la gestion de l’ensemble du portefeuille de projets et assigne un gestionnaire de projet (PM) pour chacun d’entre eux. Le PM participe et soutient l’ensemble des parties prenantes afin de d’assurer une transparence et un suivi de la portée, de l’échéance et du budget.

Responsabilités principales du gestionnaire de projet

– Mise en application de l’entente contractuelle

– Gestion de la portée, du budget et de l’échéancier

– Mise en place du plan de communication

– Résolution d’obstacles identifiés en cours de projet

– Gestion des demandes de changement à la portée initiale et de la communication des risques

Avantages

– Une meilleure prise de conscience des enjeux par les clients, car ces derniers comprennent mieux la gestion nécessaire pour atteindre le résultat final

– Une prévisibilité (budget, échéancier, tâches à faire, rapports)

– Une ligne de communication directe et continue avec le client

– Des livraisons de produits fonctionnels et qui répondent aux attentes grâce aux sprints et démonstrations

Les conditions de succès

Dans un contexte d’Agilité Structurée, l’implication directe des clients est essentielle. Il est fréquent qu’un manque de connaissance des clients en matière de développement logiciel ou de culture agile implique un détachement pour ce qui est des détails du projet. Nous préconisons que le gestionnaire de produit (PO) soit un membre de l’équipe du client parce qu’il est le mieux placé pour maîtriser l’ensemble du contexte et les enjeux d’affaires. Il est même possible de suivre des formations pour apprendre comment exercer ce rôle, si besoin il y a.

Responsabilités d’un gestionnaire de produit (PO)

– Cérémonies propres à la culture agile : séances de démarrage, grooming, planification des sprints, planification des versions, revue des sprints de démonstration et rétrospective en compagnie des parties prenantes

– Priorisation des récits utilisateur et de la gestion du backlog

– Qualité des livrables et suivi de l’assurance qualité à la suite des tests d’acceptation de l’utilisateur

– Identification des changements apportés au projet

Finalement, avant de démarrer le projet, il est impératif d’établir une structure de gouvernance. Grâce à cette structure, non seulement le rôle de chacun est clairement défini, mais une liste de tous les livrables est créée. Cela permet de statuer à tout moment sur l’avancement et la santé du projet. Pour les projets externalisés, il faut déterminer la personne-ressource pour chacun des rôles, tant du côté du client que du côté du partenaire de TI.

Une confiance regagnée

Si les deux dernières décennies nous ont appris une chose, c’est bien que les méthodologies agiles n’avaient rien d’un feu de paille. Or, pour certains clients, l’adoption d’un mode de fonctionnement axé sur l’Agilité pure est loin d’être la meilleure option, et dans certains cas, l’Agilité peut entraîner une réactivité excessive aux changements. Voilà pourquoi il est judicieux de combiner les avantages de l’Agilité à des paramètres structurants qui assurent la bonne gouvernance d’un projet.

Pour veiller à la réussite de vos projets de TI, l’équipe de Logient a adopté une approche qu’elle a baptisée « l’Agilité Structurée ». Cette approche hybride remet l’accent sur vos besoins d’affaires et vous offre une meilleure visibilité sur l’avancement de vos projets. Elle vous permet de confier la gestion de vos mandats aux spécialistes d’un bureau de projet qui veilleront au respect du budget, de l’échéancier et de la portée, en plus de communiquer avec vous de façon proactive. Dans un tel contexte, les équipes de développement peuvent consacrer toute leur énergie et leur talent à la création des fonctionnalités.

En faisant affaire avec l’équipe chevronnée de Logient, vous pourrez compter sur un partenaire qui place les besoins et la participation des clients au cœur de son travail.

Communiquez avec nos spécialistes dès aujourd’hui !