Changement et temps de réponse

Scrum, Kanban et rock'n roll !

Avec mes camarades bordelais Fabrice et Frédéric, je travaille sur la traduction de Kanban and Scrum: making the most of both.

Une des différences mises en évidence par Henrik Kniberg est le fait que Scrum n'autorise pas de changements dans le périmètre du sprint, alors qu'avec Kanban le changement est possible plus facilement (je ne rentre pas dans les détails, vous pourrez bientôt le lire).

Ce qui fait qu'en suivant strictement Scrum, le temps de réponse à un changement serait en moyenne d'un sprint et demi (en comptant le développement, jusqu'à ce que le changement soit fini), en tout cas plus long qu'avec Kanban.

Evidemment le "strictement" ci-dessus a son importance, parce que sur le terrain on peut très bien être plus souple dans la prise en compte des changements avec Scrum.

Cette notion de changement m'a rappelé une question que j'ai posée lors du QCM du module agile :


Le Product Owner veut ajouter une nouvelle story en plein milieu du sprint. Quelle est votre réaction ?

  1. Refuser poliment
  2. Accepter sans conditions
  3. Négocier le retrait d’une story en échange
  4. Demander une prime

Pour moi, la meilleure réponse est la 3 : si une story n'est pas commencée, il est possible de la remplacer par une nouvelle de taille équivalente, c'est à l'équipe de le décider. C'est que je recommande en général et c'est ce qu'on fait pour IceScrum. Je suis donc plutôt dans l'esprit Kanban.
Un expert Scrum (mais aussi Lean, pourtant) avec qui j'en ai discuté aurait choisi en premier la réponse 1. Pour une équipe qui démarre avec Scrum et qui est habituellement très perturbée par des changements, cela se conçoit.

Les résultats sur cette question, c'est : la moitié ont répondu 1, un tiers 3 et le 1/6 qui reste 2[1]. Personne pour demander une prime !

La chanson du jour, c'est Changes.

Notes

[1] pour la correction, cela a fait un point pour ceux qui ont répondu 1 ou 3 et zéro pour ceux qui acceptent sans conditions