Dans ce billet, nous nous basons sur un expérience vécue de mise en place d’une méthodologie (Scrum) sur un projet de développement, pour analyser un piège qui, selon nous, guette toute organisation désireuse de s’améliorer via l’adoption d’une méthodologie : le piège de l’Artefact.

Le piège

Un jour, un homme décide qu’il veut devenir moine. Il accepte alors de s’astreindre à certaines règles de vie, à une discipline. Il revêt également un habit qui le fait apparaître comme moine aux yeux de tous.

L’organisation qui souhaite devenir Agile, ISO, CMMi ou “Force Pure” (non, ne cherchez pas “Force Pure” sur Google : nous utilisons ici ce terme pour désigner une méthodologie ou une certification quelconque) accepte de s’astreindre à certaines règles de fonctionnement, à une discipline. Elle produira des artefacts qui pourront notamment servir à démontrer aux observateurs son respect de ces règles, à prouver qu’elle “est” ce qu’elle prétend être.

Pour valider le fait qu’un homme est un moine, ou qu’une organisation est Force Pure, l’observateur extérieur aura donc un moyen fort simple à sa disposition : il lui suffira d’en analyser l’habit. Nous le savons pourtant : “l’habit ne fait pas le moine”.

La société X veut devenir Agile

La société X a vu dans l'Agile un moyen d’être plus performante, plus réactive, plus efficiente. Pour ce faire, les organisations Agiles sont parées d’un arsenal de pratiques, d’outils, et de divers signes visibles. Afin d’obtenir cette parure, elle fait appel à un consultant Agile.

Beaucoup d’organisations suivent le cas de la société X et choisissent différentes méthodologies afin d’atteindre différents buts :

• Démontrer leur maturité et leur capacité à délivrer un service de haute qualité,
• Améliorer leur capacité à produire des composants ISO à moindre coût,
• Diminuer le time to market.

Place à l’artefact

La DSI de la société X s’est lancée. Le consultant Agile l’aide dans sa mise en place des pratiques et outils qui vont bien. Sur un premier projet, les rôles sont distribués : Product Owner, Scrum Master, Tech Lead, développeurs.

Le backlog est un tableau Excel à 9 colonnes. Un outil de tests fonctionnels automatisés est mis en place. Comme l’a suggéré le consultant Agile, l’équipe projet a collé des feuilles sur les murs pour faire un taskboard, acheté des post-its et affiché des burn-up charts. Toujours sur les conseils du consultant, des rituels ont été mis en place : stand-up, bilans d’itération, rétrospective...

Quelques semaines plus tard, la mécanique est en place, l’habillage est complet. Le consultant Agile est remercié, la société X est maintenant sur les rails du succès grâce à sa parure de Scrum et XP.

Y’a un truc qui coince...

Pourtant, quelque chose cloche.

Le produit livré présente des défauts de qualité. A la fin de chaque itération, les parties prenantes du projet discutent la pertinence de ce qui a été développé. Les développeurs sont frustrés car leur travail finit souvent à la poubelle.

Voilà quelques phrases que l’on entend typiquement dans les couloirs ou pendant les réunions sur le projet “agile” de la société X :

• “Prioriser, oui, mais bon... De toutes façons l’important c’est de tout faire !”
• “Vous traitez ça comme vous voulez (bug, story, whatever), mais ça doit être en production demain !”
• “Bon, la rétrospective, on la fait ou pas ?”
• “C’est vrai qu’on a changé le périmètre de l’itération en plein milieu, mais en même temps un projet ça vit, et on est agile !”
• “OK, ce que tu as codé c’est pas exactement ce qu’on voulait, mais bon... Je te valide la story, et puis tu corriges ça dans la foulée ?”
• “Oui, bon, l’Agile c’est gentil, mais c’est surtout un truc de développeurs !”
• “Ca marche pas ! - C’est vrai que ça nous semblait bizarre mais bon c’est ce que l’on nous a dit de faire.”

Sous l’habit, la vraie nature

En effet, nombre d'artefacts sont en place et semblent attester d'un respect de la méthode. Mais en fouillant d’avantage, on se rend compte que tout n'est pas si simple...

Taux de couverture du code par les tests unitaires : 82%. Mais que teste-t-on ? Ces tests sont-ils pertinents ? Le problème ici est que l’on pense avoir une bonne pratique, on a mis en place un indicateur, les chiffres sont positifs, mais ils ne révèlent pas la qualité des tests effectués. La qualité du test est difficile à mesurer. Pour pallier ce problème, on peut conserver cet indicateur mais changer nos pratiques de développement en passant à TDD (construction du test puis écriture du code permettant de satisfaire au test).

Binômage entre développeurs. Oui, on a binômé sur le projet. Mais avec le temps, la pratique a disparu. En cause : pas le temps de binômer, il faut produire, et puis l'on considère que chaque membre de l’équipe est suffisamment monté en compétence... En effet, on aura tendance à penser que l’on produit plus de valeur à deux derrière deux machines, qu’à deux derrière une seule machine... Puisque dans ce dernier cas, la productivité en terme de lignes de code produites par développeur serait mécaniquement divisée par deux ! Néanmoins, la pratique du binômage (actif) facilite la propriété collective du code, améliore le design applicatif et améliore la précision des estimations.

Stand-up meeting, 10h00, tous les jours. L’ensemble de l’équipe participe au rituel du stand-up meeting, chacun communique sur ce qu’il a fait la veille, ce qu’il va faire, et quels sont ses blocages. C'était en tous cas le cas au départ.

• Au fur et à mesure, le format dérive et les participants se contentent de remonter l’avancement du sujet sur lequel ils travaillent. Avec l'érosion de la pratique du binômage, on se spécialise sur des pans de l’application : à chaque itération, on travaille sur les mêmes sujets et on ne s'intéresse plus au travail des autres.
• Les problèmes ne sont plus communiqués, car on a peur d’être jugé. Ce n’est pas toujours évident de dire “je suis bloqué, je n’y arrive pas, pouvez-vous m’aider ?”
• L’équipe n’a pas prévenu de son retard la dernière fois, alors on veut s’assurer qu’elle va bien tenir les délais cette fois-ci... Le stand-up meeting prend alors des allures de point de suivi de l’avancement, pendant lequel la MOA ne cessera de rappeler “On est très attendu là-dessus, il faut vraiment que ça livre !”...

Au final, l’absence de relation de confiance a dégradé l’utilité du rituel : synchroniser l'équipe et lever les points de blocage.

Des User Stories et des spécifications Fitnesse. On alimente les équipes de développement en User Stories. Mais on préfère les exprimer sous forme d’algorithmes ou de conceptions détaillées parce que l'on considère que les développeurs n'ont pas les compétences nécessaires ou la responsabilité du design de l'application. Les équipes fonctionnelles n'expriment plus des besoins et dérivent, elles expriment des solutions.

Que s’est-il passé ?

On se rend compte qu'on a transformé la méthodologie pour de mauvaises raisons : peur du changement, incompréhension de l'objectif de la pratique...

La société X a voulu devenir agile, mais veut avoir :

• des concepteurs, garants de la conception applicative,
• des développeurs garants de la production de lignes de code,
• des qualifieurs garants de la qualité de l’application.
• ...

On a ajouté de la structure organisationnelle avec des chefs pour chaque équipe, dont les objectifs divergent...

La démarche Agile prône une équipe auto-organisée, responsable, unifiée... L’organisation précédemment décrite va à l’encontre de ce principe et ne favorise pas un climat de confiance nécessaire pour le bon fonctionnement de l’équipe. Un retour aux valeurs de l'Agile est nécessaire.

Certains des artefacts sont là, le projet semble agile. Mais visiblement, le process, lui, est bafoué. Les pratiques sont réaménagées, parfois détournées de leur objectif initial : améliorer la productivité, la qualité, l’efficience de notre organisation.

Quelques pistes pour ne pas se faire piéger

Pour ne pas être pris dans le piège de l’artefact, voici quelques idées qui peuvent aider :

1. En début de projet, l'équipe définit son objectif, et le révise régulièrement

2. L’équipe se forme à la méthodologie qu’elle a retenue

3. Des rétrospectives sont conduites de manière régulière et non négociable

4. En rétrospective, l'animateur pose les questions suivantes :

- “Y'a-t-il des pratiques qui vous semblent inutiles, inadaptées ou améliorables ?” - "Y'a-t-il de nouvelles pratiques à adopter ? Qu'en attend-on ? - “Vous avez travaillé avec différentes personnes depuis la dernière rétrospective ; comment ces collaborations auraient pu être améliorées ?” (= rendues plus efficaces)

Les réponses à ces questions orienteront l'ajustement de la méthode aux besoins de l'équipe. Ce travail doit être fait sous le contrôle d'un garant de la méthodologie qui veillera à ce que ces ajustements servent réellement l'objectif de l'équipe.

5. L’équipe met en oeuvre les nouvelles pratiques

6. Lors de la rétrospective suivante, on repart au point 4

Conclusion

Il ne faut pas perdre de vue que l’utilisation d’une méthodologie ou l’obtention d’une certification, quel-qu'elle soit, n’est pas une fin. Transformer son entreprise, adopter une nouvelle méthodologie, est un moyen permettant de répondre aux enjeux poursuivis par celle-ci. Il ne suffit pas d’endosser les artefacts de la méthodologie pour garantir l’atteinte de ses objectifs. Le but du moine n’est pas d’être reconnu comme tel aux yeux de tous, c’est de se rapprocher de son Dieu. Aussi, Saint Jérôme nous précise : “ce n’est pas à l’habit qu’on reconnaît le moine, mais à l’observation de la règle et à la perfection de sa vie.”

On a envie de dire “c’est du bon sens”, et c’est vrai. Encore faut-il savoir en faire preuve...

Note : cet article aurait également pu s’intituler “J’ai 250g de farine, 200g de beurre... Je ne peux pas rater mon gâteau.”