Published by

Il y a 13 ans -

Temps de lecture 6 minutes

Agile Tip n°1 : comment aborder un projet en difficulté avec Agilité ?

Nous connaissons tous des projets qui ne marchent pas et les raisons peuvent être nombreuses, nous n’allons pas y revenir. Alors comment faire quand vous vous trouvez au chevet de l’un de ceux ci ?

Le but de ce billet n’est pas de vous donner une méthode universelle mais juste quelques conseils, en toute humilité.

Règle n°1 : accédez au bon interlocuteur

.
Quand un client vous invite à sa table pour évoquer ses déboires sur un projet ou ses projets en général et vous demande d’y remédier, posez vous tout de suite la bonne question: avez-vous accès au bon niveau de management ?

Fuyez tout interlocuteur qui vous expliquera qu’untel dans la division d’à côté porte la responsabilité des problèmes rencontrés (par exemple la MOA vous expliquera que la MOE est responsable, la MOE vous expliquera que l’intégrateur ou les équipes internes ne sont pas à la hauteur.). Celui à qui vous devez parler n’entre pas dans ce genre de considération.

Votre interlocuteur, doit présenter les deux caractéristiques suivantes :

  • 1/ Il doit avoir intérêt à ce que le projet marche et est capable de vous chiffrer très précisément ce que lui coûte l’échec, chaque jour (perte de CA, de marché, de marge,…). Si votre interlocuteur ne peut pas clairement quantifier les impacts liés à ses déboires alors qu’il est au bon niveau c’est que l’application n’est pas critique pour l’entreprise et avec un peu d’acharnement thérapeutique, votre client parviendra à faire finalement marcher son projet et il n’a pas besoin de vous.
     
  • 2/ ll doit être capable de supprimer tous les obstacles (impediments en anglais dans Scrum) et cela quelque soit la nature de ceux-ci. Il doit par exemple être capable de changer le processus des achats (et oui, rien que ça!), investir les fonds nécessaires pour sauver le projet, mobiliser et rendre disponibles les bonnes ressources en interne comme en externe.

Pour résumer, il doit être au niveau n ou n-1 de l’organisation.

Si nous ne pouvez y accéder, laissez tomber, en expliquant pourquoi vous ne pouvez rien faire pour votre client/prospect. Vous perdez en effet votre temps et si vous prenez le projet, vous subirez les mêmes travers que ceux qui se sont cassés les dents avant vous.

Règle n°2 : procédez par étape.

Une fois que vous vous êtes assuré que les ingrédients d’une bonne et franche prise de consience des problèmes passés sont réunis et que votre client a le pouvoir de changer les choses, alors appliquez la règle #2.

1/ Etablir un nouveau Product Backlog

Les difficultés rencontrées présentent le bénéfice d’avoir fait évoluer les mentalités, préciser plus finement les besoins. Vous avez la chance d’hériter d’une expérience que vous n’avez pas vécue, ce qui est suffisamment rare pour être exploité au maximum. Reprenez donc rendez vous avec les utilisateurs impliqués sur le projet, invitez en d’autres et repriorisez le travail qui reste à faire pour le mener à bien.
Identifiez avec eux ce qui DOIT être fait et ce qui PEUT ETRE DECALE à plus tard. Passez du temps sur cette étape, affinez, négociez, obtenez le consensus. Soyez un jusqu’auboutiste du LEAN (la suppression des gaspillages). Un petit conseil: confrontez les utilisateurs à votre interlocuteur de plus haut niveau, vous verrez que les besoins réellement vitaux subsistent tandis que le superflu est très vite passé aux oubliettes.

2/ Analysez les obstacles passés

Y a-t-il eu des problèmes d’organisation, des compétences manquantes, des ressources insuffisantes, des carcans contractuels trop contraignants? Toutes les questions méritent d’être posées. Aucune ne doit être occultée, passée sous silence pour d’obscures raisons politiques. Si vous butez sur cette étape, retournez à la règle n°1 car vous n’êtes pas au bon niveau.

Passez beaucoup de temps à l’établissement d’une liste exaustive et précise des obstacles rencontrés. Présentez cette liste à votre interlocuteur car celui-ci doit formellement s’engager à supprimer tous ces obstacles ainsi que tous ceux qui se présenteront. Si vous n’obtenez pas cela, considérez que vous avez fait un très bon audit de la situation mais restez en là.

3/ Evaluez la vélocité de votre équipe

Il est de coutume chez votre client comme partout de dire que le travail X est fait en n jours par l’équipe de développement Y. Partez du principe que c’est faux, que tout doit être à nouveau démontré. Comme partout, tout le monde se fourvoye depuis des années sur les capacités de l’équipe Y et les délais sont régulièrement dépassés.
Pour connaître la vérité sur ce sujet, obtenez de votre interlocuteur le droit de lancer 2 ou 3 sprints qui certes, vont faire avancer le projet (ce qui finira de convaincre votre interlocuteur) mais qui vont surtout vous donner avec certitude une estimation des capacités de votre équipe. Après 2 ou 3 sprints, vous saurez enfin ce dont elle est capable et pourrez vous engager auprès de votre interlocuteur.

4/ Négociez avec votre interlocuteur

Lui-même a peut être une idée faussée de sa deadline. Après avoir passé tout ce temps dans l’entreprise, vous serez à même de lui faire peut être accepter une date plus lointaine ou un Product Backlog légèrement édulcoré.
Demandez-lui les ressources dont vous aurez besoin. Portez une attention toute particulière au Product Owner qui doit être capable d’arbitrer des choix parfois difficles dans la priorisation des fonctions du logiciel. Il doit en général être un homme (ou une femme) de confiance de votre interlocuteur. Veillez au renforcement éventuel de l’équipe par des éléments clef (le ScrumMaster en particulier, si ce n’est pas vous), au remplacement de certains membres empêchant l’équipe d’avancer et aussi au « clonage » d’éléments devenus trop importants dans le dispositif car uniques (tout membre d’une équipe Agile doit pouvoir être remplacé).

Règle n°3 : ne transigez pas sur les principes fondamentaux de l’Agilité

Ne tombez pas dans les mêmes travers que les autres, ceux qui ont échoué avant vous. Respectez quelques éléments fondamentaux.

  • Une attention toute particulière doit être portée à la qualité du travail, quitte à réécrire des pans entiers de l’application dont vous héritez et tant pis si cela coûte cher (nous écrirons un billet sur le coût de la non qualité).
  • Respectez votre équipe et notamment son rythme. Laissez lui de l’espace, de l’autonomie. Vous n’êtes pas un général en chef qui reprend une armée en dérive, qui dicte ses instructions à des soldats désemparés mais plutôt un chef d’orchestre qui reprend une équipe capable dont vous ne doutez (et ne douterez) pas une seconde. Elle, en revanche, a le droit de douter de vous, de son chef car celui (ceux) d’avant n’a (n’ont) pas vraiment brillé par ses (leurs) résultats.
  • Respectez le fonctionnement même des principes agiles comme une taille fixe de sprints, l’évaluation de ce qui se fait dans les Sprints par le Poker Game, la livraison d’un logiciel opérationnel à chaque fin de Sprint, ….

 

A bientôt pour l’agile tip n°2.

Published by

Commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Sapient, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.