Scrum, Agilité et Rock'n roll

Vous avez plusieurs équipes qui font du Scrum et vous voulez garder une vue générale, plutôt que d'avoir des projets séparés. Voilà une façon simple de faire du "scrum de scrums".

Si mon livre a de bonnes critiques de la part de ses lecteurs, c'est en grande partie à mes relecteurs que je le dois.

J'ai reçu il y a quelques jours la 3ème édition du livre de Véronique Messager sur la gestion de projet agile.

Le scrum (ou mêlée) est une pratique très représentative de Scrum.

Je suis allé vérifier sur place.

Fête du travail

Souvenirs, souvenirs.

6 projets (sur 6) ont choisi Scrum

Ces derniers mois, la région Rhône-Alpes paraît avoir décollé sur l'agilité.
Un club d'agilistes s'est créé. Des blogueurs y apparaissent, comme Alex. Les étapes de l'Agile tour de Valence et Grenoble affichent déjà complet.

Des retours d'expérience y sont publiés, comme celui d'Emmanuel Chenu qui raconte les pratiques mises en place pour faciliter la communication dans son équipe.
L'article qu'il publie est plutôt bluffant quand on sait que cette équipe développe des logiciels temps-réel critiques embarqués pour l'avionique(ce que j'ai fait pendant plusieurs années dans ma vie de développeur).
Les pratiques sont illustrées avec des photos. Elles sont nombreuses : à côté des classiques, il y a en de beaucoup moins connues comme le niko-niko et le gizmo.
Un autre point intéressant est que l'équipe ne s'est pas contentée de suivre une méthode : les pratiques présentées viennent de Scrum, XP et Lean.

Bien avant de passer à Scrum, je faisais du processus itératif. J'ai encadré de nombreux projets qui appliquaient un processus itératif, genre RUP. Comme dans Scrum, il y avait une planification à 2 niveaux : plan grosses mailles pour le projet et plan détaillé pour l'itération. Le concept est le même, mais la façon de préparer le plan diffère, essentiellement sur 2 aspects :

• le timing
• la responsabilité

Côté timing, avec Scrum c'est simple : le plan de l'itération n se fait au début de l'itération n lors de la réunion prévue pour ça. Avec un processus plus axé sur le contrôle par la hiérarchie, le plan d'itération doit suivre un workflow de validation. Cela se passait à peu près comme ça, dans l'avant Scrum :

• quelques jours avant la fin de l'itération n, le chef de projet prépare le plan de l'itération n+1,
• lors de la revue de l'itération n, le plan de l'itération n+1 fait partie des livrables présentés au management,
• compte tenu des retours faits lors de la revue, le chef de projet ajuste le plan.

Il fallait aussi prendre en compte les travaux effectués entre la date de la revue n et le début de l'itération n+1 (il pouvait s'écouler quelques jours)

Côté responsabilité, la planification est clairement l'affaire de l'équipe avec Scrum. Avant, le plan d'itération était de la responsabilité du chef de projet même s'il était dit explicitement dans le RUP que :

• le chef de projet travaille en collaboration avec l'architecte pour définir le contenu de l'itération,
• le plan d'itération doit être évalué en interne avant d'être présenté à une revue. Chaque membre de l'équipe doit adhérer aux critères d'évaluation et être d'accord sur le planning proposé.

La pratique Scrum d'une équipe autonome et responsabilisée rend caducs ces aller-retours entre le chef de projet, les membres de l'équipe et le management.