Les patterns d'adoption de l'agilité

La transition à une méthode agile se fait de différentes façons selon le contexte. Les façons de faire les plus fréquentes...

Une organisation qui passe d'un processus pas vraiment agile à un processus plus agile doit choisir entre de nombreuses voies possibles. Il y a en effet de multiples pratiques agiles, touchant les différentes disciplines du développement et il faut choisir par lesquelles on va commencer.

Au cours de ses expériences de consultant, Mike Cohn a identifié les patterns suivants pour des transitions à l'agilité :

  1. commencer en appliquant les pratiques d'ingénierie technique[1]
  2. commencer par la mise en place des itérations[2]
  3. commencer en appliquant les pratiques d'ingénierie agile des exigences[3]
  4. commencer petit [4]
  5. faire la transition pour toute l'organisation d'un coup
  6. introduire quelques pratiques discrètement[5]
  7. commencer par communiquer sur le processus de transition à l'agilité[6]
  8. commencer sur un projet en pleine crise

Ces patterns ne sont pas exclusifs et sont applicables en fonction du contexte. Ce sont les personnes chargées de la transition qui choisiront les patterns qui sont les plus adaptés.

Sur les projets sur lesquels je suis intervenu, les patterns d'adoption le plus couramment adoptés sont 2 3 et 4, généralement les 3 ensemble. Pour la publicité faite à l'agilité, plutôt 7 que 6[7]. Concernant les pratiques d'ingénierie technique, c'est très variable, cela dépend de ce que l'équipe fait déjà. L'introduction de nouvelles pratiques d'ingénierie peut être progressive[8].

J'ai eu l'expérience d'intervenir sur un projet en pleine crise et, après un audit, je leur ai proposé de passer à l'agilité en commençant par éliminer le gaspillage[9].

A part avec mes étudiants[10], je n'ai pas encore eu l'occasion de participer à un passage à l'agilité à grande échelle comme celui cité là, j'attends les organisations volontaires...

Notes

[1] par exemple intégration continue, pair programming

[2] itérations courtes, toutes de même durée et produisant un logiciel qui fonctionne

[3] user stories, backlog, product owner, implication du client

[4] avec ce qu'on appelle généralement un projet pilote

[5] en cachette du reste de l'organisation

[6] annoncer les objectifs avant de voir les résultats

[7] c'est rare de faire appel à un consultant en cachette

[8] sur un premier projet, il ne faut pas trop charger la barque du changement

[9] mais en même temps ils ont fait intervenir un consultant gestion de projet traditionnel, il y a des organisations schizophrènes

[10] 30 à 40 étudiants répartis sur 7 ou 8 projets qui démarrent en parallèle