S'adapter au contexte... et vice versa

Dans cet article, paru en septembre 2000 dans "Langages et Systèmes", j'écrivais page 6 "Adopter XP implique des mutations". Il me semble que cela s'applique à l'agilité de façon plus générale.

Que la mise en oeuvre d'une approche agile tienne compte du contexte, de l'environnement, me parait être une nécessité. C'est d'ailleurs un principe d'XP : adaptation locale.

D'un autre côté, être agile correspond à un changement de rôles d'identités des personnes actives du projet. Le Chef de Projet MOA devient par exemple "Client" XP ou Product Owner Scrum. Ce n'est pas le même rôle. Dans cet ordre d'idée, laisser à penser qu'un Chef de Projet MOE se transforme naturellement en ScrumMaster ou Coach agile est à mon sens démagogique. Un peu comme un bon technicien ou ingénieur qui deviendrait naturellement bon manager... Ou un bon mathématicien qui deviendrait bon prof de mathématiques. D'autant plus que cela ne facilite pas la prise de conscience de la différence des rôles.

Cette différence de rôles, de pratiques,  de responsabilités... est due à un autre changement, encore plus profond : le projet lui-même change, dans le cadre d'une transition vers l'Agile. Pour être clair, le point focal n'est pas le projet, plutôt le produit. Habituellement, nous avons deux phases macro pour un produit :

1. Développement (y compris pré-étude), qui se concrétise par la mise en exploitation
2. Maintenance, bien souvent prise en charge par une équipe différente.

Dans une approche agile, centrée sur le système et les livraisons fréquentes, le schéma est :

1. Exploration ou "sprint 0"
2. Première version (à Tzéro + 3 mois par exemple)
3. Deuxième version (à + 3 mois...)
4. etc

Si l'Agile s'adapte au contexte, ce contexte - et les personnes qui le composent - s'adaptent à l'Agile. Il s'agit de "virer sa cutie" : de CP MOA on devient Product Owner, de Développeur on devient Extreme Developpeur, etc.