Dans le cadre d’un projet en collaboration avec l’un de nos clients, j’ai pu découvrir une organisation d’équipe « Scrum » telle que je ne l’avais jamais pratiqué auparavant. Il s’agissait d’une équipe pleinement autogérée.

Nous devions travailler en collaboration avec deux équipes de développement, en organisation Scrum et sur un même produit. Le but était d’enrichir le produit afin qu’il soit de la meilleure qualité possible, et ce, en respectant les délais impartis par le client. J’ai donc pu confronter nos méthodologies.

La méthodologie agile

De mon expérience de chef de projet, j’ai travaillé sur des projets industriels, orientés vers le naval militaire ou les systèmes embarqués. Ces projets sont difficilement réalisables en agilité : il s’agit souvent de cycles en V classiques avec une seule itération de développement et en travaillant sur un cahier des charges clair et défini dès le début des développements. Depuis 3 ans, je découvre le monde de l’informatique de gestion et des méthodologies Agile, du moins les théories. Mais je n’avais jamais rencontré, jusqu’à ce projet, une équipe autonome, en autogestion complète. Avant d’entrer dans le cœur du sujet de cet article, redéfinissons les quatre valeurs du manifeste agile :

• –  Interactions entre les individus
• –  Collaboration avec les clients
• –  Livraison du produit attendu
• –  Acceptation des changements, des besoins et de la réactivité

De ces quatre valeurs, nous retrouvons également les douze principes du manifeste :  

Un projet en méthodologie Scrum

J’ai eu la charge de monter une équipe pour accompagner notre client sur un projet de développement en recherche et développement. Une autre équipe était déjà sur le projet, mais avait demandé à être renforcée afin d’atteindre les objectifs de livraison du logiciel. Elle était en place depuis plus d’un an, et travaillait en respectant rigoureusement les valeurs et principes agiles, en méthodologie Scrum. Je connaissais la théorie de l’agilité, mais je ne l’avais encore jamais vu mise en pratique de manière aussi rigoureuse. Cela m’a permis d’observer les effets positifs ainsi que les négatifs d’une organisation agile rigoriste. Dans un premier temps, j’ai noté que cette équipe se connaissait parfaitement : chacun savait ce qu’il devait faire et comment travaillaient ses équipiers. Les différentes cérémonies Scrum étaient respectées, notamment la « rétrospective ». Cette équipe, comme le défini le Manifeste Agile, était parfaitement autonome et autogérée : elle gérait ses itérations en fonction des besoins du Product Owner et cherchait à s’améliorer au quotidien. La communication était omniprésente, que ce soit dans les différentes cérémonies, dans les échanges journaliers, pendant les heures de travail, mais aussi en dehors … Les échanges étaient uniquement bienveillants. Dans ce type d’organisation, il n’y a pas de hiérarchie, mais j’ai noté qu’un leadership s’était mis en place. Tout d’abord, celui du Scrum master qui avait une influence naturelle par son rôle, puis également celui de personnalités qui sortaient du lot. Les leaderships naturels des membres de l’équipe permettent surtout de pouvoir s’appuyer sur les aspects techniques, par exemple, un architecte ou un expert technique, tandis que le Scrum master était le garant du bon déroulement du process.

L’importance de la relation client

Vient ensuite la relation entre l’équipe et le client. Dans ce projet, le client n’a pas toujours su se rendre disponible. L’équipe a donc cherché à l’impliquer au maximum, et ce, en amont du projet. La feuille de route globale est toujours partagée et son implication dans les validations des développements fait que le produit suit une logique de développement cohérente dans sa globalité. L’objectif étant de réaliser un produit répondant au mieux aux besoins du client. L’ensemble des développements sont orientés vers le client afin de correspondre à ses attentes. Chaque ticket de développement est choisi en fonction de son apport au produit et de sa valeur pour le client.

La place du Chef de projet dans une équipe autogérée

Enfin, l’équipe a toujours son mot à dire sur la rédaction des fonctionnalités, dans sa validation et son acceptation pour l’inclure dans un sprint. Une fonctionnalité peut être refusée si elle n’est pas suffisamment claire, si elle ne rentre pas dans les critères de la « definition of ready », permettant le démarrage d’un développement. Mais l’équipe sait aussi s’adapter aux besoins du client et être flexible dans son process pour faire des compromis. Cette organisation autogérée, propre à l’agilité Scrum, permet à l’équipe de se challenger au quotidien et d’avancer clairement vers un objectif commun. Cependant, il y a parfois un manque de clarté dans les objectifs du projet et des tensions peuvent apparaître entre les membres de l’équipe Scrum. De mon analyse, la présence d’un chef de projet permet de garder des objectifs clairs lorsque des tensions apparaissent dans l’équipe. Son rôle est d’autant plus important quand, dans notre cas, des développements sont réalisés de manière commune et qu’il faut faire en sorte d’être réactif pour ne pas bloquer l’autre équipe. Un chef de projet ne se substitue pas à un Scrum master : le Scrum master est le garant du bon fonctionnement d’un sprint, aussi bien dans son suivi que dans sa méthodologie. Je termine cet article en citant le blog ITforbusiness : « Pour être aligné avec les principes Agile, le chef de projet ne doit pas être considéré (ou se considérer) comme le « chef ». En effet, ceci est en contradiction avec le principe d’autonomie de l’équipe Agile. Il doit être vu comme un « chef d’orchestre » en charge de la coordination des dépendances fonctionnelles et techniques. Comme le recommandent les principes Agile, il devra collaborer avec les autres membres de l’équipe pour apporter sa compétence et partager avec elle les décisions à prendre et les stratégies de gestion des dépendances. » Articlé rédigé par Matthieu-Paul, Chef de projet