Agilité@Scale : Que répondraient vos équipes à la question “Quelle est la valeur apportée à votre client dont vous êtes le plus fier dans les 3 derniers mois ?”

Invité par mon excellent confrère Alain Sacquet à proposer un retour d’expérience lors d’un Think Tank sur les pièges de l’agilité à l’échelle organisé par GFI, j’ai réfléchi à l’angle sur lequel je souhaiterais aborder le sujet. Il ne m’a fallu pas très longtemps avant de me décider sur mon sujet favori : les équipes, et plus particulièrement la maturité des équipes.

En effet, au démarrage d’une transformation agile, on expérimente sur une ou deux équipes, la plupart du temps pour mettre le maximum de chance à la réussite du projet. On constitue alors une équipe avec les meilleurs éléments de nos équipes. D’une part, car ils sont souvent promoteurs de la méthode et car on veut les valoriser. D’autre part, comme il s‘agit d’une équipe pilote, on va leur créer un espace hyper protégé, avec le droit à l’erreur et la sécurité psychologique sans vraiment s’en rendre compte. On crée ainsi une situation ultra biaisée, et en vérité, quelle que soit la démarche utilisée, il est fort probable qu’ainsi le résultat soit à la hauteur des attentes.

Si c’est utile pour éventuellement convaincre des sponsors pour lancer une démarche d’agilité à l’échelle de votre IT, voire de l’entreprise, il est fort probable que vous n’ayez rien appris, à part probablement quelques artefacts issus de la méthode que vous aurez choisie, souvent SCRUM.

Le Cargo Cult

Fort de ce “succès”, vous vous préparez à déployer à l’échelle, par des formations massives à certains de vos collaborateurs pour devenir vos futur Scrum Master ou Product Owner, ou vous achetez un forfait “Transformation Agile” dans une grande boite de conseil. Les murs se transforment en colonne de post-its, vos équipes se réunissent tous les matins debout pour échanger sur les post-its qu’ils ont traités. Ca y est vous êtes Agile. Champagne !

Ou pas. Il est plus fort probable que vous ayez de l’Agilité “Canada Dry” : Ça a la couleur de l’agilité, le goût de l’agilité… mais ce n’est pas de l’agilité. Ce phénomène est appelé le Culte du Cargo.

Le Culte du Cargo est un phénomène apparu au XXème siècle où les aborigènes copiaient ce qu’ils observaient des occidentaux sans comprendre dans le but d’obtenir notamment de la nourriture. Ils ont notamment copié un radio émetteur car ils pensaient qu’ainsi ils recevraient aussi des rations et du matériel. Après nombre d’appels infructueux – et pour cause – ils ont créé une piste d’atterrissage. Sans plus de résultats, évidemment.

En copiant sans comprendre le fond, ils n’avaient aucune chance d’obtenir les résultats qu’ils espéraient. Ça vous rappelle quelques chose ?

Symptômes

Les symptômes peuvent être simples à détecter, il suffit de déambuler dans vos open spaces et de poser des questions.

Par exemple, il est fort probable que la plupart des équipes aient un management visuel, car c’est un des marqueurs forts visibles par tous, notamment des managers. Mais est-il réellement utilisé voire utile ? Posez la question à un membre de l’équipe, est-ce que le sujet sur lequel il travaille est dans la colonne en cours ? A l’inverse, prenez un post-it de cette même colonne et demandez qui travaille dessus ?

Un des autres marqueurs forts est le daily stand-up meeting. Répond-il bien aux intentions de collaboration et transparence ?

On le résume souvent à trois questions simplifiées. Petit à petit, les membres de l’équipe ne s’écoutent plus car cela devient un moment de reporting. Dans les cas extrêmes, cela devient de plus en plus long, les personnes arrivent en retard, voire les personnes ne se parlent plus en dehors de ce meeting…

De nombreux coaches ont écrit sur ce sujet, je vous invite à lire :

• Olivier My : Une alternative au Daily Scrum Meeting,
• Nicolas Ploquin : Le Daily Stand-up, c’est débout mais pas que, 
• Luc Taesch : Daily Meeting, un protocole de réunion,
• Sans oublier CommitStrip :

“Lorsque l’organisation ne comprend pas la philosophie, la mentalité et les intentions de l’agilité, les individus appliquent alors des « recettes ». Il devient alors plus important de respecter les consignes (telles les 3 questions du Daily) plutôt que d’appliquer une intention – celle d’augmenter la collaboration et la transparence”

Martin Proulx, Expert en comportements agiles, Audacium Leadership inc.

Le passage à l’échelle

Pour éviter ces phénomènes, il est important de comprendre qu’une transformation, un changement de pratiques, ne se déploie pas simplement en appliquant un framework (Scrum, Safe, …). Les êtres humains ne sont pas des robots sur lesquels on applique des mises à jour :

Notamment, si on ne comprend pas le sens derrière ces pratiques, on va uniquement transmettre les artefacts et non les intentions. L’expérience de Asch démontre bien d’ailleurs notre capacité à se conformer au groupe, même quand il a tort.

C’est ainsi que, avec l’aide parfois de société de consulting, on arrive à l’agilité “Canada Dry”. Par imitation, conformité, on voit très vite fleurir les cérémoniels et autres artefacts. Les scrums masters et product owners sont certifiés et comme par magie, votre organisation est “Agile”.

La situation peut même être encore plus fragile, car souvent les managers et les équipes ne retiennent que les avantages perçus, sans comprendre et donc prendre en compte les contraintes.

C’est ainsi que l’on se retrouve avec des équipes “autonomes” à tendance “indépendantistes”, car on n’a pas accompagné la montée en maturité de l’équipe sur ce sujet. C’est également ainsi qu’on se retrouve avec des managers qui font “confiance” aux équipes tant qu’il n’y a pas de problème, mais qui revienne à un mode contrôlé dès qu’il y a du flou ou des risques.

Quelques points essentiels

Il ne s’agit pas ici de donner des leçons, les précédents paragraphes ont surtout montré qu’il ne suffit pas d’appliquer des recettes pour que cela fonctionne. L’objet ici est de partager ce qui m’a semblé aider dans mes contextes.

Ces points sont le fruit d’apprentissages et d’expérimentations, et me semble important lors d’un passage à l’échelle :

• avoir une vision, un horizon. On ne passe pas à l’échelle parce que c’est à la mode (en tout cas, ce n’est pas souhaitable), mais pour répondre à des besoins dans un contexte. On sous-estime souvent cette partie qui permet à chacun de trouver du sens à la transformation. Il ne s’agit pas uniquement de co-construire une vision, mais également de la promouvoir, de la “marketer” pour qu’elle soit connue de tous et partagée.
• développer les compétences humaines, les “soft skills”. Lors du recrutement ou pendant la transformation, il faut notamment développer les capacités à :
  • co-élaborer, 
  • gérer un désaccord ou un conflit,
  • décider à plusieurs,
  • écouter sans chercher à convaincre,
  • se soutenir face à l’incertitude.
• intégrer les nouveaux collaborateurs et équipes. Les formats bootcamp permettent par exemple de diffuser l’ADN de votre entreprise, d’expérimenter les pratiques dans un contexte de sécurité psychologique. Les cas pratiques sont bien plus intéressants et motivants que du slideware.
• construire un réseau qui soutient le changement et la diffusion des compétences. Un coach Agile seul, voire une équipe de coaches ne peuvent supporter seule la transformation, et surtout, doivent pouvoir sortir du dispositif. Il faut donc mettre en place un système soutenable qui accompagnera les équipes dans le temps.

Il y en a bien d’autres, et pour creuser ce sujet, je vous invite à lire les articles de Luc Taesch avec qui j’ai eu le plaisir de faire un bout de chemin lors d’une phase de transformation :

• La maturité d’une transformation
• La maturité d’une transformation – Comment ?

Ainsi que le livre co-écrit avec Alain Sacquet “Mettre en oeuvre DevOps : Comment évoluer vers une DSI Agile ? #autopromo

Maturité des équipes 

Au delà des points précédents, ce qui me semble essentiel à retenir, c’est qu’une entreprise est un environnement complexe, les individus et les groupes également. On ne peut utiliser une seule méthode pour toutes et tous, et cela prend du temps.

Il faut accepter que chaque équipe va avoir un niveau de maturité différent et qu’il faudra donc adapter nos modes de management, d’accompagnement en fonction de ce niveau.

Cette proposition de modèle de maturité est basée sur Olivier Devillard &  Bruce Wayne Tuckman, qui ont proposé des modèles de construction de la cohésion d’un groupe.

L’idée est donc de développer l’agilité en fonction du niveau, en s’inspirant par exemple du concept Shu-Ha-Ri. Il s’agit d’un concept issu des arts martiaux japonais qui décrit les 3 étapes de l’apprentissage.

Shu-Ha-Ri peut se traduire par suivre les règles, comprendre les règles et transcender les règles.

Les frameworks (Scrum, Safe, …) sont utiles à l’étape Shu de l’apprentissage de l’Agilité. Mais pour pouvoir réellement passer à l’Agilité@Scale et amener l’ensemble de nos équipes au niveau d’équipes Excellente, l’organisation devra les comprendre et surtout les transcender.

Pour creuser ce sujet, je vous invite à lire l’ouvrage d’Olivier Devillard : La dynamique des équipes et l’intelligence collective

Retour aux sources

Finalement si l’on revient au manifeste Agile, et notamment ce principe :

Une question intéressante à poser à nos équipes pour mesurer notre maturité agile :

Quelle est la valeur apportée à votre client dont vous êtes le plus fier dans les trois derniers mois ?

Le mot fier est important car l’entreprise consacre des budgets important sur nos sujets, et nous passons une partie importante de notre temps à notre activité professionnelle, assurons nous que ce temps soit utile et qu’il nous rende fier :

“Je ne conçois pas que l’on traverse la vie et le temps inconsciemment, de façon banale. En ne sachant pas, le jour écoulé, à l’orée de la nuit, ce qu’on en a fait. C’est une des choses qui m’effraient le plus, de me rendre compte que le temps passe sans rien en faire.”

Christiane Taubira, femme politique