Agilité par contamination

Lorsqu'on souhaite mettre en oeuvre Scrum la première fois, il est souvent dit de mettre en place la totalité du framework et dans un second temps de l'adapter quand l'ensemble des acteurs possèdent le recul nécessaire (pour justement l'adapter favorablement). Cette mise en place totale a pour but de ne pas tomber dans les fameux "Scrum But", souvent cause de l'échec de la mise en place de Scrum. Les "Scrum But" pour simplifier représentent les entorses au framework (Exemple : c'est le ScrumMaster qui fait les estimations et affectent les tâches, oui ça c'est de la très grosse entorse ;-)).

Je vous propose ici de vous raconter un de mes retours d'expérience sur le sujet qui est très différent de l'approche dont je viens de vous parler.

Il y a bientôt un an, j'ai intégré une équipe de développement chez un éditeur logiciel qui ne pratiquait pas "l'agilité". Ce nouvel environnement me paraissait idéal pour mettre en place Scrum couplé avec un peu d’Extrême Programming pour plusieurs raisons :

• une petite structure (moins de 25 personnes).
• une équipe de développement de moins de 6 personnes.
• une forte croissance.
• la volonté de développer une nouvelle version d'un produit.

Il faut avouer que Scrum est très déroutant dans ces pratiques quand on ne les a jamais mises en oeuvre. Comme je ne m'appelle pas Jeff Sutherland (un des papas de Scrum) et que je ne suis pas un extrémiste (enfin j'estime ne pas l'être, ce qui est différent, je vous l'accorde), je n'ai pas forcé pour la mise en place de Scrum.

En revanche, je travaillais sur un sujet isolé et avec une liberté totale sur ma façon de travailler. J'ai donc fait du Scrum et de l'Xp seul (ok ce n'est pas vraiment du Scrum). Tiens ça me fait penser à Jean Jacques.

Hey hop, c'est parti, je récupère un tableau en carton, j'ai un mur juste derrière moi, impeccable,  ça sera mon scrum board. Un petit tour par la compta : "Heu, vous auriez des post-its? Ha, vous n'avez que cette couleur, ok ça ira très bien pour commencer. Vous pouvez en commander d'autres? et de plusieurs couleurs?".

Un ou deux jours passent...

Réaction 1 : "Ha c'est comme ça que tu travailles?"
Réaction 2 : "C'est jolie tous ces post-its derrière toi, c'est quoi, ça marche comment?"

Côté pratique d'ingénierie, pas d'intégration continue, pas de DVCS (en tous cas pas celui que je voulais :-)), pas de suivi de qualité, pas de déploiement continu. Ok, qu'à cela ne tienne, "Just Do It". C'est parti pour mettre en place une forge logicielle complète sur une machine virtuelle dans un coin de serveur (apache, jenkins, git, sonar, maven, ...).

Réaction 3 : "C'est quoi l'intégration continue?"

J'avais maintenant tous les outils que je souhaitais pour développer. C'est parti. Les semaines passent, les post-its s'entassent...

Réaction 4 : "C'est pas mal ton tableau avec les post-its pour voir l'avancement du travail"

A force de question et de discussion autour de Scrum avec l'équipe de développement, je me propose de leur faire une présentation de Scrum. C'est parti pour une présentation de 2h très conviviale. L'objectif est de faire découvrir les principes du framework. Rien de plus.

Réaction 5 : "C'est vraiment très différents, ça n'est pas du tout aujourd'hui notre façon de travailler, ça fait un peu peur"

Les semaines passent... et qu'est-ce que je vois sur le bureau du collègue à côté de moi, le livre "Scrum" de Claude Aubry. Je lui dis que c'est un super bouquin qu'il a bien fait de l'acheter.

Réaction 6 : "C'est ma compagne qui me l'a acheté car je lui avais parlé de la présentation que tu avais faite"

Alors là je suis scotché!

Les semaines passent... et un gros sujet à traiter par toute l'équipe nous tombe dessus. On ne sait pas par quel bout le prendre. Je propose aux membres de l'équipe qui connait le mieux le sujet de faire un mind map pour modéliser le travail à effectuer ainsi qu'une réunion tous ensemble où l'on ajuste le Mind Map pour tous obtenir une bonne vision de ce qu'on va devoir faire.  J'extrais ensuite le contenu du Mind Map dans un fichier Excel.

Réaction 7 : "C'est un peu comme un Backlog ce fichier Excel, non?"

Je l'ai ensuite renommé en "Backlog".

Réaction 8 : "Par quoi on commence?"

Je propose de refaire une réunion avec toute l'équipe pour qu'on priorise les sujets/tâches tous ensemble pour traiter les tâches les plus urgentes.

Réaction 9 : "On priorise tout, tout de suite?"

Je propose alors de faire un point tous ensemble toutes les semaines et de prioriser/reprioriser les sujets.

Réaction 10 : "On migre les applis existantes sur git"?

Yes!

Réaction 11 : "Comment on fait pour rajouter un Job dans Jenkins"?

Yes! Je te montre!

Les semaines passent... et je discute avec le directeur général. Il m'apprend qu'il s'est documenté sur Scrum et les méthodes Agiles qu'il trouve ça très intéressant et qu'il souhaite qu'on fasse des petites réunions tous les matins.

Aujourd'hui, nous ne pouvons pas dire que nous "faisons du Scrum" mais tous ce qui est mis en place nous aident réellement au quotidien. L'utilisation d'un backlog et la réalisation du Daily Scrum du matin sont maintenant une évidence. J'espère que cette démarche (non préméditée) de contamination va se poursuivre.

Alors que je pensais que Scrum ne pouvait fonctionner sur le principe du tout ou rien, je me rends compte que l'agilité progressive est un succès dans notre cas.

Vous en pensez quoi?