Une équipe agile, une équipe avec du caractère.

Voici quelques interrogations que l’on entend parfois à propos des équipes agiles.

Est-ce qu’il n’y a pas malgré tout un chef ?

Oui ! En tout cas, il y a un ou des leaders.

Les personnes expérimentées ne sont-elles pas forcément plus influentes ?

Oui !

Est-ce qu’on peut vraiment faire binômer un développeur senior avec un débutant ?

Non, sans doute pas très longtemps.

En tant qu’analyste métier, quelle est ma place ?

Et on entend parfois des responsables fonctionnels dire des choses comme :

"De toute façon, notre référence sera toujours le document de spec !"

Il est apparemment assez difficile de comprendre ce qu’est une équipe agile pour les praticiens du cycle en V. Toutes ces réflexions, toutes ces résistances au changement, viennent de la représentation mentale que nous avons de ce qu’est une équipe.

Dans le cycle en V, les équipes sont cloisonnées. Les personnes sont regroupées par spécialisations : les spécialistes métiers sont ensemble pour former une équipe, les développeurs sont ensemble, les testeurs de même, les architectes (ça c’est sans doute le plus dingue)...

Dans le cycle en V, les équipes sont homogènes par construction, suivant le bon vieil adage : "qui se ressemble s’assemble".

Avec l’agilité arrive la fin du cloisonnage et c’est pour moi une des révolutions majeures. Un projet de développement logiciel (depuis sa vision jusqu’à sa livraison concrète au client), n’est réalisé que par une seule équipe [1].

Une équipe cross-fonctionnelle

Une équipe agile est le rassemblement de l’ensemble des compétences nécessaires pour mener à bien le projet. Elle réunit des personnes d’horizons différents avec des compétences variées. Une équipe agile est par définition très contrastée. Elle est le rassemblement d’individualités fortes plutôt que l’alignement d’une armée d’unités de production interchangeables. C’est une équipe qui a du caractère.

L’équipe agile est jugée sur le produit fini. Il n’y a pas de livrable intermédiaire. Cela signifie que si des analystes fonctionnels sont présents dans l’équipe, ils seront eux aussi jugés sur le produit final et non sur la qualité de leur document de spécification (qui peut, par ailleurs, tout à fait exister dans un projet agile). Cela signifie qu’ils sont responsables du contenu fonctionnel de l’application, mais aussi de la bonne transmission de ce contenu fonctionnel aux développeurs et de la validation de la présence effective de ce contenu dans l’application. Entre parenthèse, on comprend mieux qu’ils doivent s’intéresser aux tests !

Scalabilité ?

Si l’on en croit l’article suivant, les grands projets ont encore moins de chance de réussir. Qui plus est, il est sans doute assez hasardeux de généraliser sur le sujet tant les expériences correspondantes sont spécifiques. Les grands projets de ce type trouvent des équilibres de fonctionnement très différents d’un cas à l’autre.

Quoi qu’il en soit, on peut monter en charge tout en gardant des équipes de caractère. Une telle équipe ne peut être très grande. Une équipe réunissant des compétences aussi variées ne pourrait pas fonctionner si elle était constituée de 50 personnes.

Une équipe de ce type ne peut dépasser les 7 ou 8 personnes.

Pour monter en charge et réaliser de gros projets il est possible de multiplier les équipes agiles en distribuant les éléments fonctionnels du projet sur plusieurs équipes. Chaque équipe reste une équipe cross-fonctionelle, et l’on ajoute une activité de synchronisation des différentes équipes : ce que l’on appelle par exemple le Scrum de Scrum ou méta-Scrum.