Extreme Startup @ Agile Nantes

Grâce à Agile Nantes j’ai eu l’opportunité avec Cédric Pineau d’animer un atelier Extreme Startup à La Cantine de Nantes. Voici quelques notes sur cette session, sans bien entendu rien dévoiler du contenu de l’extreme startup ! Nous étions une petite dizaine au départ avec des bases de code très diversifiées : 2 équipes en Java, une équipe en PHP, une équipe en node.js.

Ressenti des équipes

La plupart des participants n’ont pas ressenti vraiment le besoin de refactorer le code. Quand on a la tête dans le guidon, le copier-coller fonctionne très bien ! En plus, il permet d’être sûr que l’on n’a pas cassé de fonctionnalité quand on rajoute du code et en redéploie. Seule une équipe a réellement écrit des tests unitaires, aucune n’écrivant de tests fonctionnels.

Ceux qui n’étaient pas programmeurs ont eu du mal à savoir sur quoi agir. Certains se sont organisés pour faire de la veille en suivant l’évolution de leur score et de leur projet sur un écran à part, ce qui permet aussi de se partager le travail. Analyser ce qui arrive en temps réel demande du temps cependant, et permet aussi aux non-développeurs de vraiment se sentir utile. Une équipe a fait de la R&D en partageant le travail entre 2 développeurs : un qui produit du code opérationnel, un autre qui développe des fonctionnalités futures.

La question de l’exploitation des logs a été levée, certains demandant à ce que la simulation propose plus de métriques et de moyens de savoir ce qui se passe. Mais on peut se demander si ce n’est pas aux développeurs d’être capable de fournir ces informations, ce qui pose la question intéressante de l’opérabilité des solutions : dans quelle mesure le produit est capable de fournir des données au-delà de la fonctionnalité qu’il remplit ?

L’environnement de développement a posé problème à une équipe développant en PHP: le mode serveur REST n’est pas habituel dans cet environnement et de ce fait, l’équipe a eu du mal a avoir un serveur basique fonctionnel. D’autant plus que le serveur de base proposé sur github est basé sur une utilisation en ligne de commande et l’ouverture de sockets, chose qui n’est pas du tout usuelle dans l’univers PHP.

La simulation montre bien l’important de maîtriser son environnement et les fondamentaux de sa plate-forme.

Comprendre le score

Quelle est la signification du score de chaqué équipe ? S’agit-il d’un revenu généré, du cash disponible, de parts de marché ? Ou bien encore d’une mesure abstraite de confiance ou d’image du groupe concerné sur un certain marché ? Cette question du rapport au score se pose lorsque de nouveaux entrants pénètrent le marché : leur score est de 0 ce qui du coup peut les avantager par rapport aux scores d’autres participants ayant déjà un historique négatif à rattraper. Cela fait partie de la simulation car la capacité d’une startup à pivoter (ou persévérer) est un élément important d’une stratégie produit.

Toujours du point de vue de la simulation, la situation est potentiellement différente selon qu’une startup fonctionne sur des fonds propres ou des fonds externes. Dans le premier cas il sera difficile de remettre les compteurs à 0 : une fois que l’on a consommé l’ensemble de son patrimoine, il n’est plus possible de réinvestir ! Inversement dans le second cas, un échec peut conduire à l’assèchement des financements, le ou les porteurs de projets devenant persona non grata auprès de financeurs potentiels.

Améliorations possibles

Une composante importante de la tactique dans le développement d’un produit web est absente de la simulation : le test A/B. Les seules mesures dont disposent les équipes sont les points marqués ou perdus, le cumul des points et la position relative par rapport aux autres équipes. S’il apparaît possible d’anticiper sur les évolutions futures du marché avec un minimum d’observation, il ne semble pas possible de réllement tester la réaction du marché par rapport à telle ou telle solution.