Catégorie : Méthodes Agiles

Le titre provocateur « L’Agilité est morte » a envahi la blogosphère ces derniers temps avec des articles qui proposent toujours les mêmes solutions pour la sauver. L’ironie est que ces solutions pour sauver l’Agilité sont souvent les causes de son échec. Voici les 2 fausses bonnes idées les plus courantes.

Étendre l’Agilité à toute l’organisation

Il est couramment admis qu’une équipe agile, isolée et seule, ne peut pas fonctionner correctement si l’ensemble de l’organisation n’est pas elle-même agile et si l’ensemble du management n’est pas impliqué dans la transformation agile globale. Mais c’est une fausse bonne idée pour les raisons suivantes…

Toute transformation globale de l’organisation est une aventure à la fois coûteuse et extrêmement risquée. L’échec de la transformation globale est quasi certain. Cela aboutira au rejet de l’Agile. 

De plus, une transformation globale peut-elle être initiée avec une approche inventée dans le domaine informatique ? Même si le Digital a gagné en importance, une transformation d’une telle envergure ne peut être initiée qu’au niveau des Métiers. 

Enfin, il est utile de rappeler que l’Agilité, née dans les années 90, n’avait alors pas besoin d’une entreprise entièrement agile pour démontrer ses bénéfices. Les pionniers de l’Agilité ont prouvé que d’excellents résultats peuvent être obtenus sans un changement organisationnel global.

Plutôt que de prôner une transformation agile de l’ensemble de l’organisation, n’est-il pas plus judicieux de démontrer concrètement les bénéfices à petite échelle ?

Appliquer l’Agilité au-delà de l’Informatique

L’idée d’appliquer l’Agilité à d’autres domaines que l’informatique est séduisante. Si cela fonctionne pour l’IT, pourquoi pas ailleurs ?

En fait, rien ne garantit que cela marchera. Et en cas d’échec, c’est l’ensemble de l’approche agile qui pourrait être remise en question.

La première difficulté réside dans les spécificités de chaque domaine. Même dans  l’Informatique, l’Agilité n’est pas adaptée à tout. En effet, conçue pour le développement logiciel, l’Agilité n’est pas adaptée aux projets d’infrastructure.

La seconde difficulté est la résistance naturelle au changement. Les autres services de l’entreprise pourraient être satisfaits de leurs processus actuels et percevoir cette transformation initiée par l’informatique comme une intrusion indésirable.

Il faut faire une distinction entre l’Agilité dans le développement logiciel et les autres formes d’Agilité dans d’autres domaines. L’Agilité dans le développement logiciel a de solides fondements et des réussites reconnues tandis que les autres formes ont besoin de faire leur preuve.

Faut-il sauver l’Agilité ?

L’Agilité n’étant pas une fin en soi, une question s’impose: faut-il sauver l’Agilité ?

En fait, l’Agilité n’a pas besoin d’être sauvée. Si cela fonctionne, tout va bien et la question de sa survie ne se pose pas. Si il n’y a pas de bénéfices évidents, il faut chercher une approche plus adaptée.

D’ailleurs, l’Agilité comme un tout unique n’existe pas. Il y a juste des interprétations de principes très généraux et des tentatives de mise en oeuvre de ces principes.

Pour toute organisation qui se lancerait dans une mise en oeuvre de l’Agilité, notre conseil serait de toujours commencer à petite échelle.

En conclusion, on peut dire que l’Agilité « solution miracle » est morte. Les tentatives pour la sauver en la faisant passer « à l’échelle » risquent d’aboutir à une déception encore plus grande. Mais ce serait dommage de ne plus en faire du tout…

Souvent il est fait référence aux 4 valeurs agiles du Manifeste Agile. Mais cette expression « valeurs agiles » est bien mal venue. Elle freine la compréhension et l’adoption de l’approche agile en lui conférant un statut de dogme. Or l’Agilité est tout sauf un dogme.

« Valeurs Agiles » est un terme dangereux

Dire que l’Agilité repose sur des valeurs génère automatiquement des résistances lors de sa mise en oeuvre.

L’entreprise a ses valeurs. Les individus ont leurs valeurs. En positionnant l’Agilité sur le plan des valeurs, on déclare la guerre aux valeurs existantes, donc aux individus et à la culture des entreprises.

Or l’objectif de l’Agilité n’est pas de révolutionner la culture des entreprises, ni de changer les gens.

Le Manifeste Agile commence par « Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire. ». Il est facile de mettre tout le monde d’accord sur cet objectif quelles que soient leurs valeurs…

Un problème de traduction

Dans la traduction officielle du manifeste, on utilise le verbe valoriser et non le mot valeur.

Ces expériences nous ont amenés à valoriser :

• Les individus et leurs interactions plus que les processus et les outils
• Des logiciels 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

source: http://agilemanifesto.org/iso/fr/manifesto.html

On pourrait dire aussi donner plus d’importance à ceci plutôt que cela. Ce n’est pas une question de valeurs. C’est un choix de priorités.

Préceptes Agiles

Plutôt que de parler de « valeurs agiles », il vaudrait mieux dire les 4 préceptes agiles, c.-à-d. des « recommandations pratiques enseignées par l’expérience » (cf. Larousse).

Pour tous les « anciens développeurs » qui ont connu les méthodes et les processus lourds des années 90, les plannings de Gantt qui ne servent à rien, les spécifications incohérentes ou incomplètes, les projets au forfait qui tournent mal etc., les 4 pseudo-valeurs sont des recommandations pratiques issues des enseignements des erreurs du passé.

Et même si ce ne sont que de simples préceptes, ils s’opposent à la croyance dominante dans le monde de l’Entreprise. Cette croyance héritée du Taylorisme est que les méthodes et les processus seraient la clé de l’efficacité et de la réussite.

En s’opposant à cette croyance si largement admise, les préceptes agiles représentent un changement de paradigme. Ils sont donc déjà une mini-révolution.

En parlant de préceptes agiles plutôt que de valeurs, on redonne à l’Agilité sa nature d’approche pragmatique de recherche d’efficacité qui ne menace pas les valeurs de l’entreprise.

La plupart des retours d’expérience à propos de la mise en place de l’Agilité dans les organisations font apparaître un obstacle majeur: la transparence ne fait pas partie de la culture des organisations.

Pire, la transparence est le plus souvent découragée. On préfère faire bonne figure en toute occasion, quitte à minimiser les problèmes, afin de ne pas être injustement classé parmi les messagers porteurs de mauvaises nouvelles. Cela engendre le syndrome du projet pastèque, rouge à l’intérieur et vert à l’extérieur.

Or c’est justement sur la transparence, ou plus exactement sur le marché implicite «confiance contre transparence», que repose la démarche Agile. Grâce à elle, la collaboration entre le Métier et l’équipe de développement est beaucoup plus efficace, car elle est directe, peu formalisée dans des documents ou ralentie par des processus (de validation ou autres).

Pour passer à l’Agilité, il y a un changement de culture à opérer au niveau de l’organisation tout entière.

Les équipes de développement, et les chefs de projet en particulier, doivent désapprendre la crainte de se faire taper sur les doigts à chaque annonce de contre-performance ou de difficulté. Ils doivent trouver un courage nouveau pour communiquer les éventuelles mauvaises nouvelles le plus tôt possible. Cela permet à tous de prendre les bonnes décisions au meilleur moment. Le Management doit encourager cette transparence et associer la contre-performance à de l’apprentissage. 

Quant au Métier, il doit s’associer à l’équipe de développement et quitter le mode de collaboration client-fournisseur. S’associer implique de ne former qu’une seule équipe et de participer à la résolution de tous les problèmes, y compris techniques. Cela passe par une acquisition d’un minimum de connaissances techniques sur le projet et par la recherche active du meilleur compromis entre valeur métier et faisabilité. Un gain supplémentaire non négligeable pour le Métier sera d’en retirer au final une bien meilleure compréhension de son produit ou de son outil.

Les équipes sont-elles prêtes à faire part de mauvaises performances éventuelles ? Le Management pénalise-t-il les mauvaises performances sans distinction ? Le Métier a-t-il envie de s’impliquer dans la technique ? Les réponses à ces questions sont essentielles pour démontrer un environnement propice au développement de la valeur Transparence, indispensable à la démarche Agile.