ScrumDay 2014 : retour de bâton pour l’agilité ?

Nous étions au ScrumDay en 2013. On vous en avait même pas mal parlé. L’ambiance était un peu euphorique, avec quelques touches hippies. Nous allions changer le monde avec Scrum. Ou en tout cas le monde de la création de logiciels. Aujourd’hui, nous n’en sommes plus à faire des plans sur la comète. Nous sommes confrontés à des difficultés concrètes. Au point qu’on commence de plus en plus à entendre des voix qui s’élèvent contre l’agilité en général et Scrum en particulier. L’ambiance en 2014 était donc bien différente. Petit tour d’horizon.

Ça y est, on est “agile”. Et maintenant, comment on fait ?

Le deuxième jour du ScrumDay a pris la forme d’un grand openspace, où chacun pouvait soumettre son thème et proposer une discussion. Une grande partie de ces questions tournait autour de la mise en place concrète de l’agilité. Eh oui, ce n’est jamais aussi simple qu’on l’avait imaginé ou qu’on nous l’avait vendu.

Faire du logiciel, ça n’a jamais été simple, et ça ne le sera probablement jamais. Et c’est là qu’on se confronte à un des premiers problèmes. Ceux qui ont eu de la chance se sont fait accompagner pendant leur fameuse transition agile. Sauf que les coaches se placent à un niveau organisationnel et qu’on constate très souvent un manque de liant entre la théorie et la pratique une fois ces coaches repartis vers d’autres horizons. Sans parler des équipes qui peuvent continuer à essuyer des plâtres pour des années à venir. Le problème selon moi est que l’on a survendu l’agilité, et nous l’avons présentée comme une terre promise idyllique et parfaite pour tout le monde. Sauf que ce n’est pas du tout le cas.

Combien d’équipes pratiquent Scrum sans être agiles ?

Combien d’équipes et d’organisations sont réellement prêtes pour l’agilité ? Ou au moins sont prêtes à se donner les moyens de devenir agiles ? On implémente Scrum ou une autre méthodologie de façon mécanique, mais investit-on vraiment du temps à comprendre et faire comprendre les valeurs fondamentales de l’agilité ?

Je ne compte même plus les cas que j’ai pu rencontrer où le management et/ou le métier se disent prêts pour l’agilité, mais qui concrètement ne valident jamais les pré-requis fondamentaux pour bien y parvenir. Quelques indices souvent révélateurs :

• Il existe toujours une MOA.
• Avant on avait des specs. Maintenant, on a un Backlog qui fait office de pense-bête pour le (ou les) PO.
• On a un architecte en chef, ou une cellule architecture toute puissante qui décide des détails d’implémentation.
• On gère toujours des projets, pas des produits.
• On a plusieurs PO pour une même équipe.
• Les équipes sont organisées par domaine technique et sont interdépendantes.
• On n’a jamais quelque chose de réellement livrable en fin de sprint.
• Et les priorités changent tout le temps. Mais on est agile, non ?
• Le déroulement du sprint n’a souvent pas grand rapport avec ce qui a été décidé lors de la planification.
• On développe vite, et on verra plus tard si ça marche.
• Avec une règle de trois, je connais mes délais à partir de la valeur en points de mes User Stories.
• Lorsque je démarre le développement d’une User Story, je ne sais pas encore comment je vais valider qu’elle répond bien aux attentes des utilisateurs.
• Le contenu du Backlog est de qualité douteuse, même pour les US prioritaires.
• On ne sait d’ailleurs pas ce qu’on considère comme une User Story de bonne qualité.
• … ni vraiment quand elle est terminée.
• L’équipe de testeurs rôde dans les couloirs.
• C’est quoi un utilisateur ?
• J’ai un PO, ou pire, un proxy-PO, qui n’a aucun pouvoir réel de décision.
• Les devs se considèrent et donc sont de simples exécutants.
• L’équipe dans son ensemble n’a pas réellement de volonté de s’améliorer.

Cette liste déjà longue pourrait encore se compléter à l’infini. Une des origines de ces problèmes est que les impacts de l’agilité sur l’organisation entière de l’entreprise sont souvent mal expliqués et/ou mal compris. On entend très souvent dire “ah oui, mais chez nous, c’est pas pareil”, ce qui revient à penser qu’il existe une et une seule forme d’agilité possible : “la bonne”. C’est une chimère. Faute de pouvoir se plier à l’ensemble des contraintes de cet objectif inatteignable, on ne se plie qu’à certaines, et on finit par faire du ScrumBut ad vitam aeternam.

Si Scrum vise à remettre l’humain au centre des préoccupations, cela ne vient pas sans contrepartie. Être Team Member dans une équipe Scrum est un métier fondamentalement différent de celui de développeur dans un cycle en V. On confie aux Team Members des responsabilités jusqu’ici dévolues aux chefs de projets, architectes, concepteurs, etc. Tout le monde en conviendra, il s’agit d’un travail bien plus intéressant que celui de simple exécutant, consistant à traduire un spécification technique détaillée en code. Mais on demande aux Team Members de se responsabiliser et de prendre des engagements. Cela nécessite naturellement un minimum de maturité, d’expérience et de recul de ces derniers. Toutes les équipes n’ont pas les moyens ou les capacités de le faire.

Moralité : si on veut vraiment devenir agile et bien faire du Scrum, il faut s’en donner les moyens. Avant de prendre ce chemin, demandez-vous s’il est fait pour vous, et si l’organisation est réellement en capacité de le faire. Ensuite, réorganisez et rassemblez les équipes, donnez un réel pouvoir de décision au PO, laissez décider l’équipe de l’implémentation. On ne peut pas bien faire d’agilité dans une organisation qui ne se remet pas en question et qui cherche réellement à s’améliorer.

Scrum n’est pas et ne sera jamais auto-suffisant

Lorsqu’une organisation implémente Scrum, elle se rend rapidement compte que ça ne suffit pas. Scrum part du principe que vous avez en entrée de sprint un Backlog priorisé, et en sortie un logiciel viable et fonctionnel. Sauf que le Scrum Guide ne nous dit pas comment.

Le Backlog est la colonne vertébrale de Scrum. La qualité de son contenu est une condition nécessaire au bon déroulement du processus. Mais entre le besoin formulé par un utilisateur et la planification de la User Story dans le sprint qui vient, beaucoup de choses peuvent se passer. Il peut donc être nécessaire de compléter Scrum à l’aide d’autres méthodes : Kanban, Story Mapping… Le terme User Story, d’ailleurs, ne vient pas de Scrum. Il vient d’Extreme Programming. Dans Scrum, cela s’appelle un “élément de Backlog”. C’est dire si c’est précis.

Si Scrum introduit la définition d’un élément terminé (Definition of Done), il s’avère rapidement indispensable de formaliser son pendant : la Definition of Ready. Elle liste l’ensemble des pré-requis indispensables à l’équipe afin qu’elle l’exécute correctement. Et l’ami Michel en profite pour vous conseiller Executable Specifications With Scrum, qui traite justement de la façon d’amener une idée à quelque chose de compréhensible et testable par le développeur.

Enormément d’équipes Scrum utilisent le Planning Poker pour chiffrer les User Stories. Ca aussi, c’est une technique empruntée à Extreme Programming (XP). Et ce n’est pas la seule : Intégration Continue, Pair Programming, TDD… Ce n’est pas pour rien que les deux méthodes sont souvent associées. D’ailleurs, Extreme Programming est la seule méthode agile à s’être réellement intéressée à comment on développe concrètement du logiciel. Ce n’est pas pour rien que c’est la méthode préférée des vieux routards et autres développeurs réellement aguerris. Si certaines pratiques de XP, comme l’Intégration Continue, sont aujourd’hui très répandues, d’autres relèvent encore de la Science-Fiction. C’est tout de même dommage.

Alors, que fait-on ?

On apprend. Un des principes fondamentaux de l’agilité est de se confronter tôt et le plus souvent possible aux problèmes afin de les résoudre et accélérer. Cela vaut aussi naturellement pour la méthodologie de travail elle-même. Une grande majorité des implémentations de Scrum que l’on voit aujourd’hui sont mauvaises. Mauvaises car issues d’un effet de mode. Mauvaises car tout le monde s’y est mis sans forcément se demander si l’organisation était compatible et allait s’en donner les moyens. Mauvaises car on s’est vu vendre une simple méthodologie sans en comprendre les principes fondamentaux sous-jacents.

Scrum est-elle pour autant une mauvaise méthode ? Bien sûr que non. Mais il conviendra à l’avenir d’être bien plus prudent avant de s’y lancer à corps perdu. Non, Scrum n’est pas fait pour tous les projets. Non, Scrum n’est pas la recette miracle pour guérir tous les maux d’une organisation. Et non, tous les profils ne sont pas adaptés pour faire partie d’une équipe Scrum.

En tant que sociétés de conseil, c’est à nous de signaler ces points à nos clients afin de les accompagner au mieux. Cela passe par une prise de conscience du fait que nous faisons nous-mêmes partie du problème. Beaucoup d’entre nous – et je m’inclus dedans – sommes devenus des VRP de luxe de l’agilité en général et Scrum en particulier, biaisés par le fait que nous en vivons. Nous cherchons à appliquer les mêmes recette partout, nous persuadant qu’elles produiront les mêmes résultats. C’est pourtant faux, et c’est ce que nous apprenons, avec une certaine douleur, aujourd’hui.

Le tableau parait bien morose. Mais après tout, n’est-ce pas justement cela, l’agilité ? On avance, on trébuche, on apprend, et on s’améliore. Cela vaut pour tout le monde. Après tout, on sait d’où on vient, mais pas encore où on va.