vendredi 23 novembre 2012

Agile Tour Paris 2012 : REX - 10 pièges à éviter

Tuan Vo Vinh de la Société Générale nous propose son retour d'expérience de la transformation agile et plus particulièrement de la mise en place de Scrum au sein des équipes qu'il gère. Il nous explique que sa motivation était sa frustration de n'avoir assisté jusqu'ici qu'à des conférences présentant des retours d'expérience de transition agile positive et sans problème. Son objectif est donc de nous présenter les erreurs et ratés qui sont survenus sur ses projets mais également les solutions qu'ils ont trouvées pour régler ces difficultés. Sa présentation consistait donc en une liste de 10 erreurs commises par une partie ou l'autre et ce que lui, en tant que non-agiliste, et ses coaches ont appliqué comme solution.

1) La fraude sur la marchandise :
Certaines choses paraissent évidentes pour les utilisateurs comme par exemple le fait que les anciennes fonctionnalités seront inclus dans le projet de refonte de leur produit. Malheureusement, ils n'expriment pas ce besoin auprès du PO qui acte donc le fait qu'ils ne souhaitent plus certaines fonctionnalités...
Solution proposée : avoir une liste d'exigences et un minimum viable product bien définis.

2) La prime d'assurance :
Le coût de l'agilité n'a pas été anticipée. Surtout l'erreur a été commise de considérer que les sprints seraient un succès à 100%, ce qui a entrainé un surcoût au final.
Solution proposée : prendre en compte le coût de l'agilité (rituels et estimation)

3) Oublier la vision :
Il survient au fil des sprints un problème de vision à long terme. Le PO reste focalisé sur le sprint N+1 voir N+2 mais en oublie qu'il y a par exemple une v2 dont les exigences peuvent demander certains aménagements pour éviter le faire/défaire/refaire.
Solution proposée : Remember the future en permanence !

4) "In God we trust" :
Penser à tort que le PO sait tout et ne se trompe jamais.
Solution proposée : challenger le PO, par l'équipe ou le project manager.

5) Engagement mou :
Il arrive que l'équipe ait une baisse d'engagement. Les solutions apportées par le management furent dans un premier temps agressives (heures supplémentaires) puis douces (récompenses en temps libre si engagement du sprint respecté). Cela n'eut aucun effet sur l'engagement.
Solution proposée : avoir des profils seniors moteurs

6) "Please do not disturb" :
Pas de gestion des imprévus alors qu'il y a des impératifs. Le sprint est trop isolé.
Solution proposée : l'adaptation ne veut pas dire échec. Acquérir la capacité de déscoper et restaffer.

7) Plaire au client, oublier le reste :
Typiquement les user story au black pour plaire aux demandes des sponsors/clients.
Solution proposée : ne pas sortir du backlog les fonctionnalités non fonctionnelles.

8) "What you see is NOT what you get" :
Conséquence de l'effet démo :le client pense à tort que parceque ça marche en démo, alors la fonctionnalité ne connaitra aucun bug en production.
Solution proposée : toujours avoir des tests UTILISATEURS avant le mise en production accepter les régressions tester les cas limites faire des sprints de bug fix

9) L'armée de clones :
Penser que tout le monde est identique car les performances individuelles sont masquées par l'équipe qui forme une entité. Le manager ne peut pas récompenser l'excellence individuelle.
Solution proposée : "one to one coaching et feedback" sans influence externe.

10) Pas pour les enfants :
l'Agile semble facile. C'est faux : la mise en place et le bon fonctionnement est difficile !
Solution proposée : choisir les bonnes personnes capable de le faire. Si les personnes n'acceptent pas l'agilité, c'est peut-être que ce n'est pas la bonne organisation pour l'appliquer.


Au final, ce qu'on peut voir c'est que l'agilité est difficile d'application. D'un point de vue personnel je ne suis pas d'accord avec certaines des solutions apportées qui font plutôt penser à une mauvaise compréhension de scrum. Cependant, chacun trouvera des solutions aux problèmes selon son contexte et les solutions proposées par Tuan Vo Vinh ont le mérite d'avoir fonctionné pour les projets SGIB, dans leur environnement particulier, ce qui n'est pas forcément une mauvaise chose après tout...

ROTI : 3/5

4 commentaires:

  1. Si cela a fonctionné, tant mieux ! je dirais... mais avec un sourire déçu.

    Beaucoup de choses sont ici loin, très loin, de la culture agile.
    Par exemple : la question sur la "prime d'assurance" est aux antipodes d'une pensée agile.
    Pas d'exigences en agile, c'est une appellation risquée qui détourne du but premier de la user story : exprimer de la valeur fonctionnelle/métiers.
    Au contraire : ne PAS accepter les régressions, ne pas tester les cas limites si ils ne sont jamais joués, ne pas faire des sprints de "bug fixe" car on corrige les bugs dès qu'ils apparaissent. Ce n'est pas simple mais c'est CA l'idée.
    etc etc

    Le diable se cache dans les détails : ici l'agilité ne me semble que d'apparence. Peut-être est-ce moi qui me trompe, peut-être que la forme me trompe, etc.

    Mon avis : appeler la session "notre chemin vers l'agilité". Ils font manifestement des efforts, ils essayent, c'est très bien. Mais il faut qu'ils entendent qu'ils n'y sont pas encore, qu'ils n'ont pas compris l'état d'esprit. (Il faut bien le dire non ? sinon on va laisser s'imposer un agile qui n'en est pas un). Je suis sûr qu'ils apprécieront et qu'ils remettront la main à la pâte.

    pas assez de "pourquoi" trop de "comment" ici.

    Bye




    RépondreSupprimer
  2. Encore moi.
    Donc je récapitule ce que je lis :
    on fait des exigences
    le daily scrum est un coût
    ne pas écouter le PO
    Une baisse dans l'engagement c'est pas bon, on s'engage pas comme on veut hein
    On change le contenu et les membres de l'équipe si nécessaire
    On fera des sprints de "bug fixe" après, pas grave si à la démo ça marche (si on a de la chance) on corrigera plus tard
    Gardons les individualités dans la gestion des primes, cela motivera l'équipe

    j'ai compris ?

    RépondreSupprimer
    Réponses
    1. Effectivement, la présentation avait un air de WTF par moment...
      Ensuite l'intervenant s'est défendu à plusieurs reprises d'être un non-agiliste. Et comme il a un poste de manager, on imagine facilement les dérives que cela a finalement occasionné sur ses projets...

      Ironiquement, ce n'est pas la première fois que j'entends qu'une transformation agile n'a pas été un succès dans le monde de la banque. Je dis ça je dis rien mais il y a probablement une histoire de culture...

      Supprimer
  3. Hello
    J'attends la vidéo. Elle devrait sortir si c'était dans le grand amphi.
    Bye

    RépondreSupprimer