Méthodes agiles : les écueils à éviter

Force est de constater que la souplesse des méthodes agiles tourne parfois au désordre. Il n’est pas inutile de recenser les écueils à éviter pour pouvoir profiter des gains liés à ces méthodes.

J'avais ri il y a quelques années quand mon cabinet nous avait proposé une formation nommée "scrum". Plus personne ne rit aujourd'hui, les méthodologies agiles ont fait leur chemin et sont omniprésentes dans les directions techniques, particulièrement adaptées pour le développement de produits Web et mobile. De quoi s'agit-il ? D'un ensemble de "règles" régissant les développements, qui ont lieu en une succession d'itérations de une à trois semaines. Les itérations démarrent avec des "planning games", au cours desquels les fonctionnalités du "backlog" sont chiffrées et attribuées à des développeurs. Les développements sont ensuite suivis dans le cadre de "stand-up meetings" quotidiens et s'achèvent avec une "démo" des développements au métier, qui peut valider ou demander des évolutions.

On le voit, ces méthodologies permettent, par rapport au traditionnel cycle en V, une collaboration accrue entre les équipes et une grande réactivité en cas de changement. Mais force est de constater que la souplesse tourne parfois au désordre. Il n'est donc pas inutile de recenser les écueils à éviter pour pouvoir profiter des gains liés à ces méthodes.

Risque n°1 : un pilotage "le nez dans le guidon"
Une confusion courante consiste à penser que les méthodologies agiles sont des méthodologies de gestion de projet. Or, elles n'encadrent que les phases de développement et de tests.

Les conséquences de cette confusion sont de deux ordres.

En termes de pilotage d'une part. Le pilotage des projets est réalisé uniquement dans les instances liées aux itérations (démonstrations, planning games...) : c'est là que les déscopages fonctionnels sont validés, souvent par les techniciens en dehors de l'avis du métier. Le management perd la main sur le projet faute de visibilité. Il est donc indispensable de maintenir des instances de pilotage et des reportings réguliers, qui permettent par ailleurs un recul salutaire dans la gestion des projets.

Le deuxième effet pervers concerne l'encadrement du travail du métier. Un mode itératif peut être adapté pour la réalisation de développements et de tests, mais il est beaucoup moins pertinent pour la définition d'un produit. En effet, l'ergonomie d'un produit ne peut pas être efficace si de nouvelles fonctionnalités sont définies "à la petite semaine" pour alimenter les itérations à venir. Il est donc important de maintenir des phases de conception suffisamment longues pour permettre un réel mûrissement du besoin et éviter une réflexion basée uniquement sur les réactions face à ce qui a été développé, qui peuvent entrainer beaucoup de retravail.

Une autre conséquence d'une organisation centrée sur les développements est un temps accru du métier en support à la technique pendant les itérations. Dans l'absolu, c'est un point très positif qui permet au métier de monter en compétence sur les problématiques techniques et ainsi de concevoir des produits en conséquence. Mais à l'excès, le rôle du métier se limite au support des développements et le temps consacré à la conception de la phase suivante n'est plus suffisant. Commence alors un cercle vicieux de retard perpétuel du métier. La technique commence à prendre la main sur le choix des futurs développements, sans la vision fonctionnelle nécessaire.

Risque n°2 : Un projet allongé
Les méthodes agiles sont souvent choisies dans l'idée d'accélérer la sortie des produits. Pour plusieurs raisons, elles peuvent au contraire amener à des retards sur les projets.

D'abord, car trop de flexibilité dans la prise en compte de nouveaux besoins peut provoquer une moindre rigueur dans la conception initiale du produit, ou bien générer de nouvelles demandes au fil du projet, dont on aurait pu faire l'économie. Encore une fois, un pilotage serré du projet à un niveau plus macro que le suivi des itérations permet de limiter ce risque.

D'autre part, les méthodes agiles favorisent souvent un souci élevé sur la qualité, avec les démarches d'intégration continue et de refactoring. Or, le mieux est l'ennemi du bien et très souvent - en particulier pour un nouveau produit dont l'audience initiale ne sera pas élevée - un meilleur délai de "time to market" a plus de valeur économique qu'un produit de qualité supérieure.

Risque n°3 : L'humain au centre du système
Avec de nombreux dogmes et des pratiques qui peuvent plus s'apparenter à des jeux qu'à du travail, les méthodes agiles ne laissent personne indifférent. On aime ou on n'aime pas : il faut choisir son camp.  Ainsi si elles peuvent motiver certaines ressources, certaines peuvent également se sentir exclus.

Dans des équipes jeunes ou constituées de prestataires, la mise en œuvre et l'acceptation des méthodes de fonctionnement se fait aisément. Dans des organisations plus traditionnelles, ces méthodes peuvent entraîner le rejet de développeurs habitués à travailler de manière autonome pendant un temps plus long. Pour eux, des réunions quotidiennes et les méthodes collaboratives peuvent apparaître comme un excès de contrôle.

Ces méthodes peuvent également poser un autre problème : elles favorisent souvent une conversation par rapport à la formalisation d'un besoin ou d'une décision. Si dans l'absolu ce mode de collaboration est beaucoup plus efficace, il ne permet pas d'identifier les "maillons faibles" sur le projet car le suivi des remises de livrables est le plus souvent peu formel et ne permet pas de détecter un  travail non fait, mal fait ou fait en retard. Ainsi sur un projet "agile", on peut mettre beaucoup plus longtemps à identifier les lacunes humaines et à y remédier.


En conclusion, il est indispensable de se rappeler que les méthodes agiles ne sont que des méthodes de développement. La conception doit rester une phase à part, et un réel pilotage de projet doit être mis en place. Si l'on garde ces éléments en tête, on peut tirer tout le profit de ces méthodes : une communication efficace entre métier et technique, des gains de qualité considérables et une meilleure prise en compte des problématiques techniques dans les projets, souvent négligées dans les phases de conception des traditionnels cycles en V.