Bien jouer son rôle dans l’équipe Agile : Tous pour Un, Un pour Tous!

Tous les membres formant une équipe Agile se voient comme une seule équipe ayant un objectif commun. Il n’y a pas de place pour la mentalité de “jeter par dessus le mur” dans l’esprit Agile. Les analystes ne jettent pas les requis par dessus le mur aux designers, les designers et les architectes ne jettent pas leur designs par dessus le murs aux développeurs, les développeurs ne jettent pas leur code partiellement testé par dessus le mur aux testeurs. Une bonne équipe Agile est plutôt dans un esprit de “tout le monde est dans le même bateau”.

Par ailleurs, si les membres de l’équipe travaillent ensemble comme une équipe unie, chacun d’eux est voué à jouer un rôle spécifique. Il est très important de comprendre son rôle afin de bien le jouer pour livrer la valeur attendue du projet.

Mais que veut dire le mot rôle?

Un rôle est une fonction qu’un membre de l’équipe effectue au cours du projet. Un membre de l’équipe peut avoir plus d’un rôle dans chaque projet. Un rôle n’est pas égal à une position hiérarchique ou une personne, fait qu’on retrouve dans plusieurs équipes Agiles. En d’autres termes, un rôle est un ensemble de “responsabilités”.

Les différents rôles dans l’équipe Agile

Le Product Owner

Le premier rôle est le “product owner”. La première obligation du product owner est de s’assurer que tous les membres de l’équipe suivent la vision commune du projet. Il le fait en établissant les priorités de telle sorte que la fonctionnalité qui a la valeur la plus grande soit toujours celle que l’équipe est en train de livrer. Le product owner s’assure d’effectuer les décisions qui mènent à un bon retour d’investissement sur le projet. Généralement, dans le développement logiciel commercial, le Product owner est quelqu’un du service de Marketing ou Produit de l’entreprise. Si le développement est pour l’interne, le product owner peut être un employé, un analyste ou la personne finançant le projet.

Le Client

Le deuxième rôle est le client. Le client est la personne qui a décidé d’acheter le logiciel, ou de financer le projet. Si le développement est pour l’interne, le client est généralement un représentant d’un autre département. Généralement, dans ces cas, les rôles du product owner et du client sont combinés. Pour un produit distribué commercialement, le client est la personne qui achète le logiciel. Dans les deux cas, le client peut ou pas être l’utilisateur du logiciel, qui est bien sur un autre rôle important.

Le développeur

Un autre rôle très important est le développeur. Le terme développeur réfère généralement à n’importe quelle personne impliqué dans le développement du logiciel. Ceci inclut les programmeurs, les testeurs, les analystes, les Administrateurs et ingénieurs de Bases de Données, les experts en convivialité ou interface utilisateurs, les rédacteurs techniques, les architectes, les designers etc. Dans certains cas, même le product owner peut avoir un rôle de développeur.

Le Project Manager

Un rôle final est le project manager. Ce rôle change significativement dans les projets Agiles. Les gestionnaires Agiles se concentrent beaucoup plus sur le “leadership” que sur la gestion. Dans certains projets Agiles, la personne qui joue ce rôle joue également un deuxième rôle, le plus souvent le rôle de développeur, et très occasionnellement le rôle de product owner.

Pas de barrières entre les spécialités

Souvent teintes d’une mentalité de “commande et contrôle”, les méthodes classiques ont tendance à renforcer la séparation des rôles en effectuant une séparation entre les spécialités dans le temps. Par exemple, l’analyse des besoins se fait avant que le développement commence. L’architecture se fait au complet avant le développement. Le test ne peut commencer qu’après que tout le développement soit complété.

En agile, le concept est complètement différent, l’équipe est une unité. Les barrières entre les différents intervenants dans la livraison du produit tombent afin d’offrir un flot plus fluide.

Par exemple, le manifesto Agile dit que

Les meilleures architectures, spécifications et conceptions émergent d’équipes auto-organisées.

Dans ce cas, le mot “émergent” efface cette séparation, et l’objectif étant de livrer à petit incrément, nécessite que l’équipe formé par des membres de différentes spécialités travaille en unité.

Incompréhensions communes

Limiter soi même par son rôle

Dans ce cas, la personne  s’identifie avec le rôle et s’y limite. Des exemple courants sont :

• “Je suis un programmeur, alors je ne sais faire que de la programmation, et non le test”
• “Je suis un analyste QA, Je ne peux pas aider dans d’autre chose que le test”

Limiter les autres par son rôle

Dans ce cas, la personne limite son rôle a soi même et empêche les autres de le jouer. Par exemple :

• “Je suis un architecte, je suis la seule personne qui peut travailler sur l’architecture du logiciel”
• “Je suis un product owner, je suis la seule personne qui dicte les besoins”

Penser en Silo

Il est facile de tomber dans le cas :

• “Ce n’est pas ma responsabilité, ce n’est donc pas mon problème puisque ce n’est pas mon rôle”.

Dans ce cas, si les rôles sont équivalents à des positions ou des départements, l’impact peut être majeur et très négatif.

Imaginez l’impact si vous avez un Département d’analystes, un Département de développeurs et un département de QA, et que chacun essaye d’optimiser ses propres rôles!

Lier les rôles à une compensation

Dans ce cas, si les rôles sont liés à des compensations, chaque responsabilité que la personne prend à l’extérieur du scope de son rôle est au mieux une perte de temps et peut être au détriment de sa carrière.

Conclusion