Le Manifeste Agile expliqué et comment l’appliquer
Le Manifeste Agile est un document qui définit des modes de travail favorisant l'adaptabilité, la réactivité et la flexibilité dans le développement logiciel.
Du moins, c'était son intention initiale. Aujourd'hui, les méthodes agiles se sont répandues bien au-delà du monde de la technologie et sont utilisées dans de nombreux autres secteurs.
Mais... qu'est-ce que cela signifie exactement ? Et comment un manifeste se traduit-il dans votre travail quotidien ? Explorons cela ensemble.
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Qu'est-ce que le Manifeste Agile ?
Le Manifeste Agile est une déclaration écrite qui comprend quatre valeurs et 12 principes destinés à améliorer les méthodes de travail dans le développement logiciel.
Plutôt philosophique que prescriptif, le Manifeste a été conçu pour être adaptable à une grande variété de tailles d'équipe, d'objectifs et de conditions.
Les 4 valeurs du Manifeste Agile
Le Manifeste Agile officiel se compose de ces 4 valeurs :
- Les individus et leurs interactions plutôt que les processus et les outils
- Des logiciels opérationnels plutôt qu'une documentation exhaustive
- La collaboration avec les clients plutôt que la négociation contractuelle
- L'adaptation au changement plutôt que le suivi d’un plan
Il est intéressant de noter que les auteurs ont complété les valeurs par cette précision : « C’est-à-dire qu’il y a de la valeur dans les éléments de droite, mais nous valorisons ceux de gauche davantage. »
Cela souligne que le Manifeste Agile ne prône pas le suivi d’un certain processus ou l'utilisation d’un outil agile particulier. Il s’agit d’adopter un état d’esprit spécifique.
Les 12 principes du Manifeste Agile
En plus des quatre valeurs, le Manifeste Agile énumère 12 principes qui expliquent comment interpréter et appliquer ces valeurs dans des projets agiles.
1. Mettre le client au centre
La priorité absolue est de satisfaire le client grâce à la livraison précoce et continue de logiciels à forte valeur ajoutée.
2. Accueillir le changement
Accueillez favorablement les changements de besoins, même tard dans le développement. Les processus agiles exploitent le changement au bénéfice compétitif du client.
3. Livrer fréquemment
Livrez fréquemment des logiciels fonctionnels, toutes les quelques semaines à quelques mois, en privilégiant les cycles les plus courts.
4. Collaborer entre équipes
Les responsables métier et les développeurs doivent travailler ensemble chaque jour tout au long du projet.
5. Cultiver les talents
Constituez vos projets autour de personnes motivées. Donnez-leur l'environnement et le soutien nécessaires, et faites-leur confiance pour mener la tâche à bien.
6. Communiquer
Le moyen le plus efficace et efficient de transmettre de l’information à une équipe de développement et en son sein est la conversation en face à face.
7. Mesurer l'essentiel
Le principal indicateur d’avancement est le fonctionnement effectif du logiciel.
8. Maintenir un rythme soutenable
Les processus agiles favorisent un développement durable. Les commanditaires, développeurs et utilisateurs doivent pouvoir maintenir un rythme constant indéfiniment.
9. Miser sur la qualité pour aller plus vite
Un souci constant de l’excellence technique et d’un bon design accroît l’agilité.
10. Privilégier la simplicité
La simplicité – l’art de maximiser la quantité de travail non fait – est essentielle.
11. Ne pas microgérer
Les meilleures architectures, exigences et conceptions émanent d’équipes auto-organisées.
12. Réfléchir et s’ajuster
À intervalles réguliers, l’équipe réfléchit à la manière de devenir plus efficace, puis ajuste et adapte son comportement en conséquence.
Histoire, auteurs et origine du Manifeste Agile
Dans le monde de la tech, le Manifeste Agile est abordé avec la même révérence — et parfois irrévérence — que tout texte sacré transmis au fil du temps.
En février 2001, 17 professionnels du logiciel se sont réunis dans l’État de l’Utah aux États-Unis, se surnommant eux-mêmes « The Agile Alliance », pour élaborer ce qu’ils ont appelé un « Manifeste pour le développement logiciel agile ». Ce document, qui met en avant quatre valeurs et douze principes, est aujourd’hui connu sous le nom de Manifeste Agile.
Les auteurs du Manifeste Agile sont souvent désignés comme l’Agile Alliance et représentaient divers processus de développement, y compris l’Extreme Programming, Scrum et Crystal.
Un rapide coup d’œil au site officiel du manifeste montre les auteurs dans une ambiance qui rappelle une société secrète ou une réunion de pères fondateurs. Leur intention était clairement de créer quelque chose qui aurait un impact durable sur l’industrie. Et ils y sont parvenus.
Bien que les personnes réunies dans l’Utah n’aient pas été les pionniers des principes agiles au sens large, elles ont néanmoins formalisé des valeurs qui germaient depuis un certain temps en arrière-plan dans le monde du développement logiciel.
Aujourd’hui, la méthodologie agile a imprégné presque tous les secteurs.
Les auteurs incluaient :
- Kent Beck
- Mike Beedle
- Arie van Bennekum
- Alistair Cockburn
- Ward Cunningham
- Martin Fowler
- James Grenning
- Jim Highsmith
- Andrew Hunt
- Ron Jeffries
- Jon Kern
- Brian Marick
- Robert C. Martin
- Steve Mellor
- Ken Schwaber
- Jeff Sutherland
- Dave Thomas
Pourquoi le Manifeste Agile est (toujours) important
Le Manifeste Agile reste pertinent grâce à sa focalisation sur des modes de travail centrés sur l’humain et sa souplesse.
Avec les évolutions technologiques rapides, les exigences des projets changent fréquemment. Le Manifeste Agile permet aux responsables de projets de donner la priorité à l’adaptabilité et à la collaboration, en créant un environnement de projet réactif et résilient, capable à la fois de produire, d’innover, et de s’adapter au besoin.
Il encourage également un état d’esprit centré sur le client, en valorisant les solutions fonctionnelles plutôt qu’une documentation exhaustive. Cela permet aux chefs de projet d’obtenir des retours rapidement et de perfectionner continuellement leur travail, garantissant que le projet reste aligné avec les besoins des utilisateurs. Cette approche itérative et orientée client augmente le taux de réussite des projets ainsi que la satisfaction.
Comment appliquer le Manifeste Agile
Plongeons un peu plus dans chacune des quatre valeurs du manifeste agile. En passant en revue ces valeurs fondamentales, nous explorerons aussi les 12 principes qui les sous-tendent.
Valeur n°1 : Les individus et leurs interactions plutôt que les processus et les outils
Le cœur de l’agile, c’est l’humain. Agile met l’accent sur le travail en équipe, la collaboration rapprochée et l’autonomie dans la prise de décision. Agile ne consiste pas à dire à une équipe quoi faire ou quoi construire.
Dans les projets agiles, la communication doit être fluide et continue, non pas définie ni planifiée à l’avance. Travailler en silos cloisonnés ne correspond pas à l’esprit agile.
Évaluer la communication de l’équipe
Demandez-vous : vous et votre équipe, avez-vous des conversations en face à face ? Ou bien vous reposez-vous sur des emails, des documents et certains outils de messagerie tant appréciés (sans citer de noms ici) ?
Même en télétravail, une discussion en face à face peut accélérer les choses. Surtout lors de la formation d’une nouvelle équipe, la communication synchrone favorise la confiance, l’ouverture et aide à construire des relations.
Soyez moins contrôlant
Nous en avons tous déjà fait trop à ce niveau, parfois. Mais, la confiance est essentielle à l’agile. Vous cherchez quelque chose à mettre en place dès maintenant ? NE FAITES PAS DE MICROMANAGEMENT (oui, je l’écris en majuscules exprès).
Il est tentant de vouloir tout détailler, d’attribuer minutieusement les tâches à l’équipe, puis de les suivre jusqu’à l’échéance imposée (ou non), dans le but de tout contrôler. Mais pour vraiment responsabiliser votre équipe, vous devez lâcher un peu prise et lui laisser la pleine possession de son travail !
Encouragez une équipe auto-organisée
Il ne s’agit pas de gérer, mais de guider et de faciliter. Une équipe auto-organisée est une équipe qui choisit elle-même la meilleure manière d’accomplir son travail. C’est à elle de décider comment transformer le carnet de commandes en code prêt à être livré. Mais attention à ne pas tomber dans l'excès inverse en n’offrant aucune aide ou orientation : l’équipe a toujours besoin d’une vision, de motivation et d’assistance pour lever les obstacles.
Dans ce cas, comment passer du simple fait de distribuer les tâches à la recherche de la meilleure façon de faciliter le travail ?
Ne vous inquiétez pas trop du processus ou de l’outil
Je sais, je sais — on parle constamment d’outils de gestion de projet et de logiciels de gestion de projet agile dans le monde du management agile.
Mais voilà : votre client se fiche de votre processus de travail agile interne. Et il ne devrait pas s’y intéresser.
L’agilité consiste à adopter une approche centrée sur le client et à permettre à votre équipe de fournir un travail de meilleure qualité et avec plus de valeur. Nous reviendrons plus loin sur cette approche orientée client !
Brisez les silos
Les silos freinent la collaboration et vont donc à l’encontre des valeurs de l’agilité.
Pour sortir des silos, voici quelques conseils :
- Colocalisez l’équipe : Oui, encore celui-là. C’est super si vos designers peuvent s’asseoir côte à côte et discuter design, mais n’est-ce pas encore mieux s’ils discutent avec les développeurs de la création de ce superbe produit ? Je sais que cela peut être difficile à mettre en place dans une grande organisation ou à distance, mais se retrouver sur un canal Slack partagé, ou organiser des séances de coworking synchrone où chacun peut se concentrer ensemble, même à distance, permet de garder l’équipe connectée.
- Découragez les transferts entre départements : Le mode de fonctionnement cloisonné, façon cascade, où chaque département travaille par étapes (UX, puis design, puis développement, puis QA), mène souvent à des erreurs de communication et accroît le gaspillage sur le projet. Essayez de faire travailler votre équipe ensemble sur les fonctionnalités plutôt que de passer le relais en chaîne. Même si vous travaillez en sprints mais avec un sprint design en amont, impliquez les développeurs dès le sprint design : ce sont eux qui vont réaliser, après tout !
Valeur n°2 : Un logiciel fonctionnel plutôt qu’une documentation exhaustive
Sachez que le manifeste ne dit pas de supprimer toute documentation — il s’agit simplement d’accorder plus de valeur aux éléments de gauche qu’à ceux de droite. Cela signifie que la documentation reste nécessaire. Par exemple, Scrum utilise les user stories pour permettre au développeur de démarrer la construction.
Mais comment réduire la documentation lourde et chronophage pour rapidement aller vers du concret ?
Rendez votre documentation plus efficace
Identifiez les points de blocage ou de friction dans votre processus. Êtes-vous trop focalisés sur la documentation ? Passez-vous un temps fou à rédiger l’exigence parfaite, à élaborer des scopes fonctionnels interminables, et vous manque-t-il ensuite de temps pour construire le produit ? Diminuez la documentation inutile en :
- Vous concentrant sur les tâches de conception et de développement qui enrichiront le produit lui-même, plutôt que sur un document écrit qui ne sera finalement pas utilisé
- En organisant, dès le départ, des ateliers pour définir les exigences et les étapes suivantes au lieu de rédiger des documents interminables. Documentez et partagez les résultats sous forme de photos et de brèves notes.
Passez rapidement à la construction
Rédiger des tonnes de documentation sur les besoins permet de cartographier les attentes de l’entreprise, du client et de l’utilisateur. Mais voir quelque chose qui fonctionne, réagit, évolue, c’est bien plus utile au final.
Pensez à ces quelques techniques pour accélérer la progression de votre projet :
- Réduisez la phase de découverte ou de définition : Limiter le temps consacré à la définition permet à l’équipe de disposer rapidement d’éléments à traiter pour les designers et développeurs. Vous pouvez accélérer en utilisant ces questions pour les ateliers de découverte.
- Organisez des ateliers : Réunir les parties prenantes en atelier permet de prendre des décisions plus vite.
- Modifiez votre plan de projet : Avez-vous programmé d’abord la définition, puis le design, puis le développement ? Songez à avancer le développement et à faire travailler designers et développeurs ensemble, plus tôt dans le projet.
Utilisez des méthodes de prototypage plutôt que des conceptions statiques
Au lieu de présenter l’avancement sous forme de document de définition ou de maquette plate qui sert uniquement de case à cocher pour approbation client, montrez-leur quelque chose qui fera partie intégrante du produit final.
Utilisez le prototypage rapide pour obtenir un élément fonctionnel et utilisable—et, plus important encore, quelque chose que vous pouvez tester auprès des clients. Recueillir des retours sur un prototype constitue un moyen pertinent de suivre les avancées, plutôt que de s’appuyer sur un livrable qui n’a pas l’avantage de faire partie du produit fini.
Vous pouvez créer des prototypes à différents niveaux de fidélité :
- Basse fidélité : Maquettes cliquables. Cela permet de créer rapidement un modèle à tester auprès des utilisateurs, principalement pour évaluer le style, l’ergonomie et de simples interactions.
- Fidélité moyenne : En intégrant du mouvement ou de l’animation.
- Haute fidélité : HTML fonctionnel. Utilisé pour des interactions plus complexes, mais vous pouvez ensuite le transformer en code livrable.
Les prototypes haute fidélité sont plus proches d’un « logiciel opérationnel » que les autres types, mais prennent également plus de temps à produire. Les prototypes de faible ou moyenne fidélité offrent déjà aux développeurs une meilleure base que des maquettes statiques.
Livrez rapidement quelque chose à l’utilisateur final ou au client
C’est un point crucial.
Ainsi, grâce à des livraisons fréquentes de logiciels opérationnels, le client peut profiter des nouvelles fonctionnalités dès leur sortie. Plutôt que d’attendre la fin du projet pour un lancement global, apporter de la valeur rapidement à votre client est essentiel pour obtenir un meilleur produit.
Comment pouvez-vous atteindre une livraison plus fréquente dans votre organisation ?
- Passez en revue votre plan projet ou feuille de route : Avez-vous prévu de terminer le développement puis de lancer à la fin ? Réfléchissez avec votre équipe à découper le travail en fonctionnalités ou segments pouvant être livrés indépendamment au fil du projet.
- Misez sur les obstacles : Un élément clé de votre rôle consiste à lever les freins qui bloquent l’équipe. Comment pouvez-vous les aider à livrer plus efficacement ? Existe-t-il des méthodes de travail qui ralentissent la sortie des versions ? Organiser une rétrospective de sprint avec votre équipe peut dévoiler des pistes d’amélioration des processus.
- Automatisez : Si votre organisation consacre beaucoup d’efforts aux livraisons, automatisez les tâches dès que possible. Par exemple, les tests et le déploiement automatisés économisent du travail manuel et réduisent l’effort nécessaire à la mise en production. Échangez avec votre équipe de développement agile à propos de leurs méthodes et des possibilités d’automatisation.
Valeur n°3 : La collaboration avec le client plutôt que la négociation contractuelle
Au lieu de rédiger, au début du projet, un contrat ultra-détaillé mentionnant précisément les livrables, le périmètre, le budget et les délais, gardez votre contrat agile aussi générique que possible. Les décisions sont prises tout au long du projet grâce à une collaboration étroite avec les clients et parties prenantes.
L’agilité ne consiste pas à passer un temps fou à définir à l’avance les besoins. Il s’agit de lancer un projet et d’apprendre en chemin grâce aux tests clients et à l’expérience recueillie sur les logiciels opérationnels.
Adoptez une approche centrée client
J’adore cette citation d’un article de Neil Killick :
« Un penseur agile se demande sans cesse : “Quelle est la façon la plus simple ou la plus rapide d’apporter de la valeur au client ?” Vous posez-vous cette question chaque jour ? Sinon, commencez par là. »
Ce n’est pas uniquement aux designers ou développeurs d’y réfléchir—les chefs de projet aussi. Nous sommes aussi garants d’apporter le meilleur produit ou service possible au client. Votre client, l’utilisateur de votre produit ou service, doit être au cœur de tout ce que vous faites.
Placez l’utilisateur final au centre du plan
Plutôt que de planifier autour de livrables ou d’estimations, élaborez votre planification autour de bénéfices concrets pour le client. Que souhaitez-vous que le client fasse, et pourquoi ? Comment mesurerez-vous que cela fonctionne ?
Recadrez la discussion pour qu’elle se concentre sur la valeur livrée au client, au lieu du nombre de tâches réalisées.
Impliquez votre client de façon rapprochée
Au lieu de se limiter à une réunion d’avancement hebdomadaire et à livrer au client et aux parties prenantes à la fin d’une période définie, travaillez à associer votre client au projet au quotidien.
Si vous adoptez davantage une méthode Scrum, faites du client le propriétaire du produit. Le propriétaire du produit est responsable de la convergence des exigences métier, techniques et client. Obtenir l’adhésion du client et collaborer avec lui dès le départ et fréquemment est crucial pour éviter les retards. Cela permet au final de générer un meilleur produit ou service pour l’utilisateur final.
Impliquez un client distant
Si votre client n’a pas le temps de contribuer au projet ou n’est pas impliqué, assurez-vous que quelqu’un dans l’équipe le représente. Il est essentiel que quelqu’un prenne en compte les besoins des clients et de l’entreprise.
Même si le client n’est pas engagé au quotidien, assurez-vous de communiquer régulièrement avec lui et, au minimum, impliquez-le dans toute planification agile et discussions de priorisation. Travaillez avec lui pour démontrer les bénéfices de son implication.
Mettez en place une feuille de route produit
Envisagez d’utiliser une feuille de route produit pour cartographier la trajectoire de votre produit. Une feuille de route permet de communiquer le plan pour le produit et de visualiser les fonctionnalités prévues pour la livraison. Cette feuille de route n’est pas figée au lancement du projet ; elle évolue au fil du temps afin de refléter les changements de priorités.
Assurez-vous de dialoguer avec vos utilisateurs finaux ou clients
Je ne le répéterai jamais assez : vous devez tester votre produit auprès des utilisateurs finaux et des clients, le plus tôt et le plus souvent possible.
Les tests offrent de nombreux avantages :
- Vous pouvez vous assurer que votre produit répond aux besoins des clients, c’est-à-dire : le produit est-il utile pour le client et donc pour l’entreprise ? Cela vous aide à évaluer l’adéquation produit-marché.
- Vous pouvez intégrer les retours des clients dans votre processus de conception et de développement, ce qui aboutit à un produit final de meilleure qualité.
- Vous pouvez obtenir des informations utiles pour les travaux futurs.
- Le problème souvent cité pour les tests clients est le budget : cela peut être coûteux. Voici quelques façons de tester, peu importe le budget de votre projet :
Tests guérilla : J’adore cette approche car elle est économique et simple. Proposez aux gens un vrai (ou virtuel) café en échange de quelques réponses sur vos maquettes ou prototypes. Il est plus difficile de cibler précisément qui répond à vos questions, mais un retour rapide peut être utile lors des tests sur l’aspect visuel ou des interactions simples.
Enquêtes : Pour collecter des données quantitatives auprès d’un plus grand nombre de personnes, vous pouvez créer une enquête pour évaluer une conception ou approfondir le comportement des clients.
Des sites comme usertesting.com : Vous pouvez mettre en ligne vos maquettes sur l’un de ces sites et recruter des participants via ceux-ci (en utilisant des critères si besoin). Ils vont alors parcourir vos conceptions, enregistrer leurs impressions et répondre à vos questions.
Tests en présentiel : Oui, cela peut être une option plus coûteuse, car vous devrez probablement recruter des participants et offrir des incitatifs ; cependant, cela peut s’avérer inestimable si vous testez des interactions complexes ou des fonctionnalités à haut risque.
Valeur n°4 : S’adapter au changement plutôt que suivre un plan
Les projets agiles et en cascade ne pourraient pas être plus différents sur ce point. Sur les projets de développement logiciel traditionnels, on fixe les exigences, le budget et le calendrier à l’avance, alors que l’agile autorise et valorise le changement.
Le changement est positif ! Ce n’est pas un ennemi ! Combien de plans de projet se sont déroulés exactement comme vous les aviez conçus au départ ? Pas beaucoup, je suppose (j’ai travaillé sur des projets dont le plan a été modifié des dizaines de fois).
Les plans représentent la meilleure estimation à un instant donné, que vous pouvez affiner au fur et à mesure – mais ils ne prévoient généralement pas la possibilité de changer. Que se passe-t-il si les besoins des clients évoluent ? Si l’entreprise change de cap ? Si votre client change de priorités ? Ou si les fonctionnalités prévues sont plus complexes à réaliser que vous ne le pensiez.
Les modes de travail agiles embrassent l’incertitude grâce à une planification adaptative (par exemple le planning poker). Ainsi, les valeurs Scrum stipulent que l’équipe planifie le travail sprint après sprint. Avant de commencer une période de travail limitée dans le temps, les équipes agiles sélectionnent les éléments du backlog et les priorisent pour le développement.
Bien qu’il y ait souvent une pression pour figer les coûts, les délais et le périmètre dès le début du projet, adopter une vision plus réaliste des incertitudes aboutit souvent à un bien meilleur produit au final. Au bout du compte, c’est ce que vous, le client et vos parties prenantes devriez rechercher.
Voici quelques façons de commencer à introduire la notion de changement dans vos projets et encourager plus de flexibilité :
Créez un plan « allégé » pour rassurer les parties prenantes
« Mais il nous faut un plan ! » crient vos parties prenantes. Plutôt que de les affoler en déclarant « Surprise, il n’y a pas de plan ! », élaborez un plan de publication allégé pour leur donner confiance tout en assumant une démarche un peu moins formelle.
Si vous pratiquez la gestion de projet agile avec les processus Scrum, vous disposerez d'une liste d’histoires utilisateur priorisées et estimées dans votre backlog. Travaillez avec le propriétaire du produit pour regrouper celles-ci en versions approximatives, et cartographiez-les sur votre feuille de route produit.
Essayez de ne pas tout planifier, ce qui contredirait les avantages de la méthodologie Scrum. Présentez à vos parties prenantes les plans des deux ou trois premières versions, puis expliquez-leur que la replanification est au cœur de la méthode agile, et que vous communiquerez régulièrement les mises à jour et les futures versions au fur et à mesure. Avec un peu de chance, cela leur donnera la confiance dont ils ont besoin !
Accompagnez l'équipe vers une approche basée sur les sprints
Mike Cohn, dans son article « Introducing an agile process to an organization », suggère d'aider les équipes à adopter Scrum en définissant différents types de sprints, par exemple :
- Prototypage
- Collecte des besoins
- Analyse et conception
- Mise en œuvre
- Stabilisation
Voici comment il explique l'utilité de cette démarche :
« Nous travaillons alors avec les équipes pour définir les livrables attendus de chaque type de sprint. L'introduction des types de sprints apporte juste assez de formalisme pour que les équipes puissent voir plus clairement le déroulement du projet. À mesure que les équipes deviennent plus à l’aise avec l'informalité de la méthode agile, elles abandonnent progressivement le concept des types de sprints. »
Il s'agit là d'une autre façon de structurer votre plan de versions. Si vous assignez un “type” à chaque sprint, vos parties prenantes peuvent visualiser la structuration du plan, tout en vous permettant de ne pas avoir à garantir des fonctionnalités précises. Votre équipe dispose également d'une meilleure idée de ce sur quoi elle va travailler.
S’éloigner des délais fixes
Donner à votre équipe une date limite ou communiquer une échéance fixe à votre client sont deux stratégies vouées à l’échec ou à provoquer beaucoup de stress. Instaurer la confiance entre vous, votre équipe, votre client et les parties prenantes est fondamental pour démontrer que vous allez livrer, et apporter de la valeur, à l'utilisateur final.
N’oubliez pas, l’objectif est de réduire la nécessité de multiples points de contrôle et validations. Imposer des échéances sur votre projet ne vous aidera pas à atteindre ce but. De même, il n’est pas souhaitable de mettre la pression sur votre équipe en la relançant constamment pour qu’elle livre le travail “promis”.
Comme mentionné ci-dessus, les feuilles de route et les plans de versions peuvent être de bons mécanismes pour s’écarter d’une logique de date fixe. Donner aux parties prenantes une idée de ce qui sera livré dans un futur proche peut les rassurer sur l’existence d’un plan.
Optez pour un périmètre basé sur le temps et les ressources
Si vous avez un périmètre avec prix et livrables fixes, il est difficile de travailler de façon véritablement agile. Vous pouvez certes appliquer certaines des techniques abordées plus haut, comme favoriser la collaboration au sein de l’équipe. Mais votre capacité à répondre et à vous adapter au changement, à laisser l’équipe déterminer son travail ou à adopter une approche plus centrée sur le client sera limitée.
Essayez d’aboutir avec votre équipe interne et le client à un périmètre basé sur le temps et les ressources : c’est-à-dire que le client paie pour une équipe, et non pour des livrables prédéfinis. Au début, certains clients peuvent être inquiets s’ils ne savent pas exactement ce qu’ils vont recevoir.
Pour réduire ce risque, vous pouvez inclure dans le périmètre un backlog d’activités ou de tâches pouvant être considérées pour le lancement. Indiquez dans le contrat que l’équipe recalcule et priorise le backlog avec l’apport du client au fil de l’avancement du projet (même si tous les éléments ne seront pas forcément traités).
Pour aider à gérer la priorisation et les livrables qui évoluent, les équipes peuvent utiliser des logiciels de gestion agile pour re-prioriser en continu leur backlog, ainsi que des outils de collaboration pour le développement logiciel pour coordonner la collaboration interfonctionnelle.
De cette façon, vous ne vous engagez pas sur un périmètre figé, et le client est moins soucieux de l’apparence du produit final.
Continuez à suivre l’avancement
Le suivi et la visualisation de la progression ne disparaissent pas en l’absence d’un plan projet formel. Maintenir la visibilité de l’avancement pour l’équipe et les parties prenantes permet non seulement de ne pas perdre de vue les obstacles et points de blocage potentiels, mais aussi de garder tout le monde informé.
L’utilisation d’un tableau de gestion des tâches façon Kanban ou de tableaux de bord agiles fonctionne bien pour les projets agiles. Une fois votre processus visualisé, vous pouvez commencer à mettre à plat les tâches et activités de support. Cela vous aide à repérer les goulots d’étranglement que vous pouvez lever pour accélérer la livraison au client.
Critiques du Manifeste Agile
Comme toute autre méthodologie de gestion de projet, l'agile n'est pas parfaite. Les critiques soulignent que les auteurs du Manifeste Agile formaient un groupe homogène qui a peut-être négligé de prendre en compte d'autres approches du travail, comme les avantages du télétravail ou la manière d'appliquer l'agile en dehors du domaine du développement logiciel.
Lorsque l’agile est poussé à l’extrême, cela peut se traduire par des décisions prises en comité, ralentissant ainsi le rythme du travail. Le manque de documentation peut finir par nuire à la livraison des projets, en particulier dans un environnement à distance où la communication asynchrone est essentielle.
Si vous décidez d’adopter l’agile dans vos projets, veillez à consulter les valeurs et principes agiles. Ils constituent un guide utile pour garder sous contrôle les dérives potentielles de l’agilité.
Pour en savoir plus sur le débat entre méthodologie et état d’esprit agile, cliquez ici.
Agilité, pas agile
Une dernière pensée : n’oubliez pas la rétrospective ! Comme l’indique le Manifeste :
À intervalles réguliers, l’équipe réfléchit à la manière de devenir plus efficace, puis adapte et ajuste son comportement en conséquence.
Quel que soit le type de processus que vous appliquez, la rétrospective est un moyen efficace d'évaluer votre mode de fonctionnement et de l’optimiser pour la réussite. Veillez à inclure régulièrement des rétrospectives de projet dans tous les processus que vous utilisez – et à disposer d’un mécanisme pour intégrer vos apprentissages ! PS : Il est aussi important de faire parler vos membres d’équipe les plus discrets lors des rétrospectives : voici comment.
Et maintenant ?
Pour en savoir plus sur la mise en place de méthodes agiles et profiter de l’expérience des meilleurs chefs de projet, découvrez nos offres d’abonnement DPM.
