Le passage à l’Agile : les difficultés

L'Agile évoque les concepts de Réactivité, Adaptabilité, Coopération ou encore Communication, qui séduisent les managers mais ne sont pas simples à mettre en place. Comme le souligne la coach agile Chen Ping, le passage à l'Agile nécessite un important soutien à la fois managérial et technique. De plus, il serait faux d'assimiler – comme c'est souvent le cas – l'Agilité à Scrum. Enfin, même si l'Agilité a été pensée pour les projets logiciels, elle peut aussi s'appliquer à d'autres domaines.

L'Agilité, dont les valeurs et principes sont recensés dans le Manifeste pour le développement Agile de logiciels, permet de gérer des projets de développement informatique, et entraine une grande réactivité de la part des équipes de développement. Cependant l'Agilité et les méthodes pour la mettre en œuvre comportent certains pièges, qu'il faut apprendre à repérer pour mieux les éviter.

 

"Pourquoi l'Agile n'a pas fonctionné" selon Chen Ping

Dans son article Pourquoi l'Agile n'a pas fonctionné (traduit de Why Agile Didn't Work), Chen Ping met à profit son expérience de coach agile pour souligner les principales causes d'échec du passage à l'Agile dans les entreprises. Si l'on résume, les problèmes de management sont les suivants :

  • L'agilité suppose qu'une même tâche puisse être effectuée par n'importe quel membre de l'équipe, mais en réalité tous n'ont pas les compétences nécessaires. Il faut donc être vigilant lors de la constitution des groupes de travail.
  • La mauvaise coordination voire le manque de confiance entre les différents acteurs empêche le succès des pratiques agiles.
  • Le Scrum Master manque de pouvoir pour aider son équipe et résoudre les problèmes, car c'est bien souvent un manager qui a le pouvoir de décision finale. Une solution serait que le manager lui-même, s'il en a les compétences, assure une partie des fonctions du Scrum Master.

Quant aux problèmes techniques, on peut les résumer ainsi :

  • Le non-respect de certaines règles établies, comme dans tous les domaines, peut entraîner d'importants ralentissements. Chen Ping prend notamment l'exemple des règles qui régissent le commit de code.
  • De mauvais outils de tests, qui sont évidemment synonymes d'une perte de temps et d'efficacité.

Comme le souligne Chen Ping, réussir son passage à l'Agile est en réalité plus compliqué qu'il n'y paraît et nécessite un important soutien, à la fois managérial et technique.

 

Scrum et ses imperfections

Lors de nos prestations, nous mettons nos clients en garde contre ce que nous appelons les "deux risques n°1" de Scrum : le manque de vision produit et la dette technique. Ces deux risques sont inhérents à l'Agilité, mais sont encore plus importants lorsque l'on applique la méthode Scrum.

Souvent, le Product Owner (PO) n'est pas représenté, ou bien pas représentatif. Le PO doit représenter le client et les utilisateurs finaux, mais dans nombre de projets c'est le Scrum Master qui joue ce rôle, ou bien une personne qui n'a pas toutes les qualités requises (manque d'autorité, de contact avec le donneur d'ordre, de connaissances métier...), ce qui entraîne des différences de vision produit.

La dette technique représente les compromis faits sur la qualité, qui ont tendance à prendre de l'ampleur en s'accumulant. Leur réparation a posteriori entraîne donc, à l'instar des dettes financières, d'importants "intérêts". Les cycles rapides préconisés par l'Agilité poussent encore plus à la tentation de ne pas s'occuper de suite de la dette technique, qui va devenir de plus en plus difficile à éponger.

Contrairement à d'autres méthodes agiles, Scrum n'apporte pas de réponse à ces deux problèmes, pourtant très fréquents lors du passage à l'Agile. Le PO est défini dans ses relations avec l'équipe de développement, mais pas avec les utilisateurs et les donneurs d'ordre, et même si la méthode Scrum préconise d'éviter les compromis sur la qualité par la définition du "fini", elle n'explique pas comment le définir.

On a souvent tendance à assimiler Scrum et Agilité, mais c'est une erreur. Bien qu'étant la méthode la plus souvent appliquée lorsque qu'une entreprise souhaite passer à l'Agile, car c'est en apparence la moins lourde à mettre en place, Scrum n'est que l'une des diverses méthodes agiles applicables. On peut citer parmi les plus connues le Kanban ou l'eXtreme Programming (XP), qui présente l'avantage de mieux répondre à certains risques.

 

Pour aller plus loin...

Dans son article Les 7 pièges des méthodes agiles, Yannick Lacaute décrit plus précisément nos "deux risques n°1", ainsi que d'autres pièges inhérents au passage à l'Agile.

 

L'Agilité appliquée aux projets non-logiciels

Si l'Agilité est par essence liée aux projets logiciels, la plupart de ces principes peuvent être adaptés à toutes sortes de projets, en gardant les valeurs décrites dans le Manifeste pour le développement Agile de logiciels, c'est-à-dire valoriser :

Les individus et leurs interactions plus que les processus et les outils
Des logiciels [ou des produits] opérationnels plus qu’une documentation exhaustive
La collaboration avec les clients plus que la négociation contractuelle
L'adaptation au changement plus que le suivi d’un plan

Cependant les principes de l'Agilité ne peuvent être appliqués qu'à un certain type de projets : ceux qui ne suivent pas obligatoirement d'ordre précis, dont les étapes sont interchangeables. Nous avons par exemple déjà utilisé Scrum au sein de JPI Conseil pour mener à bien un projet marketing, puisque ce type de projet peut s'effectuer avec une certaine souplesse. A contrario, il sera impossible de construire une maison de cette façon : on ne peut pas construire les différentes pièces si les fondations ne sont pas bâties, ou poser le toit avant les murs.

Pas de commentaire.

Ajouter un commentaire