Accueil > Méthodes Agiles > Freins à la mise en place des méthodes agiles

Freins à la mise en place des méthodes agiles

Préambule

J’ai eu l’occasion de côtoyer pendant 2 ans les méthodes Agiles et plus particulièrement la méthode Scrum. 90% des éléments agiles y étaient respectés : Un product owner, un scrum master, la proximité avec le client, les tests unitaires, les tests fonctionnels, des stand up meetings (daily scrum), des rétrospectives, … Le tout permettant d’avoir un produit évolutif autour d’une équipe soudée et solidaire.   Un changement de mission dans une grande société m’a permis de constater qu’il pouvait exister de nombreux freins à la mise en place des méthodes agiles. Ce billet n’est pas là pour trouver des solutions à tous ces blocages mais il permettra peut-être à certains de les anticiper avant d’y être confronté directement.

Locaux de l’entreprise

C’est peut-être tout bête, mais la pratique des méthodes agiles nécessite un certain aménagement de l’espace. J’ai commencé ma mission dans une équipe répartie sur 2 étages ce qui ne facilite pas du tout la communication. De plus les bureaux n’étaient pas adaptés pour mettre en place un mur de post-it ainsi que tous les éléments visuels pour mener à bien les projets (burndown chart, actions suite aux rétrospectives, …) Nous avions donc une petite salle de réunion à part et pas toujours disponible, où se déroulait le stand-up meeting et où se trouvaient nos post-its. Difficile dans ces conditions de « faire vivre » un sprint ou même de le consulter rapidement.

Avant de mettre en place les méthodes agiles, il faut donc mettre en place son environnement de travail : un grand mur sans fenêtre, un open-space/bureau permettant d’intégrer la totalité de l’équipe, … Bref faire en sorte de ne pas mettre de frein à la communication.

Pour palier cette difficulté, des outils collaboratifs informatisés permettent de consulter ou mettre à jour le sprint depuis son ordinateur. Nous avons par exemple utilisé Trello pour gérer les actions à entreprendre pour améliorer notre environnement.

Intérêts portés aux méthodes agiles

Un second frein est l’intérêt porté aux méthodes agiles ou à l’inverse le manque d’intérêt.   Certains membres de l’équipe souhaitaient en apprendre plus et désiraient « tester ». D’autres étaient sceptiques mais voulaient essayer. Enfin une minorité était totalement réfractaire sans avoir effectué de mission en agile. Lors de la première rétrospective j’ai pu le constater avec l’exercice ESVP  (un autre billet expliquant cet exercice suivra bientôt). Dans mon cas, certaines personnes se sentaient « prisonnières » et ne souhaitaient pas aller plus loin. D’où un déséquilibre dans l’équipe où certains vont « jouer le jeu » et d’autres s’en détourner. Ce manque d’intérêt est aussi observable dans la hiérarchie qui n’a pas forcément confiance dans cette méthode. Plusieurs raisons à cela :

  • Une expérience en agilité qui a abouti sur un échec
  • Un manque d’information sur certains points (comment facturer un projet en mode agile, comment connaitre la date de livraison finale, …)
  • La peur d’avoir moins de contrôle car l’équipe agile devient plus autonome
  • Peur du temps pris par les réunions (rétrospectives, planning poker, …)
  •  …

Or une chose est sûr, il faut l’appui de sa hiérarchie pour mettre en place les méthodes agiles sur un projet. Les conseils d’un coach agile peuvent permettre de rassurer. Un vrai coach et non un commercial agile, car un coach montrera moins de souplesse face aux craintes du client (« Non on ne supprimera pas les rétrospectives, ce n’est pas une perte de temps », « Le stand up meeting n’est pas le lieu pour faire passer ses ordres », …). Ce qui diminuera la possibilité d’échec. J’ai eu l’occasion d’être coaché lors de ma précédente mission. Mais avant d’intervenir avec l’équipe de réalisation, le coach agile a fait de nombreux entretiens et exercices avec l’équipe dirigeante pour expliquer comment changer la manière de mener ses projets ainsi que les impacts à court et long termes. Il y a donc moins de surprise : par exemple, le temps assez long pour mettre en place Scrum n’est pas une déception car cela a été prévu et expliqué.

Il a de même défini des règles pour les développeurs et pour les dirigeants. Par exemple ne pas ajouter de fonctionnalité pendant une itération, ou  ne pas aller voir directement un développeur pour lui demander de travailler sur autre chose.

Pour argumenter sur le temps pris en réunions agiles, il faut rappeler qu’un projet se joue au tout début :

  •  Ai-je bien compris le besoin du client ?
  •  Est-ce que toutes les fonctionnalités/tâches ont été abordées et comprises ?
  •  …

Tout cela prend du temps mais permet d’en gagner sur d’éventuelles « réunions de crises » qui surviennent à la fin du projet où on se rend compte que le besoin du client n’a pas été compris et que tout est à refaire. Il faut aussi souligner que les « réunions agiles » sont time-boxées et ne s’éternisent donc pas.

Profil des membres de l’équipe

Ayant travaillé sur quelques projets en V classique, j’ai constaté qu’il y avait beaucoup plus de communication et d’interactions dans un projet en agile. Autant dire que certains profils risquent de ne pas se « retrouver » dans cette méthode de travail :

  •  Solitaire qui code dans son coin
  •  Réfractaire aux tests unitaires
  •  Assez peu ouvert aux changements
  •  Peur de perdre un statut (Ex : passer « d’architecte » à « membre d’une équipe agile »)

Lors d’un entretien d’embauche, il ne faut pas hésiter à présenter les candidats à l’équipe, autour d’un café par exemple. Ceci afin d’avoir le ressenti de tous et choisir le candidat qui s’intégrera le mieux (pas forcément le plus expérimenté).

Type de projet

Lorsque l’on travaille sur un produit où on se sent proche du fonctionnel, il est facile d’écrire des user stories, de les comprendre, de les tester… et finalement de s’approprier ce produit.
Par contre sur un projet à 90% technique, on a plus tendance à définir des tâches dépourvues de fonctionnel.
Ex : on reçoit cette donnée dans ce format, on la transforme un peu, et on l’envoie à un autre système.
Il n’est même pas nécessaire de comprendre le use case derrière, alors que c’est une des bases des méthodes agiles.
On peut effectivement poser des tests unitaires mais on est loin de pouvoir travailler main dans la main avec un PO pour créer des tests fonctionnels.
De même, on ne peut pas faire une démo à un client pour lui montrer l’avancement en fin d’itération.
Il me paraît donc difficile d’appliquer la méthode Scrum à ce type de projet. D’autres méthodes seraient peut-être plus adaptées (Lean, Kanban, …).

Organisation

Une MOA, mais pas vraiment …

Actuellement dans ma mission le périmètre du produit est très vaste. Il n’y a donc pas un seul point de contact avec la connaissance fonctionnelle. Je travaille donc avec plusieurs personnes (MOA) qui fournissent chacune un besoin sur leur brique du périmètre, avec les inconvénients suivants :
  • Les différentes MOA ne se consultent pas forcément, il peut donc y avoir des incohérences entre 2 parties du produit
  • Elles ont du mal à définir des comportements fonctionnels. Le plus souvent on fait des aller-retour entre développeurs et MOA
Ces aspects là sont un frein à la mise en place des méthodes agiles :
  • Impossible de définir des stories chiffrables (car les comportements ne sont pas connus avant de démarrer les développements)
  • Impossible de rendre le fonctionnel testable.
On peut cependant aider les MOA à définir leurs besoins :
  • Faire des workshops question-réponse avec l’équipe pour impliquer tout le monde
  • Les amener à réfléchir en Given-When-Then. Mis en place sur un projet très complexe fonctionnellement. Le démarrage n’a pas été facile, mais aujourd’hui on peut dire que cela nous sauve la vie à chaque évolution. Je vous invite d’ailleurs à découvrir le billet d’Anna NIANG sur la manière de rédiger des user stories.
  • Encourager à ce que les informations ne proviennent que d’une seule source

Population de chefs de projets > population de développeurs

Eh oui cela peut arriver…
Sur ma mission actuelle, le nombre de briques utilisées dans les différents projets est très important. Un chef de projet gère une ou plusieurs briques et doit « piocher » dans la réserve des développeurs lorsqu’il y a des corrections à faire ou l’ajout de nouvelles fonctionnalités.
Une des conséquences assez néfaste aux méthodes agiles est que les développeurs de la même équipe ne travaillent pas sur les mêmes choses.
Un stand-up meeting a été maintenu pendant quelques temps avant d’être abandonné car les membres de l’équipe n’ont pas assez d’interaction entre eux. Les sujets des uns n’intéressent pas forcément les autres car ils ne sont pas concernés, n’ayant jamais travaillé sur le sujet.
Cette organisation a un autre impact négatif : étant donné que les personnes travaillant sur un projet changent assez souvent, il n’est pas possible d’établir une vélocité d’équipe. On ne peut donc pas prévoir ce qui peut être réalisé dans X itérations. Dans cette configuration on travaille sur du court terme uniquement.
Dans ma précédente mission en Scrum, lors de la mise en place, il a fallut quelques itérations pour justement estimer une vélocité d’équipe assez proche de la réalité. Pour ce faire, il y a, à mon avis, quelques pré-requis :
  • Garder la même ossature d’équipe au maximum
  • Bien connaitre l’application
  • Avoir conscience des points forts et des points faibles de son équipe (Ex: très bon savoir faire pour concevoir une architecture, plus de difficultés dans la création des interfaces)

Le copro driven

Fonctionnement bien connu en entreprise où un comité de projet définit les dates de sortie à l’avance, sans chiffrage, sans étude détaillée des fonctionnalités et sans priorisation car il faut tout !
Il ne reste plus qu’aux chefs de projet ou à un éventuel scrum master de faire rentrer les sprints dans les délais annoncés.
Sachant qu’il n’est pas rare qu’une fonctionnalité soit ajoutée sans en retirer d’autres, on comprend que la qualité du produit en fait les frais ainsi que la motivation des équipes.
On voit vite que les méthodes agiles ne sont pas compatibles avec un tel fonctionnement.
Il faut donc une réelle volonté à tous les échelons pour changer de méthode.

Une petite conclusion

Le retour d’expérience sur ces blocages n’est pas là pour décourager mais plutôt pour aider à anticiper ces différents problèmes. Il faut aussi se rappeler qu’en agilité il faut voir un frein comme une source d’amélioration : une MOA qui a du mal à définir un fonctionnel => au lieu de le subir, aidons-là à progresser et du même coup rapprocher les différents profils qui composent une équipe agile. Au final tout le monde y gagne.

Une des 4 valeurs fondamentales des méthodes agiles est justement la collaboration avec le client. Le rapprochement avec le client  permet une meilleure compréhension et donc un produit plus proche des attentes. Si le lien avec l’équipe de réalisation est parasité ou mal construit on obtient des fonctionnalités mal développées et des retards de livraison.

Il est intéressant de souligner le principe suivant du manifeste Agile : « 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 ». Pour chaque frein identifié on doit essayer de trouver des solutions pour s’améliorer.

Évidemment une expérience pratique des méthodes agiles permet d’avoir un bon recul par rapport aux différents blocages rencontrés, ce que ne permet pas une formation théorique de quelques jours.

N’hésitez pas à commenter des cas similaires de freins et si vous avez réussi à les débloquer. Ce sera bénéfique à toute la communauté agile 😉

  1. Pas encore de commentaire
  1. Pas encore de trackbacks


4 − deux =