L’Agilité chez les éditeurs logiciels

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.