« Auto-organisation » ne signifie pas « faire tout ce que l’on veut »

Dernièrement j’ai été confronté à plusieurs discussions sur le principe d’auto-organisation de l’équipe qui m’ont fait réfléchir à ce que cette notion véhiculait.

Je profite de cet article pour vous donner mon avis sur les 3 points suivants :

• L’auto-organisation vue par l’équipe comme étant synonyme de liberté totale
• L’auto-organisation structurée suivant un certain processus
• L’auto-organisation comme technique de protection

Tout d’abord un petit rappel sur la notion d’auto-organisation des équipes Agiles.

Auto-organisation Agile

Dans la plupart des méthodes Agiles (Scrum en particulier), la notion d’auto-organisation est un principe très fort car il se révèle très efficace.

En effet, les personnes qui font les choses (les « sachants ») sont généralement les mieux placées pour définir la meilleure façon de faire ces choses. Bien entendu, cette approche pourrait être discutée dans certaines situations ou les acteurs disposent d’une faible capacité de réflexion ou de prise de décision, mais dans le domaine du logiciel nous avons plutôt affaire à des personnes possédant un bagage (niveau d’études) important. Donc en appliquant un principe d’amélioration continue (Essai / Évaluation des résultats / Analyse des problèmes / Modification du processus), une équipe auto-organisée est bien la meilleure façon d’obtenir des résultats efficaces.

Auto-organisation et Liberté

J’ai rencontré des équipes qui disaient haut et fort : « Nous sommes auto-organisés, alors faites nous confiance et laisser nous faire nos choix ».

Généralement une équipe fait ce type de remarque non pas pour expliquer les bénéfices de l’auto-organisation agile, mais pour se protéger en réponse à ce qu’elle considère comme une agression (par exemple un rappel par le management que la date de fin du projet approche ou que le budget n’est pas extensible). Dans ce cas l’équipe fait une erreur d’analyse qui peut se révéler grave de conséquence. En effet, en voulant se protéger, elle risque de se fermer sur elle même, d’apparaître comme une boîte noire au sein de l’organisation, donc hors de contrôle, et de générer encore plus d’inquiétude et donc encore plus d’intervention par le management.

S’il s’agit de l’équipe technique (de réalisation), il est important de lui rappeler que l’auto-organisation est bien synonyme de liberté de choix, mais que tous ces choix doivent contribuer à l’atteinte de la vision du projet. Je me rappelle d’un cours de philo sur le thème : « La liberté de chacun s’arrête où commence celle des autres ». Donc il ne s’agit pas de faire des choix technique de façon unitaire, mais de vérifier de quelle façon chacun de ces choix techniques contribue à la vision du projet.

S’il s’agit de l’équipe globale (métier inclut), il est important de lui rappeler que le produit en réalisation s’inscrit dans une vision d’entreprise et que chaque choix sur le produit doit encore être évalué au regard de cette vision globale.

Si chacun, et donc l’équipe, a connaissance de cette vision et réalise des choix alignés, alors la confiance sera effective et la liberté encore plus forte (n’oubliez pas que la confiance ne se décrète pas, elle se mérite).

Auto-organisation et Structuration

Lorsque l’équipe prend un engagement, sous réserve que l’équipe prenne encore un engagement en début de sprint, ce pour quoi je suis favorable même si ce n’est plus recommandé par Scrum 3.0, j’estime qu’il n’y a pas à interférer dans la manière que l’équipe va mettre en œuvre pour tenir cet engagement.

Vouloir imposer à l’équipe, à priori, une façon de s’organiser au quotidien revient à faire preuve d’ingérence. J’y vois un risque important de désengagement de l’équipe sur l’atteinte du résultat du sprint. A titre personnel, je ne suis jamais autant efficace que lorsque je me suis défini moi même mes objectifs et que j’ai toute latitude pour les réaliser, et je pense qu’une équipe Agile est dans le même état d’esprit.

Lorsque l’équipe constate un problème, comme la non livraison de la totalité de l’engagement, alors, si la cause du problème est la volonté de vouloir tout finir en même temps, il est intéressant de lui soumettre quelques idées comme la limitation du nombre de Story en cours ou la notion d’essaimage. Mais encore une fois, ce ne sont que des propositions, car c’est bien l’équipe qui décide du mode opératoire.

Auto-organisation et Protection

Sur ce sujet, je suis plutôt fâché d’avoir lu dans un billet que « l’auto-organisation avait été inventé par les Agilistes pour se protéger d’un management de type Taylorisme, et que cette solution était un échec » (NON je ne vous donnerais pas de lien sur ce billet, je refuse de lui faire de la pub !!!). Dans ce billet, l’auteur vante les mérites du Lean comme seule réalité valable et réduit l’Agilité à de la gestion de projet sans intelligence. Si j’étais mauvaise langue, je dirais que comme les Managers sont la cible principale du business Lean, il est important de les caresser dans le sens du poil en leur expliquant qu’ils sont indispensables pour tout et en particulier pour décider à la place de leurs équipes … mais je ne suis pas mauvaise langue … alors vous n’avez rien lu 🙂

J’aime l’Agilité car elle présente le Manager comme un soutien à l’équipe (Servant Leadership), en charge de développer les individus et de les faire grandir, et d’assurer sa protection pour qu’elle s’épanouisse sereinement et deviennent une équipe réellement performante. Dans l’Agilité le manager est indispensable, et néanmoins, c’est à ceux qui savent faire les choses que l’on confie la responsabilité de s’auto-organiser pour être efficace … c’est cela que j’aime dans l’Agilité !