Qu'est-ce que l'agilité dans le monde logiciel ? Reprenons ses concepts fondamentaux (la théorie) et comment nous la pratiquons chez FoodMeUp.

Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire.
Ces expériences nous ont amenés à valoriser

Les individus et leurs interactions plus que les processus et les outils

Chez FoodMeUp, nous avons travaillé dur pour construire une culture d'entreprise qui valorise le franc parler et le bien être. Il n'y a pas de meilleur manière de progresser sur le sujet que de confronter la théorie de l'ouvrage Radial Candor à sa mise en pratique quotidienne dans l'environnement de l'entreprise.

Pour exercer l'agilité, on se repose fortement sur le framework scrum. un framework c'est un cadre de travail. Le scrum c'est donc un cadre de travail qui favorise la communication. Être fan de scrum c'est donc être fan de communication ! Cette explication permet de désamorcer les frustration relatives aux mauvaises pratiques de l'agilité.

Chez FoodMeUp on a de nombreux process et outils qui facilitent le travail au quotidien. Cependant on s'en détache dès qu'on rencontre des contraintes humaines justifiées. Les process et les outils sont à notre service, ils permettent de gagner du temps, de ne pas avoir à penser à tous les détails car de nombreux automatismes en découlent.

Des logiciels opérationnels plus qu’une documentation exhaustive

Disons le clairement : on est très fier de notre documentation. Mais elle n'a pas d'utilité qui lui soit propre, elle sert à garantir la stabilité de notre logiciel.

Elle a le role de spec : on écrit une documentation fonctionnelle pour notre frontend et une documentation API pour notre backend.

On écrit aussi beaucoup de pseudo tests fonctionnels qui permettent de clarifier le comportement attendu par notre API. On a atteint une couverture fonctionnelle de presque 100%.

Est-ce ça prend du temps ? Oui. Est-ce que ça en fait gagner ? Oui, définitivement : on n'a presque jamais d'incohérence, d'incompréhension, de régression, de bugs. Tout est fluide. Le logiciel est opérationnel.

La collaboration avec les clients plus que la négociation contractuelle

On construit clairement notre outil avec les retours clients. On en a déjà parlé intensivement dans cet article.

L’adaptation au changement plus que le suivi d’un plan

Chez FoodMeUp, on est très lean. Le lean est une composante de l'agilité : on se repose sur un pull du marché plutôt que pusher des choses inutiles.

Pour bien comprendre ce que ça veut dire, je recommande la lecture de The Gold Mine.

Plusieurs exemples permettent d'en rendre compte :

  • Notre roadmap n'est pas figée, elle évolue fréquemment (elle n'est jamais complètement chamboulée, on a des convictions et un peu d'expérience qui permet d'éviter les erreurs monumentales) ;
  • On prépare un backlog 2/3 semaines à l'avance, on n'a pas un backlog rempli de 200 tickets tous ready. Le contraire reviendrait à stocker de la valeur ajoutée au milieu du cycle de production, et le stock est un ennemi du lean.
Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.

Retrouvez cela sur le site du manifesto Agile :

Une équipe au top

Envie d'apprendre et d'avoir un impact ?

Les principes sous-jacents

Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.

Nos travaux reposent sur des études utilisateur. Nous avons toujours le souci d'un grand ROI et d'un UX/UI optimal.

Nous mettons en production presque une fois par personne et par jour avec des pics à 2 mises en prod par jour et par personne.

Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client.

Notre projet c'est notre entreprise. Elle est agile, par uniquement dans le développement logiciel d'ailleurs. Dans notre pratique du marketing et des sales nous suivons les mêmes principes. En tout état de cause, les changements sont bienvenus, y faire face et un signe de lucidité. C'est bien évidemment plus facile de les embrasser qu'on n'a pas à sacrifier un investissement. D'où la nécessité de bien étudier le besoin et de ne pas investir trop tôt.

Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.

On ne fait jamais de tunnel, i.e. on ne développe jamais des briques inutilisables et déconnectés de la production. On fonctionne par sprint de 2 semaines, ça change parfois, mais on livre de manière continue.

Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.

Notre équipe a une culture produit et une culture agile. La communication est simple et récurrente. On fait communique quotidiennement et parce que les sprints servent à diminuer les dispersions, on lève la plupart des doutes dans nos cérémonies de backlog refinement et planning poker.

Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.

Notre équipe déploie une énergie extrêmement positive. C'est une équipe talentueuse et les talents attachent une forte importance à des objectifs clairs et à des conditions de travail matérielle optimales. Envie d'en apprendre plus ? Lisez First, Break all the rules.

La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.

Dès qu'un échange se rallonge, on se téléphone. Dès qu'une discussion téléphonique devient compliquée, on programme un point de visu.

Un logiciel opérationnel est la principale mesure d’avancement.

Opérationnel ne signifie pas seulement absence de bug mais également utilisable. D'où l'importance accordée à l'UX dans nos process. Les parcours sont simplifiés au maximum. De nombreux clients nous préfèrent d'ailleurs à des solutions plus riches fonctionnellement, simplement parce que notre outil est opérationnel = utilisable.

Les processus Agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.

On ne rush pas, même si ça va très vite. On avance par itérations successives, dans un rythme confortable et enthousiasmant.

Une attention continue à l'excellence technique et à une bonne conception renforce l’Agilité.

"Build quality into the product", dixit The Gold Mine. L'excellence à tous les niveaux garantit de ne pas avoir à revenir 3 fois sur un un sujet mal conçu.

La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.

L'excellence c'est aussi la simplicité. On proscrit en particulier les délires techniques. Toute l'équipe est sensibilisée à un bon ROI.

Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées.

A notre échelle c'est assez simple. On a hâte d'avoir de multiples équipes et d'expérimenter l'agilité à l'échelle.

À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.

En fin de sprint on réalise une rétrospective qui permet de comprendre ce qui a fonctionné, ce qu'il faut améliorer et on se donne une todo. On varie fréquemment les formats pour ne pas lasser l'équipe et faire émerger de nouvelles choses.

Picture @Meghan Holmes