Sélectionner une page

Le cas d’étude d’aujourd’hui porte sur une problématique où le coach Agile empêche l’organisation à devenir Agile en imposant des pratiques. Ce comportement est souvent le résultat lorsque nous avons la tête dans le guidon. Nous en perdons la boussole de l’Agilité.

Les conditions du cas d’étude correspondent à un cas de tutorat d’une jeune coach agile ayant le rôle de ScrumMaster. Il est issu d’un assemblage de plusieurs tutorats, de supervisions et de coaching de Coach Agile et ScrumMaster que j’ai réalisés.

Observations

L’équipe

L’équipe accompagnée a commencé son parcours agile en ayant mis en place Scrum depuis quelques semaines maintenant. L’entreprise de cette équipe a suivi les recommandations d’un grand cabinet de conseil en organisation.

Les différents managers ont affecté le rôle de Product Owner au chef de projet MOA (Maîtrise d’ouvrage) et le rôle de ScrumMaster à la chef de projet MOE (Maîtrise d’œuvre).

Les différents développeurs, 2 testeurs et un concepteur sont mis dans l’équipe « Development team ». Cette development team est délocalisée.

Les événements

Les clients, mangers et utilisateurs constituent des recueils de besoin. D’après le ProductOwner, ce qu’il reçoit n’est pas suffisant et nécessite des compléments pour chaque besoin exprimé. Et comme à son habitude, après sa relecture du recueil des besoins, il organise des ateliers avec les différentes parties prenantes. Son objectif pour ces ateliers est d’obtenir de précision afin de rédiger des spécifications fonctionnelles détaillées. Ces spécifications sont alors transmises à la ScrumMaster pour qu’à son tour, elle les relie puis les transmet à l’équipe de développement.

La ScrumMaster ayant lu que pour être Agile, il faut écrire des UserStory. Elle va voir le Product Owner et lui demande de transformer sa spécification en des UserStory. Malheureusement, le ProductOwner est extrêmement occupé avec les ateliers et la rédaction des spécifications. Il lui indique qu’il n’a pas le temps de faire cela. En plus, il se pose la question de l’apport de cette technique dans ce qu’il fait déjà. Elle lui explique que les UserStory sont une autre forme de spécification mais Agile et qu’elles doivent remplacer les spécifications fonctionnelles détaillées.

Pour le convaincre, elle lui indique aussi que sans UserStory, ils ne seront pas Agile. Par conséquent, ils ne respecteront pas l’objectif annuel qui leur a été assigné : faire le projet en Agile. Au bout de la discussion, le Product Owner n’a pas plus de temps pour transformer la spécification fonctionnelle détaillée qu’il a écrit.

La ScrumMaster ayant lu aussi que le ScrumMaster est un Servant Leader, elle y voit donc, une porte de sortie. Le mot Servant résonne dans la tête comme être au service du Product Owner et de l’équipe. Et, donc, elle doit faire à leur place quand ils n’ont pas le temps de faire les choses. En plus, elle utilise la concentration comme argument, c’est-à-dire, qu’en faisant, ils restent concentrer sur les choses qu’ils sont en train de faire et qui est plus important comme coder ou rencontrer les parties prenantes. Elle prend alors l’initiative de rédiger les UserStory et les saisies dans le JIRA.

Cet outil sert à transmettre les demandes à l’équipe de développement. Après avoir lu plusieurs blogs, elle en conclut que les UserStory ne doivent pas contenir beaucoup de détail et ne doivent être pas trop petites ou trop grosses. En relisant la spécification qui lui a été transmise, la ScrumMaster trouve que celle-ci empiète sur la conception technique en y intégrant des requêtes et du cheminement des données dans le système d’information. Donc, elle décide de retirer tous ces détails conformément à sa compréhension de la UserStory.

Une fois qu’elle a terminé de rédiger les UserStory dans JIRA, la ScrumMaster en informe le Product Owner et la Development Team. Puis, elle demande à l‘équipe de donner ses estimations comme le souhaitait le Product Owner.

Des plaintes et des griefs

Une fois qu’elle a informé le Product Owner et la Development Team, elle reçoit des plaintes de la Development Team et des griefs du Product Owner.

Les plaintes de la Development Team

  • Le contenu n’est pas assez détaillé ;
  • Il n’y a pas cohérence ;
  • C’est difficilement compréhensible ;
  • C’est trop flou ce qui est à faire ;
  • Nous préférons avoir les spécifications fonctionnelles détaillées.

Les griefs du Product Owner

  • Le contenu des UserStory ne correspond pas à la Spécification fonctionnelle détaillée transmise ;
  • Il avait encore des modifications à apporter, il ne fallait pas transmettre à la Development Team ;
  • Les UserStory n’ont pas de cohérence et son trop macroscopique ;

Les autres éléments à prendre en considération

  • La Development Team est constituée de jeunes développeurs, concepteurs et testeurs. Ils appartiennent tous à un centre service d’une société de service informatique.
  • Le Product Owner est un ancien Architecte technique et logiciel.
  • Les membres de l’équipe ont eu une sensibilisation à l’Agile par un atelier sur 1 h 30 avec des Lego®.
  • Le ScrumMaster lit des blogs pour identifier les tâches qui l’incombent dans son nouveau rôle.
  • Les managers veulent suivre à la lettre les recommandations de l’étude commandée au prestigieux cabinet de conseil.

Ce qui a provoqué la demande d’accompagnement

  • La ScrumMaster ne supporte plus la position dans laquelle elle se trouve ;
  • Trop de conflits entre la Development Team, Le Product Owner et la ScrumMaster ;
  • Les managers n’ont pas de visibilité sur l’avancement du projet et les indicateurs habituels montrent que le projet est très en retard.

La demande de coaching

L’accompagnement sera un coaching et tutorat de la ScrumMaster pour qu’elle prenne en charge toute la dimension de son rôle d’une dizaine de séances de 1 h 30.

Analyse

Protocole d’analyse

  • Quelle est la problématique de l’organisation ? Du ScrumMaster, du Product Owner et de la Development Team ?
  • Qu’est ce qui provoque ces problématiques ?
  • Identifiez-le(s) principe(s) Agile (AgileManifesto) qui ne sont pas suivis.

Regardons la situation

Quel est le problème ?

La ScrumMaster n’en peut plus ! Il n’est pas soutenu sur sa prise d’initiative et n’accepte pas de recevoir toutes ces plaintes des uns et des autres. Elle ne sait pas comment réagir et quoi faire.

Qu’est ce qui provoque la situation ?

  1. Nous avons une chaîne de fabrication de documentation : Recueil des besoins, Spécifications fonctionnelle détaillée, des « UserStory » et où les développeurs sont exclus jusqu’à la réception de UserStory par JIRA.
  2. L’envie de bien faire de la ScrumMaster.
  3. Des croyances de la ScrumMaster :
    • Pour être agile, il faut écrire des UserStory
    • Le ScrumMaster est un Servant Leader au sens un faire-valoir
    • Le ProductOwner va trop loin dans la rédaction de sa spécification en y indiquant des requêtes SQL.
  4. Une peur de ne pas atteindre l’objectif de la ScrumMaster.
  5. Le ProductOwner n’a pas (ou peu) de temps à consacrer à refaire sous une forme différente le travail qu’il a déjà fait.
  6. L’équipe a besoin d’information et de détail pour comprendre ce qui est attendu.

situation-pratique-userstory-impose-2

Quels sont les principes qui ne sont pas respectés ou mis en œuvre ?

La chaîne de fabrication de documentation provoque une surcharge de travail du ProductOwner puisqu’il doit compléter l’expression de besoin par des ateliers et doit rédiger des spécifications et doit écrire des UserStory… Le principe qui est oublié : La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.

L’équipe réceptionne les besoins par un outil JIRA et sous une forme ou elle perd de l’information => Principe : La méthode la plus simple et la plus efficace pour transmettre de l’information à l’équipe de développement et à l’intérieur de celle-ci est le dialogue en face-à-face.

La chaîne de fabrication de documentation évite le principe : Les meilleures architectures, spécifications et conceptions émergent d’équipes auto-organisées.

Actions de coaching

Pour rappel, l’accompagnement est uniquement réalisé sur le ScrumMaster. Nous devons amener la ScrumMaster à prendre conscience de ses croyances pour qu’elle les atténue. En faisant cela, elle va modifier son comportement. En résultat, les griefs et plaintes vont diminuer, voir disparaître.

Pour réussir cela, nous allons orienter notre questionnement et notre action vers le fonctionnement de Scrum et plus particulièrement sur la constitution et gestion du Backlog Produit, puis sur le principe d’amélioration continue.

Une façon de faire simple et efficace est de relire le ScrumGuide ensemble. Puis de partager le fait que les Items ne sont pas nécessairement des UserStory mais peuvent être d’autre forme de représentation de ce qui est nécessaire pour construire le produit.

Pour la croyance « trop de détail », nous allons orienter notre discussion sur l’auto-organisation et les besoins des uns et des autres et inviter la ScrumMaster à vivre une nouvelle expérience en organisant un atelier Give and Take Matrix dont le thème portera sur le niveau de détail nécessaire aux uns et autres de l’équipe.

Le dernier élément est la peur de ne pas être Agile et de ne pas atteindre l’objectif. Il est nécessaire de traverser cette peur en séance. Vous pouvez le faire en questionnant ou en utilisant un outil comme My worst Nightmare. Pour ma part j’utilise une association des deux.

Pour aller plus loin

Découvrir l’Agile

La référence Agile : Agile Manifesto

Comprendre des termes comme ScrumMaster, ProductOwner, Backlog : ScrumGuide

Utiliser des ateliers :

Obtenir des fiches pour animer des ateliers : Innovation GameGameStorming

Réaliser des ateliers en ligne  : Weave

Se former et se faire accompagner

Formations en ligne : Histoire de réussir – Academy : Choisir L’Agile pour son Equipe

Formations certifiantes : Agilbee

Se faire accompagner : Coaching Agile, Coaching individuel, Coaching en Leadership Agile, Supervision de coach Agile et ScrumMaster

Nicolas DELAHAYE