Billet #1 : La frustration est de l’or

Quelles sont les conséquences du manque de communication et de réflexion ? Quels sont les blocages qui empêchent d’initier une démarche d’amélioration continue ? Comment délivrer l’équipe de la peur d’agir ?

Introduction

Qui suis-je ?

L’agilité, avant, je voyais cela plutôt de loin. Je développais donc le fonctionnement de l’équipe ne faisait pas vraiment partie de mon périmètre. Seulement, comment faire lorsqu’on vit pendant un an les dysfonctionnements et la perte de motivation de toute une équipe ?

C’est avec la volonté de sortir de certains malaises que j’ai commencé à m’intéresser à l’agilité. C’est ainsi que je me suis vue prendre progressivement le rôle de Scrum Master au sein de l’équipe que j’ai accompagnée, durant un an et demi, dans une démarche d’amélioration continue.

Pourquoi ce REX ?

Cette démarche que l’équipe a entrepris a permis d’encourager la hiérarchie à intégrer des pratiques agiles dans le cadre de la réorganisation du service informatique, incluant ainsi l’ensemble des projets informatiques dans un processus agile.

L’agilité vous intéresse mais vous êtes dans le cadre d’un projet où il est compliqué d’appliquer une méthodologie agile “by the book” ? Je vous propose de partager mon retour d’expérience à travers une série de billets. Vous y découvrirez une approche agile par la pratique !

• Billet #1 : La frustration est de l’or
• Billet #2 : La rétrospective est la clé de voûte
• Billet #3 : Installer collectivement une culture
• Billet #4 : Petites boucles de rétroaction
• Billet #5 : Grandes boucles de rétro action
• Billet #6 : L’effet papillon

Contexte

Dans ce premier billet nous allons nous intéresser au contexte dans lequel l’équipe se trouvait et les blocages qui empêchaient l’équipe d’agir.

Un projet à grande envergure

Il s’agit d’un extranet, en production depuis dix ans, qui a été victime de son succès. Les fonctionnalités ont été développées par couches avec très peu de ressources au fil des années. Le projet est utilisé à l’échelle internationale par les employés et les clients de l’organisation. L’activité métier est découpée en trois grandes composantes, l’application permet le suivi de l’ensemble du processus métier.

L’organisation

Pour des raisons historiques, le projet se trouvait au sein d’un service métier qui représente un tiers des activités métiers gérées par l’application. L’ensemble du service se positionnait plutôt comme utilisateurs de l’application donc la méthodologie de gestion de projet informatique ne faisait pas partie des préoccupations de la hiérarchie.

L’équipe

L’équipe est composée de huit personnes avec des niveaux d’expériences et des spécialités hétérogènes. Les rôles n’étaient pas clairement définis voire même historiques, donc plutôt que de vous faire un long discours voici un schéma qui vous permettra de mieux comprendre :

Gestion de projet en cascade

Toutes les étapes du cycle de développement étaient totalement prises en charge par l’ensemble de l’équipe de développement, en allant du recueil du besoin utilisateur à la livraison de l’application, en passant par la conception et la recette.

Dette technique

Le projet continuait de fonctionner de cette manière mais ce système était de moins en moins efficace. L’équipe déployait une grande énergie en analyse et en maintenance des fonctionnalités, au détriment de la qualité technique et fonctionnelle de l’application.

Une énergie bloquée

Soutien hiérarchique

Lorsqu’un projet de cette envergure n’est pas régulièrement refondu, on arrive à un stade où la moindre fonctionnalité prend un temps extrêmement important en développement. Cette situation générait une frustration, tant au niveau de l’équipe, qu’auprès du management. La situation ne faisait que se dégrader. Averti de cette dégradation, le management a tenté d’améliorer la situation.

Du temps pour mieux faire

Le management a donc convoqué les membres de l’équipe individuellement pour avoir un retour sur la situation. Afin de répondre à la problématique de dette technique, ils ont accordé un pourcentage de 30% du temps dédié à la technique.

Blocages

Cependant, l’équipe n’arrivait pas à sortir de son quotidien, il était impossible de déclencher le changement. En réalité la hiérarchie avait accordé du temps pour résoudre la conséquence et non pas la cause du problème. Le sentiment d’insatisfaction au sein de l’équipe s’est accentuée, une insatisfaction tellement forte que tous les membres de l’équipe envisageaient de quitter le projet.

La frustration est de l’or

J’ai donc cherché à comprendre pourquoi l’équipe n’agissait plus en initiant des discussions avec les différents membres de l’équipe. J’ai pu en conclure que l’inactivité de l’équipe ne relevait pas d’une absence de motivation mais d’une frustration.

La frustration est de l’énergie bloquée. Il faut exploiter cette énergie pour provoquer un changement  (« Frustration is gold » Culture Hacking de Robert Richman)

J’ai fini par comprendre que l’équipe souffrait terriblement d’un manque de visibilité et de communication. Le point bloquant était que les membres de l’équipe estimaient que ce n’était pas leur rôle de s’impliquer sur la méthodologie de gestion de projet.

Délivrer l’équipe de la peur d’agir

J’ai donc pris l’initiative de proposer une rétrospective dans le but de rétablir la communication au sein de l’équipe. Dans mon prochain billet nous reviendrons sur le déroulement de notre première rétrospective et sur le plan d’action qui a permis à l’équipe de se libérer de la peur d’agir.

A suivre…

Retrouvez l’ensemble du Retour d’expérience avec le hashtag #AgileFromScratch