L'acrobate et la sentinelle - Petit guide de l'agilité en milieu hostile
Le 08 juin 2016
« La flèche a déjà atteint sa cible avant d'avoir laissé l'arc. » - Zen
I have a dream...
Dans ce monde idéal, le codeur développait en toute tranquillité content d'éprouver sa pure technicité, le métier exprimait sans conséquence ses besoins au gré du déroulé projet, la finance découvrait chaque jour que dans un même périmètre budgétaire, de plus en plus de fonctionnalités étaient embarquées. Niveau direction, les tableaux de bord de pilotage des différents ratios restaient d'un vert immaculé.
Et enfin, le client, non content d'être devenu 'customer centric' était heureux et insouciant.
... Focus sur une sonnerie de réveil très désagréable...
Le monde n'est pas parfait
L'agilité aurait peut-être une chance d'approcher cette vision idyllique mais la perfection est rarement au rendez-vous.
Ces méthodes apportent évidemment une réelle capacité à paralléliser et à fluidifier son projet. Elles permettent une meilleure gestion des changements et l'amélioration de la communication entre entités. Enfin, elles tendent à impliquer plus grandement vos équipes. Ce qui n'est déjà pas mal !!!
Mais pour que ces attendus s'expriment sans nuire à la réalisation de vos objectifs, il est nécessaire de faire preuve de rigueur et de ne pas oublier un certain nombre de fondamentaux propre à la gestion de projet. Partant du principe que dans votre pratique de l'agilité, vous tomberez inévitablement sur des impondérables, il n'est pas inutile d'avoir son petit guide de survie dans la poche. Sans parler d'une hostilité avérée, il est encore une fois rare d'évoluer dans un monde aussi parfait que le décrivent les manifestes des méthodes agiles.
Une dose de pragmatisme et de bon sens ne seront alors pas de trop pour jouer d'une part les acrobates face à des positions de principes et d'autre part les sentinelles afin d'atteindre votre seul objectif véritable : livrer le projet dans les métriques sur lesquels vous vous serez engagé. Vous endosserez alors l'un de ces deux rôles en fonction de la situation.
Le périmètre du projet
« Bon, on ne sait pas encore quel est notre offre, mais allons-y ! »
Agile ne signifie pas magique, elle ne se substituera pas à l'objectif recherché. En revanche, elle peut être un accélérateur pour emporter l'adhésion de votre client ou de votre équipe en par exemple, proposant un prototypage rapide et visuel de maquette et en éclairant les zones d'ombre et d'incertitudes. Et puis si vous n'avez pas d'équipe technique immédiatement disponible, il existe nombre d'outils de maquettage ou de prototypage permettant de modéliser un parcours client, une application mobile ou un site web.
C'est une bonne façon de procéder qui vous permettra de lever le flou chez vous ou chez le commanditaire. Concrètement, elle vous permettra de répondre aux questions suivantes : Quel est le périmètre du projet ? Ai-je bien compris l'ensemble des aspects ? Les champs d'action sont-ils bien définis ? La complexité est-elle de mise avec mon expérience de conduite de projet et les délais demandés ?
Le démarrage de projet
« C'est le jour J. Go go go ! Au fait je push sur quel repository ? »
Le déploiement d'un contexte agile sur un nouveau projet sera d'autant plus simplifié que votre environnement sera mature. En quoi cela consiste ? Un outil de suivi de projet, un gestionnaire de version, un environnement de recette honnête et un processus de mise en production bien établi.
Si ce n'est pas le cas, prévoyez une phase en amont durant laquelle vous définirez vos outils et la façon dont s'articulera l'ensemble de votre projet. Ce cadre permettra aux équipes de prendre d'autant mieux possession de leur projet. Peu à peu, vous goûterez aux vertus de l'intégration continue et vous vous dirigerez lentement vers les notions d'usine logicielle et de qualité.
Le 'refactoring'
« Déjà trois sprints et trois refontes majeures de code… »
Pour peu que vous tombiez sur un intégriste de l'agilité, il y a fort à parier que ce dernier vous tiendra le discours suivant : inutile de mener une analyse poussée à la vieille école telle que le partitionnement des modules, le modèle de donnée, etc. Avançons (c'est à dire codons), il sera toujours temps de faire les modifications en fonction des difficultés que nous rencontrerons. Inutile de dire que sur un grand projet, ce type de fonctionnement conduit à des dérapages. Et pourtant, c'est une évidence : un bon projet, c'est un bon départ. Et un bon départ, c'est non seulement un environnement de développement et de projet bien calé mais également une analyse technique poussée en relation avec un métier solide.
Affirmer le contraire, c'est suicidaire.
Donc, ne cédez pas aux sirènes de l'agilité et du on verra plus tard... Visualisez votre roadmap projet. Planifiez vos étapes techniques et définissez les jalons importants. Soyez une sentinelle !
Le client
« Messieurs, tout est ok. A dans six mois ! »
Si les trois premiers points étaient normalement adressables à votre seule main, ce point de non-participation dans un contexte agile est important. Il peut être d'autant plus problématique si cette absence est du fait de votre client qui a bien entendu compris que vous pouviez être souple sans pour autant vous fournir les éléments de projet dont vous aviez besoin. Alors, comment faire ?
- Voire les gens. Vous synthétiserez les questionnements qui auront agités la task force que vous aurez mise en place
- Utiliser les Comités en prétextant le nécessaire suivi du projet et en plaçant des noms évocateurs (Pilotage, Cadrage, Développement, Produit) selon les personnes visées
- Communiquer synthétique et large et balayer les avancées, les points de vigilance et les prochaines étapes
L'ego
« Le groupe, c'est moi. »
L'une des grandes forces mais également faiblesses de l'agile est de se fonder sur le groupe. Le fabuliste Esope n'est pas loin. Et c'est à vous de gommer les effets individuels pour mettre en avant le collectif. Vous le premier.
- Etre vigilant à l'effet « bouc émissaire » qui peut surgir lors des phases contraintes du projet. Accompagner, écouter et démontrer l'utilité de chacun
- Composer avec les personnalités fortes constituera une jolie source de réflexion la nuit. Oui, vous aurez peut-être à intégrer dans votre projet LE spécialiste rexx sur 3270 doté d'une expertise à la hauteur de son fichu caractère
- Le cas échéant, vous pouvez créer des îlots au sein de votre espace projet, voire prendre la décision de ne pas intégrer la personne dans le stack projet et de le solliciter en mode consultant. Cela fera autrement plus de boulot mais si le groupe s'en sort moins crispé, vous serez gagnant
Les rituels
« Pas de post-it, pas agile… »
De même que pour le ‘refactoring' où certain pouvait être amené à tenir un discours aux antipodes de la gestion de projet (mais très raccord avec la théorie de l'agile), ce n'est pas parce que vous ne tiendrez pas de ‘Daily Scrum' ou que vous n'organiserez pas de ‘Planning Poker' que vous n'aurez pas une démarche agile. En revanche, vous forcez à adopter tel ou tel rituel peut très bien vous amener à échouer dans la mise en place d'une démarche agile.
Rappelons-le, votre objectif principal est simple, terminer le projet. C'est ce qui vous est demander. Et vos objectifs secondaires en recherchant à insérer de l'agilité sont triples :
- Accepter les évolutions pendant le projet
- Améliorer la communication entre service
- Impliquer votre équipe par le jeu de la participation
En conséquence, si l'organisation d'un petit déjeuner 'étendu' le lundi matin vous permet de répondre à ceci, ne vous en privez pas. Et si vous n'éprouvez pas le besoin de décorer vos murs de post-it coloré, ce n'est pas si grave...
Le chiffrage & le planning
« Elle va me coûter chère ma voiture ? Et quand est-ce que je serai livré ? »
Vous aurez à vous engager et à jouer les acrobates pour traduire les résultats de vos 'planning poker' et 'backlog' en espèce sonnante et trébuchante face aux sentinelles que seront au choix votre contrôle de gestion, votre client, votre responsable (rayer les mentions inutiles). Quelques facteurs vont vous aider à tomber juste, c'est à dire dans une fourchette de 10%.
- Prendre en compte votre expérience propre de développeur ou de chef de projet. S'appuyer sur le ressenti des équipes au moment des sessions quotidiennes
- Déterminer le degré de « souplesse de votre projet » ; en quoi cela va consister, à déterminer si en scénarisant des problèmes (perte d'une ressource, accroissement de la complexité, oubli d'un point d'architecture ou d'une étape particulière) les métriques restent globalement dans les clous
- Mesurer l'enchainement des ressources par rapport à ce qu'il faut produire. La traduction des n-sprints en diagramme de Gant pourra faire hurler les puristes du scrum, mais il n'en demeure pas moins que c'est une bonne façon de vérifier que « cela colle »
Il vous sera alors facile de traduire ces éléments en tableaux d'avancement classique et budgétaire.
Les fournisseurs ou partenaires
« Nous on travaille proprement »
Ah, ah, nous aussi. Ceci dit la question des processus et de la manière dont travaille votre fournisseur ou votre partenaire est critique dans le bon déroulé de votre projet (autre société, autre service, etc.) Est-il sur les méthodes agiles et avec la même maturité que vous ? Si oui, vous parlerez la même langue. Dans le cas contraire, il faudra adapter la manière dont vous allez communiquer avec lui selon la typologie de votre fournisseur. Sont-ils sur du cycle en V ? Cela vous imposera des relectures de spécifications plus complètes et des livraisons mieux calibrées (ce qui ne veut pas dire que vous, en interne, vous abaissiez votre rythme de livraison)
Quelle est la signification des recettes pour lui ? Technique, métier, pré-production. Autant de points à évaluer correctement sous peine de déclencher des crispations, des retards, des incompréhensions.
La livraison
« Cela ne marche pas… Je ne comprends pas, chez moi c'est ok. »
L'étape de livraison est critique car elle va déterminer le ressenti de vos premiers utilisateurs testeurs. Il est obligatoire d'y penser très en amont du projet. J'aurais tendance à dire que dès que vous atteignez un niveau d'application suffisant, vous devez entamer et caler votre processus de livraison.
Cela impliquera de penser mise à jour et industrialisation de vos processus. Vous éviterez de livrer dans l'urgence, de découvrir un nombre de paramètres codés en dur dans les programmes, de demander des ouvertures de flux auprès de vos partenaires.
En procédant suffisamment tôt, vous ancrerez votre agilité dans un processus industriel et à cela, c'est un grand bravo !
La production
« Connaît pas... »
Vous avez livré dans les temps, bravo ! C'est l'aboutissement d'un jeu collectif et le commencement d'une nouvelle phase de la vie du projet.
Vous devez désormais gérer l'intégration des remontés clientes, la gestion des différentes mises à jour et des possibles régressions, l'application des changements dans un contexte où votre applicatif ne peut pas forcément être stoppé.
Ce sera alors également à votre agilité de passer en production. Vous l'aurez outillée par les mécanismes de priorisations, la réalisation de tests, la consolidation de vos processus de livraison.
En une phrase : l'agilité dans la vraie vie.
Finalement c'est quoi un projet
En un mot : Cadrage. Cadrage de l'environnement technique, cadrage du métier, cadrage des ressources et enfin cadrage du déroulé de projet. Cette étape vous permettra non seulement de définir la base sur laquelle vous déploierez vos actions mais et surtout d'évaluer votre capacité à adresser le changement en cours de projet.
Et c'est bien là finalement la nouveauté, votre analyse devra prendre en compte la possibilité que surviennent des changements : changement dans les interfaces, dans les données, dans les parcours clients, etc...
A partir de là, vous aurez dressé vos fondations et vous pourrez sereinement naviguer au gré des vents, que ces derniers soient tourbillonnants et rapides ou de simples petites brises sans grandes conséquences. Et plus que tout, vous aurez la maîtrise du temps de votre projet.
Vous serez l'acrobate et la sentinelle...