L'Agilitateur Création de logiciels : de l'agilité à l'artisanat

Dans le cadre de mon activité professionnelle, j'ai toujours appliqué une démarche de dissémination de pratiques agile dans un processus existant, ce qui produit en pratique des méthodes de travail un peu bricolées et spécifiques à un contexte donné.

En ce début d'année, je change un peu mon fusil d'épaule. Ce changement n'a rien de dogmatique et découle plutôt d'une démarche opportuniste. Il est des contextes où les changements que peuvent apporter de légères orientations un peu plus agiles obtiennent de très bon rendements. Il en est d'autres où les mêmes changements apportent moins que ce que l'on espérait : il faut alors savoir se poser les bonnes questions...
Il serait prétentieux de ma part de définir précisément les contextes où il est plus opportun d'agir de telle ou telle manière. Peut être un jour avec le recul... Je crois que c'est avant tout une question d'expérience, au sens "essayer quelque chose" et non pas "avoir de la bouteille". Quand une méthode de travail existante rencontre certains blocages, il me semble moins risqué de tenter de résoudre les blocages au cas par cas en essayant certains changements incrémentaux. D'ailleurs, n'est ce pas le propre de l'agilité que de procéder à petits pas aisément maitrisables et testables ?
Quand ces expériences de donnent pas les résultats escomptés, il faut passer à autre chose. Pour l'heure je fais donc mon deuil (temporaire) de ces incréments méthodologiques au profit d'une mise en place de Scrum.

Le premier obstacle qui apparait devant moi découle de ce que je viens d'écrire. Lorsque l'on est fermement convaincu que du Big Design Up Front ne marche pas pour concevoir un logiciel, comment se persuader que l'on peut faire débarquer quelque part une méthode de travail qui sera, au moins dans un premier temps, livrée clef en mains prête à appliquer ?
Un terreau dans lequel enraciner cette plantation me semble essentiel. Dans le cas qui me concerne actuellement, il prend la forme d'un sentiment collectif, plus ou moins conscient, que quelque chose ne tourne pas tout à fait rond, que depuis plusieurs semaines le travail n'avance pas aussi bien qu'il le devrait. Ce contexte favorable étant acquis, il ne me restait plus qu'à déployer la démarche, en 2 temps.

Dans un premier temps, j'ai proposé à l'ensemble des membres de l'équipe de faire une présentation de Scrum dans l'absolu. Dans un deuxième temps j'affinerai la mise en place en tenant compte des diverses spécificité du contexte que l'on ne peut ignorer.

En ce qui concerne la présentation de Scrum, j'ai tout simplement suggéré de visionner la présentation de Claude Aubry sur valtech-tv "Scrum, l'esprit d'équipe comme au rugby" (on trouve ici la 1ère partie et là la 2ème) et de compléter par une petite séance de questions autour de la mécanique de Scrum (toujours par Claude Aubry, unique fournisseur de ressources francophones de qualité sur le sujet).
Cette approche se prêtait bien aux points qu'il me semblait important de mettre en avant : le backlog comme référentiel unique accessible à tous et les réunions ciblées pour instiller la communication nécessaire.
Etant donné que nous sommes à Toulouse, je n'ai pas échappé aux remarques concernant l'analogie avec le rugby : la mêlée est un élément de construction des phases de jeu à venir mais elle n'en reste pas moins un outil de destruction dont l'esprit n'a que peu de liens avec le développement logiciel. Je dois avouer que je trouve moi-même tout cela un peu capilotracté. Le maul pénétrant me semblerait quelquefois un peu plus représentatif...

Le décor étant planté, il ne me reste plus, dans les jours à venir, qu'à adapter la démarche au contexte. Au menu :

• La distribution géographique des cochons implique une utilisation incontournable d'outils électroniques. Nous disposons d'un système de téléconférence relativement efficace qui, je l'espère, nous permettra de mener à bien certaines réunions de planification de sprint et certaines démonstrations et rétrospectives de fin de sprint.


• L'intégration dans un processus de production plus général et très orienté "production de documents" ne doit pas être un frein à la dynamique des tâches quotidiennes et à la progression du sprint.


• La non unicité du directeur de produit induit un niveau de concertation supplémentaire, tout particulièrement en ce qui concerne la gestion du backlog. Cette non unicité découle d'une organisation où plusieurs entités ont, légitimement, leur mot à dire sur le contenu. On y trouve le marketing produit qui décide de la stratégie et induit la démarche commerciale. On a aussi l'assurance qualité, représentant des utilisateurs dans un domaine médical fortement réglementé. On a enfin le support produit qui, en bout de chaîne, va assurer la bon fonctionnement du système chez les clients.

La mise en oeuvre de Scrum semble démarrer sur de bonnes bases. Comment cela continuera-t-il ? La suite des évènements fera peut-être l'objet d'un ou plusieurs autres billets dans les semaines à venir. S'il y a quelque chose d'intéressant à raconter...