Apprendre à parler Agile

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

Ne ratez plus nos événements !

Pour ne rien rater de l'actualité GIW, inscrivez-vous à notre newsletter. Promis nous ne vous inonderons pas d'envois, seulement l'essentiel.

Nous ne spammons pas ! Consultez notre politique de confidentialité pour plus d’informations.

8 réponses

  1. Très intéressant !! Ca parait presque magique comme méthode.. Derrières les notions et les termes un peu barbares, on sent surtout qu’il y a la valorisation d’une équipe et de potentiels humains..
    Mais une méthode Agile comme celle-là est-elle transposable sur tous les types de projet, j’entends hors-informatique-technique? Sur des projets web éditoriaux (stratégie, rédaction de contenus, animation, etc.) on pourrait appliquer ce type de méthode ?

    1. Bonjour,
      et merci pour ce commentaire !
      A titre perso, j’ai été Product Owner (mais j’avais certaines des attributions du Scrum Master, notamment dans la gestion de l’équipe, et le côté “tampon” vis-à-vis de l’extérieur) plutôt axé marketing.
      Je pense que tout projet peut se traiter en mode Agile, mais le principe de deadline peut apparaître comme problématique : la méthode Agile étant itérative, et en amélioration continue, il est assez difficile de donner une date précise.
      Néanmoins, il est tout à fait possible d’intégrer certains points de la méthode comme notamment le tableau des avancées pour toute l’équipe (sur un paperboard divisé en 3 colonnes : “TO DO” / “WIP” / “DONE” chaque personne pose ses tâches et tout le monde voit les progrès), les micros réunions du matin pour savoir comment la journée va s’organiser et les réunions hebdos sur l’ensemble des tâches en général et ce qui peut être amélioré la fois d’après.
      La communication est à la base de tous les échanges humains et une communication fluide est un facteur de succès dans le milieu professionnel : la méthode Agile est donc un moyen simple et terriblement efficace d’améliorer l’ambiance et la productivité dans une structure, quel que soit son sujet.
      My 2 cents 🙂

  2. Alors oui et non. La question n’est pas de savoir si tout les projets peuvent se faire en agile, mais plutôt de savoir si toutes les équipes sont prêtes à fonctionner en agile.
    J’ai personnellement mené de nombreux projets forfait en mode agile (en Scrum pour être précis) et ce n’est pas la méthode qui n’est pas adaptée à la notion de deadline (Scrum n’est pas Kanban loin s’en faut), c’est le plus souvent la façon dont on adapte Scrum à son besoin.
    Car finalement il ne faut jamais oublié une chose fondamentale : Srum n’est qu’un ensemble de recommandations, ce n’est pas comme PMP ou PRINCE des méthodes à suivre à la lettre, il faut savoir implémenter certaines recommandations de Scrum et en laisser d’autre de côté.
    Ceci dit il est évident que seule la gestion de projet ne doit pas être agile, le cycle complet de vente doit l’être. Dans le cas contraire, il est évident qu’un projet borné, chiffré et vendu comme du cycle en V mais réalisé en agile aura toutes les chances de mal se passer ou de donner des sueurs froides aux PO/SM/Devs…
    Une borne temporelle nécessite il est vrai un PO de compéte’ si vous me passez l’expression 😉

    1. Je suis bien d’accord avec toi Arnaud, il faut que les équipes soient prêtes et OK, mais surtout formées réellement à la méthode (ce qui est loin d’être le cas partout).
      Scrum en particulier et l’Agile en général étant à la mode, tout le monde s’y met (et le plus souvent un peu n’importe comment).
      Les résultats peuvent donc paraître décevants car d’une part, les membres de l’équipe n’auront pas voulu jouer le jeu, et surtout, comme tu le dis très bien, bien souvent le reste de la chaîne n’est pas au courant, informée des spécificités de l’itératif.
      Ca coince donc à un moment, et c’est Agile qui prend.
      J’ai eu l’occasion d’imposer des deadlines très serrées à mes équipes en tant que PO pour certains projets : ça n’a fonctionné que parce qu’une relation de confiance s’était établie entre nous et qu’ils savaient bien (la fameuse fluidité de l’info) que nous n’avions pas d’autre choix.
      Et c’est très vrai ce que tu dis sur le fait que Scrum n’est qu’une recommandation : elle donne un cadre qu’on peut (doit, en fait) adapter à son besoin.
      Mais pour faire ça, il faut quand même connaître la doxa de la méthode, sinon, ça peut vite devenir le chaos.

      1. ça nous sommes d’accord !
        Bizarrement il faut toujours à un moment que ceux qui font soient les sachant… Bonne nouvelle pour nous, nous ne sommes pas encore inutiles 😉

  3. Bonjour,
    Je suis en phase avec l’article et les commentaires apportés.
    Les points clés pour moi sont :
    – formation de l’équipe : comprendre quel est son rôle dans le projet mais aussi le rôle des autres membres
    – communication et transparence (dans la mesure du possible)
    – une cohésion d’équipe et un coordinateur fédérateur
    – mais pour moi le plus important, restera toujours la définition du besoin par le client !! ça évite les retours en arrière, les changements de cap en cours de route, les corrections et limite les anomalies par la suite …. Le scrum master joue également un rôle important ici, il doit guider le product owner et savoir dire non ou annoncer directement les décalages, alertes ….
    Il faut aussi s’assurer que le projet peut supporter un mode agile, je pense aux réglementations bancaires pour lesquelles des deadlines imposées ne peuvent attendre.
    Enfin bref, il ne faut pas se laisser déborder par des termes, suivre ses intuitions et ne pas se laisser stresser ! Gestion de projet quoi 🙂
    Bonne journée

  4. Merci pour vos commentaires, que je découvre avec plaisir à mon retour de congés 😉 ! J’ai d’autres sujets sur la méthode Scrum que j’aimerais partager et je suis ravie de voir que les lecteurs de GIW ont de l’expérience et des choses à dire !
    Pour ma part, je n’ai encore jamais eu l’occasion d’introduire une méthode Agile dans d’autres contextes que des projets informatiques. Enfin… J’essaye depuis un mois de gérer mes tâches du quotidien avec un kanban perso. Ce sera sûrement un de mes prochains sujets.
    Je pense que, avant de vouloir à tout prix appliquer une nouvelle méthode (c’est vrai que les méthodes agiles sont à la mode), il faut déjà pendre du recul et regarder comment fonctionne son équipe ou son entreprise. Tournez-vous vers de nouvelles méthodes si votre façon de travailler actuelle ne convient pas. Si les mêmes erreurs se reproduisent, si les échecs se multiplient, si l’ambiance est mauvaise.
    Après il faut se donner les moyens de faire adhérer tout le monde comme vous dites !

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *