Oui 🙂 D’un point de vue de la faisabilité, tous les projets pourraient être menés dans une approche agile. Même si dans certains domaines, les coûts exploseraient, ça n’en reste pas moins faisable.
Alors, quels sont les critères qui vont vous permettre de choisir ou non une approche agile, c’est à dire une approche centrée sur la collecte de feedbacks utilisateurs à partir de livraison d’une ou plusieurs sous-parties terminées du projet ?
Dans cet article, j’explore quelques situations types dans lesquelles retenir une approche agile serait sans doute une bonne idée.
L'envie d'être agile
C’est la situation idéale : vous avez une équipe (ou une grande partie de l’équipe) qui souhaite s’engager dans une démarche agile. Il est donc essentiel de construire ce projet avec les personnes qui feront l’Agilité de demain dans votre équipe.
Après la vague de massification de l’Agilité à laquelle nous avons assisté ces dernières années, il est probable que vous rencontriez de plus en plus de détracteurs de cette approche. Ces mauvaises expériences d’Agilité sont souvent citées sur les réseaux sociaux et dans les médias. Les bonnes expériences sont rarement citées, il y a déséquilibre. Malheureusement cette mauvaise image contribue au rejet de l’Agilité par certains.
Vous l’aurez compris, l’adhésion de l’équipe est la première condition essentielle pour passer en Agile, quelle que soit la méthode retenue ! L’Agilité est un chemin, si dès le départ vous n’avez pas envie de prendre la route, ça risque d’être long et douloureux pour tous 😉
Sponsor et soutien de votre transformation agile
Qui sponsorise la démarche agile au sein de l’organisation ? Une équipe à elle seule pourra porter les aspects opérationnels mais elle doit être soutenue. Qui sera le ou la référent(e) Agile ? Qui sera la personne qui soutiendra l’équipe quand elle vivra des moments difficiles (on est d’accord que l’Agilité n’est pas magique hein ?! Même les équipes agiles ont des problèmes).
L’Agilité est un choix stratégique, une politique sociale pour une organisation. Ce n’est pas simplement se mettre debout devant un tableau de Post-It (arriverons-nous à nous décoller de cette image un jour … ?).
Il faut aux équipes une ou plusieurs personnes qui légitiment l’investissement de l’apprentissage de l’Agilité, qui soient ouvertes au “droit à l’erreur”, qui observent aussi les aspects humains aussi bien que les aspects performance. Nous (les professionnels de l’accompagnement agile) avons plus de recul désormais. Combien de projet de transformation agile se sont arrêtés ou ont mal fonctionné le jour où le sponsor de l’Agilité a changé de poste ?
Un projet stratégique et/ou innovant
Un bon projet candidat pour l’Agilité a une dimension stratégique plus ou moins forte pour l’organisation. Il doit y avoir des attentes de réussites, réglementaires, une ambition réelle ! Sinon à quoi vont vous servir les mécanismes collaboratifs, les rituels répétés, les itérations d’apprentissages, le traitement de retours de vos utilisateurs ? Avoir une ambition va plus loin qu’avoir une exigence de planning, c’est aligner l’Agilité sur ce qu’elle est : un moyen de livrer de la valeur tôt et de valider que l’équipe est capable de la produire.
Un projet qui part en cacahuète
Ce sont des situations délicates mais un projet bien “moisi” où on ne voit plus comment s’en sortir est souvent une bonne occasion d’introduire l’Agilité. Nous serons évidemment attentifs aux aspects humains : il est probable que l’Agilité arrive dans un contexte de tension et de ressentis très forts. L’Agilité n’est pas une solution miracle à ce moment-là, juste une approche pragmatique pour remettre de l’ordre dans les priorités, les prochains pas à faire. Si vous avez explosé votre enveloppe budgétaire, l’Agilité ne peut rien pour vous, par contre elle permettra peut-être de limiter la casse à venir.
Les pires projets sont ceux qui sont censés être agiles depuis le début… Je vais m’avancer un peu mais j’ai pu observé dans les projets que j’ai accompagnés, qu’il y avait peu de choses réellement agile. Il vaut mieux partir sur un cycle en V qu’on maîtrise plus ou moins plutôt que de mettre une étiquette “agile” et laisser croire que votre projet est Agile.
Tout simplement parce qu’on n’est jamais agile à 100%, l’Agilité est un apprentissage permanent, un apprentissage qu’on ne retrouve pas dans les projets qui sont mal embarqués.
Des délais courts
Il existe un mythe selon lequel l’Agilité ne s’applique pas aux projets de quelques jours. C’est certainement vrai si on suppose que l’Agilité va fonctionner en Scrum avec des itérations de 2 à 3 semaines.
L’Agilité ne doit pas se résumer à Scrum. Trop de praticiens ont du mal à se défaire de ce cadre (je ne les blâme pas, désapprendre est difficile non ?). L’Agilité est donc la capacité donnée à une équipe de définir un cadre collaboratif et productif y compris sur des délais courts. Oui il est possible de faire des itérations de 1 jour ! Mais non vous ne ferez pas un daily meeting de 15min à ce moment-là.
Devrez-vous écrire des User Stories ? Je n’en ai aucune idée mais la définition de Terminé sera un concept incontournable.
Un projet de grande envergure
Une autre situation idéale ! Si le projet est de grande envergure voire monstrueux, vous aurez le luxe et le privilège d’apprendre à travailler en équipe pendant de nombreuses itérations.
Les difficultés seront quand même au rendez-vous mais loin d’être insurmontables. Une attention particulière devra être portée sur les éléments suivants :
- Le découpage : comment granulariser un gros projet ? C’est souvent une tâche ardue. Il existe quantités d’approches à expérimenter (de la vision à la cartographie fonctionnelle comme avec le user story mapping)
- La fatigue et l’usure : les membres d’une équipe travaillant ensemble pendant plusieurs mois ou années tomberont dans la routine des itérations surtout lorsque l’équipe ne voit pas le bénéfice de ses actions. Vous comprenez alors l’intérêt essentiel sur les projets de grande taille de mobiliser des utilisateurs pilotes dès le début et de créer cette culture du feedback (la démonstration et la rétrospective sont donc des pratiques à garder quelle que soit la méthode)
- Le rythme soutenable : trop souvent ce principe agile reste une vue de l’esprit et est oublié. Les projets de grande envergure en Agile sont d’excellents candidats à la logique du “doucement mais sûrement”. Vous préserverez ainsi le meilleur carburant de l’Agilité : les personnes.
Le besoin de proximité avec l'utilisateur
Un projet est un service, une fonction, un outil pour un ou plusieurs utilisateurs finaux dans l’accomplissement d’une ou plusieurs de leurs tâches métier. L’Agilité met au cœur les interactions entre ceux qui font et ceux qui utilisent le projet, encore faut-il y croire et avoir le courage de se “frotter” aux utilisateurs.
Plus vous irez voir vos utilisateurs, plus vous leur montrerez, plus ils utiliseront ce que vous produisez, et plus vous aurez de retours. La liste des besoins augmentera à coup sûr.
Cette inflation du besoin sera la conséquence d’une mauvaise Agilité pour une équipe ne sachant pas prioriser et qui n’accepterait pas de filtrer et de supprimer certaines demandes. Cela vous rappelle des souvenirs ? 🙂
Le besoin de cohésion d’équipe / décloisonner
Oui l’une des résultantes de l’Agilité est une cohésion d’équipe, une collaboration fluide, des divergences de points de vue qui s’expriment et qui trouvent une issue positive. Ce monde des Bisounours est sans doute atteignable au prix de l’effort de l’apprentissage du “travailler ensemble“.
L’Agilité n’est pas une promesse creuse ni un idéal qui reste aveugle à la réalité des équipes. Quel que soit le modèle de transformation des équipes, nous observons toujours une période de tensions plus ou moins fortes. Une équipe qui choisit l’Agilité comme mode de fonctionnement ne fera pas exception.
La ritualisation des rencontres et des échanges sont un des moyens pour apprendre à s’écouter, dialoguer et décider ensemble.
Besoin de tenir des délais forts
J’ai pu observer que toutes les équipes ayant des délais très forts à tenir s’en sont tirées avec brio. Ce sont des contextes particulièrement propices à l’Agilité, à l’exercice de la priorisation, à la recherche de la valeur. Je précise que “délais forts” ne rimera que trop rarement avec “périmètre initialement imaginé” tenu.
Non l’Agilité ne permettra pas de tout faire. Le meilleur levier à actionner est souvent la négociation de la liste des demandes. C’est donc la culture de l’organisation que l’Agilité va venir percuter, pour le bénéfice de tous mais surtout de vos utilisateurs qui apprécieront que vous vous soyez concentré sur ce qui est utile, utilisable et utilisé.
Agilité ou pas, à l’impossible nul n’est tenu. Si votre projet est encadré par des délais intenables, l’Agilité pourra aider l’équipe mais ne saura être tenue pour responsable d’une aberration de planification 🙂 Une affirmation particulièrement vécue dans les ESN (ex SSII) et tous les milieux où les délais sont fixés par des impératifs souvent absurdes et déconnectés de la réalité des utilisateurs.
Besoin d’organisation spécifique
Pour toutes les équipes à la recherche de leur organisation, de leur mode de fonctionnement, estimant que la gestion de projet en interne est plutôt mal fichue, complexe ou centralisée sur une personne (le chef de projet ?), c’est peut-être le moment de changer de mode de fonctionnement.
L’Agilité “casse” les organisations pyramidales. Une équipe est un ensemble d’individus aux compétences différentes et complémentaires à qui vous donnez la capacité de s’auto-déterminer dans un cadre donné.
L’Agilité est une chance de déléguer la responsabilité de décision à celles et ceux qui savent. Essayez, vous verrez, c’est très efficace. Les rituels posent un cadre clair, répété conçu pour que chacun y trouve sa place. La transparence qui en découle donne une visibilité nouvelle au travail de l’équipe.
Mon projet est en fait un produit
Si l’Agilité est souvent visible dans les projets, on oublie trop souvent que ce n’est qu’une étape. Si un projet se définit par une liste de choses à faire entre une date de début et de fin, un produit, lui se définirait par un service à rendre en continu. Il a un début et une date de fin vie inconnue.
L’autre différence notable est qu’un projet est souvent la commande d’un client, là où un produit s’adresse au plus grand nombre (les utilisateurs).
En mode produit, l’organisation qui le crée a le pouvoir d’accepter et de définir les demandes qui le composeront. En mode projet, nous sommes souvent contraints par le client.
L’Agilité en mode produit c’est toucher vraiment la frontière avec la livraison continue et donc les approches en flux.
Autre atout remarquable en mode produit : l’équipe pourra s’élargir avec les compétences des autres services qui sont en général cloisonnés. Qui n’a jamais rêvé de mettre une personne du commerce, marketing, du développement, du test, de la documentation, du support client dans la même équipe ?
Petit clin d’œil à tous les éditeurs logiciels : l’Agilité est bien plus qu’une approche pour la R&D, c’est constituer des équipes produit.
En dehors de l'IT
J’ai peu d’espoir qu’un jour l’Agilité sorte de l’IT. Sans être fataliste, il faut se rendre à l’évidence :
- La définition de l’Agilité et la grande majorité des expérimentations sous le terme “Agilité” ont été menées depuis des années dans le domaine IT
- Malgré les efforts pédagogiques et les quelques expérimentations en dehors de l’IT. L’Agilité est une étiquette accolée au monde informatique
- Beaucoup de pratiques agiles peuvent exister dans d’autres métiers sous d’autres noms (par exemple Growth marketing, Growth driven design, Design sprint, Design thinking, DevOps, Lean startup…)
Peu importe, au final nous parlons de former des équipes qui travaillent ensemble pour livrer de la valeur régulièrement à leurs utilisateurs et qui vont apprendre à s’améliorer à partir de leurs retours.
Il me semble que cette idée est partagée par énormément de métiers qui n’ont rien à voir avec l’IT. L’Agilité est donc applicable comme principe et état d’esprit dans tous types d’organisation. Les outils et les méthodes sous-jacentes seront bien évidemment à adapter voire à créer.
Aller plus loin
- Participez au Meetup : Quelle agilité mon équipe doit-elle choisir pour démarrer ?
- L’article Comment évaluer l’Agilité de mon équipe ? et 8 ressources pour démarrer en Agilité
- Conférences sur le thème de l’Agilité
- Le jeu ANIMAGILE d’Alexandre Boutin
