On a pu voir différents retours sur le Scrum Guide 2013

• Celui de Claude Aubry.
• Lui-même fait référence au papier de Pablo Pernot.
• Ou encore celui de Christophe Keromen ; il évoque au passage des choses qui disparaissent.

Avant d’aborder le fond, ma première remarque: le document a de toute évidence été écrit avec Word sur Mac. Les auteurs ont utilisé le style par défaut sans rien changer aux styles proposés (Titre, titre 1, titre 2 et normal entre autres). J’aime bien aussi le copyright “1991-2013”, même si le premier article publié date de 1993…

Rentrons dans le fond.

La transparence

C’est un ajout par rapport aux versions précédentes. Bravo. Cela dit, c’est très centré “inspection”. J’aime bien la notion de “done partagée” (pour les items de backlog, car il y a aussi un “done” des tâches qui ne concerne que l’équipe), et pour moi la transparence passe plus par le partage d’information : tableau des tâches, backlog, etc… pas simplement à l’intérieur de l’équipe mais aussi à l’extérieur.

Le Product Owner

Cela n’a pas bougé depuis 2011. Mais je reste assez dubitatif de cette position qui créé un schisme entre l’équipe et le “responsable fonctionnel”. Je m’en étais ouvert dans ma rubrique “en finir avec” dans un post dédié aux Product Owners. Ma position n’a pas changé, et ce partage des eaux ne m’a jamais semblé agile.

La Scrum Team

Comme d’autres, je pense qu’une taille de 9 est le début de la rupture. En fonction de la dynamique de groupe, ça peut tenir ou pas, ou la rupture peut être avant. Quand je dis “rupture”, je veux dire qu’en fait l’équipe se restructurera d’elle-même en sous-groupes de manière informelle. Pas la peine de luter, ça se passera de toute façon.

De toute manière, l’art de fixer une taille est un peu osé. Une équipe de deux, ça peut marcher et avoir un sens pour certains projets, même en Scrum !

Le Sprint

Plus ça va, moins j’aime le mot “sprint” qui a trop une connotation de “rush” à mon goût. Itération me va bien. Bien sûr l’insistance sur les 30 jours (même si l’on précise que cela peut être moins) devient drôle. Plus personne au monde, à part Ken Schwaber et Jef Sutherland, ne parle d’une limite maximum à 30 jours, mais bon…

Planning meeting

Comme mes petits camarades, j’ai noté la présence du “sprint goal”. Voici une évolution que j’accueille à bras ouverts ! Depuis pas mal de temps déjà je commence mes planning meeting ainsi, et note cet objectif sur un A3 qui figure ensuite au-dessus du tableau des tâches. Il est vrai que j’arrive rarement à faire une itération avec un seul objectif, mais je ne dépasse jamais 3.

Quoi qu’il en soit j’ai pu noter une différence extrêmement importante de motivation et de productivité entre des sprints ayant un objectif clair par rapport à la vieille méthode “liste à la Prévert” qui nous transforme plutôt en ouvriers spécialisés ! C’est ce qui aide à créer du plaisir et de la motivation : donner du sens à notre travail. C’est bien plus efficace que de coller des niko-niko au mur…

Bravo pour cette évolution qui va dans le bon sens !

Daily Scrum

De manière concomitante, le Daily Scrum prend une orientation qui est en concordance avec le “sprint goal”. C’est pure logique.

Un effet de bord est que l’on parle moins d’engagement sur la liste des stories (voir plus du tout) mais d’engagement sur le but du sprint, qui donne la souplesse d’adapter le contenu en cours de route pour rester dans la ligne de l’objectif mais éventuellement en déscopant des choses !

C’est encore une évolution que j’apprécie. Je n’ai jamais été à l’aise avec la notion d’engagement telle qu’elle été exprimée. Pour moi, l’engagement est moral. La qualité et la conformité au “done” doivent être maintenus coûte que coûte. L’engagement sur une liste de stories est pour moi une manière de demander à l’équipe de s’enchainer volontairement. Elle est le stigmate d’un manque de confiance et au bout du chemin demande implicitement de renoncer au “rythme soutenable”, ce que je n’accepte pas non plus.

On a ce pour quoi on paie. L’engagement sur un ensemble de stories se paie. Souvent en rush avec à la clé une qualité abdiquée, des heures sup’ avec une conséquence désastreuse sur le moral et la confiance et le plus souvent un cocktail de tout cela. Le tout en parfaite conformité avec les valeurs du management contrôle/commande que l’on prétend avoir abandonné !

Ce qui peut paraitre un petit ajustement est pour moi un gros virage dans le bon sens !

Sprint review

Apparemment il fait toujours 4 heures ! Bon je sais que l’on parle d’itérations d’un mois que personne ne pratique. Mais cette durée est ridiculement longue. Je vise une heure maximum pour une iteration de 2 semaines. Et c’est plus souvent de l’ordre de 30 minutes. Bref, je suis aligné sur Pablo visiblement sur cet aspect.

D’ailleurs la pratique des micro-démo tend à conforter la durée de 30 minutes, voir moins.

Sprint rétrospective

Je me suis fait la même remarque que Pablo: il est curieux qu’elle soit plus courte que la démo. Mes rétrospectives sont à peu près toujours de l’ordre de 2 heures pour 2 semaines. En fonction du contexte, ça peut aller jusqu’à 2h30 ; il est plutôt rare qu’elles soient plus courtes.

Product backlog

On parle d’items qui peuvent être complétés dans un sprint. Certes, mais pour moi cela reste une granularité bien trop élevée ! Difficile d’être adaptable au sein d’un sprint si seule un item ou deux figurent au programme ! Mais bon, ce point n’est pas nouveau… Je dirais que là-dessus je suis clairement d’accord avec ce que Gilles Mantel met au programme de son Scrum Master Academy.

Surveiller les progrès vers un but

Ce point devrait être en principe en concordance avec ce qui est dit sur le sprint planning et le Daily meeting. Il ne semble pas, car on parle de monitorer à la fin de chaque sprint ! De plus je trouve que ce point n’est pas très clair…

La transparence, encore et toujours…

J’aime bien ce nouveau focus. Toutefois je le trouve incomplet. Tout d’abord il ne concerne que le “done” et la liste des items pris dans le sprint, alors que je pense qu’il doit s’étendre à l’ensemble des artefacts de l’équipe, notamment le suivi des tâches.

Ensuite pour moi la définition de terminé ne doit pas seulement venir de l’équipe, mais de l’ensemble des parties concernées par le produit : product owner, opérations, hot line s’il y a lieu, etc…

En conclusion

Globalement, ce Scrum guide n’est pas une révolution. Ce n’est pas non plus ce que l’on attendait. J’aimerai bien que les auteurs abandonnent une fois pour toute leur notion de sprint d’un mois qui était déjà ridicule il y a 10 ans et est maintenant franchement embarrassante.

Mais de manière générale, je trouve que ce Scrum guide va dans le bon sens. Les auteurs ont résisté à la tentation d’alourdir Scrum. En fait ils l’ont même allégé de notions pas indispensables, comme celle de release. D’un autre côté, je suis un grand fan de cette notion de “sprint goal” qui nous éloigne d’idées précédentes pas franchement agiles.

Bon boulot, donc !