Scrum est un processus de développement faisant partie des Méthodes Agiles qui s’inspire des valeurs collectives du rugby : scrum signifie mêlée.
En fait, Scrum n’est pas vraiment un processus ni une méthodologie -ni une méthode même si on parle de méthode Agile.
Lors d’un Scrum Gathering, Ken Schwaber, un des fondateurs, a décrit Scrum comme :
“not a process or a methodology, but a path”.
Une voie à suivre.
Neige à Toulouse, mon déplacement à Paris est annulé
C’est l’occasion de faire un tutoriel IceScrum. Celui-ci porte sur la façon dont l’outil aide à gérer différents niveaux d’exigences et produire le backlog de produit.
La nouvelle version d’IceScrum, qui s’appelle R2#9, facilite la définition de produit avec les features et les rôles d’utilisateurs qui complètent le backlog de produit.
Ce petit tutoriel vous aidera à expérimenter IceScrum sur ces nouveautés permettant d’avoir une meilleure vision du produit. Pour bien comprendre les termes utilisés, une lecture de ce billet peut être utile avant de commencer.
Hier soir, je suis allé au bar des 2 ormeaux pour regarder Dax - Toulouse. J’ouvre la porte et cherche des yeux Jean-Alain, mon camarade de rugby.
Le bar était bondé. J’étais un peu en retard, le match était commencé, mais je n’entends pas la voix des commentateurs. Ce qu’on entend, c’est de la musique. Le gros son d’un groupe qui joue sur l’estrade dans le fond de la salle.
Des exigences de localisation ou d'utilisabilité représentent des contraintes qui portent sur plusieurs user stories
J’alimente le backlog de produit d’IceScrum pour la nouvelle release. J’y mets donc des features et des user stories, qui représentent l’aspect fonctionnel. Pour avoir un produit de qualité, je réfléchis aussi aux exigences non fonctionnelles. J’avais fait un billet “que faire avec les exigences non fonctionnelles ?” il y a quelque temps en disant qu’elles devaient aussi aller dans le backlog. Mais ça ne marche pas avec toutes.
Des arguments contre les croyances erronées sur l'agilité
Emmanuel Chenu a réalisé une maquette en lego de son espace collaboratif de projet. On voit bien les 2 sièges devant un seul poste, pour le binômage.
Emmanuel est un artiste. Et il écrit aussi des articles toujours intéressants. En allant voir les legos, profitez-en pour lire le billet Agilité et critiques courantes. Dans l’article associé, vous trouverez un argumentaire précis, toujours utile si vous en êtes à vendre l’agilité dans votre organisation.
Le backlog est la liste des choses à faire par l'équipe
Ce backlog en couleurs a été produit avec une vieille version de iceScrum. Un exemple récent avec un beau dessin existe sur ce site, voir PermaBio
Les équipes agiles ne produisent pas une documentation faite au début du projet, qui décrit en détail toutes les spécifications fonctionnelles. Elles collectent les fonctions essentielles (les features) et les raffinent progressivement. Il n’y a pas un gros document de spécification, l’outil de collecte s’appelle le backlog de produit.
Il est courant de classer les pratiques agiles en 2 : ingénierie et management
Distinguer les pratiques d’ingénierie et de management, c’est fait couramment.
Vous aurez noté que dans ce blog je parle plus des pratiques de management. C’est parce que je préfère parler de ce que je pratique (!) couramment : je suis impliqué dans de nombreux projets agiles, mais je n’écris plus de code depuis déjà un certain temps.
Hier j’étais en déplacement à Paris pour une réunion de préparation à l’introduction de l’agilité dans une organisation offshore. J’en ai profité pour assister à la présentation sur le Lean chez Zenika, c’était en soirée. La présentation était assurée par Pascal van Cauwenberghe. J’avais participé à un de ses ateliers au XP Day 2007. Cette fois-ci, c’était sur The Toyota Way.
La vélocité ne mesure pas la productivité. Et l'accélération de vélocité ?
Trouvé dans InfoQ et venant de Scott Ambler, le prolifique Scott Ambler, une nouvelle mesure : l’accélération.
On sait que la vélocité est une mesure de la capacité d’une équipe pendant un sprint, qui est intrinsèque à cette équipe. Elle ne permet pas de comparer 2 équipes, ce n’est pas une mesure de productivité.
Pour y remédier, Scott propose de calculer l’accélération. C’est simple :
accélération = (vélocité de l’itération n - vélocité de l’itération m) / vélocité de l’itération m, sachant que n>m
Jeff Patton n’écrit pas souvent. Mais quand il le fait, c’est long et ça donne à réfléchir. J’avais parlé à l’époque de son article Je ne sais pas ce que je veux mais je sais comment l’obtenir. On y retrouvait la Joconde illustrant les notions d’incrément et d’itération.
La diffusion de Scrum a connu une croissance très forte ces dernières années. Fatalement ce mouvement amène son lot de personnes mal formées, d’opportunistes qui vendent des compétences au rabais… puis de projets en difficulté. Rien d’étonnant : la transition à Scrum (et à l’agilité en général) demande beaucoup d’efforts et du savoir-faire pour conduire le changement culturel.
La gestion des bugs, ou plus exactement des défauts, varie selon les projets. Même si l’objectif ultime avec une méthode agile est de ne pas avoir de défauts dans le code, dans la vraie vie des projets il y a toujours des défauts. Et il faut s’en occuper, en gardant à l’idée que c’est moins cher de les corriger tôt que tard.
Je vais vous raconter comment nous traitons les défauts sur le projet de développement de l’outil IceScrum, dont je suis le Product Owner.
Jusqu’à récemment et faute de disposer d’un serveur, l’équipe IceScrum utilisait GoogleDocs pour gérer le projet — à la Scrum — avec les backlogs en ligne. C’était limité.
Maintenant on utilise IceScrum (R2#11) comme outil pour le développement du produit IceScrum.
C’était toujours la question à l’époque où je travaillais chez un éditeur qui vendait des outils de génie logiciel :
est-ce que vous avez utilisé votre outil (par exemple Asa ou Geode ou STP) pour le développer ?
La semaine dernière j’ai eu l’occasion de connaître des usages de Scrum dans des sociétés où j’étais intervenu il y a quelques semaines ou quelques mois pour des formations et du conseil. Chacune poursuit l’utilisation de Scrum en fonction de son contexte, à partir de la base que j’ai enseignée.
J’ai appris que de nouveaux usages s’étaient mis en place, à l’initiative des équipes qui pratiquent Scrum.
En janvier, j’ai essayé Getting Things Done. Les Mêlées a raconté son expérience et il en est content. J’ai lu le livre de David Allen. J’ai tenté de l’appliquer. Comme je ne suis pas très papier, je n’ai pas pris l’option dossiers avec des chemises. J’ai essayé GTD inbox, un module complémentaire de Gmail. Au bout d’une semaine, le constat était plutôt mitigé. Trop compliqué, ça ne me convainc pas.
La transition d’une organisation à l’agilité est plus ou moins facile. Cela dépend du mode de gouvernance. La façon dont les managers gèrent leur organisation influe sur les comportements des personnes. La culture ainsi développée en fonction de la gouvernance a un impact très important sur la conduite du changement pour passer à l’agilité.
La meilleure façon d’apprendre les méthodes agiles, c’est de mettre en œuvre immédiatement les notions enseignées.
Je vais faire une série de formations publiques proposées par Ekito et données en duo avec Jean-Marie Damas.
Mon kit pour les formations contient toujours les cartes de planning poker, des notes collantes et des fiches bristol, comme le précédent, mais il s’est enrichi avec :
l’éventail qui fait du bruit, pour réclamer le silence après une discussion. C’est un accessoire que j’ai eu lors d’un match du Stade Toulousain, Au Stadium, cela permet de rythmer “on vient, on gagne et on s’en va”. le pomodoro que je viens de recevoir, qui permet de “timeboxer” les ateliers.
L'adaptation au contexte ne doit pas être un prétexte au n'importe quoi
Dans son dernier billet, Thierry rappelle que si l’agilité doit s’adapter au contexte, il ne faut oublier le vice-versa. Bien sûr quand une équipe passe à l’agilité, elle doit s’y adapter. Cela signifie qu’elle adhère aux valeurs et aux principes. Elle va également apprendre la mise en œuvre de pratiques agiles. Tout ça, c’est du changement et Thierry a raison de le rappeler : il faut commencer par adapter l’équipe à la culture agile qu’elle doit acquérir, si elle ne l’a pas encore.
Le 19 mars c’est le lancement du SUG français. Le groupe qui accueille les utilisateurs français de Scrum compte maintenant plus de 200 membres et sa croissance se poursuit régulièrement.
Une des présentations du prochain SigmaT, le 9e, sera : Quel contrat pour mon projet ?
La contractualisation agile, c’est un sujet très demandé. Cela ne concerne pas tout le monde, mais ceux qui sont impliqués dans un contrat au forfait, soit du côté client, soit du côté fournisseur, y sont très sensibles.
En tout cas, on ne peut pas se passer des utilisateurs
N. est une commerciale dynamique qui vend, entre autres, de la méthode agile. Elle me raconte qu’une administration qu’elle a prospectée lui a répondu : Non. On ne peut pas appliquer les méthodes agiles chez nous, parce que nous ne pourrions pas impliquer suffisamment nos MOA.
La personne qui a dit ça a bien compris que les méthodes agiles nécessitent une forte implication du “métier”, à travers le rôle de Product Owner. Cependant elle préfère renoncer aux bienfaits de l’agilité plutôt que d’essayer d’impliquer plus la MOA.
L'intelligence situationnelle favorise le succès. Comme au rugby
Dans la présentation Agilité en situation faite avec Philippe Kruchten pour l’Agile Tour 2008, nous avions comme attributs caractérisant le contexte d’un projet :
la taille du projet la criticité de l’application le modèle économique la stabilité de l’architecture la dispersion géographique de l’équipe l’âge de l’application le mode de gouvernance le taux de changement
Le backlog des Ateliers de l’Agilité, sur une fenêtre de la salle de cours, dans les locaux de la galerie EXPRMNTL, au milieu de l’exposition de Charley CASE.
Un atelier agile, cela produit une autre forme d’art contemporain :
Jeff Sutherland rappelait jeudi soir, lors du lancement du SUG français, qu’à peine un tiers des équipes proclamant faire du Scrum passaient avec succès le test Nokia. Ce n’est pas beaucoup. Ce n’est pas assez et j’espère qu’en France nous allons obtenir de meilleurs résultats.
Je finis ma tournée de printemps à la maison avec le SigmaT9, vendredi
C’est bien les tournées, on y rencontre plein de monde (pas loin de 100 à Marseille, plus de 120 à Paris, sûrement plus de 80 à Toulouse) et on a l’occasion de discuter pendant les apéros qui suivent les conférences.
Jeudi, en me rendant à la soirée inaugurale du SUG français, je suis passé par l’esplanade de la Défense. Devant un chapiteau dressé au pied de la grande arche, il y avait une longue file d’attente pour assister au spectacle du jour du festival Chorus 2009. Sur l’affiche du festival, le slogan, c’est : Ze française touch
Maintenant que le SUG français est lancé et bien lancé, il faut le faire vivre. J’en suis le correspondant pour le Sud-Ouest, alors je lance un appel à tous les utilisateurs de Scrum dans le Sud-Ouest pour qu’ils se manifestent et me donnent des choses à correspondre.
Le retour d’expérience d’Atchik Real-Time présenté au SigmaT9 vendredi a montré que l’équipe s’améliorait continuellement grâce aux rétrospectives. Une amélioration qui a retenu mon attention est celle de la définition de fini.
L’équipe a mis en place une matrice, avec en lignes une liste de contrôles possibles sur les stories et en colonnes les stories sélectionnées pour le sprint courant. Pour chaque story, une croix dans une ligne signifie que le contrôle correspondant est à faire. La matrice est définie par l’équipe en début de sprint.
Cette année, comme il y a 3 ans, j’aurai un stagiaire qui va travailler sur IceScrum. De septembre à fin mars, le projet a avancé avec essentiellement des ressources d’étudiants, dans le cadre de leur projet tutoré. Ces étudiants partent en stage à partir d’avril.
Ce midi j’ai déjeuné avec Marc. Souvenirs… Il y a plus de 20 ans, nous étions dans l’équipe T32 à (Télic) Alcatel. Marc, qui est maintenant manager dans un grand groupe international, a vu passer de nombreux projets de développement de logiciel. Il me raconte que le T32 a été une belle réussite par rapport à tous ces projets.
L'agilité devrait ramener un peu du plaisir de coder
Aujourd’hui et demain, je fais une formation Scrum dans une grosse SSII. J’ai passé moi-même 9 ans dans une société de services. J’aime bien rencontrer les informaticiens de SSII. La participation à des projets dans des contextes et des domaines différents leur donnent une grande ouverture d’esprit.
Je trouve qu’ils sont particulièrement intéressés par l’agilité et tout à fait disposés à l’appliquer sur leurs projets. Ils souffrent des lourdeurs imposées par leur processus actuels et regrettent de ne pas mieux se comprendre avec leurs clients.
Ça fait 3 ans que je blogue. Jour pour jour. J’avais commencé le 4 avril 2006 plein d’entrain mais aussi avec des doutes sur ma capacité à intéresser des personnes à le lire.
J’aurais pu commencer ma quatrième année de blogage par un sujet d’actualité ou de polémique : le contrat au forfait, la certification ou le test Nokia par exemple.
La certification sert à rassurer. Comme le consommateur est inquiet sur la qualité du poulet, on certifie le poulet. Mais, après avoir vu le documentaire d’hier sur Arte, les consommateurs qui auront vu comment ça se passe dans les élevages de poulet industriel ne vont pas être très rassurés.
Un backlog de produit à prioriser, du concret pour le Product Owner.
Le backlog de produit est l’outil du Product Owner. Il le triture, le malaxe, pour qu’il soit toujours utile et à jour. A jour, cela implique notamment que les éléments du backlog sont ordonnés par priorité.
Un Product Owner est amené à changer l’ordre de priorité pour différentes raisons :
Product Owner et Backlog sont les mamelles d'une équipe
Si une équipe clairement identifiée développe un produit, il ne reste plus qu’à trouver un bon Product Owner, ce qui n’est pas toujours facile, et hop avec un backlog pour ce produit, Scrum est appliqué avec la structure de projet standard : un PO, un backlog, une équipe
Malheureusement ce n’est pas toujours aussi simple. Parfois le produit nécessite plus qu’une équipe.
Le backlog de produit contient la liste des choses à faire. Pour simplifier appelons ces choses à faire des stories.
Selon l’état de ces stories, on peut identifier 4 grandes parties dans un backlog :
L’agilité accueille le changement et va même jusqu’à l’encourager (dans la réalité, c’est sous certaines conditions).
Entendu hier l’histoire d’un client pour lequel cette ouverture au changement figurait explicitement dans la proposition de contrat :
Holà, mais j’ai le droit de ne pas faire de changement pendant le projet ? Je veux que ce soit possible de ne pas demander de changement, ajoutez-le bien dans le contrat.
Un plan de release présente les itérations à venir et le contenu prévu de ces itérations. Ce contenu consiste en des éléments du backlog de produit.
Présenté sous forme de tableau, un plan de release est facile à comprendre. Il constitue un outil de communication important avec tous les intervenants du projet.
Voici un exemple du plan de release du projet IceScrum.
