Scrum, ça ne se vend pas en pack de 6

Pas plus que l'agilité ne se vend en boîte de 12

Depuis le début de l’année, j’ai participé à la mise en oeuvre de Scrum sur 8 projets différents. Les pratiques mises en place sont à chaque fois différentes. Même s’il y a un socle commun, le choix dépend toujours du contexte du projet.

Tout le monde n’est pas d’accord avec cette façon de voir les choses : certains considèrent Scrum comme un dogme intouchable. C’est apparemment le cas de Laurent Carbonnaux qui fustige les dérives dans l’application de Scrum. Il semble me considérer comme hérétique[1] pour avoir osé remettre en question l’utilité du burndown chart de sprint au profit du suivi par états.

Il est gentil de me citer, mais il me prête des pensées que je n’ai pas :

  • je n’ai pas dit qu’il fallait arrêter de faire des burndown charts de sprints. J’ai simplement dit, que dans certains contextes, on pouvait s’en passer.
  • je ne parle que des burndown charts de sprints, pas des burndown charts de release.

Scrum a été créé dans les années 90 et, heureusement, son usage évolue. Par exemple, les sprints d’un mois ne sont plus la règle absolue ni même la durée la plus courante. Sur les projets, il est nécessaire d’y intégrer également des pratiques d’ingénierie, ce qui contribue à avoir une vision sur l'ensemble des méthodes agiles.

Ma suggestion de suivre les tâches par états plutôt que par le reste à faire, elle vient du terrain. C’est sur un projet qu’il est apparu que c’était plus adapté à la culture de l’équipe. Les rétrospectives servent à ça : améliorer la façon de travailler et éviter de faire des choses inutiles en tenant compte du contexte plutôt qu’en se cantonnant à un (pseudo)dogme.

Notes

[1] tendance franco-française, ça se veut méchant ?

Voir aussi