De plus en plus d’entreprises veulent “être agiles”, ou du moins utiliser la méthodologie agile pour gérer leurs projets informatiques, entendant de part et d’autre les bénéfices et l’efficacité que procure cette méthodologie. Mais pourquoi faut-il adopter l’agilité ?
Voici 6 raisons de gérer ses projets informatiques et digitaux en agilité, et de mettre de côté la méthode Cycle en V, car non, l’agilité, ce n’est pas que des post-it !
1-Évite l’effet tunnel et laisse place à l’adaptation
L’agilité repose sur un principe d’itérations (appelées “Sprint” selon la méthode Scrum). L’ensemble des itérations doivent en principe avoir une même durée de temps, définie à l’avance, et fixe. Au cours de ces itérations qui se suivent les unes après les autres dans le temps, une ou plusieurs fonctionnalités sont développées, testées et validées. Cela signifie donc que vous avez régulièrement, selon la durée de vos sprints (N.B. : il est conseillé une durée de 2 à 4 semaines pour les sprints), des évolutions qui s’ajoutent à votre produit final. De ce fait, vous concevez et avez une vision de votre produit final “pas à pas”.
Vous pouvez également faire des mises en production au fur et à mesure que votre produit se construit et le mettre rapidement entre les mains de vos utilisateurs finaux. Cela vous permettra d’avoir du feedback régulier, de prendre les décisions nécessaires pour adapter votre produit en conséquence, et ainsi maximiser sa valeur.
Vous n’avez donc pas à attendre la fin des développements pour tester l’ensemble de votre produit, comme cela est généralement le cas dans les projets en cycle en V. L’agilité et le processus d’itérations laissent ainsi place à l’adaptation et au changement.
En effet, le risque d’obtenir un produit livré qui ne correspond pas aux attentes est donc considérablement réduit dans la mesure où il est pris sur une durée d’un sprint (et donc sur quelques semaines), contrairement à plusieurs mois lors d’un cycle en V.
2-Un Métier davantage satisfait
Comprendre Métier au sens Client
La plus-value pour le Métier réside dans le fait qu’il peut tester et valider son produit au fur et à mesure, et le voit donc évoluer régulièrement. Il a l’assurance que ce qui se développe répond bien aux objectifs du besoin exprimé. Dans le cas contraire, il sera encore temps de faire des ajustements sur les itérations suivantes.
Lors de la revue de sprint, le Product Owner ainsi que l’Équipe de développement font une démonstration de ce qui a été développé au cours du sprint précédent. Suite à cette démonstration, le métier se projette davantage et peut directement définir l’objectif et les fonctionnalités du sprint suivant.
Par ce biais, cela évite de spécifier dès le départ l’intégralité des fonctionnalités attendues dans le produit. Il n’est donc plus forcé d’avoir une vision très claire et détaillée de ce qu’il souhaite. Au fur et à mesure que le produit évolue, le métier peut modifier et ajuster son besoin (dans la limite des ressources disponibles et de la faisabilité). De plus, un des piliers de l’agilité et surtout de la méthode Scrum est la transparence. Le Métier a accès aux outils de suivi utilisés par l’équipe agile et peut à tout moment connaître l’état d’avancement du projet.
Le Métier est complètement impliqué et embarqué dans le projet, il maîtrise mieux la trajectoire de son produit, ce qui lui procure une plus grande satisfaction finale.
3-Des livraisons de meilleure qualité
Avant chaque sprint, et également pendant le sprint, il faut s’assurer que l’ensemble des contributeurs au projet ont une compréhension commune, et parfaite, de l’objectif à réaliser pendant l’itération à venir. Plus particulièrement, il est important de démarrer le sprint en ayant l’assurance que les intervenants en charge de la réalisation du produit, à savoir les développeurs, les testeurs, l’équipe UX… (regroupés sous “l’équipe de développement”), ont une bonne compréhension des User Stories (US – fonctionnalités à développer, rédigées par le Product Owner) à réaliser au cours du sprint à venir. Pour cela, il est courant de faire des “revues d’US”, qui consistent à relire avec l’Équipe de développement les US à développer. Cela permet notamment de lever des doutes, de clarifier des incompréhensions, et de poser toutes les questions nécessaires à la bonne compréhension des US.
De plus, les différentes réunions proposées par l’agilité, comme par exemple le planning poker, le daily meeting (réservé à l’Équipe de développement), la revue de sprint… sont autant d’occasions pour évaluer des complexités, anticiper des obstacles, lever des risques, trouver des solutions, etc.
L’Équipe de développement a donc toutes les cartes en main pour développer et livrer un produit qui répond au besoin du métier.
4-Une cohésion d’équipe renforcée
La méthodologie agile favorise la communication entre les intervenants, en multipliant les points d’échanges et de partage d’informations à travers ses différents rituels : sprint planning, daily meeting, weekly meeting, revue de sprint, rétrospective de sprint, backlog grooming… Chacun ayant un objectif précis, certains permettent notamment de faire remonter les points négatifs comme positifs (en termes d’organisation par exemple), tout en étant dans un processus d’amélioration continue.
Un autre principe de l’agilité, et plus particulièrement de la méthode Scrum repose sur le fait que l’ensemble des membres de l’équipe et intervenants au projet doivent avoir le même niveau d’information. Il ne doit donc y avoir aucune rétention d’information par l’un des intervenants.
Chaque acteur ayant un rôle bien défini et compris par tous, est donc très impliqué tout au long du projet. Développeurs, testeurs, UX designers, UX researchers, UI designers… souvent mal et/ou peu intégrés dans les méthodologies plus classiques, se voient davantage impliqués et considérés tout au long du projet, témoignant un meilleur engagement des équipes, et une meilleure productivité, de part l’autonomie et la confiance dont ils bénéficient.
5-Un accroissement des connaissances techniques
D’une manière générale, lorsque l’on est au sein d’un projet IT, il est important d’avoir un panel de connaissances transverses aux différents métiers auxquels on est confrontés : connaissances techniques, connaissances UX, etc., notamment pour le Product Owner. Cela lui évite d’une part de ne pas comprendre les explications des développeurs, mais cela permet également d’effacer la barrière souvent trop présente entre les équipes fonctionnelles et les équipes techniques.
Le Product Owner, faisant le lien entre le métier et l’Équipe de développement, est donc davantage en relation avec les développeurs. Ceux-ci doivent d’ailleurs dès le début de l’itération, définir quelles US vont être réalisées en tenant compte des priorités, en leur attribuant des “points d’efforts” et donc en expliquant quels sont les points de complexité ou de facilité que les US peuvent avoir. A travers ces échanges, le PO comprend davantage les impacts techniques que peut avoir une demande Métier.
Le rôle du PO est, entre autres, de rédiger des user stories compréhensibles par les développeurs ET le métier (une bonne US doit être INVEST : Independant, Negotiable, Valuable, Estimable, Small, Testable). Cela implique donc au PO de garantir un langage commun compréhensible par ces deux parties, et de prendre en compte les 2 univers techniques et fonctionnels. Les séances de “revues d’US” mentionnées plus haut servent en effet à s’assurer que le besoin est compris par tous les contributeurs (développeur, UX, testeur, PO).
Le métier, lui aussi très impliqué dans le projet, est amené à comprendre davantage certains enjeux et contraintes techniques liés aux besoins exprimés. Ils seront donc plus à même de comprendre les raisons pour laquelle une fonctionnalité peut se révéler complexe à réaliser et consommatrice en ressources et en temps.
6-Une gestion des délais différente
La première chose à savoir est qu’en agilité, on ne parle pas de planning. S’appuyant sur le fait qu’il est impossible de prédire l’avenir ni de savoir exactement combien de temps un développement prendra, on se base donc sur des estimations, des hypothèses. On estime l’effort qu’il y aura à fournir.
Ces estimations sont faites en tenant compte des apprentissages qui ressortent des itérations précédentes, ou en comparant par exemple la fonctionnalité à développer avec une autre similaire, tout cela dans le but de rendre systématiquement les estimations meilleures. On se base sur des faits passés concrets (méthode empirique).
Ainsi, utiliser des estimations permet de ne pas s’engager sur une date fixée longtemps à l’avance, oubliant généralement qu’il y aura forcément des aléas, et surtout en espérant que tout se passe bien.
Il convient ensuite de suivre la progression du sprint et la progression du produit. A tout moment on doit être capable d’estimer le travail restant à fournir. Cela est généralement suivi à travers deux graphiques qui sont le Burndown Chart et le Burnup Chart.
Le Burndown Chart sert à suivre l’avancement des sprints et permet une visualisation sur une courte période. C’est l’Équipe de développement qui en est la responsable. Le Burnup Chart, quant à lui, sert à suivre l’avancement du produit et fournit donc une visualisation plus globale. Il est sous la responsabilité du PO.
De ce fait, il est possible à tout moment d’évaluer le travail fait du “reste à faire”, en le mettant en parallèle avec le périmètre du produit attendu et mesurer ainsi si les hypothèses faites au départ étaient bonnes ou pas.
En comparaison avec la méthode du cycle en V, les principes émis par l’agilité laissent plus de place à la remise en question, aux changements, et à la gestion des imprévus. En effet, la construction progressive du produit permet d’en avoir une vision concrète, dès le départ et au fur et à mesure des livraisons. L’ensemble de l’équipe projet, mais également les parties prenantes ont donc une meilleure maîtrise du projet et chaque acteur se voit impliqué à sa juste valeur, tout en respectant le périmètre de chacun, pour une meilleure satisfaction de l’équipe.
La mise en place de la méthodologie agile dans une entité demande du temps et doit faire l’objet d’un processus progressif. Il faut à la fois adapter l’agilité au contexte de l’entreprise et à son organisation, mais également adapter les équipes à cette méthodologie et les accompagner dans ce changement. La communication en amont et la consultation des intervenants restent donc primordiales.
Article rédigé par Aurelie Leconte, Product Owner chez Société Générale
Retrouvez-la sur Linkedin
Besoin d’agilité dans vos projets ?
Faites vous accompagner par les experts en product management de Devoteam Creative Tech. Les méthodes agiles n’ont pas de secrets pour eux
CONTACTEZ NOTRE PÔLE Product Management