2014

Scrum évolue. Pratiques obsolètes Burndown chart de sprint Estimations pendant la planification de sprint Revue pour le Product Owner Rétro et revue mélangées Écrire les stories Estimation des tâches en heures Excel pour le backlog Planification de sprint en 2 parties Des slides sur l’avancement à la revue Une colonne à tester sur le tableau des tâches Pour en savoir plus, relire ce billet et celui-ci. Après les pratiques Scrum que je considère comme obsolètes dans la plupart des contextes, voici une liste de pratiques émergentes que je vous encourage à essayer en 2015 si ce n’est pas encore fait.

J’aime bien avoir un objectif sur quelque chose qui se mesure. 10 000 livres Scrum vendus Pour 2014, mon objectif en début d’année était d’arriver à 10000 livres Scrum vendus. Ce n’était pas sûr et mon impact sur les ventes est relativement limité une fois que le livre est écrit, il n’y a pas eu de nouvelle édition cette année. Je présume que ce que j’écris sur ce blog, en particulier les suppléments au livre, peut, éventuellement, pousser à l’achat.

Après la saison 1 et la saison 2, voici le retour des grenouilles agiles avec la saison 3 : Libérons l’Agilité ! Le livre est en vente chez Lulu sous 3 formats. On y trouve encore les saisons précédentes, auxquelles j’avais un peu contribué : J’avais écrit une histoire pour la saison 1, sur Sociocratie et Agilité. J’avais relu deux histoires pour la saison 2. Pour la saison 3, j’ai fait du binômage avec Stéphane Langlois (co-créateur de Scopyleft) pour écrire : Gymkhana, construire ensemble et autrement des idées citoyennes.

Dans une situation où il est nécessaire d’avoir un plan à moyen terme -un plan de release- voilà comment se servir du bac d’affinage. Plan de release, ou pas, c’est la question. Si la réponse est oui, les bacs facilitent grandement son élaboration et son suivi. Pendant le sprint zéro (ou après), on place dans ce bac tout ce qu’on prévoit de faire pour la date de fin de release. Bien sûr il ne s’agit pas de tout décomposer en stories, donc on se retrouvera aussi avec des epics.

Bien sûr, il faut ajouter un événement à ceux de ce schéma : le scrum quotidien. En 2007 puis en 2013 j’avais écrit des billets pour lister les réunions d’un sprint. Voici une réactualisation. Des changements depuis la dernière mise à jour : On ne parle plus de réunions, mais d’événements. La revue de backlog est devenue le meeting d’affinage du backlog. La planification de sprint a changé. La revue a été revisitée.

Une équipe qualifie une story d’epic pour indiquer qu’elle devra être décomposée en plusieurs stories[1]. Pour le dire autrement, il s’agit d’une story qui est trop grosse pour entrer dans un sprint. On sait qu’il faudra la décomposer, sans quoi elle ne pourra pas devenir prête et passer dans le bac de départ pour le sprint. Quand identifie t-on l’epic ? Je suggère qu’au moment où un élément entre dans le bac d’affinage, on décide rapidement de le qualifier comme epic ou comme story.

Suite de la série sur l’affinage du backlog : il ne faut pas hésiter à jeter. Pour éviter d’avoir un trop gros backlog, une première solution est de le diviser en bacs. En complément il convient de purger régulièrement ces bacs. Les éléments qui y stagnent trop longtemps sont des bons candidats à la purge. Purger le bac à sable Éliminer des éléments du bac à sable est une activité récurrente du Product Owner.

L’affinage consiste, à partir de l’idée brute, à rendre une story prête à être réalisée en un sprint. Dans la série sur l’affinage du backlog, après avoir vu le pourquoi, le quand et le quoi, voyons le qui. Bien évidemment en premier lieu vient le Product Owner. C’est lui le principal affineur. Il affine pendant le MAB, mais aussi en dehors, car il peut faire seul des travaux d’affinage comme :

Les travaux d’affinage consistent en : avoir une compréhension partagée de quelques stories pour qu’elles soient prêtes pour le sprint revoir l’ordre des stories (les priorités) décomposer des stories non élémentaires (epics) estimer ce qui n’est pas encore estimé (si on estime) approvisionner avec de nouvelles stories purger le backlog Ces travaux sont principalement effectués lors d’un MAB, au moment où l’équipe le décide. Le détail et l’ordre des activités menées lors d’une séance d’affinage dépendent de la situation.

On vous avait promis plein de bienfaits quand vous êtes passés à l’Agilité et en regardant vos résultats, vous n’en voyez qu’une partie ? On vous aurait menti ? Posez-vous la question de la maitrise que vous avez acquise : Eh oui, la transition à l’Agilité n’est pas magique. Ça prend du temps. Ça demande des efforts. En fait, les résultats dépendent de vos objectifs. Le modèle que je trouve intéressant pour illustrer les résultats que vous pouvez espérer compte tenu de la nature des objectifs de votre transformation agile est Agile Fluency.

J’ai la chance de faire partie de la communauté Agile et discuter fréquemment avec ses membres éminents. J’ai aussi le grand plaisir de faire des formations et des prestations d’accompagnement en binômes avec certains d’entre eux. Nous avons des parcours différents, cependant nous avons tous trempé dans le développement de logiciel, plus ou moins selon les sensibilités. Et nous nous sommes retrouvés dans le mouvement agile, certains plus récemment que d’autres, mais tous avec le même enthousiasme pour mettre en œuvre les pratiques agiles tout en partageant les mêmes valeurs et principes.

When to refine the backlog? L’affinage du backlog (refinement backlog, previously backlog grooming) est une activité faite par l’équipe pendant un sprint, dans le but de préparer des stories pour les prochains sprints. Dans quel cadre est-il pratiqué ? Une grande partie de ce travail est constitué de discussions entre le Product Owner et le reste de l’équipe. On peut donner un caractère permanent, officiel, à ces rencontres en les plaçant dans la cadre d’une réunion d’équipe, le meeting d’affinage de backlog (le MAB).

Mon billet précédent sur les pratiques Scrum obsolètes a été beaucoup lu et a provoqué des réactions intéressantes. Avec le même objectif, je récidive avec d’autres pratiques que je considère, pour la plupart des équipes Scrum, comme dépréciées. Estimation des tâches en heures [deprecated] : Les développeurs estiment les tâches en heures et mettent à jour régulièrement le reste à faire. Mieux -> Comme le disait Nicolas en commentaire du billet en question, il n’est pas utile de faire d’estimation des tâches en heures ou en jours.

Des petits bacs plutôt qu’un gros backlog, l’idée a maintenant fait son chemin. C’est plus facile pour l’affinage. L’idée des bacs m’est venue quand j’étais encore Product Owner d’iceScrum, il y a 3 ans. Il y avait déjà le bac à sable, puis s’est ajouté le bac à glace. Pour iceScrum, ça s’est arrêté là, mais j’ai continué à expérimenter cette façon de présenter le backlog. C’est devenu “les bacs”.

Vendredi toute la journée, mes interlocuteurs ont parlé de grooming. C’est ainsi qu’ils nomment la discussion sur le backlog, en vue de le préparer, que j’appelle -j’appelais- la revue de backlog. Ce n’est pas un mot qu’ils ont inventé. C’est moi qui les ai formés. Dans le petit guide Scrum de Schwaber & Sutherland, dans la version 2011, et probablement avant, c’était le terme employé. J’ai dû leur dire et c’est devenu une habitude.

Au cours du Raid Agile, nous avons essayé une nouvelle technique de rétrospective. A la demande générale -il y en a même eu venant de l’étranger, je vous explique dans ce billet comment animer une rétrochâtaigne. Elle se déroule en 4 étapes, une fois que l’animateur ait précisé sur quelle période elle porte. Mais d’abord il nous faut des châtaignes. Pendant le Raid en Cévennes, c’était facile, il suffisait de sortir du gîte et de se baisser pour en ramasser.

[deprecated] Je constate que des pratiques Scrum sont encore utilisées alors que je les considère, et beaucoup d’autres avec moi, comme obsolètes. Et depuis longtemps, puisque la plupart de celles que je cite ci-dessous étaient déjà dépassées quand j’ai écrit la première version de mon livre, sortie en 2010. Mais l’histoire du focus factor nous avait montrés que les habitudes ont la vie dure. Burndown chart de sprint [deprecated] : Le scrumMaster élabore un burndown chart de sprint pour vérifier la situation par rapport à la droite idéale.

Le Raid Agile, on y est venu pour son saucisson et la charcuterie cévenole mais on a aussi apprécié ses gâteaux, dont le fameux Mont Aigoual : En lançant le premier Raid Agile avec Pablo, nous avions fait trois hypothèses. Attirer du monde La première hypothèse était que nous aurions une dizaine de participants. Cela n’a pas été facile. Le message que nous passions pour inviter à participer a été amélioré plusieurs fois :

Le chapitre 18 de mon livre s’appelle La transition à Scrum. Les chapitres précédents ont traité de la mise en place de Scrum au niveau d’une équipe. Celui-ci évoque les impacts au niveau de l’organisation. Le sujet “Scaling Agile” est devenu à la mode, c’était par exemple le thème de l’Agile tour Montpellier. C’est devenu un sujet fourre-tout, qui regroupe des préoccupations bien différentes. Dans mon livre, j’ai choisi de différencier l’Agilité à grande échelle pour des gros projets, qui fait l’objet du chapitre 19, de l’Agilité au niveau des organisations, ce chapitre.

Lors de la deuxième journée de l’Agile tour Toulouse, le sujet #noEstimates que j’avais proposé a été retenu pour le premier run de l’Open Space. Nous étions un groupe de 6 ou 7 à en discuter. Le sujet ayant de nombreuses implications, la demi-heure que nous y avons consacrée est passée très vite. Nous avons tous souhaité continuer cette discussion. Nous avions d’abord envisagé de le faire l’après-midi, toujours pendant l’Open Space.