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.

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.

Voici les 6 changements apportés[2] :

  1. plus d'insistance sur la transparence,
  2. la planification de sprint avec le but 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).

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.

Donner un but au sprint est une pratique sur laquelle j'ai évolué. Je l'ai d'abord recommandée. Puis comme Pablo le fait remarquer, j'ai constaté que ce n'était 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 but, non pas au début de la planification de sprint, mais à la fin. On s'engage alors sur un but et pas sur un résultat (une liste de stories).

Le backlog, avec son grooming qui devient refinement (de mon côté je parle de culture de backlog), 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.

Sur le scrum quotidien, 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à.

Commentaires

1. Le mercredi 14 août 2013, 15:07 par CK

"la présence du PO n'est pas requise"
effectivement, celle du SM non plus, pour l'équipe de dév et par l'équipe de dév.
Ça se reflète ds la nouvelle formulation des questions.

Le SM est quand même mentionné comme facilitateur de l'événement. Je recommande que le PO (et le SM), en plus de jouer leur rôle, fassent partie de l'équipe de développement (il ne faut pas comprendre qu'ils doivent coder pour en faire partie) et avec cette appartenance, leur présence est requise au scrum quotidien. Le Scrum Guide laisse ouverte cette possibilité, page 6 : The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog. Exécuter le travail du sprint, c'est simplement participer à la finition d'une story, ce que font le PO (au moins en répondant aux questions) et le SM (au moins en participant à l'élimination des obstacles).
2. Le dimanche 18 août 2013, 10:55 par Pablo

Merci Claude, je viens de noter que mon passage de Pelican à la 3.2 avait fait disparaître le lien vers le page contact/feedback.
bye