L’agilité sans les bonnes pratiques de développement, est-ce possible ?

On associe souvent l’agilité à la réalisation des développements en mode itératif, à la mise en place des Daily meetings, des sprints et de temps en temps des rétros — et on considère qu’on fait de « l’agilité ».

Quid des bonnes pratiques agiles telles que l’automatisation des tests, le TDD ou le BDD ? Quid de l’automatisation des déploiements ? Quid de la qualité du code et de la dette technique ? Peut-on commencer sans vision claire sur l’ensemble de ces axes ?

Ces débats ressemblent bien souvent à une bataille des experts techniques contre les métiers, où tout le monde a ses raisons mais personne n’est d’accord. La décision de mettre en place ces bonnes pratiques arrive souvent tardivement et se fait au détriment de fonctionnalités métiers et d’autres priorités.

Mon avis est assez tranché : il faut que les bonnes pratiques de l’agilité soient mises en place rapidement, et surtout ne pas avoir peur de dégager du temps pour démarrer ce processus. Le temps est souvent l’ennemi des bonnes pratiques. Le débat doit être sérieux et éclairé, sans être très technique.

La mise en place de ces bonnes pratiques est un vrai sujet, sur lequel de nombreux projets ont failli. Les considérer comme des options « si nous avons de la capacité dans le sprint » est une très mauvaise idée, car la décision se prendra toujours au dernier moment. Leur intégration doit être faite dès le début.

Il faut également prendre le temps d’expliquer aux parties prenantes la pertinence de ces bonnes pratiques pour obtenir un système plus robuste et plus performant. Avoir une vision claire n’est pas un luxe, c’est le minimum pour réussir.

J’en conclus que l’agilité sans les bonnes pratiques de développement est une chimère — d’où le titre de cet article.