Réponse à Appel d’Offre Agile

appel d'offresDernièrement j’ai été sollicité par une société de service en informatique pour les aider à répondre à un appel d’offre important (plusieurs M €) dans lequel l’Agilité était obligatoire.

Commençons par la fin en disant que l’histoire s’est bien terminée puis cette société a gagné les lots les plus importants de cet appel d’offre, puis revenons au début de l’histoire.

Histoire

Cela faisait de nombreuses années que je ne m’étais pas confronté à l’écriture d’une RAO (Réponse à Appel d’Offres), exercice que j’ai pratiqué quotidiennement, ou presque, de 1998 à 2002, et j’étais très intéressé à l’idée de replonger dans cet exercice difficile que néanmoins j’aime bien.

Le contexte était également particulier puisque le client était un fin connaisseur de l’agilité, il n’allait donc pas suffire de lui écrire des banalités sur l’agilité pour le convaincre de la compétence du fournisseur (J’ai déjà vu un simple copier/coller de Wikipédia ou du contrat type mis à disposition par Xebia … bonjour la compétence du fournisseur !!).

Pour la méthode Scrum, il n’était pas question de remplir la RAO de pages et de pages de description de la méthode, avec des schémas récupérés sur le net. Il ne fallait surtout pas confondre quantité et qualité, tout en sachant que dire « nous sommes agiles » ou « regardez toutes nos expériences agiles » n’allait pas suffire à convaincre.

Il y a avait également une demande de PQS dans l’appel d’offre, ou Plan Qualité de Service, avec certains indicateurs demandés … qui n’étaient pas forcément compatibles avec une démarche agile.

Alors comment se sortir de cette situation ?

Compétences Agiles

Pour convaincre le client de la compétence agile du sous-traitant, je suis parti des fondamentaux, c’est à dire les valeurs du manifeste. Une simple description de ces valeurs n’aurait pas suffit à le convaincre, alors j’ai décidé d’adopter une approche plus « personnelle » en décrivant comment ces valeurs étaient implémentées chez le fournisseur, et voici l’introduction de ce chapitre.

Chez XXXXXX, nous avons conscience que ce n’est pas la méthode choisie (Scrum, XP, Kanban, Crystal …) qui suffit à véhiculer ces valeurs au sein d’une équipe projet.
Pour être Agile, il est nécessaire de bien appréhender que l’Agilité n’est pas une façon d’améliorer les processus existants au sein de l’entreprise mais bien un réel changement de paradigme qui propose une nouvelle façon de réaliser les projets et en particulier de concevoir la relation entre le client et le fournisseur.

Les 4 sections suivantes décrivent comment nous implémentons ces 4 valeurs agiles au sein de nos projets et les points de vigilance de leur mise en œuvre.

Ensuite, pour chacune des valeurs du manifeste, j’ai donc indiqué les éléments, issus de ces valeurs, qui étaient importants (i.e.: la notion d’équipe performante, l’établissement de la confiance,  la gestion du changement …) et les propositions du fournisseur pour faciliter/accompagner/contribuer à la mise en œuvre de ces éléments dans le cadre du projet.

Méthode Scrum

Pour décrire la méthode, j’ai utilisé un principe similaire et la section démarrait par cette phrase.

La phase de lancement est décrite au § et pour la conduite de ce projet durant la phase opérationnelle, nous prévoyons d’utiliser la méthode Scrum telle que définie par Ken Schwaber et Jeff Sutherland. Comte tenu de la compétence de YYYYY en terme d’agilité et particulièrement sur la méthode Scrum, nous n’allons pas la détailler dans notre réponse. Nous allons simplement rappeler ses grands principes et décrire les aspects sur lesquels nous portons une attention particulière.

Ensuite, j’ai indiqué les éléments spécifiques qui, de mon expérience, peuvent rendre difficile la mise en œuvre de Scrum (pas les trucs de base bien entendu !) et les pratiques complémentaires qui permettent d’éviter certains désagréments.

Plan Qualité Service

Cette section était surement la plus délicate à rédiger et en particulier ce qui concernait les indicateurs, dont l’indicateur de Productivité qui était proposé.

Après avoir réduit au minimum les comités de pilotages, et surtout bornés ceux-ci à un suivi des aspects contractuels, il a bien fallu adresser les attentes du client en terme d’indicateurs. Si les indicateurs de mesure de la vélocité (désolé pour les défenseurs du #NoEstimate), la qualité fonctionnelle (Nombre de bugs en Prod), la qualité technique (« Dette Technique » … ou « Code Pourri » comme disait Pascal en keynote d’Agile Grenoble 2013) et la satisfaction du client me semblaient tout à fait pertinents, ce n’était pas la même chose pour l’indicateur de productivité. En effet, ce dernier était calculé en divisant la vélocité par le nombre de jours travaillé par l’équipe, donc un ratio de points produits pour 1 journée de travail.

Je n’aime pas du tout cet indicateur ! 

Je sais qu’il est largement utilisé dans le monde du service, cela doit surement rassurer certains responsables de production, et je le trouve totalement anti-agile car il génère un nombre de biais importants. J’ai donc proposé de remplacer cet indicateur par trois autres qui me semblent donner le même résultat sans comporter de biais anti-agile.

En complément des indicateurs demandés, j’ai également proposé au client 2 autres indicateurs, un premier pour mesurer la pérennité de l’équipe du sous-traitant et un deuxième pour mesurer la satisfaction des équipiers.

Bonus

Toute RAO se doit de contenir quelques propositions qui n’ont pas été explicitement demandées, c’est le bonus proposé par le fournisseur au client (ou « Excitment » en référence au modèle de Kano). Pêle-mêle, j’ai donc abordé des sujets tels que les tests fonctionnels, la recette avant mise en production, le traitement des anomalies ou la gestion documentaire, sans oublier au passage un petit tour pour visiter les communautés de pratiques.

Bilan

En corollaire, je dois dire que j’ai pris un réel plaisir à réaliser cette prestation.

Ma collaboration avec le fournisseur a été d’une très grande qualité, avec une confiance réciproque qui s’est rapidement instaurée malgré une certaine inquiétude initiale sur ma capacité à rédiger correctement une RAO … que j’ai rapidement dissipée 🙂

 

5 réflexions sur « Réponse à Appel d’Offre Agile »

  1. Bonjour,
    j’ai bien apprécié ce post sincere. Et ça m’a rappelé la seule fois où j’ai rédigé un RAO. C’était avant de m’intéresser serieusement à l’Agilité et j’avais été forcé de mettre beaucoup de blabla sachant que de nombreuses choses ne seraient pas vérifiées. Le principal était de gagner le marché !
    On sens bien ici que ca n’est pas la même démarche: elle semble beaucoup plus sincere.

    Neanmois, ce qui m’intrigue c’est comment ne pas se sentir malhonnete par rapport au valeurs de l’agile lorsque l’on est, comme c’est ton cas ici, en train de faire une RAO agile et que l’on ne va pas soit même participer au projet. Ce que je veut dire c’est que n’y a t’il pas une part de naiveté à s’investir et vanter les mérites de l’Agile alors que l’on est embauché seulement ponctuellement par une société de service qui ne maitrise apparemment pas si bien que ca l’Agile, sinon elle ne ferait pas appel à un consultant exterieur. Qu’est ce qui prouve que les valeurs agiles seront bienr respectées alors que c’est ce qui est vanté ici alors même qu’on fait appel à un intervenant exterieur ?

    Attention, hein, je sais que mes questions sont « limites » et pourraient etre mal interprétées et il ne faut surtout pas prendre les mots « malhonnete » et « naif » que j’ai écrit plus haut pour des attaques. J’ai vraiment trouvé le post intéressant mais il a en même temps soulevé de nombreuses questions en moi (et accessoirement m’a fait me souvenir du temps où j’etais en SSII 😉 ).

    François

    François, il n’y a aucun problème avec tes questions 🙂
    Voici quelques informations complémentaires :
    – J’ai formé les équipes du fournisseur
    – Je dois animer la communauté de pratique interne
    – J’aurais de l’information régulièrement sur le déroulement des projets
    Et de plus, j’ai trouvé que la démarche du fournisseur était sincère (j’ai discuté directement avec ceux qui vont faire et non juste le commercial) … l’avenir me dira si j’ai eu raison de leur faire confiance
    Un grand merci pour ton feedback
    Alex

  2. Bonjour,

    Merci pour ce post ! Je suis en SSII et travaille sur un plateau agile chez un client. J’ai participé à la rédaction du contrat et du PQS. Nous sommes parvenus à trouver pas mal d’indicateurs qui permettent à notre client de pouvoir mesurer la qualité de la prestation. Nous les avons fait évoluer au fur et à mesure du temps. Notre PQS est en constante évolution pour coller à notre organisation agile.
    Est-ce que la forme du contrat (régie, forfait)était imposé dans le cadre de l’AO ?

    La forme du contrat était entre les 2, c’est à dire certaines parties au forfait et d’autres qui se rapproche plus de la régie, sans en être réellement.
    Sinon il faut effectivement revoir régulièrement le PQS au cours de la prestation, c’est ce que j’ai proposé en mettant en œuvre des rétrospectives spécifiques.
    Alex

  3. Bonjour,

    Merci beaucoup pour cet article très intéressant.
    Je suis par contre curieuse de savoir comment as tu calculé les indicateurs de pérennité et de satisfaction des équipes ?

    Merci d’avance,

    Céline

  4. Pérennité : Chaque équipier présent durant 1 sprint marque 10 points (cumulatif de sprint en sprint jusqu’à un maximum de 100 points – 10 sprints). Par exemple à la fin d’un sprint, les 6 équipiers donnent un total de 100+100+80+60+40=380. Le fournisseur s’engage à maintenir ce total supérieur à 300 ce qui lui permet de changer un équipier s’il le souhaite, mais pas trop souvent
    Satisafcation : Un simple Happy & Fun est en place depuis plusieurs années

Laisser un commentaire

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