Une start-up est une entreprise à fort potentiel innovant qui souvent se fait financer par des acteurs externes à la structure. Ces acteurs misent sur le fort potentiel de l’idée initiale pour rentabiliser leur investissement.

Par nature, ces financeurs ont besoin d’être rassurés quand à l’utilisation de leur argent et sur le délai de retour sur investissement. Ce qu’un projet innovant ne peux garantir de par sa nature de saut vers l’inconnu.

C’est pourquoi le choix de la technique de management à utiliser par le(s) fondateur(s) est primordiale pour rassurer les investisseurs tout en laissant à l’équipe toute liberté d’action.

Balance oh combien difficile à équilibrer.

Les méthodes de gestion de projet « traditionnelles »

La plus populaire des méthodes classiques de gestion de projet est la méthode cascade ou waterfall. On la nomme ainsi car son principe est de valider les étapes une par une jusqu’à la fin du projet sans revenir à une étape précédemment validée. Elle fut créée par Wiston Royce en 1970.
Les principales étapes de la méthode wartefall sont les suivantes :

• Exigences : le demandeur du projet défini ce qu’il attend du produit,
• Conception : comment sera le produit,
• Planning : définition de l’échéancier et du budget,
• Mise en oeuvre : développement du produit,
• Vérification : tests unitaire, d’intégration, end-to-end, etc…
• Maintenance : réalisé pendant le cycle de vie du produit.

On trouve des avantages à cette méthode : elle est simple et facile à mettre en oeuvre, elle est logique et structurée. De plus, elle facilite, en théorie l’estimation des ressources, en temps, en budget et les ressources humaines.

Mais waterfall présentes des inconvénients majeurs. En effet, il n’y a que peu d’interaction avec le client qui ne verra pas le produit avant la fin du processus et, de plus, effectuer des changements relève de l’impossible car ils auront un impact sur les phases en cours, suivantes et surtout précédentes du projet, or l’eau d’une cascade ne remonte pas la chute qu’elle vient d’effectuer.

Une autre méthode classique et dérivée de waterfall est la méthode du cycle en V. Son principe est de voir le projet sous forme de deux flux : un descendant qui détaille le produit jusqu’à sa réalisation, et un flux ascendant, qui assemble le produit en vérifiant sa qualité.

Le flux descendant a pour objectif de détailler le projet à tous les niveaux : les exigences, la conception, les ressources et la mise en œuvre.

Le flux ascendant, quand à lui, vise à valider le produit jusqu’à son acceptation par le client. Il comprend principalement des séries de tests permettant valider le produit par rapport au besoin et aux exigences.
Le cycle en V est donc composé de la succession d’étapes suivantes : exigences, analyse fonctionnelle, conception générale, conception détaillée, mise en œuvre, test unitaire, intégration, test d’intégration, test système, et enfin test d’acceptation.

Malgré les avantages du cycle en V – une approche plus systématique des produits – si l’on se rend compte au cours de la mise en œuvre que les spécifications étaient incomplètes, fausses ou irréalisable, le changement sera ardu et surtout extrêmement coûteux en ressources. De plus, le cycle en V étant issu du modèle en cascade, il en hérite les défauts liés
à l’approche séquentielle et linéaire de phases.

Les méthodes agiles

Pour palier aux inconvénients des méthodes classiques de nouvelles méthodes de management ont été développé, nous allons nous intéresser à deux d’entre elles : Scrum et Kaban.

Scrum est adapté à des équipes de 6 à 10 personnes, le but est de livrer le plus vite possible un produit même s’il n’intègre pas l’ensemble des fonctionnalités demandés puis de recueillir un feed-back et d’itérer pour parfaire le produit jusqu’à son aboutissement.

Un point central de la méthode Scrum est le product backlog, c’est un référentiel des exigences initial, hiérarchisé en collaboration avec le client. Sont présentes dans le product backlog l’ensemble des fonctionnalités du produit sous forme d’user story. Une user story correspond à une fonctionnalité dans son ensemble, elle contient ce qui doit être fait, comment cela doit être fait, ainsi que les critères d’acceptabilité de la fonctionnalité.

Cette méthode introduit aussi un nouveau concept : le sprint. Un sprint est une itération de quelques semaines tout au plus, permettant de sélectionner les user story les plus importantes, de les développer, de les tester et de les intégrer dans le produit. L’objectif étant qu’à l’issue du sprint l’ensemble des user story choisie par l’équipe soient intégrées dans le produit. Le choix des user story qui seront implémentées lors d’un sprint est défini par le sprint planning meeting, une réunion entre le product owner, le Scrum master et l’équipe.

Le dernier aspect de Scrum qui sera évoqué est la mêlé quotidienne. C’est une réunion de 15 minutes dans la journée où chaque membre de l’équipe doit s’exprimer et répondre à trois questions : qu’ai-je fait hier et quels ont été les éventuels problèmes rencontrés ? Que vais-je faire aujourd’hui ? Ai-je des difficultés pour continuer mon travail ? En faisant cet exercice quotidiennement chaque membre de l’équipe est au courant de ce que font ses collègues et il peut coordonner son travail et aider ou se faire aider en cas de difficultés.

Les avantages de la méthode Scrum rapportée aux méthodes traditionnelles sont l’adaptabilité aux changements, la visibilité du travail de l’équipe de développement démystifié pour le client et l’inspection de ce qui est fait à des fins d’amélioration.

La deuxième méthode agile qui sera abordée dans cet article est la méthode Kanban.
Cette méthode est un système simplifié de gestion des workflows développé au Japon par Toyota au début des années 1940. Son but premier est de rendre le processus de production efficace et agile, mais il peut également contribuer à soutenir un leadership fort, une transparence organisationnelle, le travail d’équipe, favoriser une communication et une
collaboration plus ouverte au sein de l’entreprise

Kanban s’appuie sur un tableau – le board agile – présentant plusieurs listes de taches – les cards – à accomplir dans un interval de temps court, quelques jours maximum. Il n’y a pas de template du tableau type, ce tableau doit être adapté aux besoins de l’équipe, mais on trouve souvent les colonnes : to-do, in progress, waiting, blocked, et done.

Chaque colonne décrivant où en est l’équipe sur la tache. De plus le board étant à la vue de tous, cela permet de repérer rapidement une table stagnant dans une colonne et d’identifier d’où vient le problème. Malgré les apparences Kanban possède également des évaluations régulières et un examen rétrospectif du travail. Il est accompli pour chaque tache et non à des intervalles réguliers comme Scrum.

De plus Kanban est un processus continu, qui ne s’arrête pas à certains moment pour figer le travail, les tâches étant extraites et validés à mesure des livraisons de l’équipe.

Piloter une start-up ne peut entrer dans un seul cadre

Une start-up est un projet comportant une grande part d’incertitude, pour cela les méthodes agiles sont les plus adaptés, néanmoins ce projet innovant doit passer une succession d’étapes structurées et ordonnées pour être parfaitement adapté au segment de clientèle cible et à son marché.

Il ne faut pas rejeter en bloc les méthodes classiques en effet leur rigueur est indispensable pour pouvoir prendre du recul mais il ne faut pas rester dans leur cadre figé et immobile car une start-up est avant tout un bateau qui file au grès du vent et des flots.

L’équipage de ce bateau doit pouvoir virer de cap, louvoyer et éviter les récifs qui se dressent devant lui.

La start-up doit donc mixer les deux grandes façons de gérer les projets, classique et agile, afin de toujours garder le cap tout en pouvant changer radicalement chaque point de l’environnement du projet à chaque moment du trajet.

ARTICLЕ MANAGEMENT INSTITUT G4 – CAMILLE LANGE– CAMPUS Paris