Category

Méthodologie agile

L

‘origine d’un conflit peut être variée, mais il provient essentiellement d’un désir. Une personne désire quelque chose qui n’est pas conforme au désir d’une autre personne. La naissance d’un conflit vient d’une non prise en charge rapide des problèmes rencontrés. Le conflit dans une équipe agile est inévitable. Chaque membre s’exprimant, interagissant et exprimant leurs désirs en permanence.

Le fait que l’on n’ose pas aborder un problème est la peur. La peur de s’exprimer, la peur de ne pas plaire, la peur de ne pas être à la hauteur ou encore la peur de reproduire des situations passées. Les personnes n’osent pas affronter un conflit car il va nécessiter une remise en question de soi-même. Les conflits ne sont généralement pas abordés du fait de cette remise en question. Pour gérer un conflit, on n’a pas le choix, il faut agir. Si la résolution d’un conflit n’est pas prise en charge rapidement, l’effort pour le résoudre sera décuplé.

La gestion des conflits passe par la négociation et la coopération des parties prenantes. Trouver un accord équitable entre les parties est un facteur de réussite dans la gestion d’un conflit. Le but, préserver durablement les relations au sein d’une équipe agile.

Un conflit au sein d’une équipe agile peut venir d’événements perturbateurs externes ou internes à l’équipe, d’un groupe de personnes ou d’un seul et même individu :

  • Evénements organisationnels : Les membres d’une équipe peuvent exprimer une résistance au changement.
  • Evénements de groupe : Les membres d’une équipe peuvent rencontrer des difficultés à collaborer.
  • Evénements interpersonnels : Deux membres d’une équipe peuvent rencontrer des tensions qui mettent en difficulté leurs relations.
  • Evénements individuels : Les membres peuvent rencontrer des périodes de stress, démotivation ou encore de burn-out.

 

Les niveaux de conflits

Un conflit doit être considéré comme une tâche, au même titre que les tâches quotidiennes d’une feature team. Ces conflits peuvent prendre différentes formes, avec des niveaux d’intensité variables. Speed Leas, auteur de plusieurs ouvrages sur ce vaste sujet, a établi une liste de 5 niveaux de conflits :

Niveau 1 – “Problème à résoudre” :

Ce premier niveau caractérise une équipe performante dans sa gestion des conflits. L’équipe va coopérer. Elle va émettre des idées et des faits. Le but, identifier les actions à entreprendre pour pallier la naissance d’un problème. La prise en charge immédiates des querelles permet de pérenniser la relation de travail entre les membres et de mieux appréhender les problèmes futurs.

Niveau 2 – “Le désaccord” :

L’équipe, par l’absence de communication et d’écoute, ne parvient pas à trouver un accord. La simple discussion ne permettra pas de résoudre ce niveau de conflit. Chaque membre de l’équipe cherche à protéger ses arguments tout en se positionnant afin de trouver un éventuel compromis. Les dialogues deviennent sujet à interprétation, les sentiments personnels prennent le dessus. Le dialogue pour la résolution du problème au sein de l’équipe est de plus en plus rare.

Niveau 3 – “La compétition” :

Les membres ne souhaitent pas résoudre le conflit et des groupes de personnes commencent à se former au sein même de l’équipe. Les idées concordantes forment des clans et des attaques entre les groupes de personnes sont échangés. L’identification du problème est complexe car personne ne formule correctement ses attentes. A ce stade, certains membres peuvent se considérer comme ceux qui font tout.

Niveau 4 – “La croisade” :

Les membres souhaitent avoir le monopole dans les prises de décisions et ils souhaitent également exclure certaines personnes. Les groupes de personnes formées s’affronteront via leurs principes plutôt que leurs idées. Les membres pensent que les gens ne vont pas changer et qu’il faut les sortir de l’équipe. On peut identifier là l’attitude punitive des membres.

Niveau 5 – “La guerre mondiale” :

Les groupes de personnes s’affrontent, la communication a complètement disparu. Il ne peut pas y avoir d’échange constructif. L’affrontement peut aller jusqu’à l’insulte ou des atteintes physiques. Aucun résultat positif ne peut sortir de l’équipe. On identifie là l’attitude destructive des membres.

Mesurer le niveau de conflit

Comment appréhende-t-on un niveau de conflit dans une équipe agile ? L’observation, la conversation et l’intuition au sein de l’équipe agile vous permettront de déterminer le niveau de conflit et les actions plus ou moins importantes à réaliser pour pallier les problématiques rencontrées. Un conflit ne se caractérise par forcément par des cris et une ambiance pesante. Il peut être silencieux et finalement atteindre son plus haut niveau en l’absence d’identification et d’actions entreprises.

Un niveau de conflit peut être différent entre chaque membre d’une même équipe et peut concerner une personne, un groupe, opposer deux personnes ou deux groupes, voire plusieurs personnes ou plusieurs groupes. Les qualités d’écoute et d’analyse de l’observateur sont donc déterminantes, les cas de conflits étant très variés.

Dans l’ouvrages de Speed Leas, trois comportements vont vous aider à identifier un niveau de conflit.

  • Les plaintes : À de nombreuses occasions, vous pouvez entendre les membres de l’équipe s’exprimer. Ne prenez pas le dessus sur la conversation en essayant de résoudre le conflit tout de suite. Ecoutez attentivement et laissez-vous le temps de définir l’ampleur plus ou moins grande du conflit.
  • L’énergie : Observez l’équipe et identifiez les mouvements collaboratifs (une résolution de problème, une conversation autour du kanban, l’auto-organisation de l’équipe, etc …). Un manque de collaboration et d’auto-organisation peut résulter d’un conflit de deuxième niveau.
  • Le langage : Le langage reste l’élément principal pour définir le niveau de conflit au sein d’une équipe. L’analyse doit porter attention aux échanges entre les membres, leurs conversations et finalement comment ils s’expriment entre eux.

L’analyse du comportement :

Dans le but de déterminer le niveau de conflit présent dans l’équipe, l’observation passe par une phase d’analyse du comportement. Ce schéma peut vous aider à déterminer les sources d’un conflit et ses conséquences sur chacun des membres de l’équipe.

analyse-comportementale

  • Situation et problème : Décrire le problème qui a déclenché le conflit.
  • Ce que je pense : Décrire la réaction de la personne concernée.
  • Ce que je ressens : Décrire les émotions de la personne concernée.
  • Ce que je fais : Décrire les actes, fasse au problème rencontré, de la personne concernée.
  • Les conséquences : Décrire les conséquences relationnelles et concrètes des actes de la personne concernée.

Répondre aux conflits :

L’objectif d’une équipe agile est qu’elle s’auto-organise ou se réorganise dans un environnement complexe, sans l’intervention d’une personne externe à l’équipe. Pour les niveaux 1, 2 et 3, aucune intervention n’est requise. L’analyse du conflit par l’observateur va être déterminante dans sa résolution. Si le conflit perdure, il est alors nécessaire d’intervenir afin que le conflit ne devienne irrésolvable.

Il ne faut pas craindre le conflit, il est même inévitable pour toute organisation. Il est même une composante naturelle de la dynamique de groupe :

« Si les membres d’une équipe ne se font pas sortir les uns les autres de leurs zones de confort durant des discussions, il est alors extrêmement probable qu’ils ne prennent pas les meilleures décisions pour l’organisation ». Overcoming The Five DYSFUNCTIONS of a TEAM de Patrick Lencioni.

Notre culture et notre environnement nous apporte une vision du monde et une perspective qui nous distingue les uns des autres. Chacun de nous voit le monde avec ses yeux et personne ne détient la vérité absolue. Il est donc indispensable de prendre en considération la perspective de chaque membre de l’équipe agile. Chaque perspective favorisera la construction d’une vision efficace pour l’organisation.

Que faire pour chaque niveau de conflit ?

Niveau 1 – « Problème à résoudre » : La résolution par la collaboration et l’échange entre les membre de l’équipe. L’objectif est d’obtenir une décision commune.

Niveau 2 – « Le déssacord » : La collaboration doit être soutenue par la mise en avant de valeurs partagées. Les sentiments personnels doivent laisser place à l’écoute. Il est alors indispensable de rappeler les règles de bonne conduite et de redonner un cadre de collaboration à l’équipe.

Niveau 3 – « La compétitions » : La négociation et l’accommodation vont être déterminants pour trouver un terrain d’entente entre les groupes de personnes formés au sein de l’équipe. La négociation ne doit pas remettre en cause les valeurs et les principes qui sont le fondement de l’équipe. Mettre en avant l’importance de la relation entre les membres plutôt que le sujet de la discorde. Cette volonté de nouer des liens au sein de l’équipe peut donner naissance à une relation de confiance sur le long terme.

Niveau 4 – « La croisade » : Les groupes de personnes formées doivent être écoutés séparément. L’objectif est de déterminer les volontés de chacun d’acheminer les perspectives jusqu’à ces derniers soient capables de coopérer.

Niveau 5 – « La guerre mondiale » : Il faut mettre en place tout ce qui est possible pour qu’il n’y ait aucune atteinte physique entre les membres de l’équipe.

Pour conclure

L’observation et l’analyse sont la clé d’une résolution de conflit réussie. L’objectif n’est pas de lancer un certain nombre actions dès lors qu’un conflit se présente. Le but est d’amener l’équipe à résoudre en autonomie son conflit. Vous devez déterminer objectivement le niveau de conflit de l’équipe afin de déterminer votre niveau d’intervention. Le conflit n’est pas un échec, il est une composante naturelle dans une équipe agile.

Pour qu’une organisation avance, il est inévitable que des conflits fassent leur apparition. La diversité des cultures et des perspectives qui constituent l’organisation est un réel atout et la prise en compte de chacun d’eux est déterminant. Enfin, n’oubliez pas de renforcer l’esprit d’équipe suite à un conflit à travers des activités extra-professionnelles et des valeurs partagées.

La méthodologie agile a bouleversé notre façon d’appréhender notre travail ainsi que les interactions entre les membres d’une même organisation. Le Product Owner est un des maillons essentiels au sein d’un environnement agile. Son travail a de fortes dépendances avec les nombreux corps de métiers qui constituent son équipe.

Une équipe agile, c’est une équipe qui s’améliore et s’organise dans un environnement complexe, pour délivrer en continu des évolutions ou de nouveaux produits aux utilisateurs. Grâce à l’agilité, le renforcement de l’esprit collectif est décuplé par l’autonomie dont fait preuve l’équipe projet. La gouvernance décentralisée, mise en place par l’intermédiaire de groupes de travail, permet d’optimiser la création de valeur de l’entreprise.

L’agilité nécessite un meilleur engagement des acteurs d’un projet, un time-to-market réduit et finalement une meilleure productivité et performance de l’entreprise. Au sein d’un environnement agile, le Product Owner représente l’utilisateur final, en incarnant une interface entre le métier, représenté par les chefs de produit et les équipes de développement.

La vision produit :

Lors du cadrage d’un projet, les stakeholders vont définir une vision de leur(s) besoin(s) et le contexte de mise en oeuvre de leurs besoins. Ses objectifs s’accompagnent de KPI’s, dans le but de quantifier l’impact prévisionnel de ses attentes. les stakeholders vont alors répondre au “Pourquoi ?”.

  • Quelles sont les attentes de mes utilisateurs ?
  • Quel va-t-être mon coeur de cible ?
  • Quelles sont les actions entreprises par mes concurrents directs ?
  • Quelles sont les performances de mes produits actuels ?

Le Product Owner ne sait pas ce que va faire le produit en détail. Cependant, il sait répondre aux questions suivantes :

  • Pourquoi fait-on le produit ?
  • Quel(s) problème(s) va-t-on résoudre ?
  • A qui sera destiné le produit ?

Les stakeholders expriment leur(s) vision(s) produit à l’équipe projet. Le rôle du Product Owner est de faire converger les attentes de chaque partie prenante (UX, UI, développeurs, recetteurs) afin de définir le “Comment ?”.

  • Comment va t-on répondre à la vision, par l’intermédiaire d’un fonctionnel apportant de la valeur au produit ?
  • Quel(s) bénéfice(s) les utilisateurs vont-ils tirer du fonctionnel ?

Chaque acteur du projet est potentiellement un utilisateur final du produit, il est donc essentiel de prendre en compte l’ensemble des attentes émises.

Le Product Owner va alors entamer une période de mûrissement, consistant à traduire la vision produit en termes fonctionnels par l’intermédiaire d’ateliers UX, UI et techniques. Sa connaissance du produit et des utilisateurs finaux est un atout essentiel dans la formalisation du besoin en user-story. Le Product Owner aura préalablement défini un lotissement fonctionnel à travers une Storymap ayant pour but de prioriser les éléments fonctionnels faisant partie intégrante du besoin et les éléments nécessaires à une première mise en production, appelé Minimum Viable Product.

Le mûrissement d’un projet :

Durant toute la phase de mûrissement, le Product Owner collabore étroitement avec l’ensemble des parties prenantes au projet, afin de définir un fonctionnel répondant aux objectifs quantifiés définis par les stakeholders.

Il doit faire la synthèse de l’ensemble des enjeux autour du besoin. Il maîtrise les enjeux de conception, de planning et de coût. Il est également le moteur du produit confié à l’équipe, en garantissant une priorisation fine sur les fonctions essentielles, en portant l’intelligence collective pour un produit de qualité apportant de la valeur et en libérant les freins que l’équipe projet peut rencontrer. A chaque atelier, il doit impérativement répondre à ces questions :

  • A t-on répondu correctement à la vision des stakeholders ?
  • Va t-on atteindre les objectifs fixés par les KPI’s ?
  • A t-on répondu correctement aux attentes des utilisateurs ?

Son rôle est d’animer divers ateliers dans le but d’obtenir des user-story traduisant explicitement le fonctionnel associé au besoin initial. Le Product Owner doit avoir une connaissance métier et technique suffisante à la bonne compréhension des opérations engagées. Il s’appuie sur des experts pour résoudre des problématiques pointues, dont il n’a pas les connaissances. Il doit être un utilisateur perpétuel du produit, afin d’en faire un bon produit et de déceler les évolutions à haute valeur pour les utilisateurs.

Les user-story et le backlog :

Le Product Owner est le garant du backlog, qui est une file d’attente des éléments constitutifs fonctionnelles et techniques du produit, ordonnancées par ordre de priorités. Pour prioriser son backlog, le Product Owner a besoin de quatres informations :

  • La valeur : déterminée par les stakeholders, elle permet de donner une estimation de l’impact qu’aura une fonctionnalité auprès de ses utilisateurs finaux.
  • La taille ou l’effort : déterminée par l’équipe de développement, elle permet de donner une estimation de la complexité d’une tâche.
  • Le risque : déterminé par l’équipe de développement, il permet d’appréhender les Users Story ayant potentiellement un impact sur la vélocité de l’équipe durant un sprint.
  • La stratégie de l’entreprise : elle traduit la direction stratégique globale prise par les membres exécutifs de l’entreprise.

Lorsqu’il présente sa note de cadrage à l’équipe projet, les stakeholders ne vont pas se limiter à émettre 4 à 6 idées. Le rôle du Product Owner est de définir un périmètre de mûrissement à l’ensemble de l’équipe. La priorité donnée aux tâches à accomplir est importante afin de ne pas surcharger les développeurs. Les Users Story présentes dans le backlog seront réalisées par l’équipe de développement, itération après itération, dans le respect absolu de l’ordre déterminé par le Product Owner. Des tâches non priorisées impliquent un risque d’obtenir des livraisons de mauvaise qualité.

Les user-story sont conçues tout au long du mûrissement. Elles sont prêtes à être présentées à l’équipe projet, dès lors qu’elles spécifient les éléments suivants :

  • Les objectifs, le contexte et les KPI’s marketing
  • La description fonctionnelle : “en tant que” … “je peux” … “si bien que” …
  • Le lien vers le contrat d’interface
  • Les règles de gestion
  • Les parcours et les maquettes avec l’ensemble des liens vers les ressources permettant le bon déroulement du développement
  • Les tests d’acceptance
  • La description de l’expression de besoin statistiques
  • Les marqueurs à implémenter

Suite à leur présentation, elles sont soumises au chiffrage de l’équipe de développement ainsi que de la recette. Ce chiffrage permet de quantifier la complexité d’une user-story et au final d’en identifier un nombre limité à exécuter à chaque sprint, dans le respect de la vélocité de l’équipe de développement.

Le rôle du Product Owner est d’accompagner la User Story tout au long de sa vie, de la définition fonctionnelle à la mise en production, jusqu’au suivi de la prise en main du produit par les utilisateurs finaux. Il est le garant de la conformité fonctionnelle et de la réponse à la vision marketing donnée par les stakeholders.

La vie dans l’équipe projet :

Le Product Owner collabore étroitement avec tous les acteurs du projet quelque soit leur domaine d’activité et participe à l’ensemble des rituels de son équipe. Cette collaboration est cruciale pour garantir le succès des projets qui lui sont confiés. Son impératif est la prise en compte et la pondération des attentes et des risques soulevés par chacun des acteurs. Il doit partager une vision commune avec l’équipe de réalisation et communiquer sur le “pourquoi ?” défini lors de son cadrage, notamment :

  • Pourquoi fait-on le projet ?
  • En quoi est-il utile pour le produit ?
  • Quels bénéfices les utilisateurs vont-ils en tirer ?

Il doit être constamment en alerte. Il doit faire preuve de flexibilité vis à vis des imprévus et  des difficultés de réalisation rencontrées. Il s’assure, par l’intermédiaire d’échanges constants de la bonne compréhension des user-story par les équipes de développement.

“Se réunir est un début, rester ensemble est un progrès, travailler ensemble est la réussite.” Henry Ford.

Tout au long du projet, il représente l’utilisateur. Il transmet et rappelle la vision formalisée par les stakeholders. Il doit s’assurer de l’adéquation des fonctionnalités développées, avec les objectifs quantifiés, avant leur livraison. Il assure le suivi des produits, du cadrage jusqu’à la prise en main du produit par les utilisateurs finaux. Finalement, le Product Owner doit constamment s’adapter ainsi qu’agir en fonction des retours de ses utilisateurs finaux, qui doivent être un de ses principaux moteurs de décision, avec les enjeux stratégiques de son entreprise.