Dynamisez votre agilité avec l’Appreciative Inquiry

Ramez … et rêvez !

Les résultats sont mornes, le commerce grince des dents, la production s’interroge, le marketing s’étonne et ne comprend pas. Bref, morose, la conjoncture. Alors la direction réclame des plans d’action, des KPI tous neufs, des kanbans bien rangés, des courbes de vélocité, du TDD, etc.
Dans le même temps, on entend généralement de belles injonctions : « soyez créatifs ! », « innovons, sacrebleu ! », « partagez plus, que diable ! »… Haha, c’est bien joli, mais on est déjà à 100% occupés par les outils à mettre en place et la résolution des problèmes. Vous nous demandez de créer d’innover et de capitaliser, mais on est sous pression en permanence. Les membres de l’équipe sont fatigués, stressés, déprimés. On fait comment ? En gros d’un côté on vous demande de sauver le soldat Ryan et de l’autre vous devriez déjà avoir inventé le Uber de l’an prochain. Cela vous rappelle quelque chose ? Voyons comment on peut essayer de sortir de cette douloureuse impasse avec l’Appreciative Inquiry. Ou, pour utiliser une formule plus « appréciative » : voyons comment vous pouvez dynamiser votre agilité avec l’Appreciative Inquiry.

Le problème est un loup pour l’homme

Résoudre les problèmes, c’est nécessaire, bien entendu. Et nous sommes entraînés à faire cela depuis les bancs de l’école. Le hic, c’est qu’on finit par ne voir que des problèmes. Et cela pèse lourd dans les esprits de tout le monde. On ne parle que de ça au café, à la cantine du midi, et même en famille. Qu’il s’agisse de redresser la courbes des ventes, d’améliorer la qualité du logiciel, ou même de « restaurer une bonne ambiance dans l’équipe », nous avons tous tendance à rechercher des solutions. C’est efficace, oui, et absolument nécessaire. Mais est-ce enthousiasmant ? Est-ce vraiment ce qui motive les humains ? Est-ce que c’est en pensant « problème » (ou « solutions », ce qui revient au même) que l’on est le plus efficace pour innover, créer, susciter l’engagement ? Une des découvertes à la base de l’Appreciative Inquiry, c’est que les gens répondent aux questions qu’on leur pose. Et l’autre c’est que le fait de poser une question façonne le comportement d’autrui. Autrement dit, lorsque l’on ne parle que des problèmes, on altère fortement la capacité d’un groupe humain à être efficace, créatif et innovant.

Ne penser la vie de l’entreprise exclusivement (ou presque) sous l’angle de la résolution des problèmes, c’est nourrir en nous des ressentis négatifs. C’est un peu ce que dit cette vielle légende amérindienne : “Un vieil indien explique à son petit fils que chacun de nous a en lui deux loups qui se livrent bataille. Le premier loup représente la sérénité, l’amour et la gentillesse. Le second loup représente la peur, l’avidité et la haine. “Lequel des deux gagne” demande l’enfant. “Celui que l’on nourrit” répond le grand père.”

Dans votre entreprise, lequel des deux loups est le mieux nourri ?

Une question d’équilibre

Faisons une radio d’une entreprise, voici ce que l’on peut voir:

Untitled(15)

Oh surprise, il y a des problèmes, mais aussi des ressources vitales, des richesses précieuses. Les problèmes doivent être maintenus à un niveau le plus bas possible. Mais que faisons-nous des « énergies positives » ? L’Appreciative Inquiry est un moyen pour faire rayonner ces ressources. Elle propose de nourrir ce côté positif au sein des groupes humains, pour les accompagner vers plus d’efficacité durable. Avant de décrire plus avant ce qu’est l’Appreciative Inquiry, voici pourquoi ce travail « positif » est essentiel. Les travaux de A. Maslow sur la motivation (la fameuse pyramide) sont très connus. Mais ils sont anciens et surtout ne reposent sur aucune démonstration empirique solide. Edward L. Deci et Richard Ryan ont établi et validé empiriquement trois besoins fondamentaux de l’être humain :

SDT Autonomie Compétence Sentiment d appartenance

Leur théorie de l’auto-détermination nous rappelle l’importance capitale du sentiment d’appartenance et de l’autonomie dans la nature humaine. Ce que le travail de Deci et Ryan nous rappelle ici, c’est qu’en se focalisant sur la résolution des problèmes, on oublie une part essentielle des leviers de motivation de nos équipes et de nos entreprises. Pour régler les problèmes, on s’assure que les processus sont suivis, on demande la clarification des fiches de postes, on fait intervenir coachs et formateurs. Ou encore on « rappelle à l’ordre », on utilise le « levier » du management par objectifs, etc. Au mieux, on organise des événements sociaux au cours desquels les humains sont censés trouver une source de motivation, mais sans s’impliquer vraiment dans ce qui constitue la source réelle de la motivation. Sans questionner la place de l’autonomie véritable (qui n’a rien à voir avec la délégation), ni s’interroger ce qui peut vraiment créer du lien entre les personnes et entre elles et l’organisation. Ce que démontre la théorie de l’auto-détermination,  et ce qui fait la réussite des entreprises dites libérées ou « Opale », c’est que le management issu du XIX siècle doit se réinventer pour inclure toutes les sources de motivation. Dans ce contexte, les apports de l’Appreciative Inquiry sont tout à la fois surprenants et riches de potentiel.

L’Appreciative Inquiry, une découverte stupéfiante

Dans les années 1980, David Cooperrider et Suresh Srivastva, tous deux chercheurs, étudient les facteurs de bon fonctionnement d’un hopital de Cleveland. Ils interrogent donc le personnel de l’hôpital et découvrent que tout fonctionne vraiment bien. Après une deuxième campagne d’entretiens, le directeur de l’hôpital les rappelle pour leur signaler que l’ambiance s’est fortement améliorée depuis les entretiens, de même que la performance de l’organisation. Non seulement les gens répondent aux questions qu’on leur pose, mais quand on leur pose des questions sur ce qui fait vie dans une organisation, le fonctionnement de l’organisation tend à s’améliorer significativement. L’Appreciative Inquiry (AI) naît de ce constat, en 1987. Depuis, elle fait l’objet constant de travaux de recherche et d’expériences concrètes dans des groupes qui vont de 1 à 50 000 personnes. Il s’agit donc plutôt d’une pratique validée par l’expérience que d’un outil, encore moins d’une méthode théorique. L’Appreciative Inquiry repose sur les principes suivants :

  1. Constructionnisme : les questions que nous posons ont un impact immédiat sur le monde et le comportement des gens.
  2. Positif ou Héliotropisme : plus nos images internes sont positives, plus nous seront attirées vers elles.
  3. Poétique : comme les poèmes, nos vies et nos organisations peuvent toujours être réinterprétées, nous pouvons en permanence écrire de nouvelles pages de nos vies et de nos organisations.
  4. Simultanéité : les changements commencent dès que l’on pose des questions, parce que les questions entraînent la pensée dans une certaine direction (vous vous souvenez des loups ?).
  5. Complétude : il est plus efficace de réunir toutes les parties prenantes si l’on veut faire évoluer une organisation.
  6. Anticipation : c’est l’image que j’ai en tête qui déclenche mon comportement, nous sommes tous attirés par les images que nous projetons.

l’Appreciative Inquiry en pratique

Une exploration appréciative consiste à réunir autant que possible toutes les parties prenantes de l’organisation sur laquelle on souhaite opérer un changement. La démarche s’appuie sur une méthode pratique qui suit cinq étapes :

5D Projet appréciatif AI

Sans entrer dans le détail du mode opératoire, faisons un arrêt sur la première étape, car elle est cruciale. Décider du projet appréciatif est en effet le début de la démarche en elle même. A ce stade, le commanditaire imaginera probablement une demande du style « Je veux régler le problème du manque d’engagement et de partage dans l’entreprise ». Et bien non. Vous l’aurez deviné, notre sponsor pose la question en termes de problème. Et ce n’est pas ce que nous voulons. Et pourquoi voulez-vous régler ce problème, monsieur le sponsor ? Dès le début donc, il s’agit de transformer le besoin en désir. A quoi bon demander à un groupe de travailler sur ce qui fait vie dans l’entreprise si c’est pour les questionner sur l’inverse, n’est-ce pas ? Donc le projet appréciatif commence par l’élaboration d’une demande appréciative, formulée d’une manière positive. Par exemple, si la demande initiale est : « Je veux que l’équipe arrête son mauvais esprit et se querelle », le mail d’invitation final pourrait ressembler à : « Retrouvons nous pour faire rayonner la joie de travailler ensemble ». L’objectif visé est en ligne avec l’idée initial, il est ambitieux, mais il est aussi, est c’est essentiel, désirable et attractif.

Le projet appréciatif est partagé avec un groupe projet, formé à la méthode, qui élabore un guide d’entretien. Les membres de ce groupe projet seront ensuite répartis auprès de tous les collaborateurs ou membres de l’équipe dans la phase centrale du processus d’exploration, qui recouvre les étapes de « Découverte », « Devenir », et « Décision ». Le moteur de toute la démarche est activé durant l’étape de découverte. Chacun des participants est invité à raconter un moment de sa vie dans lequel il s’est senti pleinement en phase avec le projet appréciatif. Il peut s’agir par exemple d’un vendeur de jardinerie, qui raconte une belle vente réussie. Ces histoires sont un moment de partage humain, et elles débouchent sur l’identification des facteurs d’envie, d’engagement, de créativité, qui ont permis ces moments. Inutile à ce stade de détailler les étapes suivantes, vous sentez bien que tout découle de l’énergie qui se libère à ce moment. Toute la puissance de l’Appreciative Inquiry réside dans ces moments de partage. Il ne reste plus, si l’on veut, qu’à canaliser cette force pour déterminer un plan d’action partagé répondant à l’objectif fixé.

Dynamisez votre agilité avec l’Appreciative Inquiry

Vous voulez que votre entreprise ou votre projet soient vraiment agiles, c’est-à-dire capables d’adaptation, de flexibilité, d’innovation ? On ne le répétera jamais assez, l’agilité est plus un état d’esprit qu’un ensemble de méthodes et d’outils. L’agilité privilégie les humains et leurs interactions (appréciation) par rapport aux processus (résolution de problèmes), prône la co-localisation et l’autonomie des équipes, etc.  Pratiquer l’agilité en se focalisant sur les cérémonies, les artefacts, le développement continu, le TDD, c’est rester au stade de la résolution de problèmes. Il vous manque un supplément d’âme pour réussir vraiment. Parmi les clés de la motivation humaine, vous négligez probablement l’importance de l’autonomie véritable et du sentiment d’appartenance. Et si pour être vraiment agile, vous aviez besoin de faire un détour par l’exploration appréciative ?

Pour cela, vous pouvez bien entendu mener une exploration appréciative à plus ou moins large échelle, mais vous pouvez déjà commencer à faire deux choses. Tout d’abord poser les questions de problèmes sous un angle appréciatif, comme indiqué plus haut. Et aussi vous habituer, par exemple lors de vos rétrospectives ou autres réunions d’équipe, à utiliser les 4 questions usuelles de l’AI 1 (généralement posées en duo, et ensuite résumées au groupe) :

  1. Pourriez-vous décrire une expérience, un moment, une situation de votre vie professionnelle dans lesquels vous vous êtes senti complètement engagé, plein de ressources ou de vie ?
  2. Sans modestie excessive, quelles sont vos réussites ou vos succès les plus remarquables, qu’est-ce que vous apportez de spécifique dans votre activité ?
  3. Qu’est-ce qui vous procure, dans votre activité (ou votre organisation), le maximum de plaisir, de satisfaction, qu’est-ce qui lui donne vraiment vie ?
  4. Quels sont les trois souhaits que vous formuleriez pour renforcer la vitalité et la bonne santé de votre activité (organisation) ?

Et si l’Appreciative Inquiry pouvait, tout simplement, vous aider à mener votre activité ou votre équipe d’une manière plus efficace ? Qu’en pensez-vous ? L’avez-vous utilisée, envisagez-vous de l’utiliser dans le cadre de votre activité ?

Remerciements : merci à Jean-Christophe Barralis de l’IFAI et à Bernard Rohmer de l’association MOM21 pour m’avoir guidé sur les chemins de l’Appreciative Inquiry.

Exemple : Appreciative Inquiry et conduite du changement dans « 65 outils du changement » de Arnaud Tonnelé, pages 16 à 20.

Appreciative Inquiry sur Wikipedia (EN)

Rétrospective Agile Appréciative (EN)

Lire la suite

Aux sources de l’innovation – 1. Innover

Aux sources de l’innovation – 1. Innover

Innovation, innovations

A l’heure des fintechs, des startups de disruption massive, l’innovation fait couler beaucoup d’encre. Un peu comme le bonheur, on trouve beaucoup de recette et pourtant… Qu’est-ce qui fait le succès d’une innovation ? Comment s’assurer qu’elle soit efficace, c’est à dire qu’elle émerge, ET qu’elle soit vraiment mise en œuvre ? Cette série de billets propose quelques pistes pour répondre en 4 étapes :

  1. Innover, qu’est-ce que c’est ?
  2. Est-ce qu’il y a des raccourcis, par exemple peut-on apprendre l’innovation ?
  3. Que tirer de l’analyse des innovations réussies et des situations qui semblent la bloquer ?
  4. Quelles conditions permettent à l’innovation de s’enraciner et de porter des fruits?

Innover ?

Nadya Zhexembayeva
Nadya Zhexembayeva

Nadya Zhexembayeva se présente comme « Chief Reinvention Officer ». Son discours est assez simple : « vous devez réinventer votre business tous les trois ans et demi » (voir sa conférence TED). Et l’explication semble assez logique. La durée moyenne entre naissance et de déclin des activités diminue et tend actuellement vers 7 ans. Les statistiques semblent dont recommander d’innover fortement avant d’entamer le déclin. Et en effet, les cas de disruption massive version « David contre Goliath » sont fréquents. Faute de quoi votre activité risque de mourir. Les fruits de l’innovation sont donc vitaux pour quiconque souhaite pérenniser son activité.
Ok, alors disons que c’est important, mais au fait, qu’est-ce que c’est que innover ?

Alex Pentland
Alex Pentland

Alex (Sandy) Pentland propose cette piste dans « The roots of innovation » : innover, c’est essayer de nouveaux comportements. Ce très photogénique et brillant professeur au MIT se penche sur le phénomène des « signaux honnêtes » pour comprendre l’efficacité des entretiens d’embauche ou des speed datings. De quoi s’agit-il et quel lien avec l’innovation ? C’est assez simple : nous avons appris à décider très vite, de manière largement inconsciente. Nous reproduisons cela dans nos organisations de sorte que nos comportements sont une expression de notre réseau social plus que de notre réflexion. Par conséquent nous avons plutôt tendance à reproduire qu’à innover. A nous conformer qu’à inventer de nouvelles voies. Et Sandy Pentland n’assène pas cela, il le mesure. Spécialiste du « reality mining », il a conçu des « sociomètres », outils qui lui permettent d’analyser les interactions entre des personnes qui prennent des décisions. Tout simplement en mesurant des paramètres comme le rythme de parole, les hochements de tête, etc. Donc Sandy Pentland mesure ces fameux « signaux honnêtes », que l’évolution nous a appris à préserver pour favoriser la perpétuation de l’espèce. Un exemple de ces signaux : le springbok, cette gazelle d’Australie, fait des bonds en hauteur quand il fuit devant un prédateur. Absurde ? En fait, c’est un moyen de signaler qu’il est en pleine forme, en gros il fanfaronne pour que le prédateur lui préfère un individu faible. Nous humains rougissons, par exemple, nous hochons la tête, nous adoptons des postures mimétiques, en fait nous émettons et recevons de nombreux signaux.

Ces signaux sont non-verbaux et inconscients, tant dans leur émission que dans leur lecture, et nous les utilisons en permanence. Par exemple, Pentland remarque que, pendant les périodes électorales, des groupes d’étudiants se reconfigurent spontanément pour rassembler des personnes partageant les mêmes convictions, ce qui renforce ces convictions. Plus généralement, il conclut de ses mesures que, dans nos choix, les attitudes et les actions de nos pairs prédominent par rapport à la logique ou à l’argumentation. Nous sommes visiblement guidés dans nos délibérations par le sens commun, et le sens commun est fruit de l’ensemble des habitudes de notre « famille sociale ». Cet apprentissage social nous influence en exerçant une pression sociale. Nous favorisons inconsciemment des décisions basées sur des associations entre ces signaux et les choix à faire. Et c’est efficace ! Alors qu’un entretien d’embauche fournit dans un temps court une quantité objectivement faible d’information, les choix qui en découlent sont bons à 79% selon Pentland. Alors quoi ? Et bien le problème c’est que ces mécanismes favorisent le consensus, la maximisation du ROI à court terme, la minimisation des risques, la conformité. Vous voyez le problème avec l’innovation ?

C’est là qu’arrive le marché aux idées. Les abeilles qui essaiment choisissent le lieu de leur future ruche par un cycle répété d’exploration et de recrutement. Chaque individu peut proposer des idées, et tenter de rallier d’autres individus. Progressivement, le lieu « idéal » convainc tellement d’abeilles qu’il s’impose à toute la colonie. Les sociomètres de Pentland montrent que des chargés d’innovation dans une entreprise agissent de manière similaire. Leur comportement est un cycle de rayonnement hors de l’équipe « innovation » et d’échanges internes. Et plus le cycle est rapide, plus son activité sociale est riche, plus sa créativité est élevée.

Donc, si innover, ce serait essayer de nouveaux comportements. Et créer des innovations qui réussissent supposerait de parvenir à convaincre de leur pertinence. Voilà déjà une bonne raison pour installer plus de machines à café et réapprendre les bienfaits de la cohésion sociale dans l’entreprise qu’en pensez-vous ?

Lire la suite

Obtenez plus de feedback avec le ROTI

Obtenez plus de feedback avec le ROTI

A la fin d’une réunion ou d’un atelier, vous avez envie d’entendre le groupe exprimer son avis. Le ROTI, c’est la solution simple que vous utilisez pour prendre le pouls d’un groupe à la fin d’un atelier ou d’une réunion. Mais comment faire pour aller au-delà d’une évaluation de 1 à 5 avec quelques pâles propositions ? Le feedback, c’est essentiel pour être agile, nous en avons besoin en permanence, et pas uniquement durant les rétrospectives. Même si ça prend un peu de temps, j’essaie toujours d’y apporter un soin particulier.

Depuis quelques temps, j’utilise une variante du ROTI, qui me permet d’obtenir des retours riches en quelques minutes. Elle s’inspire des principes de la conversation structurée en cherchant à activer différentes aires du cerveau pour enrichir le résultat de la réflexion.

Retour sur temps investi

R.O.T.I, c’est Return On Time Invested. En gros, en tant que participant à un atelier ou à une réunion, à quel point je considère avoir bien investi le temps que j’y a investi. Usuellement, on demande aux participants de voter à main levée en indiquant par le nombre de doigts dressés leur niveau de satisfaction.

Voici la description simple et efficace qu’en donne JC Grosjean, sur son (remarquable) blog.

roti-grosjean

C’est simple, efficace et facile à expliquer à une équipe. Mais c’est un peu trop simple, surtout si on en reste à un chiffre. Que représente-t-il, ce feedback, c’est ce que j’ai envie de savoir. Parce que sinon l’exercice tourne aisément à une petite minute d’autosatisfaction bon marché. Vous ne trouvez pas ?

« Sous quel pont, Monsieur ? »

« Sous quel pont, Monsieur ? », ce fut, dit-on, la réponse d’un candidat au concours d’entrée à l’ENA à qui l’on demandait d’indiquer le débit du Rhône à Lyon. Dans un projet agile, on fait tout sauf éviter de répondre aux questions. Alors avant tout, vous voulez être sûr que les retours de votre groupe partage une vision commune des objectifs. J’aime bien insérer au début des ateliers un peu importants une « Definition of Done » (DOD), comme celle-ci par exemple :

Definition Of Done

C’est l’occasion d’un bref échange avec le groupe et bien sûr aussi une manière de pratiquer la DOD même quand on n’est pas en train de développer du logiciel.

Trois temps, 2 cerveaux

Du coup, au moment de conclure, je présente sur une planche le rappel de la DOD en même temps que le petit schéma des niveaux du ROTI. Et avec ces informations à l’écran, je lance le ROTI. En trois temps :

  1. A tour de rôle, je demande aux participants d’exprimer leur ressenti avec deux mots, par exemple « fatigué et surpris » ou tout ce qui leur vient sur le moment
  2. Ensuite, je demande le ROTI
  3. Enfin, je fais un tour à la cantonade pour demander les points à améliorer

Les résultats sont en général très fructueux. Pendant le tour de « ressenti », on sent s’installer une ambiance d’écoute étonnante, on remarque des hochements de tête, des sourires, des rires parfois… Autant de signaux non verbaux précieux pour « sentir » si la réunion a marché ou pas. Le kaizen commence dès ce moment en fait. Les résultats du ROTI, que je note rapidement, deviennent de ce fait un indice complémentaire de l’efficacité de la réunion, et ils sont éclairés, détaillés par les propositions d’action qui suivent.

Dans cette petite variante du ROTI, vous commencez par conduire votre groupe vers son cerveau droit, celui des sensations, des sentiments, de l’interprétation. Dire ce que l’on ressent, ce n’est pas si fréquent quand on doit décider quoi faire. Nous allons en général directement aux actions (ici, les propositions d’amélioration). Bien souvent, on voit même des décisions qui sont prises très vite après l’énoncé de quelques faits, du pur cerveau gauche. Or, quand on prend un peu le temps d’examiner les faits sous l’angle de l’imaginaire, du ressenti, des interprétations, le champ des actions envisagées s’élargit fortement. Vous en doutez ?  Je vous encourage à essayer sur vos prochains ROTI, avec et sans l’étape « ressentis » : les résultats sont plus riches avec que sans, non ?

PS : Dans un prochain billet, je vous proposerai une description plus complète de la conversation structurée.

 

Lire la suite

NoEstimates : soyez vraiment agile

Pour ne pas estimer, il faut vraiment être agile

L’édition 2015 de la conférence Lean Kanban France, c’est la rencontre avec des orateurs remarquables de l’agilité en IT et en dehors de l’IT. En ouverture de la deuxième journée, Vasco Duarte, qui plaide pour l’arrêt de l’estimation des tâches dans les projets informatiques, nous a livré une vision détaillée de son analyse. C’est convaincant mais suffit-il de convaincre les parties prenantes d’un projet pour pouvoir mettre cela en place ? Estimer c’est s’engager. Donc prendre la responsabilité et en décharger l’autre. Nos organisations sont-elles assez agiles pour cela ?

Le message

Le message de Vasco Duarte est plutôt simple :

  1. Pour augmenter la productivité, vous devez produire le même volume de résultats avec moins de travail.
  2. Si vous organisez votre travail par ordre de priorité, que vous travaillez toujours sur les choses les plus importantes, alors la tâche « estimer » n’aura pas d’impact sur votre plan de travail.

Mais pourquoi estimer ne serait-il pas prioritaire ? Vasco Duarte démontre sur de nombreux exemples concrets que « l’estimation exacte » n’existe pas. Il montre également comment les estimations sont utilisées à tort pour répondre à des questions essentielles de la gestion projet, telles que la taille de l’équipe, durée prévisionnelle du projet, ce qui se traduit ensuite en budget à allouer pour le projet. Sa posture critique reste pour autant toujours constructive et ne l’empêche pas de proposer des outils alternatifs pour répondre avec les bons outils à ces questions. Voici par exemple un résumé de ce Vasco Duarte appelle « Applied capacity planning with no estimates« .

  1. Analyser – Procéder à une analyse détaillée des informations collectées pour pouvoir les exploiter.
  1. Collecter des mesures – Il est nécessaire de mesurer pour prévoir.
  2. Temps – Le temps est en général un facteur limitant du projet.
  3. Prévoir – Utiliser les données collectées pour établir des prévisions par rapport aux contraintes temporelles.
  4. Hypothèses – Le travail de prévision n’est valable que lorsque certaines conditions sont réunies. Les expliciter sous forme d’hypothèses est essentiel.
  5. Similitudes – Utiliser la prévision et comparer avec d’autres références.
  6. Penser – À partir savoir ainsi collecté, réfléchir et évaluer la faisabilité du projet, sinon prendre les décisions adaptées.

Globalement, la démonstration est très convaincante. Mais le problème n’est-il pas au-delà des faits qu’il énonce si brillamment ?  Ne pas estimer c’est aussi ne pas entrer dans le jeu de la prédiction. Et assumer ensemble la réussite du projet. #NoEstimates serait-il en fait une autre manière de dire « Préférons la collaboration avec le client à la négociation contractuelle » ?

 La démonstration

Visiblement, Vasco Duarte ne cherche pas à convaincre. Pas d’appel à nos émotions ou d’effets ronflants dans sa présentation. Il énonce tranquillement des faits. Et c’est très convaincant.

Il rappelle par exemple l’impact énorme des files d’attente dans nos projets. Une tâche donnée passe en moyenne entre 80 et 90% du temps de son « existence » à attendre qu’on s’occupe d’elle. Il est donc plus important, mathématiquement, de mesurer et d’optimiser le débit du flux que d’estimer des temps de travail sur chacune des tâches.  Logique non ?
Vasco présente également le résultat d’expérimentations très concrètes. Il s’agit par exemple de comparer la date de fin du projet d’après les estimations et en remplaçant les estimations par la valeur 1. La date finale est peu impactée.  Un participant de la conférence en profite pour twitter avec malice sa propre expérience :

Tweet

Vasco rappelle également que les incidents, totalement imprévisibles ont un poids aussi important que la nature du projet dans l’issue finale. En d’autres termes, quand on regarde le coût par unité de temps, la complication accidentelle est aussi importante que la complication intrinsèque :

Estimer ... la complication accidentelle aussi ?
Estimer … la complication accidentelle aussi ?

La conclusion semble donc sans appel. Les estimations échouent à prédire convenablement l’issue d’un projet. Il appelle donc les dirigeants d’entreprises à ne pas « parier l’avenir de leur entreprise sur la base de méthodes qui ont de si mauvais résultats ». Autrement dit : « l’espoir est une mauvaise stratégie de management ».

L'espoir n'est pas une bonne stratégie de management
L’espoir n’est pas une bonne stratégie de management

La démonstration de Vasco Duarte a de quoi ébranler les plus sceptiques. Pourquoi donc continuons-nous massivement d’estimer ?

Il suffit de s’y mettre ?

Nous en discutons entre participants après la keynote et ceux qui ont essayé témoignent. Il pour lutter contre la fausse évidence des estimations, il faut convaincre. Et cela prend beaucoup plus de temps que de ne pas estimer. Ok, mais alors, il ne reste plus qu’à démontrer par l’absurde que cela ne sert à rien, comme nous le suggérait notre twittos taquin ? Oui, c’est une approche efficace bien que radicale. Mais qui présente des risques. Parce que les estimations ne servent pas vraiment, pas seulement, à deviner la date de fin. Dans la discussion qui s’ensuit, nous revenons en fait à ce que Craig Larman appelle le « contract game ».

Le « contract game »

Quand je donne une estimation, je donne aussi à mon interlocuteur la possibilité de me dire en cas d’écart « pourtant tu m’avais dit… ».  Estimer servirait donc (avant tout ?) à transférer la responsabilité sur les épaules de celui qui estime. Estimer c’est s’engager. Donc prendre la responsabilité et en décharger l’autre. Nos organisations sont-elles assez agiles pour cela ? Ne pas estimer nécessiterait d’admettre à la fois que la bonne estimation n’existe pas mais aussi qu’il vaut mieux « favoriser  la collaboration avec le client plutôt que le contrat ». Diantre, il faudrait donc mettre en œuvre vraiment les valeurs agiles ?

Voici la démarche en 10 points que Vasco Duarte propose pour mettre en place une démarche « NoEstimates » :

  1. Faites confiance à votre système (de mesure et de développement logiciel) ou construisez-en un autre,
  2. Réduisez le cycle des retours (de la part du client),
  3. Croyez les données (mesurées), pas les prévisions,
  4. Examinez (systématiquement) des alternatives pour prendre des décisions ,mieux corrélées à valeur ajoutée pour l’activité de votre entreprise,
  5. Tester avant tout la valeur, ensuite seulement la fonctionnalité,
  6. Les estimations sont un gâchis, réduisez leur impact sur votre activité,
  7. Ne mesurez l’avancement que sur la base de logiciel opérationnel,
  8. Apprenez à comprendre votre système (mesures, temps de traversée, débit, …),
  9. Utilisez des méthodes qui ont fait la preuve de leur efficacité,
  10. La transformation commence par vous-même.

On voit que son approche est strictement méthodologique. Très juste et efficace certainement, mais Vasco Duarte ne dit rien du lâcher-prise qui sera nécessaire dans l’organisation. Qui devra accepter dans votre projet que l’équipe ne s’engage pas sur une date de fin estimée a priori ? Qui devra s’impliquer aux côtés de l’équipe pour mesurer avec elle l’avancement réel puis projeter cet avancement ? Qui devra se convaincre qu’un projet efficace c’est avant tout un projet qui délivre de la valeur souvent, peu importe quand on décide de l’arrêter, ni même quel est son coût si son retour sur investissement est à la hauteur des attentes ? Ces questions sont importantes pour vous éviter des efforts inutiles quand il s’agira de convaincre de ne plus estimer.

Pour ne pas pas estimer, il faut vraiment être agile

Être vraiment agile, se remettre personnellement en question, mettre de côté des estimations hasardeuses au profit de mesures rigoureuses… Pas si simple en fait.

C’est peut-être pour cela que la première fois que Vasco Duarte a présenté son analyse, désormais mondialement connue sous le titre de NoEstimates, la réponse fut si sèche. « Ferme la porte…. Et ne parle de ça à personne !».

Pour ne pas estimer, il faut  donc pouvoir vraiment être agile et, au passage, déranger quelques usages. Tout un programme n’est-ce pas ?

Pour aller plus loin

Voici un excellent article sur la question de l’estimation et de l’évaluation dans les projets agiles, par David Morris, avec une belle traduction de @OyoMy. Entre autres idées, on y retrouve celle-ci : estimer est souvent utile, les estimations, elles, sont souvent inutiles. Parce que estimer permet de clarifier et parce que les estimations deviennent une cible de fait, qui renvoie la valeur à l’arrière-plan des priorités.

PS : Merci à yann Gensollen (@Yann_G, play14.org) pour la relecture de cet article et les compléments pertinents et essentiels qu’il y a apportés. Il est également l’auteur d’un article fort intéressant sur cette conférence Lean Kanban France 2015

 

Lire la suite

Convergence agile

Convergence agile

L’édition 2015 de la conférence Lean Kanban France, c’est la rencontre avec des orateurs remarquables de l’agilité en IT. Mais c’est aussi un cette année un très enrichissement croisement de points de vue qui démontre une vraie convergence de points de vue face à la complexité et l’accélération de notre environnement. En effet, on n’a pas parlé uniquement d’informatique, de projets, de « flow » de stories, etc. Karl Scotland aborde  la transformation agile en nous parlant de ronds-points. Mélanie Poulain facilite le travail collaboratif en utilisant des outils d’agilistes, de comédiens et d’animateurs de colonies de vacances. Alexandre Gérard transforme un porte-avions fragile en multiples speed-boats autonomes et performants grâce à des valeurs fortes… Cette conférence est celle d’une convergence agile, l’émergence de modes d’organisation humains plus adaptés à gérer la complexité. Et, qu’il s’agisse de diriger une entreprise, de dessiner un rond-point ou d’aider des managers, les similitudes des solutions adoptées sont tout à fait remarquables.

 Les ronds-points agiles de Karl Scotland

La keynote de Karl Scotland  a un objectif clair : nous vendre une n-ième idée géniale pour réussir une transformation agile. En l’occurrence il s’agit de déployer Kanban à large échelle en utilisant l’outil « X-Matrix » proposé par Hoshi Kanri. Selon Scotland, l’outil ne doit pas être utilisé de manière rigide. Il sert avant tout à explorer, visualiser et communiquer les éléments d’un système kanban, ainsi leurs corrélations. Plus que l’outil, ce sont les échanges qui ont lieu autour de l’outil qui ont de la valeur. En fait, plus que la présentation de X-Matrix (si vous souhaitez approfondir cet aspect, voyez cet article), c’est cette posture qui fait l’originalité de son propos. Il propose de déployer la stratégie, plutôt que les tactiques. Par exemple pour lui, l’agilité c’est de la stratégie, alors que ce qu’on appelle « Agile », c’est une tactique.

« Agility is a strategy, Agile is a tactic. »

Parce que c’est plus important, plus efficace de donner une direction que de dire quoi faire. Parce que des contraintes de gouvernance, qui prescrivent ce qui ne doit pas être, sont comme un exosquelette qui freine la croissance. Alors que des « contraintes autorisantes » (enabling constraints) sont comme un squelette interne. Elles permettent de rester cohérent, de garder une forte cohésion, tout en poursuivant librement la croissance. L’analogie avec le monde vivant est simple et puissante. La croissance des crustacés est contrainte par leur exosquelette, une dangereuse mue est nécessaire pour grandir. C’est pourquoi, Karl Scotland recommande de chercher dans chaque organisation le système d’exploitation le plus adapté. Et de ne pas essayer de copier directement des modèles, des tactiques, comme par exemple le « modèle Spotify ». Même si vous aimez passionnément courir, n’essayez pas de reproduire les exploits des plus grands. Il prend l’exemple de Mo Farah, champion du monde de 5000m qui réussit à augmenter sa vitesse progressivement dans un entrainement en altitude.

 

Mo Farah, champion du monde de 5000 m.
Mo Farah, champion du monde de 5000 m.

En résumé, si vous êtes un chat tigré, ne vous prenez pas pour un jaguar !

Mais c’est bien joli, cette théorie des « contraintes autorisantes », mais est-ce que ça marche ? Karl Scotland prend la disparition des feux tricolores. Une source de chaos ? Tout le contraire. Les « magic roundabouts » sont des ronds-points « à l’anglaise » à l’intérieur desquels on retrouve de petits giratoires. Voici le rond point magique de  Swindon en Angleterre :

Magic rondabout
Schéma d’un « rond point magique »

 

Considéré comme le plus effrayant du pays, il est aussi le plus sûr et celui qui offre le meilleur débit de circulation. Les facettes de cette métaphore et leur proximité avec l’IT sont multiples. Pour n’en citer qu’une, cette approche montre qu’on peut augmenter le débit global du flux en réduisant le débit à l’entrée du processus. A l’appui de cette évocation , K. Scotland nous propose cette vidéo, qui montre comment la ville de Poynton résoud un épineux problème de circulation qui coupe le centre ville en deux :

Karl Scotland nous propose également une version modifiée du manifeste agile. Il met l’accent sur un point de vue plus stratégique que tactique et suggère :

  • de favoriser une économie du flux (s’assurer que l’on délivre de la valeur rapidement et au meilleur coût, etc),
  • de réduire la taille des expérimentations pour apprendre vite, souvent et de manière, là encore, frugale,
  • de livrer des services, en s’assurant de leur parfaite adéquation à la la raison d’être de l’entreprise,
  • et bien entendu de mettre en place une boucle de rétroaction efficace en mesurant et en répondant aux retours de la part des utilisateurs.

 

Manifeste agile : stratégie, flux, vision et rétroaction rapide
Manifeste agile : stratégie, flux, vision et rétroaction rapide

L’approche est intéressante, et en même temps, nous sommes plusieurs à nous interroger après la coFail-First-Attempt-In-Learningnférence : pourquoi avoir effacé l’humain de cette liste de valeurs. Cela nous laisse une impression de gêne.

Pourtant l’approche de Karl Scotland semble bien intégrer la composante humaine quand il fait travailler ensemble chez Rally Software toutes les catégories de collaborateurs et les clients.
De même quand il reprend cette interprétation du mot « fail » (échouer), en faisant un acronyme : « First Attempt In Learning » (première tentative d’apprentissage).

Les outils de facilitation de Mélanie Poulain

Une autre conférence marque le croisement des expériences et des points de vue. Mélanie Poulain commence son parcours avec une mission peu engageante : la performance par les processus. Mais l’entreprise souffre, un cabinet mène une étude anthropologique et montre une image rigide, repliée sur elle-même plus qu’entreprenante.

 

L'anthropologie, révélateur de la culture d'entreprise
L’anthropologie, révélateur de la culture d’entreprise

Les dirigeants réunissent le personnel pour annoncer une réorientation stratégique profonde. La mission de Mélanie change : « aidez-nous à mieux travailler ensemble ». « Un CODIR qui dit ça vous autorise implicitement à échouer », rappelle Mélanie. Pas si fréquent. D’autant qu’on lui donne les moyens de son actions. Elle intervient gratuitement auprès des diverses entités de l’entreprise en tant que facilitatrice interne. Et qu’utilise-t-elle ? Alors que c’est encore délicat parfois de parler de jeux sérieux, elle pioche carrément dans les astuces des colonies de vacances et organise des jeux, pas sérieux du tout, pendant la pause de midi. Les places sont limitées… et prises d’assaut !  Les réunions facilitées se multiplient, et, signe de succès, les pratiques se reproduisent indépendamment de son action. Le lien avec les pratiques agiles est vite fait quand elle présente les outils utilisés en réunion. Planning poker, dotvoting, marshmallow challenge, rétrospective en étoile, … Un vrai manuel du parfait agiliste.

 

Quelques outils de facilitation utilisés par Mélanie Poulain
Quelques outils de facilitation utilisés par Mélanie Poulain

Les speed boats d’Alexandre Gérard

Quiconque a déjà entendu parler du reportage « Le bonheur au travail », diffusé en février 2015 connaît Alexandre Gérard. Sa conférence porte un message enthousiaste « Et si les entreprises libérées pouvaient changer le monde ? ». De son point de vue « dans 5 ans le mouvement des entreprises libéré aura fait basculer le monde économique ».

Alexandre Gérard
Alexandre Gérard

Au-delà de ce pari, ce qui est frappant ici c’est la convergence de résultats et d’analyse entre l’agilité et ces modes de management d’entreprise « alternatifs » qu’évoque Alexandre Gérard. Alexandre Gérard, confronté à une crise grave en 2009 transforme radicalement le mode de fonctionnement de son entreprise. Il confesse « pendant 15 ans, j’ai géré la boîte pour les 3% ». Les 3%, ce sont les individus qui ne jouent pas le jeu. Et il fait cela car il abandonne à cette époque une croyance selon laquelle les individus n’aiment pas travailler. Ce qui le conduit, à donner à ses employés une très grande autonomie. Il  explique comment les responsables locaux sont élus sans candidats et comment les entités régionales décident de leur budget souverainement. Et bien entendu, ce qui résonne à nos oreilles c’est quelque chose comme « Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés. 1».
Alors que son entreprise avait les pires difficultés à affronter la tempête, tel un puissant porte-avions difficile à manœuvrer, il laisse émerger une organisation fortement décentralisées. Désormais, elle se compose d’une quarantaine d’entités régionales autonomes. Ces « speed-boats » agissent et décident localement avec une telle liberté d’action que Alexandre Gérard consacre actuellement 30% de son temps à l’entreprise, le reste se répartit entre un travail de consultant auprès des dirigeants et de conférencier.

Et d’ailleurs en entendant Alexandre Gérand, on croit entendre un consultant spécialisé dans la transformation dite agile. Quel est son rôle dans l’organisation alors ? « J’ai un rôle de gardien des libertés et des valeurs, de la culture », nous dit Alexandre Gérard. Tout comme Karl Scotland, il porte la stratégie, laissant la tactique à plus compétents que lui : ceux qui sont au contact direct des difficultés du terrain.

La performance comme cible, l’agilité comme moyen

Voici donc trois conférences qui, décidément, marquent une ouverture importante. Trois conférences qui témoignent, chacune à leur manière, de tentatives pour rester performant alors que tout change à un rythme effréné. Et qui, chacune à leur manière, font écho aux principes, aux valeurs, aux outils de l’agilité.   Une manière de  nous rappeler que « Agile » est bien plus qu’une boîte à outils pour informaticiens. Une manière de nous rappeler que l’agilité est la vraie cible. L’agilité, cette capacité à s’adapter, à innover, à être performant dans un environnement complexe, changeant, riche en ruptures.

 

 

Lire la suite

Agile : agir sur l’organisation et la culture ?

Agile : agir sur l’organisation et la culture ?

Est-ce que « la méthode agile » recèle des fragilités qui freinent le passage de la théorie à la pratique ? Et si les freins étaient aussi, voire plutôt organisationnels et culturels ? L’analyse critique proposée par Gil Develey dans son article illustre un point de vue, des inquiétudes et quelques incompréhensions qui sont parfaitement légitimes.  Les pratiques agiles peinent encore à s’imposer à grande échelle. Agir sur l’organisation et la culture est essentiel pour réussir une transformation agile. Au même moment paraissait « Friction », un article passionnant de Mary Poppendieck qui justement éclaire cette question de la difficulté qu’ont les opérateurs historiques publics et privés à intégrer dans leur organisation, dans leur culture, les pratiques qui permettent aux projets informatiques de réussir et de répondre aux attentes des clients et utilisateurs.

Agile-balance

« Les règles de la méthode agile »

M. Develey cite les cinq règles suivantes :

  • décomposer le domaine en activités appréhendables de bout en bout
  • donner la responsabilité d’une activité à une équipe
  • chaque équipe dispose de l’autorité nécessaire pour définir le fonctionnement futur
  • chaque équipe est autonome en termes de capacité de décision, et de compétence technique
  • le client est impliqué au plus près des activités informatiques tout au long du cycle (depuis le design en passant par les tests, jusqu’à l’acceptation finale).

Ces règles correspondent effectivement à des pratiques que l’on retrouve dans les projets agile et sont plutôt représentatives des valeurs et principes de l’agilité. Mais commençons par le commencement : « agile » est plutôt un mouvement qu’une méthode. Prenant ses racines dans dans certaines pratiques de l’industrie (Toyota en particulier), l’agilité apparaît dans l’informatique dans les années 1990 et est basée depuis 2001 sur le manifeste agile. La finalité de l’agilité dans l’IT est de mieux développer des logiciels. Ce manifeste ne décrit pas une méthode, il pose simplement quatre valeurs et douze principes. Les valeurs sont reprises ci-dessous  (texte complet du manifeste agile) :

  • privilégier les individus et les interactions plutôt que les processus et les outils,
  • privilégier la collaboration avec le client plutôt que la négociation d’un contrat,
  • privilégier la réponse au changement plutôt que le suivi d’un plan,

Le fait qu’il ne s’agisse pas d’une méthode est important : les valeurs et principes de l’agilité peuvent en effet s’appliquer à bien d’autres sujets qu’au développement logiciel.

A la suite du manifeste agile, diverses pratiques sont apparues ou ont évolué, qui intègrent les valeurs et principes agiles. Et là on peut parler de méthodes, Scrum par exemple, qui ont en commun un cycle de développement itératif, incrémental et adaptatif.

Méthode Scrum, une introduction très concrète en Anglais (Merci à Michael James)

L’article de G. Develey est donc plutôt juste quand il reprend notions d’autonomie et d’implication du client, ainsi que l’accueil bienveillant du changement, que l’on retrouve dans le manifeste. De même pour la décomposition d’activités appréhendables de bout en bout, qui vient probablement d’une expérience de « feature team » souvent proposé et en même temps débattu par les agilistes . La « notion de clarification » quant à elle, évoque par exemple les pratiques de raffinement de backlog que l’on retrouve en complément de Scrum.  Mais en quoi est-ce ces pratiques, qui sont nées de la volonté de faire mieux, conduiraient en elles-mêmes les projets à l’échec ? L’auteur indique « les demandes de changement, les modifications, font l’objet d’une gestion particulière et sont ou pas intégrés dans les développements ultérieurs ». Accueillir le changement est un des principes de l’agilité justement parce que les approches précédentes échouaient en voulant figer le besoin avant de lancer la réalisation. D’ailleurs, même avec une approche de type « cycle en V » les changements doivent être gérés. Donc s’il y a problème à un moment avec la balance du changement, la cause doit probablement être recherchée ailleurs dans le projet ou son environnement. La fièvre est là, mais ne cassons pas le thermomètre pour autant.

« Fragilité de la méthode » ?

Selon M. Develey, la fragilité de l’agilité résiderait dans trois conditions, que l’on suppose implicitement impossibles à réunir puisqu’elles constituent une fragilité selon l’auteur.
Premièrement « trouver un représentant qui ait à la fois autorité et connaissance métier ». Diantre. Est-ce que cela n’est pas autant nécessaire sur un projet non-agile ? A un moment, il faut bien par exemple valider des spécifications, donc prendre une décision en connaissance de cause sous l’angle métier.
Ensuite « réunir une équipe de développeurs qui maîtrisent leurs outils (…) trouver un bon interprète ». Saperlipopette ! Mais comment faire un projet réussi sans une équipe compétente et sans passeurs efficaces entre le métier et la technique[1] ?
Enfin, « disposer de testeurs expérimentés » et « intégrer très en amont les problématiques d’exploitation ».  L’article évoque également comme des difficultés le travail collaboratif et le debriefing quotidien. N’est-ce pas également surprenant ?
Il semblerait que la conclusion « fragilité de la méthode » masque en fait des problèmes propres à l’organisation. En tout état de cause, il est difficile d’incriminer des bonnes pratiques qui ont prouvé leur efficacité dans bien des contextes.

Agile, l’affaire des directeurs de la transformation ?

L’article débute en fait par une déclaration qui peut éclairer un peu les choses :

« Depuis une bonne dizaine d’années, plusieurs Directeurs de Transformation (mènent leurs projets en mode agile) ».

Nous y voilà, non ? Pourquoi diable le fait mettre en œuvre des pratiques destinées à améliorer l’efficacité des projets informatiques serait-il l’apanage plutôt des directeurs de la transformation ? Est-ce parce que ces méthode sont nouvelles ? Non, elles ont plus de vingt ans.
Les directeurs de la transformation sont chargés dans ce cas de réussir la transition numérique d’un business. Et ils le font en réinventant complètement l’expérience client, parce que c’est ce que font justement les nouveaux venus, qui innovent radicalement dans la manière d’aborder le client et son parcours. Et parce que ces nouveaux venus concurrencent directement les opérateurs historiques.
Il se trouve que souvent, les équipes qui réussissent cette transition numérique contournent les organisations en place pour regroupent dans la même équipe la palette complète des compétences nécessaires. Réunir une équipe qui maîtrise la réalisation, de bout en bout, nous retrouvons le propos de M. Develey. C’est ce que Mary Poppendieck appelle dans son article les « full stack capabilities » :

« Les grandes entreprises ont les mêmes ensembles complets de compétences que les startups, mais ces comptétences appartiennenet à des services différents et il existe des frictions aux frontières de chaque service. Plus encore, les opérateurs historiques sont profondément impliqués dans les modes de fonctionnement actuels, donc les grands opérateurs historiques sont généralement incapables de vraiment réinventer le parcours client. Malgré tous leurs efforts pour se montrer innovants, (ils) ont tendance à ne pas voir les frictions embarquées dans le parcours client qu’ils fournissent actuellement. »[2]

On voit donc de plus en plus coexister deux types d’organisation. La structure « historique » conserve ses processus, ses règles, sa structure très hiérarchisée et cloisonnée, et on confie à des sortes de startups internes le soin de réussir à repenser l’expérience client via le digital. C’est ainsi que naissent les directions de la transformation, les laboratoires d’innovation digitale ou autres pôles digitaux. La DSI elle même est contrainte de répartir ses ressources entre les projets « classiques » et les projets « digitaux », souvent pilotés en direct par la communication, le marketing voire la direction générale.

Cette situation conduit à un système d’information bimodal (Bimodal IT). Une informatique à deux vitesses en quelque sorte. C’est probablement la marque d’une transition profonde. Nécessaire et parfois douloureuse, cette transition remet en question l’organisation et la culture des entreprises. Elle bouscule également les rôles et les responsabilités, certains managers étant appelés à devenir plus des servant leaders que des figures d’autorité. Les inquiétudes exprimées par Gil Develey sont donc légitimes. Mais l’agilité, qui les met en lumière, n’en est pas la cause. Plus que jamais, il est important d’échanger sur nos points de vue pour réduire les inquiétudes. Il faut dialoguer pour rapprocher les « classiques » et les « digitaux », les « agilistes » et les sceptiques, les équipes agiles et les managers ou cadres dirigeants. Cet article y aura-t-il contribué ? C’est en tout cas l’intention de ce billet.

[1] Rôle dévolu au Product Owner dans la méthode Scrum.

[2]« Large companies have the same full stack of capabilities as startups, but these capabilities lie in different departments and there is friction at every department boundary. Moreover, incumbents are deeply invested in the way things work today, so large incumbent companies are usually incapable of truly reinventing a customer journey. As hard as they try to be innovative, incumbents tend to be blind to the friction embedded in the customer journey that they provide today. »M. Poppendieck : réduire les frictions pour réinventer le parcours client.

Lire la suite

Coopération : agile à l’échelle – Mary Popendieck

Comment équilibrer coopération entre équipes et autonomie des équipes pour que l’agilité survive au « passage à l’échelle » ? Article inspiré de la keynote de Mary Poppendieck lors du Scrumday 2015 (FSUG).

Coopérer : l’échec des bonnes intentions

Nos projets sont compliqués, urgents, contraints. Notre environnement est changeant, chaotique, complexe. Alors nous, pour y voir plus clair, on s’organise. L’équipe projet est un repère simple et efficace. Scrum prône l’autonomie pour réussir et en effet à l’échelle d’un « scrumteam » de 10 personnes, c’est très efficace. Mais quand on passe à l’échelle ? L’autonomie reste essentielle pour réussir, mais la coopération devient un levier capital. Que faire pour dépasser les deux écueils que représentent cette confrontation entre autonomie et coopération ?

Ecueil n°1 : puisqu’on favorise l’autonomie au sein des équipes, l’autonomie a tendance à avoir plus de poids que la coopération quand il faut coopérer entre équipes. Ce qui fonctionnait localement est contreproductif à l’échelle :

IMG_20150722_090845

Pour apporter une première réponse à ce dilemme, Mary évoque Yves Morieux et sa conférence TED à propos de « Smart Simplicity« , qui propose 6 règles pour favoriser la coopération. En particulier, il  cite directeur général du groupe Lego, Jorgen Vig Knudstorp : « on ne blâme pas pour l’échec, mais pour ne pas avoir aidé ou demandé de l’aide ». Un remarquable lâcher-prise par rapport aux logiques classiques des objectifs à atteindre. Et Yves Morieux enfonce le clou : « Soudain, il devient dans mon intérêt d’être transparent quant à mes vraies faiblesses, mes vraies prévisions, car je sais que je ne vais pas être blâmé si j’échoue, mais plutôt si je n’ai pas aidé ou demandé de l’aide ».

(suite…)

Lire la suite

Atractor_Poisson_Saturne

Lâcher-prise ! Quels attracteurs pour la performance ?

Lâcher-prise, truc de « gourou », vraiment ?

Le « lâcher-prise » est plus efficace en environnement complexe que nos habitudes tenaces de tout contrôler. Ou « comment faire émerger la performance plutôt que surveiller des KPI ».

Vous avez certainement entendu des mots tels que « secte des agilistes », « gourou du coaching » ou encore « le jeu dans l’entreprise, mais c’est une blague ! ». Les théories de la complexité, de la psychologie, la théorie des jeux, les neurosciences constituent , avec la connaissance empirique, le socle des pratiques « modernes » de management et de gestion de projet telles que l’agilité, le lean, le coaching systémique, etc. Je voudrais ici mettre en évidence ces fondements scientifiques et formels. Pour renforcer la crédibilité de ces outils auprès des décideurs et vous permettre d’approfondir les mécanismes qui rendent si puissants ces outils et ces pratiques. Essayons d’appliquer cela dans le match Contrôle VS Lâcher-prise : pourquoi la réduction du contrôle au profit de l’autonomie des équipes est un choix nécessaire.
(suite…)

Lire la suite

Survivre au chaos – La vie romancée de l’Entreprise

Les histoires de l’oncle Pierre #1

Les histoires, c’est notre enfance, c’est parfois le conte ou plus souvent aujourd’hui le roman ou le film. Sa force d’évocation puise au plus profond d’entre nous. Voici une histoire qui parle de l’Entreprise. De ses difficultés à inventer son avenir dans un monde fait de complications et de complexité.

Navigation par mauvaise visibilité

Jean est à la tête de l’Entreprise depuis deux ans. Avant, il avait déjà un rôle central, c’est sur lui que reposait la conquête de nouveaux clients, le contrôle de la bonne marche des projets, la surveillance opérationnelle des marges au quotidien. Son ambition c’est de développer l’Entreprise, d’élargir sa gamme de produits et sa base de clientèle. Depuis sa nomination, il a lancé plusieurs projets innovants qui lui tenaient à cœur. Un an de travail pour les faire aboutir. Il en est certain, c’est l’avenir et les clients vont plébisciter ces nouveaux produits… Bientôt.

Mais l’année passée était terne, le commerce peine encore à trouver ces nouveaux marché dont l’entreprise a besoin. La concurrence est si vive, chaque décision dépend de tellement de facteurs, l’environnement change si vite, Jean dit parfois qu’il doit piloter un électron au milieu d’un plasma en fusion. Pour réussir à se développer, l’Entreprise doit avant tout survivre. Pas facile de voir loin dans cette purée de pois !
Alors Jean ne ménage pas sa peine. Il est là dès l’aube et ne part jamais avant vingt heures. Pour maximiser les chances de succès, il est présent sur tous les fronts, relit un maximum de choses, vérifie et corrige, souligne les erreurs pour qu’elles ne se reproduisent pas, hausse le ton parfois, parce que c’est nécessaire. L’Entreprise est un grand navire chahuté sur un océan qui ne cesse de changer d’humeur, il faut un chef vaillant à la barre. Il faut être compétent, vif, performant, aux aguets. Souvent Jean se demande ce qui se passerait s’il n’était pas là pour « assurer ». (suite…)

Lire la suite