Vous travaillez dans l’informatique, la tech… vous connaissez l’agile, le Scrum ou d’autres méthodes dérivées. Vous avez mis en place des rituels et des outils. Vous avez tous Jira et autres outils de collaboration ! Tout le monde les utilise, et beaucoup les détestent.
Je suis certain que vous avez encore plein d’autres exemples d’outils censés résoudre des problèmes. Or, vous avez plutôt l’impression que cela ne sert à rien. Voire pire, que cela ralentit l’équipe et que vous ne travaillez pas sur les vrais sujets qui comptent.
Tout le monde fait de l’agile / Scrum avec plus ou moins de rigueur, avec une approche plus ou moins fidèle aux ouvrages de référence et à la philosophie d’origine. Or, le problème n’est pas ici.
Le problème : pourquoi continuer si cela fonctionne mal ?
Pourquoi est-ce que, dans certaines organisations, nous continuons d’utiliser ces méthodes alors qu’elles ne produisent pas les effets attendus ?
Les symptômes : problèmes de délais, de qualité, incompréhension du produit et des demandes clients, faible collaboration entre collègues, turnover dans les équipes, démotivation, difficulté à attirer et à garder des profils expérimentés.
Les causes
Ce n’est pas Jira le problème, mais votre organisation. L’outil ne remplace pas l’humain. Avoir des outils agiles ne fait pas d’une équipe une organisation agile.
Au final, peu importe l’étiquette que vous vous donnez, l’important réside dans les produits que vous proposez à vos clients. Vos clients se fichent autant de votre stack technique que de votre méthode d’organisation. Ils regardent les résultats, pas les moyens que vous avez mis en œuvre.
Demandez à vos clients ce qui compte. J’ai l’intuition que c’est plutôt : les délais, le prix, votre connaissance du métier, votre réactivité, la nature de la relation que vous avez avec eux, vos propositions / idées, votre attitude, la manière dont vous résolvez les situations de crise. La partie technique et vos outils sont des détails.
Question 1 : est-ce que vous comprenez ce que vous faites ?
Vous ne comprenez pas toujours ce qu’il faut faire : cela arrive très souvent dans notre industrie. Plusieurs raisons à cela :
Le client ne sait pas exactement ce qu’il veut. C’est avant tout humain : nous sommes loin d’être rationnels. Les demandes peuvent aussi évoluer au cours du temps. Votre client peut lui aussi connaître des changements : changement de direction, changement de poste, changement de stratégie de l’entreprise. À cela s’ajoute un contexte politique, administratif ou juridique qui peut influencer le développement de votre produit.
Les jeux d’acteurs peuvent être complexes entre l’acheteur, l’utilisateur et le décideur. Ces trois rôles peuvent être joués par la même personne dans les petites organisations. Lorsque vous travaillez avec de grandes organisations, vous devez négocier avec ces trois personnes, et cela peut orienter le développement de votre produit de façon différente. Vous pouvez vous retrouver dans la situation suivante : faire plaisir au décideur ou à l’acheteur au lieu de satisfaire l’utilisateur. À court terme, vous avez peut-être gagné. Sur le long terme, c’est moins sûr.
Question 2 : est-ce que vous avez les compétences pour réaliser ce que vous voulez faire ?
Soyons honnêtes : la concurrence est rude et le niveau technique est élevé pour produire un bon produit. Constituer une équipe sur le long terme est complexe. Cela coûte de l’argent et demande du temps pour former chaque personne au métier et à l’environnement technique.
Question 3 : est-ce que vous mettez en place des habitudes qui permettent d’atteindre vos objectifs ?
C’est là que nous revenons à nos outils. Si un outil ne s’inscrit pas dans votre stratégie, il est inutile. Les outils traduisent une organisation du travail, une réflexion sur la façon dont le travail est structuré pour produire de la valeur. Si l’outil n’apporte pas de valeur, c’est un jouet. Les jouets, c’est sympa, mais allez donc justifier vos dépenses à votre chef : on a dépensé 100 € sur Slack, Jira… pour pas grand-chose.
Vous pouvez être productif avec un simple éditeur de texte ou un Google Sheet. C’est moins à la mode, mais cela fonctionne.
Soyez aussi clair sur vos objectifs. Est-ce que tout le monde sait pourquoi il travaille et quels sont les objectifs de votre produit ? Je ne parle pas de faire plus de chiffre d’affaires, plus de marge ou d’autres objectifs économiques. Cela devrait être la raison d’être de toute entreprise : croître ou, au minimum, consolider sa position.
Au départ, l’intention de l’agile
Pourquoi cette approche a-t-elle été tant adoptée ? Parce qu’elle voulait résoudre un problème.
N’oublions pas ce qui fait la force de cette philosophie :
• limiter la durée des cycles de développement
• rapprocher les clients, la vente et la technique (éviter les organisations en waterfall, avec des spécifications écrites plusieurs mois à l’avance et déjà obsolètes ; éviter de vendre des choses impossibles au client)
• travailler sur ce qui compte pour le client, avec une approche produit
Loin de moi l’idée de dénigrer l’agile ou certains outils. Mon intention est de ne pas perdre de vue ce qui compte vraiment. Les outils, les méthodes, les procédures sont un moyen, pas une fin en soi.
Garder le cap dans un projet nécessite une attention quotidienne. Le développement logiciel n’est pas réglé comme du papier à musique. Cela s’apparente davantage à une navigation en pleine mer, avec ses tempêtes et ses jours de grand soleil où l’on avance vite. Ayons l’humilité d’accepter la complexité de ce type d’activité.