Les pratiques Agiles, des méthodes sans limites ?

L’Agilité s’est depuis quelques années généralisée au sein des méthodologies de projet informatique. En effet, l’Agilité promeut :

Une rapidité de développement,
Un Most Valuable Product (MVP) de qualité,
Un modèle itératif garantissant des incréments pertinents,
Une qualité d’échange entre les différents intervenants au projet.

Les méthodes Agiles sont-elles pour autant aussi parfaites ? Après avoir été testées et déployées dans divers secteurs et entreprises, il est temps d’analyser les retours d’expérience.

Le TOP 5 des limites des méthodes Agiles

Avant de lister le TOP 5 des limites, il faut souligner que cet article n’a pas vocation a être exhaustif. Selon les expériences de chacun, certains points n’ont eu qu’un faible impact sur la gestion de projet. Cet article se veut être le plus générique possible.

1. L’Agilité, une pratique rigide et structurée

De manière un peu antinomique, les méthodes Agiles proposent un cadre de travail très strict et très organisé, ce qui peut déstabiliser les entreprises souhaitant les utiliser pour leur flexibilité.

L’implémentation d’un calendrier d’événements cadencés, notamment avec les daily meetings, les sprints planning et autres sprint retro rythment de manière intense la vie d’un projet Agile. Également, l’organisation d’une équipe projet composé de profils ayant chacun une mission bien spécifique, comme le Product Owner, ou encore le Scrum Master, ne donne de liberté quant à la manière de mener le projet Agile.

Certains pourront néanmoins préciser que c’est grâce à cette organisation rigoureuse, qui ne laisse pas beaucoup de place à une certaine souplesse, qu’il est possible d’ajuster librement le backlog projet en fonction des évolutions des priorités business. Cependant, il paraît important de prendre conscience de cette réalité.

TIPS : Afin d’assurer un meilleur suivi du projet et aider à implémenter une organisation efficace, il est intéressant de faire appel à des coachs Agile.

2. Une culture projet compliqué à assimiler et à déployer

L’Agilité est une culture à part entière qu’il faut savoir adopter et assimiler, par tous. Son mode de fonctionnement et ses concepts diffèrent drastiquement des méthodes conventionnelles des projets informatiques. C’est la raison pour laquelle, un manifeste Agile est disponible pour communiquer les valeurs que l’Agilité porte et défend.

Ces valeurs orientent la manière dont les opérationnels travaillent. Cependant, il ne faut pas pour autant oublier que ces valeurs concernent tout autant les managers des entreprises. En effet, la plupart du temps, les managers ne prennent pas en compte les valeurs et le mode de fonctionnement de l’Agilité. En conséquence, les opérationnels et les managers ne parlant pas le même langage, ce qui provoque des situations d’incompréhension et de frustration avec les opérationnels.

TIPS : Les dirigeants doivent se former au plus tôt à ce concept pour s’adapter à la démarche et aux objectifs que l’Agilité propose.

3. Agiliser son organisation a un coût

Se lancer dans l’Agilité par mode, sans réelle préparation mène droit à un échec. En effet, il est impératif de prendre conscience que l’Agilité représente un coût. Elle engendre aussi bien des impacts tant en termes de culture que d’organisation. Difficile à estimer, voici néanmoins quelques exemples de coûts qu’il faut savoir anticiper :

Coût financier : la gestion des budgets reste complexe dans le cadre d’un projet Agile. La courbe d’apprentissage, ou encore les imprévus techniques impactent systématiquement les estimations des budgets.
Coût humain : l’Agilité demande d’avoir des rôles et des compétences précis (product owner, scrum master…). Il est nécessaire de former, de recruter, d’accompagner et de permettre à tous d’intégrer les concepts de l’Agilité.
Coût temporel : L’Agilité prend du temps à être complétement maîtrisé et demande du temps pour être pleinement performant.

Egalement, le cadre contractuel proposé par les ESN ne s’adapte pas au format Agile. Il demeure compliqué de concevoir une offre de centre de services lorsque les éléments financiers reposent sur des « unités d’œuvre », des « story points » et autres « taille de T-shirt ». Etant donné que ces mesures ne sont pas d’ordre temporel, il reste très compliqué de proposer des propositions commerciales précises pour répondre aux besoins d’Agilité.

TIPS : Pour cadrer au mieux son budget, les projets Agile fonctionnent généralement mieux dans un mode en régie. En effet, l’Agilité se concentre davantage autour de la création de valeur du développement plutôt que de l’optimisation des coûts et des délais d’un projet.

4. La disponibilité des développeurs

Le manifeste Agile préconise les échanges entre les individus au profit des processus et des outils. Cependant, les échanges avec les développeurs sont parfois complexes à organiser au début d’un projet.

Dans le cadre de la méthode Scrum, chaque développeur dispose d’un maximum de fonctionnalités à développer dans un temps limité (un sprint). Or, il se trouve que les estimations de développement des fonctionnalités ne se reposent pas sur des mesures temporelles. Ainsi, il est probable que les développeurs gèrent trop de fonctionnalités à la fois. Les développeurs s’efforçant de remplir leur contrat dans le temps imparti, il leur est compliqué de trouver du temps pour se libérer facilement afin d’échanger avec le product owner. De plus, il se trouve parfois que ce travail à flux tendu puisse même aller jusqu’à dégrader la qualité de leur travail.

TIPS : Au début d’un projet, la vélocité de développement de chacun des développeurs doit être testée afin d’ajuster la complexité technique et le volume de fonctionnalités à effectuer pendant un sprint. Il est important de garder une marge pour assurer une disponibilité pour les échanges et faire face aux imprévus.

5. La minimisation de la documentation

Le manifeste Agile promeut le logiciel plutôt qu’une documentation trop volumineuse (qui parfois se trouve être trop indigeste). Malheureusement, sans documentation, il demeure complexe de comprendre et de reprendre un projet informatique. La documentation est cependant un contrat légal. Il permet d’avoir un accord explicite du contenu du livrable dans le cadre d’un accord entre sous-traitant et client.

Dans le cadre de la plupart des projets Agiles, les développeurs sont considérés comme des opérationnels techniques. Leur périmètre est parfois restreint uniquement au développement. Or, sur le long terme, ces situations peuvent être critiques. Un projet informatique non documenté n’est pas pérenne et génère un coût. En effet, dans le cas d’une maintenance technique ou si le projet change de main, tout un travail de recensement de l’existant est à faire.

TIPS : Il est impératif d’ajouter le bon niveau de documentation à la « definition of done ». Cela permet de s’assurer que la documentation s’incrémente au fil de l’eau.

Agilité - La documentation est nécessaire

Un système complexe mais néanmoins utile

Synonyme de succès, l’Agilité mal encadrée et mal utilisée, comme toute autre méthodologie de projet est inutile voire contre-productive. Faire de l’Agilité pour répondre rapidement à des enjeux business est rarement un franc succès. L’Agilité modifie en profondeur les façons de faire et les relations entre managers, opérationnels et clients. Il est impératif de comprendre et d’anticiper ces sujets. Malgré ces limites, l’Agilité reste une méthodologie performante car elle permet d’intégrer le client dans le suivi du projet. Les méthodes Agiles permettent d’ajuster le projet au fur et à mesure afin de répondre au mieux aux besoins clients.

Sources :