Water – Scrum – Fall … la réalité d’aujourd’hui ?

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.

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s