Les méthodes agiles ou comment concilier innovation et exécution de projet

Vous avez un projet innovant, autour d’objets intelligents et vous demandez quelle méthode de pilotage de projet adopter ? Les méthodes agiles vous attire mais vous vous demandez, concrètement, ce que cela implique?

Vous êtes au bon endroit!

Par définition le développement d’un projet innovant ne peut pas être imaginé et planifié parfaitement. Il est cependant nécessaire de tenir les contraintes de planning imposées par les équipes marketing et les enveloppes budgétaires imposées par leur Direction.

Parce que vous redoutez de tomber sous le coup de loi du facteur Pi (la durée réelle des projets est 3 fois supérieure à celle prévue initialement), le dispositif d’exécution de votre projet se doit d’être fiable et souple.

Qu’est ce qu’on entend par cela?

Le périmètre peut changer, il va changer, mais votre budget et votre timing doivent être protégés, en respectant le niveau de qualité adapté et en disposant d’une équipe stable.

Alors, comment les méthodes agiles peuvent vous garantir les meilleures chances de réussite tout en protégeant ces deux impondérables ?

C’est ce que nous allons voir ici.

Les caractéristiques des méthodes agiles

Le développement agile apparaît comme une alternative intéressante face au traditionnel développement en cascade. Le fonctionnement Agile prend en compte dès le départ le budget et le timing comme des données d’entrée fixes. C’est donc le contenu du développement qui sera la donnée variable.

Ainsi, les équipes vont mettre l’effort sur ce qui a le plus de valeur pour permettre de développer dans le temps imparti un produit fonctionnel correspondant au budget donné. Les méthodes agiles fonctionnent avec des livraisons régulières (cf ci-dessous), ce qui permet d’adapter la suite (amélioration de la première version en fonction des retours utilisateurs, développement de la fonctionnalité n°2 si les résultats sont bons, …).

Différents types d’outils et rôle existent pour appliquer les méthodes agiles.

1. La matrice valeur-effort

Elle permet de remettre en perspective l’essence même du produit et de revenir à l’essentiel en priorisant les différentes fonctionnalités dont on souhaiterait doter le produit. Elle consiste en un tableau qui va situer chaque feature ou caractéristique en fonction de la valeur qu’elle rapporte et de l’effort à fournir correspondant.

Ce tableau définit ensuite naturellement les quick-wins (fort ROI et peu d’effort), les choses à abandonner (ROI faible et demandant beaucoup d’efforts), celles qui apportent de la valeur mais demandent beaucoup d’efforts et celles qui apportent un peu moins de valeur mais qui représentent peu d’efforts et sont à réaliser si les plus importantes sont déjà traitées (cf le tableau ci-dessous).

2. Le product owner

Il y a également la volonté d’inclusion : on va désigner un product owner, qui sera le garant du développement du produit chez la société porteuse du projet. La particularité est qu’il intègre l’équipe comme s’il en faisait partie : il participe aux échanges, il va challenger les équipes sur le développement produit, aider à prioriser les actions. Il n’y a qu’une seule et même équipe : il s’agit là de réelle co-traitance. Le fournisseur n’est donc pas là uniquement pour réaliser le cahier des charges.

Ensemble, ils vont s’assurer du développement de la meilleure version possible du produit.

3. Les user stories

Les ateliers de rédaction de user stories constituent également un outil performant lors du développement produit. Une user story est une demande fonctionnelle basée sur un utilisateur clé du produit qui va rajouter de la valeur business au produit. Elle sera écrite dans un langage naturel compris par l’ensemble des acteurs liés au projet. Ces ateliers sont organisés tout au long du développement du projet.

4. Le développement en sprints

Les développements sont ensuite organisés en sprints (de 2/3 semaines). Cela permet de pouvoir tester les premières fonctions au bout de quelques semaines pour en valider ou en écarter certaines. Cela permet également d’ajuster le niveau de chaque fonction, une fois les tests effectués. Ainsi, le produit aura plus de chance de succès, car il sera en adéquation avec les attentes finales.

La contractualisation : vecteur de réussite du développement projet

La contractualisation permet également de capitaliser sur la réussite du produit. En effet, certains contrats tiennent davantage de la co-traitance que de la simple relation client-fournisseur. Chez Rtone, nous avons l’habitude de travailler avec des contrats 50/50 ou “stop ou encore” :

1. Le contrat 50/50

Le contrat 50/50 a un coût mensuel et un délai cible estimé pour un périmètre figé à l’avance. Si le projet finit plus tôt, les 2 parties sont gagnantes et se partagent les bénéfices. Si le projet n’est pas fini dans le délai imparti (qu’on donne avec une marge d’erreur, par exemple 8 mois, +/- 2 mois), les 2 parties ré-investissent au prorata du dépassement. Cela va encourager les équipes à finir dans les temps.

2. Le contrat « stop ou encore »

Le contrat “stop ou encore” a aussi un coût mensuel. On établit une liste de fonctionnalités envisagées et à chaque sprint, on engage une partie d’entre-elles. Pour délivrer plus, et afin de toujours rester dans une relation de satisfaction, le fournisseur doit promettre moins, pour que le contrat soit reporté de sprint en sprint. La particularité de ce contrat est que l’une ou l’autre partie peut décider ou non de stopper le projet à tout moment, et ce pour diverses raisons. Cela a un côté rassurant, car cela mise sur la satisfaction mutuelle et permet d’équilibrer les choses. Cela permet au fournisseur d’être partie prenante du projet, de travailler en véritable co-traitants.

Ainsi, équilibrer ce type de relation et faire en sorte que les intérêts soient les mêmes pour les deux parties va permettre de capitaliser sur les résultats et donner plus de force au projet.

>> Téléchargez nos templates de contrats open-source ici

L’agilité pour s’assurer que son produit rencontre son marché

Le développement doit être entendu dans un prisme technico-économique. Un projet doit avant tout être construit autour d’un marché, mais une analyse marché seule peut s’avérer fragile. D’autre part, un produit ne peut espérer être vendu uniquement pour la nouvelle technologie qu’il embarque. Un produit trouve sa légitimité dans ce qu’il va apporter à l’utilisateur. Il ne doit pas être multifonction, mais doit surtout répondre à une problématique, par sa fonction principale.

Les méthodes agiles permettent une analyse exploratoire tout au long du développement en plaçant des mock-up et des POC plus souvent dans les mains des utilisateurs finaux. Ces tests auprès des utilisateurs vont générer des remarques et permettre de tirer des conclusions à chaque version. Ainsi, l’entreprise porteuse de projet peut s’adapter en fonction et à tout moment rectifier le chemin pris par le développement. Cette méthode représente clairement un moyen de dérisquer facilement et sainement un marché.

L’agilité a certes un coût, mais cette méthode permet réellement de donner les meilleures chances de réussite commerciale à son produit en restant toujours proche de son marché. Ce coût local va donc se récupérer sur le gain global du projet. En morcelant le projet, cette démarche itérative permet de tester et valider plus d’aspects du produit et plus souvent (à chaque version), et pas uniquement au niveau technique. On aboutit donc à un produit beaucoup plus performant aussi bien au niveau business qu’au niveau technique, et donc en totale adéquation avec les attentes marché. L’agilité brille par son efficacité. En garantissant une meilleure réussite business dans sa globalité, les méthodes agiles voient leurs coûts totalement amortis.

> En savoir plus : consultez cet article tiré de notre webinar sur les gains de productivité via les méthodes agiles.

Notes de notre expert Tom Fournier :

« Nous croyons en l’agilité, qu’elle soit sur le hardware ou le Cloud car c’est avant tout dans les processus et surtout les valeurs de l’entreprise qu’elle doit être inscrite. C’est pourquoi chez Rtone, nous avons fait le choix d’intégrer en interne l’ensemble des métiers liés à l’IoT et d’être uniquement fabless. Chaque sprint peut mener à un changement que nous voyons avant tout comme une opportunité !

Nous intégrons l’agilité nous croyons que dans certains projets IoT, elle garantit plus de chances de réussite. Si vous souhaitez savoir dans quelle mesure cela peut s’intégrer à votre projet, contactez-nous et nous pourrons en discuter ! »