Le constat

Oui, l’agilité gagne en popularité dans les organisations ! Du moins, apparemment. Les idées qui en sont à la base comme le « people centric » génèrent un réel intérêt. Aujourd’hui plus encore qu’hier, « agile » rime avec « Scrum ». Cet article met en exergue ce qui était déjà un soupçon fort, ce que j’appelle le Scrum « Canada Dry » dans mon article Scrum Shu Ha Ri :

• La MOA rebaptisée « Product Owner ».
• L’organisation matricielle, avec les développeurs devant partager leur temps sur plusieurs projets (je l’avait raté celle-ci)
• Des itérations qui ne couvrent que partiellement le cycle logiciel
• La « culture projet » où les équipes se font et se défont régulièrement au grée des projets.

Les organisations elle-même créent un carcan dans lequel inscrire un projet agile devient compliqué, à moins d’en pervertir la logique : logique budgétaire, silotage des activités, prédominance de la « logique document » et des releases parcimonieuses pour d’apparentes raisons économiques et culturelles.

Pourquoi ?

Ce constat met en relief un aspect quasi schizophrénique de l’adoption de l’agilité (d’où le titre de l’article). Celui-ci s’explique du fait de l’adoption des processus agiles par les praticiens qui tend à cloisonner l’agilité dans les équipes de développement, les équipes connexes restant attachées à leurs anciens processus. La réalité du « water-scrum-fall » se traduit par :

• En amont : de lourds processus budgétaire et cadrage qui engagent les développements sur des besoins mal connus ou erronnés mais définis à l’avance. Non seulement ce passage de relai anihile la flexibilité que l’on attend des processus agiles, mais il démobilise les équipes.
• Un développement « agile » mais au mandat amendé :
  • Moins de « cross-fonctionnalité » car les besoins sont traités ailleurs.
  • Pas réellement de « potentiellement déployable » car le test est déféré hors du sprint.
  • Pas d’interaction avec le client, car c’est l’objet du cycle amont.
  • Pas d’adaptation au changement car le plan est fixé quand le développement arrive à l’équipe.
• En aval : Une ligne de démarcation importante stigmatisée par une « séparation des responsabilités » qui crée une situation de confrontation entre développement et opérations conduisant à des releases moins fréquentes. Ces deux équipes ont par ailleurs des objectifs différents : la réponse aux besoins du business pour l’un, la stabilité et le maintient en conditions opérationnelle pour l’autre.

Quelles recommandations ?

Pour l’auteur, on peut enclencher les bénéfices de l’agilité avec ce modèle à 3 bandes :

• Faire maigrir la phase amont. La plus grande partie de la production de cette phase est du gâchis.
• Rendre l’équipe de développement réellement pluridisciplinaire. Donc en intégrant les capacité d’analyse et la relation avec l’utilisateur.
• Accroitre la fréquence des déploiements en aval.