Bien souvent, dans des tentatives de transformation numérique des entreprises, la mise en place de méthodes agiles n’apporte pas le résultat escompté car elles se heurtent aux vieux modèles des couches supérieures : l’organisation et la culture des entreprises.
Les dispositifs agiles sont nés dans les startups. Ils ne sont donc pas naturellement adaptés à l’organisation des entreprises « classiques », et encore moins à celle des grands groupes français. Je vous propose de passer en revue les dysfonctionnements les plus fréquents et d’explorer les pistes pour y remédier.
Les méthodes agiles viennent se heurter à l’organisation et la culture
Source : Emmanuel Alfonsi
1. Les problèmes les plus profonds sont culturels
Le problème le plus profond que l’on peut rencontrer concerne la culture des personnes qui constituent le dispositif d’agilité. Les points de douleur peuvent aller de la difficulté à se passer d’engagements écrits à la capacité à entretenir des interactions plus fréquentes et moins formelles, en passant par des demandes qui exigent une certaine flexibilité par rapport à ce qui a été prévu. Cela engendre alors des tensions, des frustrations, et des lenteurs qui peuvent être fatales dans des projets pour lesquels le pilotage par les délais est critique.
Si le souci de flexibilité se situe uniquement côté développeurs, il y a également l’option de l’externalisation auprès de prestataires dont la culture est plus adaptée aux méthodes agiles, et avec des leviers d’escalade souvent plus performants qu’en interne dans les grosses structures. Chez l’un de mes clients, une réunion avec l’équipe de développement du centre de services externe a suffi pour lui expliquer les contraintes métier et marché qui faisaient que nous avions besoin d’agilité. Un coup de fil un peu ferme au directeur commercial du centre de services a terminé de redonner une belle dose de souplesse au dispositif agile !
Dans tous les cas il est très important d’expliquer pourquoi la flexibilité est nécessaire, en redonnant du contexte business, des perspectives, une vision qui donne du sens à ces demandes. Si on s’attaque au sujet en profondeur, il est possible de faire appel à des coachs agiles et des consultants en transformation de la culture d’entreprise, un investissement toujours utile pour l’avenir dans une ère où la flexibilité et la réactivité sont critiques dans tous les domaines.
2. Travailler sur l’organisation de la chaîne d’interlocuteurs
Le point principal à auditer et à travailler côté organisation concerne la chaîne d’interlocuteurs. Elle doit être la plus courte possible, et ses maillons les plus proches possible. Et les interlocuteurs doivent se faire le plus confiance possible. On voit trop de proxy Product Owners qui n’ont pas la confiance du métier pour exprimer leur besoin. On voit trop de POs à qui l’on ne donne pas suffisamment de temps pour travailler sur leur(s) projet(s) agile(s). Et l’on voit surtout beaucoup trop de chaînes d’interlocuteurs à rallonge qui subissent les effets du téléphone arabe.
Ci-dessous, j’ai formalisé la chaîne d’interlocuteurs du dispositif agile d’un de mes clients sur laquelle il m’a demandé de travailler. Vous pouvez constater que l’on est loin de la théorie née dans les startups qui consiste à mettre le développeur directement face à l’utilisateur final.
Chaîne de transmission des informations dans le dispositif agile d’un grand groupe français 1
Source : Emmanuel Alfonsi
Mais la tâche est complexe car elle ne peut se limiter à la théorie et doit prendre en compte les personnalités de chacun des membres de la chaîne. On a tendance à avoir envie de « faire sauter » des maillons de la chaîne, mais on tombe rapidement sur des problèmes de disponibilité, d’ego, et de confiance entre les interlocuteurs qui vont se retrouver face à face.
Tout d’abord, il existe une question de proximité physique. Vous devez analyser tous les moyens de rapprocher physiquement tous les maillons de la chaîne. L’idéal étant bien sûr le plateau projet, mais ce n’est pas toujours réalisable. Alors, on peut rapprocher certains maillons de façon permanente, comme on l’a fait pour le delivery manager et la MOA dans cet exemple, ou de façon ponctuelle. C’est par exemple le delivery manager qui se déplace désormais chez les développeurs pour chaque démo et poker planning.
On peut aussi squeezer ponctuellement tout ou partie de la chaîne. Dans cet exemple, nous avons organisé des show & tell qui mettent les développeurs en face des utilisateurs finaux pour une démo complète à la fin de certains sprints critiques. Comme dans tout projet, la confiance entre les acteurs est critique. Il y a donc intérêt à s’écarter d’un modèle idéal et rajouter un maillon qui va fluidifier et apaiser la relation entre deux autres qui ne se font pas confiance. Dans d’autres cas, la confiance peut être rétablie progressivement sans rajouter d’acteur intermédiaire, en travaillant sur le partage d’une même philosophie projet et le respect des engagements.
Chaîne de transmission des informations dans le dispositif agile d’un grand groupe français 2
Source : Emmanuel Alfonsi
3. Des outils méthodologiques simples, et respectés
On voit trop de stand-up meetings qui durent une heure au lieu de 15 minutes et de Kanbans à 10 lignes et 10 colonnes qui ne sont pas mis à jour ou consomment un temps fou pour assez peu d’efficacité. On m’a même rapporté que dans certaines équipes offshore, les outils méthodologiques sont respectés à la lettre dans une absurdité totale, par exemple avec des développeurs disposés dans un couloir pendant le daily Kanban stand-up sans pouvoir voir le Kanban…-
Le focus sur les outils méthodologiques des méthodes Kanban, Lean ou Scrum est important mais il ne doit pas se limiter à une vision « check-list ». Comme pour beaucoup de dispositifs PMO, la simplicité des outils fait souvent leur efficacité, de même que leur application en bonne intelligence, le plus loin possible d’une vision mécanique des choses.
4. Trouver le bon niveau d’implication des Product Owner, et les bons Proxy PO
La participation à un dispositif agile exige une implication continue et pourtant morcelée du PO. Il ne peut plus se faire assister d’une troupe de consultants pour rédiger des spécifications dans un premier temps puis revenir voir les résultats des tests quelques mois ou années plus tard. Il doit être impliqué personnellement au début et à la fin de chaque sprint, et être disponible pendant tout le cycle de développement.
Le PO doit donc disposer de temps pour le projet, mais aussi bien connaître le métier, ce qui le contraint également à garder des plages de temps pour travailler sur la production. C’est ce paradoxe qui amène souvent à désigner un proxy PO, qui doit alors avoir une relation très fluide et de confiance avec le PO.
5. Compléter l’agilité avec une démarche DevOps
Dernier point, les mises en production peuvent venir ralentir et rigidifier les dispositifs agiles une fois la première version de l’application déployée. Un de mes clients avait un mois de recette / intégration / mise en production, pour deux mois de développement de chacune des versions de l’application qu’il souhaitait faire évoluer.
Dans ce genre de cas, il devient alors intéressant, voire critique, de travailler sur la mise en place d’automatisation de tests, de déploiements, la création de plateformes d’intégration continue et même éventuellement viser le continuous delivery.
Pas encore de commentaires