Nombreux sont les articles qui vantent les mérites de l’Agilité. Est-ce une vraie révolution ou juste un nouvel effet de mode ?

Business Analyst depuis 2002, j’ai bien connu :

  • le document de cadrage de cent pages… jamais lu ;
  • les spécifications plus que détaillées… de poids presque indécent ;
  • les PV de recette… signés de notre sang.

En général, la documentation est rangée à la fin du projet… et plus jamais mise à jour. Qu’en reste-t-il ? L’Agilité a-t-elle signé sa mort ?

Je ne le pense pas. Mais pour autant, force est de constater que nos métiers sont en pleine mutation. Comment sinon demanderait-on aux développeurs de faire des démos, voire de rentrer en contact direct avec le métier…  N’était-ce pas le rôle de la sacro-sainte Maîtrise d’ouvrage ? J’en vois encore qui sont frileux. Et pourtant. Product Owner depuis 2011, ma plus grande satisfaction est celle d’un projet réussi, dont tous les membres se sont mis en danger, ont appris les uns des autres et ont grandi ensemble. L’équipe devient ainsi un organisme vivant où chacun trouve sa place, dans une mouvance constructive et ambitieuse.

Je suis convaincue que la clé du succès est la communication.

Car on a tous à apprendre. C’est vrai que la première fois qu’un Scrum Master donne son avis sur les User Stories, on se pose des questions. Les premières démos sont peut-être un peu brouillon. Mais quel bonheur de voir apparaître notre produit. C’est nous qui l’avons fait, et il a changé la vie du client ! Ce n’est pas que de la comm’, cela donne du sens à notre métier. Car ensemble, nous ne faisons que tailler des pierres, nous construisons une cathédrale ! 

* Trois tailleurs de pierre façonnent côte à côte une pierre. Le premier travaille mécaniquement, et quand on lui demande ce qu'il fait, c’est l’air ahuri qu’il répond : « je taille une pierre ». Le second est plus méthodique, et explique posément qu’il taille une pierre pour construire un mur. Alors que le troisième travaille si consciencieusement qu'on dirait qu'il taille un diamant. Il répond avec un large sourire : « je suis en train de construire une cathédrale ».

— Auteur inconnu

Les Casseurs de pierre, de Courbet (1849)

Alors je suis d’accord, la cathédrale ne se fait pas en un jour. La conduite du changement est un processus qui nécessite du temps. La réussite du projet passe par une remise en cause de son expérience, des rôles et des hiérarchies. Plus largement, le projet réussit si tous ses membres ont une vision commune et l’amour de notre matière première à nous, le travail bien fait. Si ensemble nous restons focalisés sur le service rendu et la recherche de la satisfaction, voire de l’étonnement du client.

La seconde clé du succès est de devenir Radically Customer-Centric et, pourquoi pas, disruptif.

Il est vrai que l’équipe gagne en confiance, en vélocité, en maturité. Mais il est aussi vrai que le changement ne se fait pas tout seul. On apprend à changer nos lunettes et à se mettre dans la peau de l’utilisateur, et cela est forcément payant. C’est une mutation de devenir Radically Customer-Centric.  Ce ne sont plus les fonctionnalités qui comptent, mais l’expérience utilisateur !

  • Changements dans la façon de spécifier : je décrits un besoin, et non plus une fonctionnalité.
  • Plus d’autonomie pour le développeur : il agit en vrai Maître d’Oeuvre, il construit une vraie solution !
  • Une autre façon de tester : les cas d’acceptance… ces grands oubliés. C’est ici que l’on se projette dans le futur produit.

Alors, il n’y aurait que du positif dans l’Agilité ? Pas tout à fait, je vois des écueils. Le processus est chronophage, cela prend du temps de bien communiquer. La rédaction des User Stories, les cérémonies…

  1. La rétro, très importante. Qu’est-ce qu’on a bien fait ? De quoi est-on fiers ? Quels obstacles avons-nous rencontré ? Comment les surpasser ?
  2. La démo,  avec ces questions-réponses et des cas d’usage auxquels on n’y avait pas pensé.
  3. La présentation, priorisation et estimation des User stories. On continue à échanger !

Mais le temps passé en cérémonie, ce sont des incertitudes qu’on lève, du temps qu’on gagne en test, des anomalies en moins. Des livraisons plus smooth, du savoir-faire accompagné du faire-savoir, fantastique !

L’autre point à lever serait, encore et toujours, la documentation du projet. Car il n’y a pas de solution magique. Les User Stories, pour être efficaces, sont courtes, orientées métier. Il n’est pas rare d’avoir plus d’une centaine sur un même projet. Alors quand on revient sur ce que le produit doit faire… Je l’avoue, on peut être perdu. D’où l’intérêt d’une documentation finalisée dans un SharePoint par exemple. Il restera une question, sa mise à jour…

Dilbert & the Agility