Screenshot 2015-06-14 14.17.34

Les défis de la transformation agile

Mardi dernier, j’ai pu participer à la table ronde de Vertex sur les défis de la transformation agile.

L’objectif de ce meetup était de:

1 Présentation et discussion du panel sur les défis d’une transformation agile

2 Exemples typiques de transformation agile et de points à surmonter

3 Est ce que Agile est adapté à tous les secteurs d’activité?

4 Question et Réponses des participants

5 Discussions libres entre participants et membres du panel.

Invités pour la table ronde: Xavier Galleri, Guillaume Duquesnay, Franck Beulé et moi-même.

Face à une vingtaine de participants impliqués, il était intéressant de voir nos (les membres du panel) différentes interprétations de la transformation agile:

  • Xavier Galleri dans son approche mise principalement sur le Craftmanship (l’artisanat logiciel) et utilise Scrum comme une base pouvant être modifée.
  • Franck Beulé a une approche plus « corporate » à savoir que l’on ne touche pas à l’organisation et on essaie d’être agile dans les silos.
  • Guillaume Duquesnay a souligné son expérience chez France Télévision. Dans un exemple très pertinent à mon sens, Guillaume expliqua que dans ce projet les contraintes de temps étaient sévères et figées: « … on ne peut déplacer Roland Garros… ». Cette contrainte entraîna un sentiment permanent de développement « à l’arrache ».

Exemples typiques de transformation agile et de points à surmonter

Il y a eu différents exemples qui ont été évoqués tels que:

  • le changement organisationnel ou plutôt son absence

  • l’impact du cycle en « V ».

    • Sur ce point, je n’ai pas trop voulu m’étendre (je parle toujours de trop mais j’y travaille grâce au Prosac) car j’ai pu constater que le « cycle en V » n’est qu’un symptôme d’un problème plus profond, la recherche du pouvoir et l’opacité.
    • En clair, il n’y a pas de problème de disposer de mini cycle en « V » dans un Sprint pendant une période de transition. Pourquoi cela? Cela permet aux testeurs, aux développeurs d’assurer une livraison a minima et de conserver leur place. Si vous supprimez le « mini cycle en V », la perturbation occasionnée peut être plus préjudiciable que salutaire et il vous faudra construire une « vraie » équipe cross-fonctionnelle capable d’analyser, concevoir, tester unitairement, recetter, valider et intégrer. Donc adieu les rôles de DevOps, intégrateur, Architecte etc… En clair, c’est un objectif à long terme.
    • Le problème que j’ai pu découvrir est davantage comportemental: en moyenne 80% des personnels des équipes sont des consultants externes qui « doivent » se taire et les « 20% » restant cherchent à se valoriser pour monter dans la pyramide hiérarchique. Ceci est encore plus important sur les contrats de prestations où les membres du prestataire sont contraints au silence et le client utilisant l’agilité comme argument pour « commander et contrôler ».
    • Bref, de mon point de vue, le vrai chantier est de sortir d’une relation « CLIENT/FOURNISSEUR » et démarrer une relation de « PARTENARIAT » où chacune des parties dispose de la liberté de parler de ses erreurs.
  • les contrats:

    • les contrats sont toujours un vaste débat et certains intervenants ont discutés sur le contrat agile de Xebia et d’autres sur leur discussion avec des avocats.
    • concernant les contrats, J. Sutherland et A. Cockburn ont très bien documentés le sujet pour proposer différentes variantes (voir ici).
    • un contrat par principe doit permettre aux deux parties de trouver un commun accord pour travailler de la manière la plus optimale ensemble. Ma maigre expérience française me permet de m’avancer à dire que dans les contrats il y a toujours un cocu et ce n’ai jamais le client. En tant que prestataire, on vous indique une date de paiement qui est en moyenne de 45 jours. En réalité, cela va largement au-delà. Par exemple, l’an passé j’ai travaillé avec Wemanity et, sans rentrer dans le détail, moins de 20% des engagements ont été tenus de leur part. Bref, les contrats même agiles devraient disposer de contraintes liées aux abus des crédits fournisseurs.
  • les services achats et les commerciaux (business développeurs).

    • Il est trop fréquent de voir une offre de transition bien conçue émasculée par une volonté de réduction des coûts et cela part des parties non-prenantes au projet.
    • Dans un précédent audit dans une banque internationale, l’offre initiale du POC de 100.000 jH prévoyait une liste de développeurs qualifiés, du coaching agile, de la formation scrum pour toutes les parties prenantes et une assistance de 30 jours de 2 experts techniques.
    • En fin de compte et après négociation entre les commerciaux et les acheteurs, il n’y avait plus de coaching, la formation s’est réduite à 5 heures de présentation en groupe, les développeurs off-shore sortaient de l’école et n’y connaissaient rien, les experts techniques étaient au bord du burnout après 6 mois.
    • Résultat: le client a maintenu ses coûts mais à mis son programme en risque majeur impliquant la mise en place de solution radicale et l’engagement d’experts supplémentaires (sur un autre budget), le prestataire perdant de l’argent s’est retrouvé avec un turn-over de 35% et des arrêts cardiaques sur site. Bref, les acheteurs et les commerciaux ont eu leur promotion!

Conclusion:

Cet évènement est une belle idée. Une belle idée….

 

la bise

 

Pierre