Apparues en 2001, les méthodes agiles n’ont eu de cesse que de se démocratiser en sein de nos entreprises. Beaucoup d’entre elles les adoptent en dépit des classiques « Waterfall method » ou « V cycle ». Celles-ci n’étant plus vraiment compétitives dans le cadre de projets digitaux où le time-to-market recherché est toujours plus court.

Face à l’utilisation quasi systématique des méthodes agiles, comment s’assurer de la réussite d’un projet ? Peut-on appliquer à la lettre les principes de la méthode, quelle qu’elle soit ?
La réponse est non : chaque entreprise possède ses propres contraintes et sa propre organisation. Ne pas prendre en compte ces particularités serait une grave erreur. Quelle est alors la marge de manœuvre pour les entreprises ? Sur quels paramètres peut-on jouer pour appliquer cette démarche et quels sont ceux qui sont, au contraire, intangibles ?
Des milliers d’articles sur le web décrivent déjà très bien les principes généraux de l’agilité. Nous passerons rapidement sur ces aspects pour nous baser essentiellement sur différentes situations issues d’expériences concrètes.

Les principes intangibles des méthodes Agiles

Qu’importe la méthode utilisée (SCRUM étant la plus classique), il existe certains piliers qui représentent les fondements même de l’Agilité. Quelques-uns sont immuables, d’autres cependant se doivent d’être adaptés pour éviter l’échec du projet. Nous verrons ici quelles sont les notions les plus structurantes.

Une approche itérative et incrémentale
L’itération, dans la méthode Agile est le meilleur moyen de s’assurer que l’on part dans la bonne direction : il faut affiner le produit par étape de manière à augmenter sa valeur. Les erreurs sont ainsi identifiées rapidement et cela permet de s’adapter aux évolutions du besoin.
La notion d’itération est donc un principe clef de la méthode. Chacune devant mener à un produit utilisable et testable sur le marché.
Celle-ci est complémentaire avec l’approche incrémentale : chaque nouvel incrément améliore le produit précédent, et ainsi de suite jusqu’à atteindre le résultat final (parfois, il n’y a jamais de résultat final). L’association de ces deux concepts constitue l’essence même de la méthode Agile : créer un cycle itératif incrémental.

Une équipe dédiée
L’équipe est aussi l’une des constantes des méthodes agiles. Elle est composée de développeurs (de séniorités différentes), d’un client ou responsable produit (product owner) et de facilitateurs (Scrummaster). Cette organisation ne variera jamais dans les grandes lignes. Il est également important de noter qu’il n’existe pas de hiérarchie directe au sein de l’équipe : tous sont complémentaires et au service de l’utilisateur final.

Priorité au MVP
En privilégiant l’accès rapide aux fonctionnalités clés du produit en cours de développement, les risques d’échecs seront considérablement diminués. En effet, chaque itération doit mener à une fonctionnalité ou un service utilisable et opérationnel. Si ce n’est pas le cas, c’est que l’équipe n’a pas su subdiviser correctement ses stories (elle seront appelées Epiques : Trop importante pour être livrées en 1 sprint).

Implication forte du business et la communication
L’implication forte du métier est primordiale dans la méthode : il doit s’impliquer dans le développement tout autant que l’équipe technique, voire plus. Il doit agir comme un Chef de Projet de proximité évoluant au côté des équipes de développement pour expliquer, ajuster et priorisés les besoins tout au long de la vie du projet.

Privilégier la simplicité aux processus lourds
Quelle que soit la société dans laquelle la méthode s’applique et spécifiquement si l’utilisation de cette méthode est une nouveauté, il faut avant tout simplifier les processus et minimiser leur nombre. Se faisant, les interactions entre les membres de l’équipe seront multipliées, multipliant par la même occasion les chances de réussite du projet.

Limites et adaptabilité de la méthode

Les méthodes Agiles peuvent évidemment être appliquées dans un environnement non Agile, même si celui-ci présente de fortes contraintes.
Il s’agit ici d’adapter graduellement ces méthodes au contexte client. Faire ressortir régulièrement les gains et bénéfices obtenus est impératif. Les paramètres comme la taille de l’entreprise, sa culture ou ses moyens sont autant de variables qui permettront de façonner la bonne méthode à utiliser.
Il faut donc prendre en compte ces paramètres pour ajuster la méthode, en voici quelques exemples :

Disponibilité métier – Il n’est pas toujours facile pour le client de libérer autant de temps qu’il le faudrait pour suivre le développement du projet.
Prenons l’exemple d’une grande entreprise où l’expert métier qui officie en tant que Product Owner est aussi sollicité sur d’autres sujets compromettant son implication et sa disponibilité. Le métier met alors en place un système de Product Owner « proxy » : Une personne technico-fonctionnelle disponible capable de parler aux équipes techniques au nom du Product Owner. Ce nouveau rôle dans l’organisation permet ainsi de libérer le temps de l’expert (toujours sollicité en cas de questions structurantes) tout en assurant une continuité de l’équipe métier. Sans cela, la disponibilité et donc la réussite d’un projet agile serait fortement compromis. Attention : dans la méthode, le client n’a qu’une seule et unique voix, il est donc très important que les deux acteurs (Product Owner et Product Owner Proxy) se synchronisent sur un seul et même discours.

Durée des Sprints – Pour les grandes entreprises, il est souvent difficile de réaliser de courtes itérations (inertie, lenteur de validation, contraintes de production, …). Rien n’empêche alors d’adapter la taille de ces sprints aux contraintes de l’organisation. 2 ou 3 semaines est la durée la plus classique mais dans certains cas, prendre plusieurs mois pour chaque itération n’est pas aberrant : l’acceptation de la méthode se fera alors de façon moins brutale. A contrario, la mise en place rapide de POC (Proof Of Concept) ou de petites applications ne nécessiteront pas plus d’une semaine par sprint.

Proximité des équipes – Alors que la méthode préconise une équipe OnShore (Sur place, avec interaction directe et physique entre les acteurs), dans certains cas, il est préférable de choisir une équipe NearShore (région ou pays voisins, pas plus de 3h de décalage horaire). Les raisons sont multiples : Réduction des coûts, compétences spécifiques, etc. Avec la démocratisation des outils digitaux de collaboration (VOIP, Partage de sources, partage d’écrans…) il est maintenant aisé de pratiquer l’Agile à distance. Néanmoins, le choix d’une équipe Offshore est à exclure car le décalage horaire et les potentielles différences de culture seront assurément des obstacles à la réussite du projet.

A vous ensuite de trouver le bon équilibre entre les principes théoriques et ceux qui seront adaptés à votre entreprise. Il n’existera jamais de méthode « universelle ». S’inspirer de ce qui se fait déjà dans d’autres société est un très bon exercice pour trouver des pistes d’adaptation.

En conclusion, rappelons qu’il n’est jamais recommandé d’appliquer une méthodologie à la lettre sans prendre en compte l’environnement culturel et organisationnel dans lequel se déroule le projet. Pour cela, il est intéressant d’avoir une approche systémique lors de la mise en place de nouvelles méthodes c’est à dire comprendre le contexte professionnel, l’environnement et l’organisation de l’entreprise. Restez pragmatique ! Parfois en effet, l’expérimentation vous mènera au constat que la méthodologie que vous aviez choisie au début n’était pas la bonne et qu’une autre sera bien plus adaptée à votre contexte.