Un aspect intéressant de Scrum réside dans la parole donnée aux développeurs. Lors des démos, par exemple.
Au fur et à mesure des sprints, nous nous sommes améliorés, pour avoir maintenant un schéma de démos assez satisfaisant.
Peu de temps après la constitution du sprint à venir, j'envoie un email d'invitation à la prochaine démo, à destination d'un cercle de plus en plus étendu. C'est le fameux concept du cercle d'influence de Stephen Covey, que l'on agrandit au fur et à mesure, à condition d'avoir su monter à l'intérieur de soi-même une organisation solidement fondé sur des principes. Ces principes, j'en ai quatre, les quatre principes de l'Agile Manifesto. Donc, pour en revenir à mon "carton d'invitation", je l'envoi au Product owner et responsables métier, responsables utilisateur, maîtres d'ouvrage, responsable organisation et gestion du changement, directeur des systèmes d'information, responsable des études informatiques, chefs de projet, développeurs d'autres équipe, graphistes, etc... Cela peut sembler au départ beaucoup de monde, mais avec l'expérience, je sais qu'en moyenne une personne invitée sur deux ne peut pas venir.
Dans ce "carton" électronique, je liste les différentes user stories sur lesquelles l'équipe s'est engagé lors du sprint à venir. ET pour chaque user story, je précise ce qui sera présenté lors de la démo : celà peut être un modèle de données, des flux d'alimentation de tables en présentant l'avant et l'après, tables vides et tables remplies, un site web, des web services avec dans ce cas, différents type d'appel, nominaux, avec erreur gérée, ...
En générale, nos démos ont lieu le vendredi après-midi. Le matin, je fais donc un point préparatif de la démo avec l'ensemble de l'équipe. On définit qui présente quoi, comment, si plusieurs écrans sont nécessaires, on s'entend sur quelques scénarios, de manière à mettre en scène le travail effectué pendant le sprint.
Lors de la démo, je laisse mes invités debout! avec quelques chaises à disposition pour qui veut s'asseoir. Cela donne un peu une ambiance cocktail, les échanges sont plus fluides, les discussions plus actives.
Je prends la parole en entrée de la démo, pour souhaiter la bienvenue aux participants et les remercier de leur présence, puis je rappelle le contexte du sprint àà l'intérieur du projet, ses attendus, ce qui a pu être réalisé, et le cas échéant, ce qui n'a pas pu l'être. Je donne ensuite la parole à l'équipe, selon les scénarios définis le matin. Souvent, on s'en éloigne un peu, parce qu'un participant pose une question complémentaire par exemple, qu'une règle métier est précisée...
Parfois, j'interviens lors des présentations effectuées par l'équipe, si je sens qu'on oublie quelque chose, ou qu'une précision doit être donnée, mais j'évite d'intervenir trop souvent. C'est le travail de l'équipe, pas le mien. Je suis responsable de la méthode, pas de la production des développements. C'est aux membres de l'équipe de s'exprimer sur leurs productions. Et cela fonctionne plutôt bien.
Pour en revenir à l'idée principale de ce billet : la parole donnée aux développeurs, je remets en comparaison ma propre situation lorsque j'étais jeune développeur. En tant que développeur, je n'avais guère la parole. Seuls les chefs de projet communiquaient avec les clients ou les demandeurs. Et lorsque l'on passait de développeurs à chef de projet, on se retrouvait brutalement installé à de grandes tables de réunion, entouré de responsables opérationnels métier et de directeurs, terrorisé à l'idée même de sortir le moindre son.
Aujourd'hui, avec les démos, les développeurs s'habituent dès leur premier projet, à prendre la parole, à exposer leurs travaux, à communiquer... et lorsqu'ils deviendront à ler tour product owner ou scrum master, ils auront déjà derrière eux cette expérience de prise de parole.
Tout à fait d'accord!!!
Rédigé par : jeremy | lundi 01 septembre 2008 à 09:38