La conférence Agile France se déroule chaque année sur 2 jours, dans un cadre très sympa : le Bois de Vincennes. Fin de la première journée, des bons moments, et quelques trucs à raconter.
J’attaque la journée par une présentation sur la PNL. Ensuite nous avons présenté Domain Driven Design avec François Wauquier. J’ai passé un bon moment et je n’ai pas vu l’heure passer. Juste le temps de remballer le Mac, et nous passons dans la salle d’à côté.
Jean-Laurent de Morlhon et Eric Mignot présentent un sujet sur Scrum intéressant : « Comment j’ai remplacé 30% de mes développeurs en adoptant l’Agilité« . Jean-Laurent présente son retour sur la mise en place de Scrum chez Vidal Software. Avec une expérience de presque 4 ans sur le sujet, ce fut très intéressant. Eric Mignot de Pyxis était là pour jouer le rôle du Coach et pour nous aider à trouver le sens et à nous faire réfléchir sur le témoignage.
J’ai beaucoup aimé cette présentation. C’est un témoignage vivant de la mise en place de l’Agilité dans une organisation, chez un éditeur. Une équipe de 10 développeurs, plusieurs produits, la place des Product Owners, la relation avec la hiérarchie, tous les sujets ont été abordés.
Jean-Laurent présente les différentes versions de leur « Scrum Board ». La version v1 classique avec « To Do/Checkout/Done ». Puis l’ajout d’une colonne « Good » pour que le Product Owner puisse donner son retour. Les Stories restent sur une ligne, et ce sont les Tasks de la Story qui naviguent de colonne en colonne. En 4 ans, le tableau s’est plus enrichi que simplifié. Mais il a répondu aux besoins de l’équipe.
La validation au fil de l’eau par le P.O est une démarche intéressante. Elle consiste lorsque le P.O est disponible, à faire une validation dès lors qu’une Story est terminée.
Eric insiste aussi sur l’importance du mot « démo ». Lorsqu’il arrive dans des équipes et que celles-ci disent « on fait la démo au PO ? « , c’est très intéressant. Le mot démo véhicule une intention différente du mot « rétrospective ». Ce mot tend aussi à influencer la personne qui vient assister à la rétrospective. Ce n’est pas un mauvais mot, c’est un mot qui donne de l’information sur la manière dont l’équipe perçoit son travail.
La rétrospective justement, est le point qui pendant les 6 premiers mois, n’a pas du tout été fait par l’équipe. Avec le recul, Jean-Laurent explique que l’équipe étant jeune avec l’Agilité, ils ne percevaient pas l’intérêt immédiat de la rétrospective. Puis ensuite, petit à petit, le besoin a émergé. Après le Design émergeant, on a la « Rétro-émergence »…
Pour donner son retour, Jean-Laurent détaille les techniques simples utilisées lors des rétrospectives. Elles permettent en fait de se congratuler entre membre de l’équipe, sans rendre cela « artificiel » ou génant, mais en permettant naturellement de reconnaître les efforts de chacun. Intéressant, surtout dans la culture Française assez peu friande des congratulations.
Faire de l’Agilité, cela entrainera aussi des frictions. Il y eu quelques échanges mémorables. Le premier P.O est parti, remplacé par une personne qui prendra ses fonctions un peu plus tard. En attendant, l’équipe a pris le rôle de P.O, mais ce ne fut pas l’idéal.
La « Sprint review » (plutôt que le terme « Demo ») permet de se resynchroniser entre membres de l’équipe, et avec le Product Owner. Il est primordial d’avoir un logiciel qui tourne. C’est le bon moment aussi pour s’assurer que le Product Backlog est à jour.
Eric demande si certains font faire la « Demo » par le Product Owner ? Après tout il faut qu’il tire le meilleur parti de cet événement. A peu de moment, le mot Scrum est cité. Eric emploie souvent le mot « Processus Itératif Incrémental« .
Jean-Laurent montre aussi des graphiques en forme de radar, qui montre Spring après Sprint l’évolution des critères de qualité de l’équipe. Sans le savoir, je faisais la même chose il y a 2 ans chez Reuters ! Great minds gets together !
Le sujet des Estimations est intéressant. Jean-Laurent n’essaye pas d’expliquer ce qu’est une estimation, ou ce qu’il faut faire. Il raconte ce qu’ils ont fait, à l’époque.
Au début, l’équipe utilise l’échelle « jour/homme ». Calculé en amont des Sprints, c’est finalement assez mal vécu et utilisé par l’équipe. Cela permet par contre de travailler « à l’ancienne » avec les équipes externes de management, en demande de chiffres.
Ils essayent ensuite une autre approche : une Story est côté en terme de « points de complexité », puis les Tâches de cette Story sont estimées en jour/homme au moment où la Story est dépilée. C’est assez pratique car on attend le dernier moment pour donner un engagement.
Personnellement, j’essaye de rester sur les points de stories. J’ai appelé cela « un nombre de patates » pour vraiment montrer aux développeurs que ce chiffre regroupe une estimation de temps, de risque et de confiance. J’aime bien avoir une unité virtuelle, afin de ne pas tordre ensuite l’agenda avec une notion de jour/homme.
Jean-Laurent raconte l’histoire d’un développeur qui avait pour habitude de suivre à la lettre les estimations en jour. Une tâche est estimée à 2 jours ? Il prend 2 jours. Une autre tâche est estimée à 5 jours ? Il prend 5 jours. Un jour, il voit le développeur entrain de faire autre chose sur son PC. Il lui demande ce qu’il fait. Comme celui-ci a terminé, il attendait en fait d’avoir écoulé les jours pour prendre une tâche suivante sur le tableau…
Nous parlons ensuite du Daily Stand-up Meeting. Dans certaines organisations, cette cérémonie est vécue comme du Reporting. Chaque développeur donne son point d’avancement et le Scrum Master (qui soit-dit en passant n’a rien à faire à cette réunion) met à jour les « reste à faire ».
Eric ré-explique l’utilité et l’organisation du Daily Stand-up meeting. C’est une cérémonie où tous les sens sont en action. La vue, l’ouïe, le toucher pour bouger les post-its. Bien mieux qu’un compte-rendu de réunion sur papier ou une téléconférence par exemple. Son utilité est de synchroniser les activités de chacun au sein de l’équipe. Le Scrum Master doit s’effacer. ll peut noter quelques points à vérifier, mais son rôle est simplement de s’assurer que la réunion a lieu chaque jour. Ensuite, il peut aller prendre un café.
Eric propose de faire le test suivant si vous êtes Scrum Master. Ne venez pas un matin à la réunion. Que se passe-t-il alors ? Est-ce que l’équipe se regroupe ou non ?
Pour terminer, Jean-Laurent balaie quelques points sur la mise en place de méthodes Agiles et certains mots comme « Stress » par exemple. Il reconnaît que depuis l’adoption de Scrum, 3 développeurs sur 10 en 3 ans sont partis. Pour certains, c’est trop violent. Devoir se réunir chaque matin et dire à haute voix : « hier j’ai bien galéré et je n’ai pas codé une ligne » est parfois un exercice insurmontable.
Le Scrum Master a un devoir de communication. Eric enfin termine en nous donnant l’une des utilités de passer en mode « Processus Itératif Incrémental » : ces approches font ressortir les dysfonctionnements dans l’entreprise et dans les équipes. J’évoquais il y a un an et demie l’effet « pétard » de Scrum : il tend à faire exploser les tensions et les points de dysfonctionnement d’une organisation. Et puis il a un effet euphorisant lorsqu’il fonctionne, car avoir une équipe qui délivre un logiciel, sans souffrances, et avec plaisir, c’est un peu le sens de notre métier non ?
Fin du premier billet
J’ai ensuite assisté à deux présentations que je couvrirai demain dans d’autres articles :
– Pierrre Piezzardi d’OCTO Technology sur la question suivante : « Le Lean management peut-il transformer l’entreprise ? »
– DRH, Agile, WTF avec Iva Konstantinovic et Gabriel de Pyxis. Débat très intéressant sur la mise en place de Scrum chez un éditeur dans la finance.
La soirée s’est terminée comme l’an dernier par un repas assis, sur des grandes tables rondes de 8-10 convives. L’occasion de parler recrutement, recherche d’emploi, Git, Spring WebFlow, les vieux développeurs, DVCS et Agilité…
0 no like
On lit beaucoup de compte rendus super positifs sur Scrum. J’aimerais nuancer car après plusieurs sprints, voici ce qu’il en ressort de mon point de vue:
– la pression est constante pour le développeur, pas de répit avec des tâches souvent très courtes. Effectivement l’auto-contrôle de l’équipe est certes un bon moyen pour se sentir responsable mais je trouve que ça peut vite tourner au lynchage public lors de DSM (s’il y a quelques c… dans l’équipe).
Il faut permettre aux équipes de souffler entre 2 sprint, au moins entre 2 livraisons. Par rapport au Waterfall, il y a cependant moins l’effet coup de bourre mais pas trop de répit, non-plus.
– je pense qu’agile est particulièrement adapaté pour des projets avec des besoins relativement simples vue la durée d’un sprint. Quand ça se complexifie il devient difficile de réaliser le sprint planning dans les temps…
– Souvent le Scrum Master est un ancien CP qui aime bien mettre son grain de sel et influencer l’équipe… (il faut rester vigilant)
Bon sinon, en terme de qualité produite et de capacité à livrer, l’utilisation d’agile a été plutôt bénéfique dans l’organisation. Ce que j’apprécie surtout c’est l’effet catalyseur d’agile, on se rend + vite compte lorsqu’on va dans le mur. Pour les DSM l’avantage aussi est de « forcer » les développeurs à communiquer.
« Comment je me suis séparé de 30% de mes développeurs en adoptant l’Agilité »
Sur ton twitter tu dis que c’est de l’humour ? est-tu si sur que ca reste une blague dans la réalité ?
Le lean dans l’industrie a servi à ça, a servi aussi à mettre une pression constante (cf message de Montain Dew).
J’en profite pour faire un copier coller d’un excellent livre « Brain Rules » :
« Stress damages virtually every kind of cognition that exists. It damages memory and executive function. It can hurt your motor skills. When you are stressed out over a long period of time it disrupts your immune response. You get sicker more often. It disrupts your ability to sleep. You get depressed. »
Est ce que certaines équipes ont mis en place une journée dîte « libre » à la fin de chaque sprint ? Ils en parlent dans le livre « Scrum from the trench » pour justement permettre aux développeurs de se « reposer en faisant autre chose » et aussi du coup faire tomber le stress. Pour ceux qui le pratique, est ce que ça marche ?
Sinon au niveau du turn over, 10% je ne trouve pas ça énorme. Quel était le turn over avant de passer à Scrum ?
Nicolas, au 5ème paragraphe, n’y aurait-il pas confusion entre rétrospective et revue. Tu compares « démo » et rétrospective.
La revue et la rétrospective sont 2 cérémonials de scrum, la revue étant le moment de démonstration de ce qui a été effectivement développé pendant le sprint donc avec le plus de monde possible, là où la rétrospective est plus un moment de prise de recul sur les pratiques donc avec une équipe réduite.
« Démo » et rétrospective ne peuvent donc pas être comparés ; tu parles d’ailleurs bien de « Sprint review » pour « Démo » un peu plus loin.
Mountain Dew, je ne comprends pas bien ta remarque sur la pression :
– avec une méthode agile, tu progresses avec un mini cycle Conception/Test/Code, c’est ton boulot, c’est quotidien, c’est parfait ; pas de pression
– avec une méthode agile, tu as un rythme soutenable, c’est dans le manifeste, sinon, ne dit pas que tu fais de l’agile ; pas de pression
– avec une méthode agile, tu as le droit d’être coincé par des obstacles, prendre du retard sur tes tâches, mais être aidé par ton équipe ; pas de pression
– avec une méthode agile, tu prends du recul fréquemment (rétrospective), ça te permet justement d’avoir un peu de répit comme tu le dis.
Où est la pression ?
En revanche, comme tu l’as très bien noté, si tu pratiques un bon waterfall, avec un peu de chance, au début du projet (pendant la moitié du temps environ) tu avances, tranquillement certes, mais vers le mur. Quand tu t’aperçois qu’il y a un mur, alors là gros coup de bourre, bien pire qu’avec l’application d’une méthode agile, en mode urgence, où ça devient du grand n’importe quoi sous pression. Donc, globalement, tu as un (long) répit régulier au démarrage de chaque projet… Bof !
– avec une méthode agile, tu as un rythme soutenable, c’est dans le manifeste, sinon, ne dit pas que tu fais de l’agile ; pas de pression
l’Agilité avec un grand A va pouvoir à résister aux contraintes du marché ? 🙂
– avec une méthode agile, tu as le droit d’être coincé par des obstacles, prendre du retard sur tes tâches, mais être aidé par ton équipe ; pas de pression
Et pour les équipes dans lesquelles les gens se tirent dans les pattes
(tiens par exemple dans une entreprise appliquant une politique de bonus personnel). La politique de bonus fait peut être sortir du cadre de l’Agilité ?
– avec une méthode agile, tu prends du recul fréquemment (rétrospective), ça te permet justement d’avoir un peu de répit comme tu le dis.
S’il n’y a pas le budget pour prendre du recul ?
J’ai pas une grande expérience et j’ai fait uniquement du waterfall (ou un truc itératif) mais j’ai quand meme fait 6 projets différents dans 6 entreprises et, à chaque fois, le problème n’était pas la méthode mais les contraintes politiques et/ou économiques.
J’ai pas eu de chance ?
Enfin j’espère pouvoir faire de l’agilité !
@Mountain Dew : le compte rendu que nous avons fait de Scrum est justement d’aborder les points qui potentiellement qui fâchent. La mise en oeuvre de Scrum est loin d\’être parfaite partout, loin s’en faut.
@Jean-baptiste L. On l’a fait. On a même eu à un moment 2 jours entre les sprints, nommées journées hors-sprint. On a un arrêté de le faire, entre autre, lorsque les PO nous ont dits des choses du genre « bon, ben ca vous le ferez hors sprint hein » sur les demandes de tâches plus techniques.
@grenzinger Il y a forcément du « budget » pour prendre du recul. La retrospective est un éléments essentiels de Scrum, c’est ce qui permet au gens de dire ce qu’ils ont a dire pour se congratuler ou critiquer les semaines passées afin d’améliorer le quotidien de tous. Si tu doutes que ces méthodes soient tourner vers les gens regarde les valeurs d’XP : http://fr.wikipedia.org/wiki/Extreme_programming#Valeurs
@Sylvain Effectivement lors de cette session j’ai parlé de Démo vs. Revue, et non de Démo vs. Rétro.