L’Agilité chez les éditeurs logiciels

Parmi les clients réguliers que j’accompagne depuis 2012, les éditeurs de logiciels occupent une place toute particulière. Peut-être parce que j’ai démarré ma carrière en tant que développeur Java chez l’un d’eux ? Ou peut-être parce qu’avant de me lancer dans l’aventure SuperTilt, j’ai eu la chance d’écrire les premières pages d’une start-up qui n’a pas éclos malheureusement.

Quelles qu’en soient les raisons, les éditeurs logiciels me fascinent, j’adore les accompagner. C’est sans doute le type d’industrie où nous (mes clients et moi) avons pu expérimenter le plus de stratégies pour déployer une l’Agilité qui a changé beaucoup de choses pour eux ces dernières années.

Dans cet article, je vous partage une réflexion ouverte. Malgré les différences de tailles, de personnes, de types de produits, de chiffres d’affaires, etc. j’ai observé que les éditeurs logiciels répondent à des mécanismes très similaires. Je ne mets pas tout le monde dans le même panier évidemment, mais les similitudes sont troublantes 🙂

Génèse d'un éditeur de logiciels

L’histoire démarre souvent de la même manière : une bonne idée au départ, une innovation sur un marché de niche plus ou moins grand, des compétences, de l’énergie, beaucoup de volonté et c’est parti pour une belle aventure ! 

La croissance à 2 chiffres est vite là, les prospects se transforment vite en clients. L’accélération est telle que de belles organisations se présentent comme intéressées et à qui il devient difficile de ne pas refuser des évolutions. Logique, efficace et rentable ! Le produit, qui était à la base une intention basée sur des observations, grandit maintenant aussi au rythme des évolutions sur mesure en plus des évolutions du marché.

Accélération du rythme

À la R&D, les bonnes idées de fonctionnalités de certains clients deviennent une entrave pour les autres clients. La maintenance logicielle évolue doucement mais sûrement. Le support client sonne mais le rythme reste absorbable, les développeurs soulèvent sans doute des besoins de traiter la dette technique mais la priorité est donnée aux nouveaux clients, aux prospects aux appels d’offre. Car pendant ce temps, les commerciaux vendent, et plutôt bien en général.

Le succès du produit ne tient alors plus spécialement à sa qualité intrinsèque mais plutôt à sa pénétration du marché, à ses forces de vente. Les recrutements s’enchaînent et la création de la 2ème équipe de production marque un tournant majeur dans la vie de l’éditeur logiciel car le noyau des fondateurs vient d’exploser pour donner vie à quelque chose de plus grand.

Les besoins d’organiser les autres fonctions de l’entreprise émergent fortement : management, RH, comptabilité, support, marketing, commerce, administratif, exploitation. Les processus se structurent de manière empirique et tant que la rentabilité est là, la structure avance ! 2 mots d’ordre résonnent alors : vendre beaucoup et développer vite des features (fonctionnalités) !

Piégé dans l'ornière de la performance

Certains éditeurs me sollicitent dès la phase de génèse (par exemple Okeenea Digitalque de bons souvenirs) pour mettre la production sur les rails avec une équipe fraîchement constituée. L’intention est généralement de partir sur de bonnes bases méthodologiques et éviter le plus possible les pièges qui vont suivre. 

Intervenir en phase d’accélération est complexe car d’un côté l’éditeur est pris dans l’euphorie de son succès et est focalisé (à juste titre) sur sa croissance (voire l’hyper-croissance). De l’autre, les actions d’accompagnement peuvent demander un temps plus ou moins long de mise en place (dans lequel souvent l’éditeur ne souhaite pas investir) et les effectifs sont mouvants avec les recrutements réguliers. Les indicateurs sont souvent tous au vert et personne ne voit les signaux faibles qui montrent clairement que l’éditeur va bientôt toucher ses limites de performance prochainement. C’est généralement lorsque ces problèmes mineurs s’installent, grandissent et perturbent plusieurs services que l’attention se reporte alors sur l’Agilité : soit il faut passer à l’Agilité (car elle n’existe pas) soit l’Agilité dysfonctionne et il faut la corriger. 

Mais avant de sauter sur la solution (corriger l’Agilité), intéressons-nous à ces signaux faibles qui vont nous en dire beaucoup sur la bonne approche à tenir. 

Les signaux faibles à observer chez un éditeur

Avant de les lister, je souhaite prendre quelques précautions : 

  • Si nous avons déjà travaillé ensemble par le passé, j’ai peut-être pensé à vous en écrivant ces lignes, mais à d’autres éditeurs aussi. J’ai pris soin de répertorier des points communs. Comme je vous l’avais indiqué pendant ma mission, vous n’êtes pas les seuls à avoir ce type de structure/problème 🙂
  • Si nous n’avons pas encore travaillé ensemble, vous trouverez certainement plusieurs de ces phénomènes chez vous. Ça ne veut rien dire pour autant sur la qualité et l’efficacité de votre organisation

Dans les 2 cas, rassurez-vous, il est peu probable que vous cumuliez l’ensemble des signaux faibles suivant : 

  • Une organisation structurée (voire cloisonnée) par service
  • Une Agilité qui démarre (et souvent s’arrête) à la R&D (Recherche et Développement)
  • Des commerciaux souvent en tension avec la R&D (et réciproquement)
  • Une incapacité à planifier des feuilles de route
  • Une R&D qui souffre de plusieurs typologies de demandes très différentes : des urgences, des trucs qui peuvent attendre, des promesses, des bugs, des fonctionnalités, de la dette technique, des projets vendus, de potentiels marchés
  • Une cohabitation de démarche produit et projet
  • Du legacy (du vieux code) très présent et une capacité à innover de plus en plus lente
  • Le support qui sature
  • Une R&D en mode “rustine” plus qu’en mode innovation
  • Des modèles économiques qui freinent, par exemple B2B2C
  • Une présence managériale forte et cloisonnée
  • Des services ayant chacun leurs propres objectifs
  • Des commerciaux objectivés individuellement à la performance
  • Des nouvelles recrues qui ont besoin de temps pour monter en compétence
  • L’oubli de l’esprit d’innovation pure (celle du début), on ne sait plus comment faire dans le flot du quotidien
  • Un lien de plus en plus faible avec les utilisateurs ou réservé à certaines fonctions (consultants, marketing par exemple)
  • Des guerres intestines qui n’en finissent pas
Pris indépendamment, ces signaux faibles ne sont pas des problèmes en soit. Mais certaines combinaisons peuvent avoir des effets très négatifs. Par exemple : “Une R&D qui souffre de plusieurs typologies de demandes très différentes” + “Les commerciaux sont objectivés individuellement à la performance” est souvent la garantie d’un cocktail explosif.

Les stratégies d'Agilité souvent observées

De nombreux éditeurs logiciels se sont autonomisés sur la mise en place de l’Agilité depuis son explosion dans les années 2010. Voici quelques-unes des stratégies les plus couramment rencontrées. Elles peuvent être le fruit d’une décision ou émerger naturellement. Je précise qu’elles peuvent être cumulées entre elles mais pas forcément :
 
  • Agilité niveau 1 : déploiement de Scrum uniquement à la R&D, parfois au test mais rarement dans les autres 
  • Des Product Owner à 2 niveaux : un Product Owner au niveau de la R&D et un Product Manager ailleurs (marketing, business, consulting, …)
  • Des Scrum Master qui pilote la R&D uniquement : souvent ils combinent ce rôle avec leur actuel mission de développeur
  • Une Agilité essentiellement itérative (et peu ou pas incrémentale). Souvent les itérations de la R&D sont suivies par une itération de test (ou QA, Quality Acceptance). Ces Agilités n’ont pas cassé les silos qui existaient avant
  • Une omniprésence d’outils numériques comme Jira ou AzureBoards (pour les plus célèbres). L’usage de tableaux physiques a toujours été une source de questionnement forte et pour beaucoup de personnes est vu comme une fantaisie et non comme comme un outil (au sens noble du terme), et pourtant …. La crise COVID, avec la généralisation du travail à distance, a clôturé le débat pour beaucoup d’équipes
  • Des demandes d’engagement et de prédiction toujours plus forte, renforcée par le fonctionnement avec des Sprint Planning d’itération et des exercices de planning poker
  • Des feuilles de route décalées de la réalité, qui voient loin, qui prennent mal pas en compte les imprévus business (les nouveaux prospects, les évolutions du marché, etc.) et qui sont peu/pas/mal connectées au travail effectif de la R&D
  • Un esprit d’Agilité basé sur des besoins de produits extrêmement flexibles et la tenue d’engagements forts avec une qualité toujours maintenue au top. Bien qu’une forme d’Agilité soit en place, la volonté de tenir les coûts, la qualité et le délai sont toujours omniprésents (le triangle de fer a la vie dure)
  • Une augmentation des effectifs pour combler les retards, garantir le développement de plus de nouveautés et combler les départs de certains collaborateurs. La notion d’Agilité à une plus grand échelle va vite se présenter avec le cortège de difficultés associées (synchronisation, dépendance, rôles et responsabilités, etc.)
Comme les signaux faibles, ces stratégies ne sont ni bonnes, ni mauvaises. Lorsqu’on peut en observer plusieurs ensemble, les résultats peuvent causer du tord aux individus (et à l’entreprise plus largement). Par exemple : “Des demandes d’engagement et de prédiction toujours plus forte” + “une R&D en mode rustine plus qu’en mode innovation” font rarement bon ménage.

Les pistes à envisager pour une Agilité plus sereine et plus efficace

 

Comme bien souvent, il n’existe pas LA solution. Celle que tous les éditeurs attendent et qui permettrait de régler le problème une bonne fois pour toute et de se concentrer sur autre chose.

Je recense ici quelques programmes d’actions que j’ai déployés chez mes clients éditeurs et qui ont eu de bons résultats. Peut-être que certains sont aussi adaptés à votre contexte.

  • Inclure les autres services dans l’Agilité et faire des équipes produit pluridisciplinaires : trop souvent limité à la R&D, l’Agilité a cette étiquette de “truc de développeur”. Si on aborde cette culture uniquement sous l’angle technique, ce raisonnement est logique. Une équipe agile accueille tous les métiers nécessaires à la construction et à l’exploitation du produit : du commercial à l’équipe infrastructure. L’information circule mieux et l’équipe fait plus souvent des compromis de meilleure qualité. Cette approche se construit avec les acteurs en place pour que cela fonctionne. Il y a tout un travail autour du dialogue et de l’écoute à prévoir car les repères de chacun sont perturbés rapidement.

  • Kanban au sein et entre chaque service : le point précédent sera sans doute dur à imaginer et à mettre en œuvre. Pendant cette étape de transition, la collaboration interservices peut déjà être améliorée avec la méthode Kanban. L’Agilité est avant tout une histoire de systèmes, de variations, de changements. Pour définir les bonnes actions qui auront de bons effets et garantir un accompagnement au changement doux et adapté, la méthode Kanban est sans doute l’approche la mieux adaptée. Sa puissance réside d’abord dans le fait de respecter les processus et les rôles en place sans imposer de nouveaux rôles ou de rituels d’équipes. En Kanban, nous observons factuellement la complexité et ce sont les équipiers qui font progressivement évoluer leurs modes de fonctionnement. Le mieux pour s’en convaincre est découter le témoignage de Cyril, manager chez Kuka

  • Remobiliser les utilisateurs finaux : à quand remonte pour la dernière fois la rencontre d’une personne de l’équipe produit avec un utilisateur final ? Les clubs utilisateurs, les invitations aux démonstrations, les interviews, etc. sont des exercices aux vertus largement décrites dans la littérature et sur le Web. Plus qu’une pratique, la proximité et la régularité des rencontres avec vos utilisateurs influence le produit

  • Une approche centrée produit uniquement : c’est une des transitions délicates à opérer car cela signifie que l’éditeur reprend la main sur sa feuille de route produit. C’est lui qui sait et décide ce que va contenir le produit. Les clients achèteront ce qui existe, on ne vend plus de promesses. Combien d’éditeurs se cassent les dents sur ce point ? Vendre du spécifique (la demande cliente) en voulant maintenir un aspect générique (qui nécessite un investissement technique fort sur l’architecture et la modularité). Cela vient résolument perturber les habitudes en place où une culture projet (le client dicte commande ce qu’il veut) cohabite avec une logique produit (la fameuse feuille de route). Certains m’opposeront que ce n’est pas possible, car cela remettrait en question le modèle économique, les relations avec de grands comptes, etc. Je vous laisse voir quelle situation est la meilleure pour vous 🙂

  • Une approche centrée client : dans la continuité du point précédent, il s’agit cette fois d’opérer un autre changement de taille : décider du contenu du produit à partir des retours utilisateurs et pas seulement à partir de comités internes de gens très compétents mais qui restent sur des croyances. Dans un comité produit, “Je pense que…” est la phrase qui témoigne d’une absence de prise en compte terrain. Comme toujours, tout est question de curseur bien dosé. Évidemment l’intuition est nécessaire pour laisser part à la créativité et aux innovations. Je parle plus ici d’introduire de manière plus systématique des indicateurs comme la satisfaction client, les retours utilisateurs pour mesurer le succès d’un développement plus que le respect des points de planning poker.

  • Une forte modularité technologique et une industrialisation moderne : chez les éditeurs qui commencent à avoir quelques années au compteur, la question des outils se pose de manière permanente. L’industrialisation, la modularité des architectures, les approches d’intégration continue voire de déploiement continu ne peuvent plus être évités ou considérés comme des centres de coûts. Dans n’importe quel métier, des collaborateurs bien outillés sont plus efficaces, la productivité est meilleure … à moyen et long terme, rarement à court terme. Ces projets d’industrialisation de la forge logicielle peuvent être des projets à part entière et nécessiter des compétences spécifiques. Cet investissement concourt au succès du produit au même titre que toutes les autres actions (marketing, commercial, etc.)

  • Des Scrum Master vraiment Scrum Master (à ce sujet voir ma vidéo “Qu’est ce qu’un scrum master ?“) : si ce rôle a souvent manqué par le passé, tous les éditeurs (ou presque) ont un ou plusieurs Scrum Master, qu’ils soient en Scrum ou non d’ailleurs. L’Agilité est souvent vue comme un outil simple (itération, planning, daily meeting avec un backlog et des US). Si en effet je partage l’idée que l’Agilité est un moyen au service d’un objectif et d’une ambition plus large, cette philosophie même outillée, fait appel à des mécaniques humaines, techniques et métier à la fois. Pour tirer la puissance d’une telle complexité, il faut bien plus que quelques pratiques ou rituels. Cette animation quotidienne est un travail à plein temps qui requière des compétences : facilitation, coaching, techniques et production, gestion de produit, accompagnement au changement, etc. Vos Scrum Masters ont besoin d’investir du temps pour comprendre et exercer pleinement leur métier

  • Une Agilité comme stratégie organisationnelle : il me semble que c’est l’aspect le plus difficile à obtenir : inscrire l’Agilité comme un pilier stratégique de l’entreprise. Il y a un avant/après évident avec un sponsoring fort : d’un côté l’Agilité est vue comme un truc à la mode puis pourra vite être abandonnée. De l’autre, elle est vue comme une composante (parmi beaucoup d’autres) de la réussite de l’organisation. À ce titre, elle sera légitime, valorisée, et bénéficiera d’une tolérance à l’erreur dans la courbe d’apprentissage. C’est un excellent moyen pour garder une Agilité vivante, qui s’améliore et s’adapte à l’organisation avec le temps. Car aujourd’hui, combien d’Agilités ont été mise en place dans les organisations et n’ont pas fait l’objet d’une réactualisation ?

  • Spin-Off Agile expérimentale : je l’ai observé une fois, j’en parle à titre d’inspiration possible. Il s’agit ici de créer une organisation dans l’organisation existante. La différence est que cette nouvelle entité a son propre mode de fonctionnement, ses propres règles sans devoir s’inscrire à tout prix dans le modèle dominant de la culture de l’organisation. Cette approche est particulièrement intéressante chez les gros éditeurs ou les cultures très complexes où les règles sont tellement nombreuses qu’il parait illusoire de dénouer un sac de nœuds pareil. Pour que ce mode de fonctionnement montre des résultats, les personnes sont détachées à 100% dans la nouvelle organisation.

Conclusion

Après toutes ces années de coaching agile, je suis toujours épaté de retrouver les mêmes signaux faibles et stratégies agiles déployés chez des éditeurs que tout oppose et qui ont leurs propres singularités.

La mauvaise nouvelle dans toute cette histoire est qu’il est probable que tout éditeur fera tôt ou tard face aux situations que j’ai décrites, parfois même plusieurs fois. La bonne nouvelle est que vous n’êtes pas les seuls à avoir ces questions d’organisation et qu’il existe en Agilité quantité de choses à essayer pour vous accompagner dans le développement de vos produits.

Audit agile gratuit

Vous voulez réaliser un état des lieux et mesurer la maturité agile de votre organisation ? Laissez-moi vous coordonnées, je reviens vers vous dans les meilleurs délais.

Ce site est protégé par reCAPTCHA et Google Politique de confidentialité et Conditions d’utilisation.
Panier
Retour haut de page