Scrum - Méthodes agiles

...pour l'Agile Tour du 16 octobre à Toulouse

Lire la suite -->

Comme je suis tous les jours avec des équipes et des entreprises qui font la transition aux méthodes agiles, j'ai tendance à croire que la diffusion de l'Agilité en France se poursuit régulièrement et qu'une fois qu'une entreprise a essayé, elle continue.
Deux messages reçus la semaine dernière viennent me rappeler que la réalité du terrain n'est pas un long fleuve tranquille vers un océan d'agilité.

M. avait monté début 2007 un groupe de travail pour discuter des méthodes agiles dans sa société de services. Il a essayé vaillamment de diffuser des informations sur les méthodes agiles. Il me racontait ses efforts et nous discutions de la meilleure façon de communiquer. La société a été rachetée il y a quelques mois. Depuis je n'avais plus de nouvelles. Dans son dernier message il me dit que les choses évoluent, mais dans une direction complètement opposée à l'Agilité. Il parle de méthodes très lourdes et bureaucratiques, et d'une mise en œuvre sur un mode plutôt militaire.

P. est à l'initiative d'une formation à Scrum que j'avais faite il y a un an. Un projet pilote avait suivi. Le contexte du projet (embarqué, offshore, gouvernance forte, CMM-I) demandait beaucoup d'efforts pour l'application de l'Agilité sur le projet. Après seulement quelques sprints, la société a été rachetée. P. a bien essayé de continuer, d'introduire IceScrum. Nouveau rachat, puis réorganisation. L'initiative est arrêtée pour l'instant.

Je viens de passer 6 jours consécutifs chez des clients pour les former aux méthodes agiles. 3 clients différents : un ministère, une SSII spécialisée dans les nouvelles technologies de taille petite-moyenne et une grande entreprise avec un SI conséquent.
Pour le ministère et la grande entreprise, la formation était synchronisée avec le démarrage d'un projet, ou plus précisément avec le début de l'application de la méthode agile sur le projet. Juste après la formation commençait le sprint zéro.

J'ai modifié récemment mes supports de cours en mettant plus en avant la notion de pratique. La formation présente une vingtaine de pratiques usuelles du développement agile. On y trouve des pratiques venant explicitement de Scrum, d'autres venant de XP et des pratiques implicites de Scrum et de l'agilité. Je les présente -évidemment- de manière séquentielle. D'abord celles qui sont nécessaires lors du sprint 0, ensuite celles qu'on met en oeuvre dans les itérations.

Les pratiques couvrent les différentes activités (disciplines) du développement : gestion de projet, analyse, conception, codage et test. Certaines sont indispensables pour un développement agile, d'autres sont optionnelles.

Dans la version courte de la formation (un jour), je présente les pratiques dans leur usage courant. Dans la version plus longue, destinée aux personnes qui démarrent sur un projet, les pratiques sont adaptées au contexte du projet et de l'organisation, et leur application est faite (ou simulée) sur le projet lui-même, par des ateliers de travail en groupe. On consomme de la note collante...

Avant de commencer le premier sprint, il y a une période de temps utilisée à préparer ce qui est nécessaire au lancement des sprints dans de bonnes conditions. Jusqu'à récemment, je désignais cette période sous le nom de phase, pour la distinguer de la phase des sprints. Je disais simplement phase de préparation et c'est que j'ai utilisé dans le plugin Scrum pour EPF.
J'utilise maintenant, pour suivre la tendance, le terme sprint 0 pour désigner cette période. C'est la mode, il y a même un article dans InfoQ sur le sujet.
Sprint 0, c'est trompeur, parce que n'est pas un sprint : sa durée est variable, les tâches qu'on y fait sont spécifiques de cette phase, il n'y a pas le cérémonial habituel des sprints, on ne produit pas une version potentiellement utilisable à la fin, on ne mesure pas de vélocité...
Les travaux spécifiquement agiles qu'on y fait, c'est élaborer le backlog initial et planifier la release. Pour cela on y mettra en œuvre des pratiques comme la vision du produit, la priorisation du backlog, l'identification des risques, la décomposition en user stories, l'estimation en points, la définition de fini et de la durée des itérations, le planning de la release, la formation de l'équipe, l'organisation de l'espace de travail.
Les autres travaux à faire dépendent en fait de l'état du projet au moment du lancement de ce sprint 0. Par exemple, s'il n'y a pas d'architecture définie, il faudra probablement y travailler ; mais si l'architecture est déjà connue et stable ce ne sera pas nécessaire.

...plutôt que training Scrum ?

Lire la suite -->

Je conseille aux organisations de développement d'éviter le multitâches en faisant en sorte qu'une personne soit affectée dans la mesure du possible à plein temps sur un projet.
Ce n'est pas un conseil que je peux appliquer moi-même sur mes activités : je travaille sur plusieurs projets en même temps. En général j'arrive quand même à consacrer une journée ou une demi-journée à un seul sujet. Mais en ce moment particulièrement j'ai à changer de contexte très souvent pour passer d'un projet à un autre.

En une journée, j'aurai fait 2 heures de cours à la fac sur la définition agile de produit(vision, features, priorité, backlog, stories), répondu à une interview d'un journaliste de 01 Informatique sur les contrats au forfait avec les méthodes agiles, participé à la réunion du comité d'organisation toulousain de l'Agile Tour, suivie d'une autre réunion portant sur la création d'un consortium pour le développement du projet IceScrum. En fin d'après-midi, j'ai une conférence Skype avec Philippe Kruchten pour préparer notre intervention du 16 octobre sur l'Agilité en situation.
Je vais également préparer une présentation que je fais demain au service méthodes d'un groupe pharmaceutique ainsi qu'une nouvelle mission dans un Ministère qui démarre jeudi, pour laquelle je dois prendre connaissance du contexte (oui oui, c'est pour de l'Agilité, dans un Ministère).
Ecrire ce billet sur le blog, c'est une façon de faciliter les changements de contexte.

Ca y est, je viens d'envoyer le chèque, je suis sponsor de l'Agile Tour.
Sponsor local, pour l'étape de Toulouse du 16 octobre après-midi de ce premier tour de France de l'Agilité.

Malgré un slogan^[1] qui me laisse perplexe et un objectif disons maladroitement parisien dans sa formulation^[2], il m'a semblé essentiel de soutenir cette excellente initiative.
L'Agile Tour va permettre de donner un écho multiplicateur (par 7, les 7 villes de la tournée) à la diffusion de l'agilité en France, on le voit déjà à travers la communication sur l'événement dans les blogs et dans la presse.

Pour suivre la préparation de la conférence de Toulouse et connaître les détails du programme, visitez le blog des organisateurs.

Enchaîner les sprints, ça fatigue. Martine l'a clairement fait savoir lors de la dernière rétrospective^[1] : elle veut des jours de récupération entre les sprints. Elle aime bien Scrum, elle apprécie le principe des sprints, mais elle a besoin de souffler.

C'est normal si on se réfère à l'objet de la métaphore, on ne peut pas sprinter pendant toute la durée de la course de fond que constitue une release. Ce n'est pas moi qui vais dire le contraire : même si je ne cours plus beaucoup, j'ai pas mal couru en longue distance. J'ai encore le souvenir des entrainements en fractionné : par exemple une série de 10 fois 200m avec 30 secondes de récupération entre chaque.

Parmi toutes les équipes que j'ai suivies depuis 3 ans, la plupart se contentent d'un week-end avant de repartir sur un nouveau sprint : la revue et la rétrospective se font le vendredi et le prochain sprint démarre le lundi qui suit par la réunion de planification.

D'autres consacrent un jour entre chaque sprint à des activités hors projet; une équipe a instauré un bug day intercalaire.

J'ai aussi connu des équipes qui choisissaient de s'arrêter une semaine tous les 3 ou 4 sprints.

Et puis certaines enchainent directement : fin de sprint le mardi, début du sprint suivant le mercredi matin.

A chacun son rythme.

J'ai fait ce matin mon premier cours aux étudiants de Master1 à l'IUP ISI. Le module Agile est au programme, comme l'année dernière. 50 heures de cours, TD ou TP, plus l'application sur les projets qui durent 6 mois.

Cet enseignement fait partie de l'ingénierie du logiciel, qui comprend aussi un module plus classique de 30 heures. L'IUP ISI est spécialisé dans le développement et le génie logiciel est déjà abordé en L3. Il est donc approfondi en M1 avec ce gros volet sur les méthodes agiles.

Cette année, suite à la rétrospective sur les projets de l'an dernier, nous allons insister sur les tests agiles : plus de pratique sur le TDD. Le programme :

• les racines de l'Agilité, les différentes méthodes agiles
• la définition de produit, la gestion agile des exigences et les tests client
• la technique des histoires d'utilisateur
• l'estimation agile (story points, planning poker)
• la planification agile et le reporting
• les réunions et le travail en équipe (Scrum)
• la maîtrise des risques
• XP, les pratiques d'ingénierie
• le pilotage par les tests (TDD)
• la modélisation agile
• le développement de logiciel libre

Les cours de l'après-midi du 16 octobre ont été neutralisés pour que les étudiants puissent assister à la conférence de l'Agile tour.

Des utilisateurs brimés depuis longtemps pas les DSI découvrent que l'agilité peut accueillir et même favoriser les changements, ce qui les amène à penser qu'ils peuvent tout changer tout le temps.
Des managers se disent qu'avec l'agilité, il sera plus facile de demander de traiter une urgence ou du travail supplémentaire non prévu à leurs équipes de développement.

Ben non. L'agilité favorise le changement, mais ne le rend pas gratuit ni permanent. Si la demande de changement venue d'un utilisateur est la bienvenue, sa prise en compte passe par une gestion des priorités dans le backlog. Et une équipe qui travaille pendant un sprint ne doit pas être perturbée.

Certains auteurs ne facilitent pas les choses. Par exemple, le livre Balancing agility and discipline fait croire que que l'agilité s'oppose à la discipline. J'affirme pourtant que les projets que je coache seraient moins disciplinés (en gros plus bordéliques) si on n'y appliquait pas l'agilité.

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.

Le prochain séminaire agile de Toulouse constituera une étape de l'Agile tour. Il se tiendra le 16 octobre, sur toute l'après-midi. J'y ferai une présentation avec Philippe Kruchten. Le programme présente un résumé de la présentation.

Les idées présentées iront à l'encontre de plusieurs croyances sur l'agilité :

• des personnes sont persuadées que leurs pratiques agiles sont universelles et peuvent s'appliquer partout,
• certaines pensent être agiles parce qu'elles appliquent 2-3 pratiques qu'elles considèrent agiles,
• d'autres disent que l'agilité c'est sûrement très bien, mais croient que c'est totalement incompatible avec leur organisation.

En fait, les retours d'expérience montrent que des pratiques agiles peuvent s'appliquer dans de très nombreux secteurs. Mais ce n'est pas la même agilité qui s'applique partout. Celle qu'on met en oeuvre dans une startup du web2.0 n'est pas celle qu'on applique dans une grande administration.
Il est aussi probable que l'agilité en Amérique du Nord ne soit pas équivalente à celle possible en France. Si les valeurs sont les mêmes, les pratiques doivent s'adapter à la culture.
Enfin, l'agilité d'une organisation n'est jamais définitivement acquise : les pratiques mises en place doivent évoluer quand la situation évolue.
Cet exposé est destiné à un large public, ceux qui ont commencé à mettre en oeuvre l'agilité comme ceux qui s'interrogent sur son adéquation avec leur contexte. Inscrivez-vous, vous aurez peut-être un cadeau.