L’Agilité en mandat : être agile, ça veut dire quoi exactement ?
Indéniablement, l’agilité est un concept dans l’air du temps. Comme beaucoup, vous en avez entendu parler, vous avez peut-être même vécu l’expérience lors de ces courtes réunions quotidiennes où vous devez être debout.
Vous vous questionnez toutefois à savoir s’il ne s’agit pas d’un phénomène dont tout le monde parle, sans jamais l’avoir vraiment vécu ? Votre équipe clame travailler en agilité, mais vous cherchez l’évolution (ou la révolution) au sein de votre quotidien professionnel ?
Cette introduction vous interpelle, cette série d’articles sur la culture Agile est pour vous !
Pour ma part, je ne revendique aucune expertise agile, j’ai simplement la chance de faire partie d’un mandat qui expérimente l’agilité.
C’est donc une photographie en cours de révélation que je vous propose, en commençant par l’illustration concrète des bases de l’agilité.
Être agile, ça veut dire quoi exactement ?
Aucune ambiguïté dans la réponse puisque l’agilité est un concept clairement défini : le manifeste qui en définit les valeurs et principes date de 2001.
La vocation de cet article n’étant pas académique, je vais me contenter d’en résumer l’objectif ainsi : développer et livrer une valeur d’affaires de manière itérative et transparente par des versions fonctionnelles de plus en plus abouties d’un produit.
Les bénéfices des livraisons itératives (on parlera de sprints) ne sont plus à démontrer, quelques-uns parmi tant : transparence, installation d’une dynamique de collaboration, réactivité, fluidité des échanges d’information, etc.
Mise en pratique : tout un défi !
La méthode Agile s’appuie sur la responsabilisation des acteurs, ainsi, l’équipe Agile définit une liste de fonctionnalités du produit et s’engage formellement à la livrer à l’issue du sprint.
Un sprint dure entre 2 et 4 semaines (3 dans mon cas), un facteur qui peut être générateur de stress pour une équipe encore en recherche du « rythme acceptable et maintenable » prôné par la méthode.
Toutes les 3 semaines, vous devez livrer !
La mise en place d’itérations courtes nécessite également d’adapter nos habitudes de travail et de gestion de projet. Ce qui est tout un défi !
Par exemple et contrairement au développement en cascade, les sprints débutent généralement avec une documentation partielle des fonctionnalités à livrer : on n’attend pas la fin de la phase d’analyse pour passer en réalisation.
Seules les fonctionnalités jugées plus complexes font l’objet de spécifications par écrit à l’intention de l’équipe de développement, les autres étant transmises oralement.
Ce qui implique une bonne communication au sein de l’équipe et une stabilité des ressources pour garantir la capitalisation des connaissances.
Les promesses de l’agilité et les défis liés à sa mise en place constituent assurément un challenge séduisant. D’ailleurs, ci-dessous, je vous présente l’équipe Agile.
L’équipe Agile
Cette célèbre illustration traduit bien la répartition des rôles des intervenants dans un projet Agile : des acteurs impliqués dans le projet (les poulets) et des acteurs directement responsables de la réussite ou de l’échec du projet (les cochons).
Les premiers interviendront sur des portions réduites du projet tandis que les seconds constituent le cœur de l’équipe Agile. Ils sont dédiés au projet à 100% : ils produisent la valeur à chaque itération.
Dans la pratique, de cette répartition découle l’organisation quotidienne du projet : qui participe à quelle réunion ? À qui rendre compte ? Qui prendra les décisions stratégiques en cours de projet ? etc.
Sur un projet informatique, les parties prenantes, les architectes, les concepteurs sont des poulets, le Product Owner (PO), l’équipe de développement, le Scrum Master sont des cochons.
Le Product Owner (PO) : il joue un rôle central dans le dispositif Agile. Issu des secteurs d’affaires il fait l’interface entre les clients du produit et l’équipe de développement. Il détient la connaissance du produit et est capable de définir, d’estimer et de prioriser les fonctionnalités à livrer. À ce titre, il est le seul donneur d’ordre pour l’équipe de développement et est dédié au projet.
Visualisez ce profil dans votre contexte en mandat et imaginez que votre client le dédie à 100% à votre projet. Non seulement lui, mais aussi toute l’équipe de développement ! Ça signifie : pas de multi projet, pas de continuité, pas de support à la production en parallèle du projet… Vous comprenez maintenant une des difficultés de la mise en place de l’agilité.
Le Scrum Master : il est le gardien des bonnes pratiques et du respect des méthodes Agiles. Il n’a pas d’autorité sur l’équipe, mais intervient pour la guider à chaque étape du sprint. Concrètement il pourra interroger l’équipe : « Le temps restant est-il à jour dans vos tâches ? », « Pensez-vous atteindre les objectifs du sprint ? », « Quelle stratégie adopter pour sécuriser la prochaine livraison », etc…
Entre autres, il met en place la réédition au bureau de projet et anime également les rituels Agiles que je vous présenterai dans le prochain article de cette série. La suite de cet article sera publiée en janvier 2018. Suivez-nous sur LinkedIn pour ne rien manquer !