vendredi 10 octobre 2008

LE CHANGEMENT ET LES CONFLITS

IRRÉDUCTIBLES GAULOIS

Je travaille dans une grande organisation dont le modèle de fonctionnement n'est pas agile.
Le modèle est assez classique des grandes structures françaises qu'elles soient industrielles, administratives, militaires, scolaires ou universitaires. Il s'agit de structures pyramidales, hiérarchisées, descendantes et élitistes. Le changement y est freiné par l'inertie des grandes organisations. On y pratique la séparation de penser et de faire, tout comme dans le paradigme de la production de masse et le cycle en vie en V. Une élite pense des procédures que les d'autres doivent appliquer pour faire.

Pourtant, il existe un appétit de changement. Différentes initiatives locales cohabitent comme la mise en place de la démarche Lean et l'adoption du développement logiciel Agile. Soutenues par la hiérarchie proche, plusieurs équipes agiles y développent des produits,
tels des villages d'irréductibles gaulois.

HOUSTON, NOUS AVONS UN PROBLÈME

En ce moment, l'équipe dont je fais partie est en train de traverser une zone de turbulences. Nous sommes confrontés à des conflits à répétition avec les intervenants en périphérie de l'équipe.
Au sein même de notre équipe et avec le Product-Owner, l'ambiance est mouvementée mais dynamique, constructive et réconfortée par des résultats. Par contre, les relations se dégradent avec les acteurs qui ne sont pas directement et quotidiennement impliqués dans la construction du logiciel.

EST-CE UN CAS PARTICULIER?

Curieusement, dans les conférences auxquelles nous assistons et participons (XP Days, Agile Tour), il y a une part importante des sessions qui traitent de la gestion du conflit et de la conduite du changement. Ce que nous vivons n'est donc pas un cas isolé:
Le travail en mode agile déclenche tôt des conflits dans les organisations qui les mettent en place.
POURQUOI? A CAUSE DU CHANGEMENT!

Ces conflits naissent car les équipes auto-organisées conduisent des changements pour lesquels certaines personnes hors de l'équipe ne sont pas préparées. Les équipes agiles adaptent les standards et les meilleures pratiques du moment, elles s'organisent d'elles-même sans chef directif, elles développent des compétences nées du vrai travail d'équipe qui déstabilisent certains experts, elles sont soudées et acceptent les contraintes si elles sont comprises et non imposées par l'extérieur.
Les équipes agiles ne font pas conformément aux procédures pensées par une élite. Elle n'appliquent pas la séparation de pensée et de faire. Elles pensent ET font.
Tout changement déstabilise, mais ce changement particulier a un effet accentué dans une structure élitiste, pyramidale, hiérarchisée et descendante. Ainsi naissent les conflits entre les équipes agiles et leur entourage.

POURQUOI? PAR MALADRESSE!

Nous sommes pris par l'élan de l'équipe. Nous consacrons plus d'énergie à avancer qu'à communiquer sur notre manière de travailler. Certains se sentent exclus de cette dynamique, de cette solidarité d'équipe et ne se sentent plus respectés.
Nous sommes des techniciens passionnés, plus habiles en amélioration continue de nos pratiques de développement qu'en communication et qu'en conduite du changement.
Ainsi, il me semble qu'une organisation qui souhaite mettre en place des démarches agiles se doit d'investir dans la conduite du changement: communication, formation, sensibilisation ...

POURQUOI? PARCE QU'ON LIVRE TÔT!

Des conflits arrivent si tôt dans un projet agile qu'on entend même dire que les démarches agiles sont plus génératrices de conflits que les démarches descendantes. Est-ce vrai?

Pour analyser ce problème, faisons (encore une fois) le parallèle entre l'équipe et son produit.

Sur un projet précédant, nous avons travaillé en mode eXtreme-Programming au sein d'un programme plus large avançant en cycle en V. A l'époque, on nous a reproché de générer plus de défauts que le reste du programme. Pourquoi? Parce que nous levions les défauts plus tôt! C'est le propre des démarches agiles qui testent tôt et livrent tôt du logiciel opérationnel pour obtenir tôt des retours d'informations sur la satisfaction du client.
Pourquoi dit-on qu'une équipe agile génère plus de conflits qu'une équipe descendante? Parce qu'une équipe agile lève les conflits plus tôt!
A partir du moment où plusieurs personnes partagent un même objectif, des conflits apparaissent. Les points de vue se confrontent, tout simplement. Les conflits accompagnent les équipes.
Dans un groupe travaillant en cycle en V, il n'y a pas de vrai travail d'équipe jusqu'à la tardive phase d'intégration. D'ailleurs, l'objectif de la phase d'intégration est de réunir les travaux menés en parallèle. A partir de l'intégration, les crises apparaissent avec le travail d'équipe. Avez-vous vécu des projets en cycle en V qui ne sont pas devenus des poudrières à partir de la phase d'intégration? Et bien les projets agiles travaillent dès le début en équipe. Les conflits sont donc levés bien plus tôt.
Un conflit est à l'équipe ce qu'un défaut est au produit. Plus il est identifié tôt, plus son impact sera limité.
Pour contenir les défauts, les développeurs utilisent les tests. Si on poursuit le parallèle entre conflit et défaut, comment maitriser les conflits dans les équipes?
Les rétrospectives d'itération sont un moment où l'équipe identifie ses dysfonctionnements et se réorganise pour les corriger.
Si le conflit est à l'équipe ce que le défaut est au produit, alors la rétrospective et l'amélioration continue des pratiques est à l'équipe ce que les tests et le remaniement sont au produit.
Bref, il me semble que:
Il n'y a pas plus de défauts dans un produit développé par une équipe agile que dans un produit développé par une équipe travaillant en cycle en V. Par contre, l'équipe agile lève les défauts plus tôt.
De même, il n'y a pas plus de conflits dans une équipe agile que dans une équipe travaillant en cycle en V. Par contre, l'équipe agile lève les conflits plus tôt.

9 commentaires:

  1. Cela fait plusieurs de tes articles que je lis. Certains me font réagir plus que d'autre, celui-là en fait parti et me pousse à prendre ma plume.
    Et pour cela, il me faut une sacrée dose de courage car je suis loin d’être un littéraire.

    Je vais donc réagir. Mais il faut tout d'abord que je parle de ton dessin (celui des cyclistes), il me semble mettre en lumière les quelques difficultés que tu rencontres.

    Je précise que tous ce qui suit n’est qu’une série de réflexions tout à fait personnelles.
    Elles n’engagent que moi, mais c’est ma façon de faire un feedback qui sera peut être maladroit ou mal compris, mais en tout cas sincère. Et dans un seul but, l’amélioration de chacun d’entre nous.

    Revenons à nos moutons, ou plutôt à nos cyclistes.
    Certes on pédale mieux dans une équipe soudée, on se sent tous dans un même élan.
    Malheureusement, on a aussi peut être tendance à oublier les autres équipes qui font parti de la même société, voir pire, on les critique. Un exemple de réflexion pour l'avoir vécu sur un projet que l’on a eu en commun : « ceux là, je vais pas les voir, ils me soulent, ils font des trucs trop compliqués, etc… ». Du coup, la lecture de ton dessin semble un peu différent : « regardez notre équipe, on est bien ensemble, on boit le champagne, on est les plus fort puisque on est devant », le dernier cycliste du tandem regarde les autres ramer avec un sourire un peu énigmatique. Il se moque ?, il a de la pitié ?

    Moi ça me laisse perplexe. Tu aurais aussi pu dessiner les trois cyclistes la tête dans le guidon qui ne regarde rien d’autre que les fesses de celui qui est devant lui !!
    Et finalement, n’est ce pas là un des aspects pernicieux de scrum : rien ne doit perturber l’équipe, le srummaster doit tout faire pour protéger son équipe. N’est ce pas du coup un risque ou une tentation de ne rester qu’avec les gens de son équipe et de ne plus être tout à fait à l’écoute des autres ? C’est un peu un comble pour des méthodes agiles, non ?

    Je conçois que le contexte de l’entreprise dans laquelle nous évoluons demande une sacrée dose de foi pour parvenir à suggérer une autre façon de travailler, mais soyons réaliste : le département dans lequel nous sommes permet de le faire. Ce n’est pas du tout le cas dans 80% des entreprises en France, voir 90% pour Valence !!
    Mais je m’égare de nouveau.
    L’équipe telle que tu la présente ne serait elle pas en fait un groupe à l’intérieur duquel on travail en équipe ? Du coup, « l’interface » que vous présentez est celle d’un groupe, et pas d’une équipe.
    Et tu sais très bien que le raccourci est très facile entre groupe et secte …

    Dans ma réflexion plus globale, et pour rebondir plus précisément sur ton article, il y a une notion qui me parait primordiale : l’humilité. Je suis de plus en plus convaincu qu’il faut être humble dans une équipe agile, mais encore plus vis-à-vis des gens qui gravitent autour. C’est aussi comme cela que l’on gagne la confiance des gens, en les respectant !! Un scrumaster dont je ne me souvient malheureusement plus le nom a dit : « le diplôme dont je me sers le plus dans ma vie professionnelle, c’est mon bafa ». Pour avoir été formateur bafa, je suis complètement d’accord avec lui. Ce diplôme qui semble n’être fait que pour animer les club med vu de l’extérieur permet en fait de mener une réflexion personnelle sur : comment guider un groupe/une équipe, comment l’être humain réagit aux phénomènes de groupe, et comment il peut devenir complètement irrationnel (mouvements de foule, sectes, etc …). Bref c’est une bonne psychanalyse sur son comportement vis-à-vis des autres.

    Et personnellement, ce sont ces notions qui me font avancer et qui me font adopter d’autres comportements dans le projet dans lequel je suis. Et pour l’instant, cela marche plutôt bien.

    Un autre truc qui me fait bondir, mais cela concerne Lean, c’est le juste à temps. On met en place des mécanismes pour améliorer l’efficacité, pour diminuer les goulots d’étranglement. Pour cela on n’hésite pas à faire faire à des pièces des milliers de kilomètres afin d’éviter le gaspillage du stockage. Cela permet effectivement de réduire les coûts, de permettre une meilleur productivité, etc … L’équipe/l’entreprise est gagnante de son points de vues. Oui mais, prenons un peu de recul. Quel est l’état de la société, de la planète, bref de tous ce qui gravite en dehors de cette équipe/société mais qui ne sont en rien concernés ? Quels sont les dommages collatéraux ?
    Et pourtant, je ne suis pas vraiment fleur bleu ou adepte de la décroissance à tout prix, mais force est de constater que notre monde ne vit pas très bien en ce moment.

    Et si on applique cela à notre échelle, à nos projets ?
    « Seul notre projet compte, on doit le protéger à tout prix et ne pas se laisser distraire pas autre chose avant la fin de l’itération » On retombe pas sur les mêmes problèmes, non ?

    Est-ce une clé, ou suis-je complètement à côté ?
    En tout cas c’est une suite de réflexion qui me trottent dans la tête depuis un sacré moment. C’est aussi un retour sur mon expérience personnelle vécu à l’intérieur de l’équipe, puis vu d’un autre tandem qui pédale normalement dans la même direction. C’est aussi une réflexion sur le comportement en tant qu’individualité à l’intérieur d’une équipe.
    Je finirais juste par ceci : l’homme est un loup en groupe, les loups vivent en meute, et il est difficile d’accepter un membre d’une meute voisine.
    Un peu comme les irréductibles gaulois finalement !!

    RépondreSupprimer
  2. ManuH,
    merci pour tes réflexions.

    Les conflits dont je parle dans cet article sont bien ceux qui ont animé la première équipe agile dont j'ai fait parti, il y a 5 ans, mais aussi l'équipe dont tu fais actuellement parti (mais il se peut qu'ils soient survenus avant que tu intègres l'équipe) et enfin l'équipe dont je fais parti désormais. Tout cela pour dire qu'il s'agit bien d'un phénomène que je constate sur plusieurs équipes différentes.

    -- Ouverture hors de l'équipe

    Je pense que notre équipe est ouverte à l'extérieur. Par contre, elle s'ouvre peut-être au-delà de ce que tu souhaiterais. En effet, nous lisons, surfons le web, assistons à des conférences, présentons des conférences et donnons des cours. J'imagine, vu tes propos, que tu souhaiterais plus d'ouverture vers l'équipe dont tu fais parti en ce moment. Tu as raison, c'est un manque à corriger.

    -- Équipe / groupe

    Réellement, je pense que notre équipe est une équipe: des développeurs convergeant vers un même objectif et intimement convaincus que la contribution de l'équipe est supérieure à la somme des contributions de ses individus pris séparément. En périphérie, on nous prend bien pour une équipe - et cela déplait parfois.

    -- Humilité

    Je ne suis pas certain que tu comprennes la nature des conflits que nous vivons. Mon analyse est que le travail d'équipe développe des compétences telles que les remarques descendantes des experts sont désormais confrontées à analyse avant prise en compte. Dans la tradition de notre organisation, c'est assez nouveau. A mon avis, ce recul pris sur les remarques des experts est parfois vécu par eux comme un manque d'humilité et de la désobéissance.
    C'est quelque chose tu n'as probablement pas encore connu dans ton expérience des équipes agiles car tu n'a pas encore été confronté à la pression des experts dans un contexte de développement critique. Par contre, je concède sans problème que nous devons améliorer notre communication.

    -- ScrumMaster / Bafa

    Dans le cas de notre équipe actuelle, je diminuerai l'impact du ScrumMaster. Contrairement aux équipes précédentes, celle-ci est essentiellement composée de développeurs agiles très expérimentés. L'impact du ScrumMaster y est bien diminué à mon avis.

    -- Équipe

    Tu parles de ton expérience personnelle dans l'équipe, mais il ne s'agit plus de celle dont nous faisions tout deux parti. Certes 3 développeurs et un PO en font encore parti, mais sinon il s'agit d'une tout autre alchimie. Pas mieux, juste autre.

    Je vais encore méditer sur tes propos. Merci!

    RépondreSupprimer
  3. Salut Manu,

    Je réagis à ton blog car j'adhère tout à fait à l'idée qu'il y a un lien fort entre organisation, équipe et produit.

    J'aime la métaphore entre le bug du produit et le conflit dans l'équipe (ou dans les équipes). J'élargirais la notion de conflit à toute autre "posture", "comportement" ou "situation" contre-productive vis à vis de l'esprit d'équipe. Il me semble t'avoir vu à l'atelier "Senteurs Agiles" à l'AgileTour Grenoble, animé par Thomas Lissajoux. Pour moi, de telles "senteurs" sont des dysfonctionnements de l'équipe ( = comme les bugs du produit) et c'est à l'équipe de prendre en charge leurs résolutions. Le travail du ScrumMaster n'est pas de les résoudre mais d'aider les équipes en ce sens. Je trouve que ça clarifie le rôle d'un "manager agile" qui va apprendre aux équipes à se débrouiller , au lieu de les assister, voire pire, de décider à leur place. Le meilleur manager est celui dont on a pas besoin ;-)

    Encore bravo pour la qualité de tes billets et articles ;-) Il n'y a plein de villages gaulois dans la Gaulle!

    RépondreSupprimer
  4. Bonjour,
    Je vais m'immiscer dans votre discussion en apportant un point de vue extérieur :
    -- ScrumMaster / Bafa
    Je dirai même plus , projet en équipe = Bafa. n'oublions pas que la principale cause d'échecs des projets informatiques est l'humain quelque soit la méthodologie (agile, V, Y, ...)

    -- Ouverture hors de l'équipe :
    peut-être qu'il faudrait instaurer des permutations entre les équipes via le pair-programming. Si j'avais bien tout compris les projets dont vous parlez sont assez longs, pourquoi ne pas faire bouger les équipes ?(si mes souvenirs sont bons Emmanuel C. tu parlais de minimum 30% de réutilisation du code entre les projets) donc ça devrait être possible. C'était d'ailleurs une des remarques du retour d'expérience Allianz: des équipes parfois un peu trop soudées.

    Mes deux roupies
    Emmanuel de Savoie (histoire qu'on s'y retrouve)

    RépondreSupprimer
  5. Bonjour à tous,

    Je suis nouveau sur ce blog, je me suis présenté hier à Emmanuel et je vais tenter de contribuer sachant que :

    - je viens de monde de Toyota et ai donc une bonne expérience de leur phylosophie

    - je démarre sur "très grand" projet en cycle V et en mode SOA industriel à grande échelle dans lequel un chantier devrait naitre pour développer, tester et faire la recette de très gros batchs représentant trop de risque pour le projet, le tout en mode agile, au moins dans l'esprit, car dans ce cas ci, les specs sont la, la conception aussi, mais l'agilité sera de les faire vite et bien et de trouver comment les faire marcher si ça coince

    - enfin, ce chantier n'est pas encore vivant et donc je n'ai pas de retour d'expérience, je qualifie tout cela et je n'ai que mes pensés à partager.

    Le danger de l'isolement de l'équipe dans un monde hostile, je le voie pour ma part ainsi :

    1. Ce n'est pas trop le cas (avant de démarrer) du fait que tout le monde s'accorde à dire que cela est nécessaire et utile : une chance, on verra après le démarrage.

    2. Le projet étant très complexe et pour ma part n'étant pas trop technique, je pense que nous serons 2 Scrumasters, l'un plus technique, l'autre plus organisationnel, l'un plus fonctionnel, l'autre plus hiérarchique, l'un plus exhaustif et rentre dedans, l'autre plus diplomate et ayant de la distance dans le conflit.

    3. Il est question de savoir laquelle des 2 organisations serait la plus efficace au total et on pense pourquoi pas, apporter la bonne parole au reste du projet pour décliner certains aspect du chantier au fil de l'eau. Par contre je fais remarquer qu'il est très difficile de dire : agile plus fort que industriel, ou l'inverse, c'est un concept contre un autre et mon message ici est de dire que 100% ou l'autre ce n'est pas bon, mais que utiliser l'un et l'autre en complément, c'est idéal.


    4. Comme il faut énormément de support et de compétences et que l'équipe sera restreintes, je pense faire en sorte que les développeurs portent une seconde responsabilité utile à l'équipe et en lien avec un centre de compétences du projet : ex. un responsable framework, travaillant au besoin avec l'équipe framework. De même pour l'environnement de test et des tirs de perfs, de même pour l'aspect fonctionnel, de même pour l'optimisation des requêtes en lien avec la dba. Ainsi, les personnes de l'équipe peuvent s'appuyer sur des référents au sein de l'équipe, qui eux mêmes s'appuieront au besoin, sur un centre de compétences. Cela créera un lien important avec le monde autours du chanter.

    Voilà, alors si un jour on se lance et que j'ai un retour d'expérience à faire, j'en serais heureux mais je rappelle que pour le moment tout cela reste théorique.

    J'espère avoir réussi à contribuer un peu.

    Bonne continuation, je continuerai à suivre attentivement.

    Julien

    RépondreSupprimer
  6. Discussion très intéressante, qui montre que pratiquer une méthode agile n'est pas sans conséquences sur les organisations et les individus... Cela rejoint le thème de mon retour d'expérience Agile Tour Grenoble.

    En attendant d'avoir des idées plus concrètes pour faire avancer le débat, je propose une piste pour des dessins pour de futures présentations:
    - première vignette : un gars lance des boomerangs sur lesques sont écrits XP, Scrum ...
    - deuxième vignette : le gars a pris un de ses boomerangs dans la figure, d'autres sont étendus par terre, l'organigramme est tout cabossé...
    - troisième vignette : on célèbre le succès du projet (mais il y a des bras bandés et des yeux pochés...)

    A+
    Bruno

    RépondreSupprimer
  7. je voulais réagir à l'article et lisant les commentaires je vois que la discussion me concerne un peu... =;]

    l'apparition de conflits que décrit Emmanuel (Chenu) est à mon avis assez fatale, malgré toute la bonne volonté que peux montrer l'équipe à les éviter et à "pédaler tous ensemble". A mon avis c'est symptomatique du fait que l'équipe devenant plus performante (ça n'enlève aucune valeur humaine aux autres, c'est juste un constat), la contrainte du systèmes est déplacée.
    Alors que la contrainte limitant la performance du système était avant à l'intérieur de l'équipe (dette technique, retards...), elle se déplace à l'extérieur (prod, capacité métier et stratégique de la MOA, culture organisationnelle).

    Pour lever ces frictions aux zones de contact, il faut agir non plus au niveau de l'équipe mais au niveau au-dessus, pour exploiter/subordonner/élever la contrainte.

    Mais oui, ca implique du changement et donc d'expliciter et de prendre en compte les douleurs des personnes concernées par la transition, y compris pour les décideurs...

    La question est : quelle est la capacité de l'organisation à changer ? Change-t-elle uniquement face à un mur ou a-t-elle une culture d'amélioration continue ?

    Sinon ca vaut le coup d'étendre les rétrospectives et de faire parler de Lean, TOC...

    Dernier point, à propos des cartes : je suis fan des dessins et suis preneur si ca t'inspire !

    RépondreSupprimer
  8. Salut Thomas,

    merci pour ton atelier "Senteurs Agiles" à Grenoble.
    Je suis d'accord pour te donner un coup de main pour illustrer ton jeu de cartes. La carte "Siamois" que nous t'avons laissé à Grenoble est un peu brouillon ;o)

    RépondreSupprimer
  9. oui, un peu... merci de ton aide !
    je reviens vers toi quand j'avance sur le sujet.
    si j'avais su que tu étais dans la salle, je t'aurais félicité pour ton cours de génie logiciel !

    RépondreSupprimer