Parlez-vous français ?

Après un premier article sur la méthode Agile, et 18 mois de pratique, il m’a été suggéré d’en écrire un peu plus. Je souhaite vous livrer quelques épisodes de mon quotidien. J’espère que vous en tirerez un éclairage, des pistes de réflexion ou des points de comparaison avec votre expérience personnelle. Pour moi, l’apprentissage de la méthode a commencé par tuer quelques termes et en apprendre de nouveaux.

Ton rôle là… Chef de projet. Et bien ça n’existe plus.

Il y a 7 ans quand j’ai commencé ma vie professionnelle, j’étais chef de projet web pour des grands comptes. Je formalisais le besoin du métier que je transmettais à la direction informatique. Les projets étaient longs, très longs, souvent en retard, souvent très chers, et puis parfois on se demandait si on était toujours dans la bonne direction, si on n’était pas passé à côté d’un besoin essentiel. J’ai appris des tas de techniques pour améliorer le taux de réussite, j’ai commencé à « avoir de la bouteille » comme on dit.

Et puis un jour on m’a dit :
– « maintenant, tu vas travailler en méthode Agile »
– « Ah bon c’est quoi ? »
– « Et bien déjà, ton rôle là… Chef de projet. Et bien ça n’existe plus. »
– « Ah bon ? Ça veut dire que je n’ai plus ma place dans les projets ? »
– « Tu vas jouer le rôle de Scrum Master.»
Voilà comment ça a commencé pour moi il y a un an et demi. Un mélange d’excitation à l’idée d’apprendre de nouvelles choses et une grande crainte de repartir à zéro…

Un nouveau lexique

Désormais tu vas oublier toutes tes habitudes, tes certitudes, tes rapports aux autres dans un projet et tu vas apprendre comment travailler différemment.

L’équipe : Tu vas désormais faire partie d’une seule et même équipe. Elle sera auto-organisée, sans hiérarchie. Elle sera composée de développeurs, d’un porteur du besoin (le Product Owner), d’un Scrum master et d’autres éventuelles expertises comme des architectes, graphistes, etc… Ah ! Et puis désormais, les développeurs sont tes amis. Vous faites partie de la même équipe.

Le Scrum Master : tu vas travailler sur le même plateau que les développeurs. Tu t’assureras qu’ils ont tout ce qui leur faut pour travailler dans les meilleures conditions, c’est-à-dire : le matériel adéquat, suffisamment d’informations sur l’objectif du projet, ses contraintes, le besoin attendu, etc … Tu aideras à lever leurs blocages et tu assureras le respect de la méthode.

Un sprint : tu travailleras avec l’équipe sur des périodes de 2 à 3 semaines de développement. A chaque début de sprint tu participeras à la planification du sprint (sprint planning) et l’équipe montrera rapidement ce qu’elle a réalisé en fin de sprint (revue de sprint) pour rectifier éventuellement les choix faits ou les futures priorités. Les itérations seront toujours de la même durée.

Le Product Owner : tu suivras le cap donné par le Product Owner, membre de l’équipe. C’est lui qui exprimera les facteurs-clés de succès du projet, la cible, les contraintes, les priorités et les fonctionnalités attendues (story). C’est lui qui fera l’interface avec les futurs utilisateurs et qui fera le tri dans ce qui est à faire maintenant ou plus tard. Il pourra changer d’avis entre deux sprints, avoir de nouvelles idées venant de lui, de l’équipe ou des stakeholders (sponsors du projet).

Les points de complexité : tu parleras beaucoup moins de jours-hommes avec tout le monde mais de points de complexité. Une échelle de points qui permet d’évaluer chaque story à partir des critères suivants : le temps de réalisation, la difficulté technique, la difficulté de mettre en place des tests automatisés, la connaissance du projet.

Les rétrospectives : à chaque fin de sprint tu organiseras des rétrospectives avec l’ensemble de l’équipe pour faire le bilan sur les points positifs et négatifs du sprint passé. Chacun aura la totale liberté d’exprimer ce qu’il ressent (« la clim est trop forte, on se caille sur le plateau ! », « le Product Owner rédige des story trop grosses, on met du temps à les livrer et on a peu l’impression d’avancer »).

Et tu verras, les gens se parleront plus, les applications seront livrées plus vites, on se rendra compte plus vite que le projet est en échec, on essayera de s’améliorer constamment…

L’importance de revenir sur les définitions, avec un peu d’expérience

Ce lexique prend tout son sens avec un peu de pratique. Il n’est pas exhaustif et porte essentiellement sur le vocabulaire de la méthode Scrum.
Je vous ai écrit en bas de l’article quelques liens vers d’autres interprétations. C’est intéressant de voir les différentes définitions de chaque auteur. Je trouve pertinent de les relire encore de temps en temps, pour vérifier que je ne m’éloigne pas du premier sens des choses.

Et vous qu’avez-vous pensé du vocabulaire Agile au début de votre expérience ?
Est-ce que vous vous êtes rapidement familiarisé avec ce nouveau langage ?

http://www.aubryconseil.com/post/2007/07/17/262-glossaire-scrum
http://www.scrumalliance.org/community/articles/2007/march/glossary-of-scrum-terms
https://www.scrum.org/Resources/Scrum-Glossary
http://www.scrum-breakfast.com/2013/02/scrum-glossary-62-scrum-related-terms.html