Les anecdotes scrum

Sur ce petit article, je vous propose de voir des petites anecdotes scrum. Pour ce début de mois d’août, nous allons découvrir des petites choses intéressantes.

Les origines du stand-up meeting ?

Si nous regardons du côté du Scrum Guide, rien ne dit que les équipes doivent faire leur daily scrum debout ; pourtant un grand nombre d’équipes le font aujourd’hui.

Constantin Guay s’est amusé à en retrouver la potentielle origine : article. Jeff Sutherland explique dans une de ses publications que chez Borland, les daily duraient environ une heure ce qui lui paraissait beaucoup trop long. Il a alors amené l’équipe à créer des règles :

• faire la daily à une heure précise pour aider les membres à s’organiser pour être plus présents
• utiliser ce moment d’échange pour aller à l’essentiel en amenant cette idée qu’elle ne dure pas plus de 15 minutes
• « ET » amener les membres de l’équipe à se lever pour être plus actifs et concentrés sur ce moment d’échange.

Le fait que les membres de l’équipe se mettent debout a permis d’amener les équipes à devenir plus dynamiques, d’être plus concentrés et de ne pas dépasser les 15 minutes recommandées. C’est peu à peu devenu une « norme » appelée stand-up meeting utilisée par de très nombreuses équipes agiles.

Vous pouvez retrouver l’article original sur ce lien : the origin of the daily stand-up.

Le nom « scrum » est d’origine japonais !

Le nom du scrum n’a pas été utilisé la première fois pour le framework que nous connaissons. Il date en réalité de 1986 avec une excellente publication appelée « The New New Product Development Game » de Hirotaka Takeuchi et Ikujiro Nonaka.

J’ai réalisé un article sur cette publication que vous pouvez lire dès maintenant : Les origines du Scrum.

Benjamin Fourio que je remercie, m’a d’ailleurs fournit ce lien qui montre que Jeff Sutherland fait une référence vers cet excellent ouvrage. On y suppose donc que le nom « scrum » a été bien repris de cette publication : http://jeffsutherland.com/oopsla/schwaber.html 

Le terme « grooming » a disparu !

Bien que souvent, des gens semblent vouloir distinguer les cérémonies « backlog grooming » et « product backlog refinement », ce sont en fait deux synonymes.

En réalité, le terme grooming a une connotation « pédophile » dans des pays anglophones et a donc rapidement disparu des ouvrages. Si vous ne le saviez pas encore, c’est le moment de l’exclure de votre vocabulaire.

Article pour vous expliquer les raisons de la disparition de ce terme : Backlog grooming agile, le terme à exclure

Le terme product backlog refinement est alors devenu l’expression de référence pour parler des affinages de user-stories.

La valeur des items sont obligatoires en scrum

Peu pratiquée, la notion de « valeurs » est belle et bien un pré-requis des éléments du product backlog. Bien que cette pratique ne se voit plus depuis plusieurs années, l’estimation des items ne doit pas être utilisée pour calculer la valeur de ce qui a été délivré.

Les éléments du backlog produit se composent d’une description, d’un ordre, d’une estimation et d’une valeur.

scrum guide

En effet à un moment, il y avait une pratique qui se voyait de dire : nous n’estimons pas les « bugs » car ils n’ont pas de valeurs… Et du coup, le burndown chart ne prenait pas en compte ce travail (et la prédictibilité non plus).

La baisse de la vélocité était alors vue comme normale car l’équipe délivrait moins de valeur.

Cependant, l’estimation et la valeur sont deux choses totalement différentes et heureusement, cette pratique a fini par disparaitre.

Mais de nombreuses équipes ne mettent pas de valeur à leurs items alors qu’elle est importante pour mieux visualiser la priorité de ceux-ci.

Les user-stories, ce n’est pas du scrum !

Pourtant utilisées dans 95% des équipes agiles, le scrum ne définit jamais les éléments du product backlog comme des user-stories. C’est devenue une pratique ultra populaire associée au scrum par erreur.

Cette pratique vient de l’univers Extreme Programming et plus précisément du livre de Kent Beck. Cependant, cette pratique n’était encore qu’un mot à ce moment là ; le concept de user-story s’est réellement développé entre 2001 et 2006.

La pratique est devenue tellement populaire qu’elle est vue comme du scrum aujourd’hui. D’ailleurs, nous voyons aussi des équipes les utiliser dans des univers 100% kanban. Cependant cette popularisation est logique, la user-story et toutes les pratiques qui l’entourent en font une pratique redoutable.

Certaines équipes qui ne les utilisent pas sont pointées du doigt ! Et pourtant, rien n’interdit aux équipes d’utiliser d’autres types d’items.

Conclusion

Pour ce début de mois d’août bien clame, j’espère que cet article vous aura appris des choses sympathique. Si vous connaissez d’autres anecdotes, n’hésitez pas à nous les partager. Le Product Owner discute de l’objectif que le Sprint devrait concrétiser et des éléments du Backlog produit qui, s’ils sont complétés durant le Sprint, pourraient permettre d’atteindre l’objectif du Sprint.