Scrum Guide 2013 et pablotages

Ken Schwaber et Jeff Sutherland, les fondateurs de Scrum, ont mis à jour le Scrum Guide. Pablo en a fait son décodage

Scrum

Pablo Pernot vient de publier un billet Scrum2013, le canevas, dans lequel il compare ses pratiques avec ce que propose ce nouveau guide. Par un tweet, Pablo m’a demandé ce que j’en pensais. Comme les commentaires de son billet sont fermés, je vais donner ma position ici.

Tout d’abord je remarque que comme pour la version précédente (2011), ce guide est publié juste après une version de mon livre[1]. Évidemment Schwaber et Sutherland ne m’avaient rien dit. Cela n’aurait pas changé grand chose, car la plupart des changements entre le guide 2011 et celui de 2013 sont présentés dans mon livre. Et aussi parce que je n’apporte pas une importance démesurée à ce guide. Cependant il est intéressant de voir son évolution.

Les nouveautés

Voici les 6 changements apportés[2] :

  1. plus d’insistance sur la transparence,
  2. la planification de sprint avec l’objectif du sprint (sprint goal),
  3. le backlog avec la définition de prêt en plus de la définition de fini,
  4. les réunions du cérémonial renommées en événements timeboxés (timeboxed events),
  5. le scrum quotidien plus orienté vers l’atteinte du but du sprint,
  6. l’accent mis sur la valeur ajoutée.

Bien que la notion de transparence soit renforcée dans cette nouvelle version, Pablo lui y voit une limite (lire son § piliers). Ma position est que la transparence n’est pas limitée et que ceux qui accèdent à cette transparence deviennent automatiquement des parties prenantes (stakeholders).

Des chiffres !

Sur la taille de l’équipe et sur la durée des événements, Schwaber et Sutherland donnent un chiffre, correspondant au maximum pour rester dans le cadre Scrum. Pablo a l’air de trouver ça élevé. Oui, un mois pour un sprint c’est beaucoup. Et les durées moyennes sont beaucoup plus basses. Oui, 10 dans une équipe c’est beaucoup. La taille moyenne est plus faible.

Mais on ne peut pas en faire grief à Ken et Jeff, ils donnent simplement la limite à ne pas dépasser.

L’objectif du sprint

Donner un objectif au sprint est une pratique sur laquelle j’ai évolué. Je l’ai d’abord recommandée. Puis comme Pablo le fait remarquer, ce n’est pas facile de trouver un but pour tous les sprints, alors j’ai quelque peu relâché cette pratique il y a 3-4 ans[3].

Mais depuis un an environ je redonne de l’importance à cette notion de but, en la liant à l’engagement de l’équipe. Je développe cette idée dans le §7.2.5 de mon livre. Je propose de se mettre collectivement d’accord sur un objectif, non pas au début de la planification de sprint, mais à la fin. On s’engage alors sur un objectif et pas sur une liste de stories.

Affinage du backlog

Le backlog, avec son vilain grooming qui devient refinement (de mon côté je parle de culture de backlog et je vais donc passer à affinage), ses définitions de prêt et de fini, j’y reviendrai prochainement.

C’est un peu le sujet des présentations que je ferai à LeanKanban France et peut-être à Agile Toulouse et Agile Grenoble.

Mêlée quotidienne

Sur la mêlée quotidienne, Pablo a remarqué comme nouveauté une question orientée sur l’atteinte du but du sprint. On peut aussi innover avec un déroulement orienté stories (§ 8.3 de mon livre). Mais moi j’ai surtout remarqué la mention de l’équipe de développement pour le daily scrum, ce qui n’inclut pas le Product Owner. Avez-vous la même lecture que moi, ce qui signifierait que la présence du PO n’est pas requise ?

Notes

[1] qui s’appelle aussi guide, en un peu plus épais, le Scrum Guide ne fait que 14 pages.

[2] liste donnée par Schwaber et Sutherland dans la vidéo d’accompagnement.

[3] Cela se reflète dans les évolutions d’iceScrum (dont j’étais Product Owner) : le but du sprint n’est pas mis en avant du tout depuis ce moment-là.

Lire aussi