5 autres idées fausses à propos des Méthodes Agiles

Idée fausse n°6: les Méthodes Agiles, c’est la liberté de faire à sa façon

Equipe en « autogestion », remise en cause du rôle de chef de projet, redistribution des responsabilités, suppression des aspects contractuels, pas de planification détaillée, absence ou presque de documents, communication principalement verbale…

Tous ces éléments, qui séduisent les équipes, ont un petit goût de liberté et d’émancipation, qui risque d’être mal perçu par le management traditionnel.

Cependant il serait faux de considérer que l’Agilité est synonyme d’absence de règles, de contraintes et de structures.

L’Agilité est avant tout un changement de priorité, comme le montrent les 4 principes du Manifeste Agile. Avec plus de recul, c’est aussi un changement de la nature même d’un projet, dont les objectifs ne sont plus le respect d’un cahier des charges, de coûts et de délais.

Or tous ces changements reposent sur des modèles d’organisation différents qui ont leurs propres règles.

Pour être Agile, il ne suffit pas de ne pas appliquer les anciennes règles, il faut surtout appliquer les nouvelles.

Idée fausse n°7: L’Agilité, c’est simple donc c’est facile

L’Agilité est synonyme de légèreté et de simplicité.  Il est naturel d’y voir une promesse de facilité.

Cette promesse est corroborée par les livres sur l’Agilité, bien moins épais que leurs prédécesseurs.  Les principes et les concepts présentés sont beaucoup moins nombreux et plus simples.

Acquérir la théorie est donc facile, mais qu’en est-il de la pratique?

En pratique, les méthodes Agiles imposent des exigences très fortes sur les individus et les organisations.

Pour les individus, il y a d’abord une exigence en matière de compétences techniques afin de produire un logiciel de qualité, évolutif et maintenable, bien testé etc. Ceci n’est pas propre aux méthodes Agiles. La différence est que cela devient une priorité avec l’Agilité.

Pour les individus, il y a ensuite une exigence de savoir-être et de discipline personnelle pour collaborer, communiquer, s’engager, s’autogérer… Il est très difficile de mettre en place le Pair Programming; et un Daily Scrum peut facilement tourner à la foire d’empoigne.

Pour les organisations, il faudrait presque une réorganisation. Par exemple, pour impliquer davantage les métiers dans le développement, pour redéfinir les postes (chef de projet, scrum master etc.) etc.

Pour les organisations, il y a aussi le problème du manque de visibilité à moyen et long termes avec un impact sur la budgétisation des projets.

Enfin, l’Agilité repose sur une exigence forte de Transparence. Cela peut avoir des implications lourdes pour les organisations et les individus. Ken Schwaber, co-auteur de la méthode Scrum, énonce avec provocation une conséquence directe de cette transparence renforcée par des feedbacks rapides: « [ l’Agilité ] expose l’incompétence« . Dit comme cela, cela fait réfléchir…

Dans la pratique, très peu d’équipes arrivent au bout d’une démarche Agile. Mais heureusement, le passage à l’Agilité peut se faire progressivement avec des gains immédiats (cf n°9).

Idée fausse n°8: Les Méthodes Agiles exigent des développeurs seniors

Les exigences de l’Agilité sur les individus (cf. n°7) induisent à penser que les méthodes agiles sont réservées à des équipes expérimentées, voire des équipes de champions du développement. Ceci est exagéré.

Le minimum requis par l’Agilité serait plutôt une équipe composée d’un coach expérimenté et d’individus ouverts d’esprit, capables de se remettre en cause, capables d’apprendre et surtout qui ont envie de progresser.

Par rapport aux autres méthodes, un avantage des méthodes agiles est de faciliter la montée en compétences rapide des membres de l’équipe.

Comment ? Tout simplement grâce à aux cycles itératifs très courts qui permettent des retours rapides sur la performance et de s’améliorer sur l’itération suivante. Dans SCRUM, cela est institutionnalisé sous la forme de Rétrospective en fin d’itération.

Par ailleurs, des pratiques comme le Pair Programming et le Daily Scrum facilitent grandement la transmission de connaissances entre les membres du projet.

On peut retenir un principe: moins l’équipe est expérimentée, plus le « Coach » doit l’être.

Idée fausse n°9: Incompatibilité avec les démarches classiques

Les méthodes agiles proposent des pratiques qui, prises séparément, ne sont pas incompatibles avec les approches classiques (cycle en Cascade, CMMI, PMBoK etc.).

Par exemple, il est possible dans un cycle en cascade d’introduire du Pair Programming, des Rétrospectives, des réunions quotidiennes, du Planning Poker, des Burndown charts, de l’intégration continue, du Test Driven… Pourquoi pas ?

S’il y a incompatibilité, ce n’est pas au niveau des pratiques, mais plutôt au niveau des valeurs.

Idée fausse n°10: L’Agilité peut s’appliquer à tout

Même dans le développement logiciel, l’Agilité n’a pas toujours été possible. Comment imaginer l’Intégration Continue ou le Test Driven dans les années 60 alors qu’il fallait réserver plusieurs jours à l’avance du temps machine sur le serveur central et imprimer son logiciel sur des cartes perforées…

Pour être Agile, il faut le vouloir mais aussi le pouvoir.

Dans des domaines, comme le bâtiment ou l’industrie*, les contraintes ne permettent certainement pas d’être aussi agile que dans le développement informatique.

Dans un projet au forfait, une démarche purement agile est inconcevable. Il faut nécessairement fixer le périmètre.

Dans un projet de déploiement, l’Agilité risque d’apporter plus d’inconvénients que d’avantages.

Pour pouvoir être Agile, il faut que le changement soit souhaitable mais aussi possible à faible coût. C’est pourquoi le développement logiciel est le domaine privilégié de l’Agilité.

* Dans l’industrie, il y a le Lean Manufacturing. Cette approche partage certaines des valeurs et des objectifs de l’Agilité, mais avec des pratiques différentes adaptées à l’industrie.