impediment

Amélioration continue vraiment continue

L’agilité a popularisé l’amélioration continue, avec les rétrospectives. A chaque fin de sprint, donc en général toutes les 2 ou 3 semaines, l’équipe s’arrête de développer, pour réfléchir à la façon dont elle a travaillé, dans le but de s’améliorer. Ce qui est moins connu que la rétrospective, c’est l’intraspective [1]. L’intraspective est une pratique consistant, quand un obstacle vient d’être éliminé, à en chercher la raison profonde, afin d’éviter qu’il se reproduise.

Obstacle pour impediment

Le livre que je suis en train d’écrire me fait poser beaucoup de questions sur (entre autres) la traduction des termes Scrum en français. Parfois je ne traduis pas et je garde l’anglais : ScrumMaster, Backlog… J’avais un doute pour “impediment’'. J’ai utilisé successivement problème puis impondérable mais je n’étais pas satisfait, d’où l’idée du sondage qui vient de se terminer et dont voici les résultats : Impondérable : 20.

Premier mai

Fête du travail Pas de billet le premier mai, je n’avais pas prévu de travailler non plus mais des impondérables sur le projet IceScrum ont fait que j’ai quand même fait des tests et de la réflexion autour de Scrum hier. Mais pas de défilé avec les syndicats ! Un syndicat, justement, on pourrait penser que c’est bien loin des valeurs de l’agilité. Mais qu’est ce que je lis le compte-rendu d’une réunion avec la direction ?

Du mou pour les impondérables

La pratique agile du jour : garder un peu de mou dans les plans. Même si on a fait une analyse des risques et mis en place une stratégie de réduction, des impondérables surviennent toujours sur un projet. Un impondérable (impediment) a pour effet de bloquer ou ralentir une ou plusieurs tâches en cours. Pour empêcher ces impondérables de remettre en cause les engagements, il faut se garder du mou lorsqu’on planifie (c’est d’ailleurs aussi une stratégie de réduction des risques).

Compter les heures, c'est mal

Suite du débat… Mon point de vue : trouver de l’intérêt dans le comptage des heures, c’est probablement le symptôme d’une mauvaise application de Scrum. Suite à mon billet sur les tâches chiantes, Rémy a fait un commentaire sur l’intérêt pour lui de relever le temps passé. J’ai fait un nouveau post sur le relevé des heures en donnant quelques arguments contre cette pratique. Rémy n’est toujours pas convaincu, alors j’en remets une couche.

Pas de volontaire pour les tâches chiantes ?

La question ne se pose pas (trop) dans les équipes Scrum. Je faisais en début de semaine une formation de sensibilisation aux méthodes agiles. Quand j’ai parlé de l’autonomie de l’équipe et que j’ai expliqué que c’est l’équipe qui identifie les tâches et chacun qui les prend, j’ai eu une question : et si des tâches pénibles ne sont prises par personne ? Hier, Cédric me racontait que lors d’une présentation de Scrum dans sa société de services, il a eu une remarque du même genre :

La mêlée quotidienne ou scrum

Le scrum est un point de rencontre entre tous les membres de l’équipe pour réguler les tâches du sprint en cours. Dans la série les réunions d’un projet agile, voici la mêlée quotidienne ou scrum. Le scrum repose sur 3 questions, auxquelles chaque participant va répondre. But du scrum L’objectif est de : Evaluer l’avancement du travail Identifier les obstacles(problèmes) nuisant à la progression Garder l’équipe concentrée sur l’objectif du sprint Améliorer l’esprit d’équipe Permettre une communication objective sur l’avancement Participants Toute l’équipe Scrum participe à la réunion.

Mesures agiles

La mesure la plus connue dans les méthodes agiles est probablement la vélocité. Mais il y a d’autres mesures simples à faire lors d’un développement agile permettant d’obtenir des indicateurs et des courbes (burndown charts, courbes diverses). Au cours de chaque sprint, on peut mesurer : tous les jours, le nombre d’heures restant à faire, ce qui permet de produire le burndown chart de sprint qu’on peut analyser selon sa forme A la fin d’un sprint :

La liste des problèmes

Impediment backlog Les présentations de Scrum abordent abondamment le backlog-le backlog de produit- et la façon dont il vit pendant le projet. Certaines s’aventurent jusqu’au backlog de sprint, que je préfère appeler la liste des tâches du sprint. Peu abordent la notion de problème (impediment) et surtout la façon de les gérer. A ma connaissance, seul Jeff Sutherland l’a évoquée brièvement dans un billet sur les 3 questions du scrum meeting.