Coach agile, Pascal Poussard nous livre son FeedBack de L’Agile France 2014 :
Encore une fois, l’équipe organisatrice de l’Agile France nous a régalés avec une superbe édition : un programme de qualité, le cadre toujours aussi bucolique du Chalet de la Porte Jaune et une foule de gens biens se distribuant des sous-rires. Je retiendrai particulièrement le retour d’expérience osé de la keynote de fin.
Cette année, c’est la session de JEAN-CLAUDE GROSJEAN et de GUILLAUME DUQUESNAY sur le cadrage de projet Agile qui m’a le plus surpris et que je voudrais vous partager ici.
Comment cadrer une conférence agile ?
Le début a été un peu difficile puisque Jean-Claude et Guillaume avaient la lourde tâche de commencer la série de sessions et qu’ils ont pu ainsi essuyer les plâtres de la logistique.
C’est donc sans lumière, sans rétroprojecteur, sans micro et avec un peu de retard qu’a débuté la conférence. Et je dois bien admettre que malgré ces difficultés et les nombreuses interruptions d’un public passionné, notre duo de choc s’en est plutôt bien tiré.
Pourquoi cadrer un projet ?
La première question qui vient à l’esprit est : pourquoi avoir besoin de cadrer un projet et plus précisément est-ce que tous les projets en ont besoin ? La réponse de Guillaume et Jean-Claude est claire : oui c’est nécessaire.
D’abord pour aligner tout le monde sur un objectif et partager la vision du projet.
Ensuite ce cadrage va permettre de se poser l’ensemble des questions qui font mal. Et l’important est de se poser ces questions dès le début, sans attendre le milieu du projet une fois tout le monde engagé. L’objectif ultime étant d’identifier les points les plus problématiques pour pouvoir décider de faire ou ne pas faire le projet. Cela dit, il ne faut pas non plus tomber dans l’excès de détails en cherchant tous les problèmes pouvant arriver. Il est indispensable de limiter ce cadrage dans le temps pour être efficace. Cette phase de projet ne doit pas durer plus d’un mois pour un gros projet et peut très bien se résumer à 2 demies journées pour des projets plus modestes. Il est très important d’adapter ce cadre au type de projet et à sa durée.
Pour enfoncer le clou, ils nous rappellent le principe du 60 / 30 / 10 mis en avant par Esther Derby qui renforce le rôle crucial du cadrage :
- 60% de l’efficacité d’une équipe se décide à la construction de l’équipe (avant son lancement)
- 30% au lancement
- 10% dans la suite du projet (après le lancement)
Des thèmes incontournables
Une fois ce cadre posé, Jean-Claude et Guillaume nous dévoilent leur liste des thèmes à aborder impérativement dans un cadrage de projet Agile selon leurs expériences . Cette liste n’est pas exhaustive mais est, pour eux, le minimum à aborder systématiquement.
Leur liste se compose des 6 points suivants :
- Enjeux et Vision
- Roadmap
- Architecture technique
- Organisation, Moyens et Budget
- Rôles et Responsabilités
- Risques
L’ordre n’est pas imposé, mis à part le premier et le dernier point. En effet, il est important de définir la vision et les enjeux en premier et de terminer par les Risques après avoir vu l’ensemble des autres points.
Et des Outils
Une fois cette liste posée, ils sont revenus en détails sur le but de ces différents points en proposant à chaque fois quelques outils adaptés.
Pour la vision, l’objectif est de résumer la raison d’être du projet. Pour se faire, il est impératif d’avoir les bonnes personnes réunies, celles capables de décider. En termes d’outils, les innovation games comme la Product Box sont particulièrement adaptés pour définir une vision. La technique de l’Elevator Pitch peut également s’avérer utile pour créer et résumer la vision.
Jean-Claude nous propose d’ailleurs un modèle de construction d’Elevator Pitch qu’il utilise sur ses projets
- Pour : Quels Clients ? Quels Personas ?
- Veulent : les fonctions principales souhaitées par typologie client
- Produit : le produit y répondant
- Qui va faire : les fonctions rendues
- A la différence de : le “plus” du produit et sa différence concurrentielle
Pour l’aspect Roadmap, je retiens qu’une Roadmap classique leur semble peu adaptée et qu’ils préfèrent largement la StoryMap qui permet de visualiser le projet en deux dimensions.
Pris par le temps, nous passons vite sur les questions d’architecture, rôles et organisation, plus classiques et pour lesquelles les outils principaux sont des réunions et des schémas.
Lors de la question du budget, un point très intéressant est abordé. Il n’est pas nécessaire, à ce stade, d’apporter trop de précisions. Nous en revenons à nos principes Agiles d’estimation par comparaison plutôt que des chiffrages absolus. Pour ma part, j’ai rarement vu des cadrages budgétaires basés sur des comparaisons de projets et cela me semble une excellente idée. Je préfère ce principe plutôt que d’essayer coûte que coûte de rentrer dans une enveloppe type (entre 400 et 800 jours).
Enfin, nous avons abordé la gestion des risques qui est un point majeur. Ils nous ont proposé une grille d’identification des risques à utiliser. Cette grille se présente comme suit :
| Risque | Probabilité | Impacts | Actions | |
| En % ou sur une échelle de 1 à 3 | Factuels, Identifiant la nature des impacts plus que les impacts eux même | Préventives ou Palliatives |
Il est important de ne pas avoir une liste à la Prévert mais de se limiter aux risques les plus importants et les plus probables. Une limite de 5 semble bien convenir. Sachant que la liste n’est pas figée et que pour chaque risque éliminé (s’il se concrétise par exemple en devenant un problème), un nouveau risque va prendre du galon et trouver sa place dans le top 5.
A emporter
En conclusion, je repars content de cette session en emportant avec moi une vision claire des étapes de cadrage de projet et une liste d’outils, connus ou non, adaptés à chaque points. Il me tarde de le mettre en place rapidement chez mes clients. D’ailleurs, il se pourrait même que ça arrive très vite.
