Digital Marketing

Pourquoi la méthode agile n’est pas faite pour vous

Est-ce que pour vous aussi l’agile s’est invité dans tous vos sujets, même les plus improbables ? Il faut être agile dans sa façon de penser, dans ses projets, dans son métier… même dans sa démarche budgétaire ! Remettons un peu d’ordre dans tout ça. L’agilité concerne avant tout une approche de la gestion de projet appliquée notamment aux développements logiciels. Mais cela ne correspond pas à tout le monde. Bien au contraire ! Explications.

Les méthodes agiles ne datent pas d’hier. La première mise en œuvre de Scrum remonte par exemple à 1993. Le Manifeste Agile, quant à lui, date de 2001 et regroupe la vision de 17 figures emblématiques du développement logiciel. Pour faire simple, la méthodologie consiste à faire la part belle à l’itération, l’interaction et la collaboration pour parvenir à un produit qui correspond aux objectifs sans être tout à fait parfait. Les principes sont louables mais appliqués à un développement de site web, cela n’est peut-être pas adapté à tout le monde…

1. Si vous n’êtes pas disponible

En tant que Product Owner (entendez celui qui est responsable de la vision du produit), vous devez être présent à chaque fin d’itération pour valider les fonctionnalités développées. Autrement dit, vous devez prévoir dans votre agenda, une réunion de démo d’une heure tous les quinze jours.

2. Si vous n’êtes pas impliqué dans votre projet agile

La réunion de démo implique ensuite de tester les fonctionnalités qui vous ont été présentées. De manière très régulière, il vous faut donc consacrer du temps à recetter le produit. Cette rigueur est nécessaire pour qu’à l’itération suivante, de nouvelles fonctionnalités soient présentées en considérant les précédentes finalisées.

3. Si vous n’êtes pas prêt à faire des choix

La méthode implique également de savoir faire des choix, d’admettre qu’une fonctionnalité n’est finalement pas utile en premier lieu pour l’utilisateur final. Et de convaincre les équipes dirigeantes parfois réticentes à revoir le périmètre initialement défini.

Lire aussi

Mon avis : après plusieurs années d’expérience sur le sujet, je constate que l’agile n’a de sens et d’intérêt que lorsque le client joue complètement le jeu. C’est-à-dire lorsqu’il est disponible tous les quinze jours pour effectuer une vraie recette des éléments développés, lorsqu’il est capable d’entendre que le périmètre d’une fonctionnalité peut être remis en cause, lorsqu’il comprend qu’ajouter des subtilités dans le développement impacte un sprint et donc la durée globale du projet (et le budget !). Sinon la méthode en V reste la meilleure option ! Rien n’empêche pour autant d’emprunter quelques concepts de l’agile pour trouver la meilleure méthode pour le projet de site web. On en parle ensemble ?