Mieux vaut passer du temps pour s'accorder avec les parties prenantes à la naissance de l'équipe que de s'apercevoir plus tard qu'on n'est pas alignés.
Après la première journée (et la soirée) ensemble, les coéquipiers se retrouvent pour s’aligner avec les parties prenantes.
Le secret d'une vision commune : partir de la vision du sponsor, en tirer la mission de l'équipe et en déduire les objectifs de la prochaine saison. Faciliter sa construction avec des ateliers et faciliter son partage en présentant tout cela sur la charte projet.
Je viens de préparer et animer en équipe (un merci spécial à Violaine) deux sessions d’une demi-journée sur comment la facilitation peut aider à obtenir une vision partagée. L’occasion pour moi de revenir sur cette notion — la vision partagée — sur laquelle, comme beaucoup, j’ai évolué sur le “résultat” attendu et sur la façon de l’obtenir.
Un outil pour se poser des questions sur la capacité de l'équipe à vivre ensemble, et à s'accorder avec ses parties prenantes.
Quand une équipe va au fond des choses, rencontre des obstacles ou subit des conflits, cela est souvent dû à des désaccords enfouis, qui remontent à l’occasion.
Ce décalage entre les coéquipiers, ou entre l’équipe et son environnement, porte soit sur des valeurs, soit sur une vision du produit à faire, soit sur la façon de travailler ensemble.
Comment y remédier ? En prenant un peu de temps pour discuter des points de vue et trouver un équilibre permettant de travailler en symbiose. L’outil support à cette recherche d’alignement, qui peut servir de charte projet, c’est un canevas, le CARE.
Le Raid #4 tirait à sa fin. Luigi s’est approché de moi et m’a fait part d’une légère frustration :
je pensais que nous parlerions plus de vision en ce 3e jour.
Vision ?
Le chapitre 13 de mon livre Scrum s’appelait “De la vision aux stories” dans les deux éditions précédentes. Dans cette nouvelle édition, il devient “De la vision aux features”, les stories ayant été poussées dans le chapitre suivant.
Il a été presque entièrement réécrit, pour incorporer les nouveaux outils du Product Owner, ceux que j’ai présentés le mois dernier lors du ScrumDay 2014.
Les notions manipulées pour aller de la vision à la story, avec quelques techniques de définition de produit pour y arriver.
Ce quadrant montre 5 outils et 6 concepts situés dans 4 cases.
Billet dédié tous ceux qui s'intéressent à l'Impact Mapping
Je présente l’utilisation de l’Impact Mapping comme une technique permettant d’aller de la vision aux fonctionnalités (features). Dans toutes mes interventions au démarrage d’un projet, je la fais mettre en œuvre avec les parties prenantes et les équipes.
Vous aimez bien les jeux agiles, mais, comme fierfeu qui l’a mis en commentaire sur le billet de la formation de janvier, vous voulez savoir si on peut les articuler.
Pour définir la vision et d'arriver rapidement à la constitution du backlog initial
Mes amis Fabrice et Alex parlent ces jours-ci, sur leur blog, des jeux collaboratifs qu’on peut faire avec les clients pour créer des produits innovants. Ces jeux sont excellents en coaching.
Utilisés pendant les formations, ils sont aussi très efficaces pour apprendre, en pratiquant par petits groupes. A partir des Innovation Games de Luke Hohmann cités par mes camarades, mais aussi avec d’autres inspirations comme Mike Griffiths, j’ai adapté plusieurs de ces jeux pour les faire rentrer dans le cursus de ma formation de 3 jours.
J’ai donné mes premières formations il y a déjà quelques années et c’était sur les méthodes les plus populaires[1] de l’époque : SADT et SA/RT.
Dans SA/RT le premier diagramme réalisé était le diagramme de contexte, et dans SADT on faisait souvent l’équivalent appelé, autant que je me souvienne, diagramme A-1.
En ces temps-là, j’en ai réalisés de nombreux, pour définir le contexte d’un système ou d’un logiciel. Puis les méthodes objet sont arrivées. Avec la méthode Fusion, qui me plaisait beaucoup, il y avait l’équivalent. Pas avec OMT.
L’enseignement des méthodes agiles, du développement agile ou plus largement de l’agilité, c’est une réalité.
C’est vrai pour des universités à Toulouse, mais sûrement aussi pour beaucoup d’autres ailleurs.
Vendredi, la première session du SigmaT15 portait sur l’enseignement de l’agilité dans deux facs de Toulouse (Toulouse 3 à Rangueil, la fac de Sciences, et Toulouse2 plus l’IUT de Blagnac). Dans chacune, plusieurs filières sont concernées et les enseignants ont fait un bilan de de ce qui est enseigné, parfois depuis plusieurs années.
Ce matin, je donne ma troisième séance de 4 heures de cours aux étudiants de master. Au programme, comment aller de l’idée du produit à la constitution du backlog initial, donc sur la vie du produit avant les sprints. Avec des ateliers en groupe, nous verrons comment construire une bonne vision, élaborer une liste de features, identifier les rôles d’utilisateurs et décomposer les features les plus prioritaires en stories.
Dans nos métiers, une vision est l’expression d’une volonté collective de développer un excellent produit. Une vision doit être ambitieuse pour entraîner les énergies et donner un élan, tout en restant réaliste.
L’absence de vision limite la capacité de l’équipe à s’investir dans un projet.
J’étais samedi au match Toulouse-Brive (38-0). Les joueurs du Stade étaient motivés malgré la chaleur. La vision d’un club comme le Stade Toulousain est donnée en début de saison (comme l’est la vision d’un produit en début de release).
En complément au billet du JC, mon camarade blogueur de Quality Street, sur l’intérêt d’avoir une bonne vision, je joins un plan type avec guide de rédaction, au format OpenOffice.
Comment s'y retrouver ? Que met-on dans le backlog ?
Pour une fois je vais utiliser les termes anglais[1].
Puisque vous fréquentez ce blog, vous devez savoir ce qu’est une story et ce qu’est un backlog (de produit), deux éléments de base dans l’application des méthodes agiles. Mais il y a d’autres termes utilisés couramment dans la gestion agile des exigences.
