Durée de vos sprints en 2013, résultats et commentaires

Le gagnant est ... le sprint de 2 semaines.

Je remercie chaleureusement les 212 votants, c'est 2 fois plus que lors de mon sondage précédent sur le même sujet, en 2010. Ca va faire un beau camembert dans la prochaine version de mon livre.

Voilà ce que ça donne :

Je ne sprinte pas

8.49 % de réponses alors qu'il y en avait 9% il y a 3 ans.

C'est à peu près stable, mais difficile à analyser. Je ne sais pas dire quel est dans ce total la part de ceux qui ne sprintent pas parce qu'ils n'appliquent pas Scrum et la part de ceux qui faisaient du Scrum et sont passés à Kanban.

Avec le commentaire d'Emilie, je pense qu'il est probable que des répondants au sondage n'appliquent pas vraiment Scrum ni une approche agile, mais ont cependant donné une durée de sprint. En effet, ce que raconte Emilie "une semaine de traitement côté dev, une semaine de recette côté client" n'est pas Scrum ni Agile. A Emilie qui débute, je dis simplement que la recette qu'on appelle plutôt acceptation se fait dans le même sprint que le dev.

Une semaine

9.43 % en 2013 contre 9% en 2010. Très légère hausse.

On aurait pu croire que la tendance pressentie à la réduction de la durée donnerait un plus grand nombre de sprints d'une semaine. Ce n'est pas le cas.

Deux semaines

41.51 % alors qu'il n'y en avait que 37% il y a 3 ans.

La durée de 2 semaines est celle la plus fréquemment utilisée, sans devenir la norme pour autant.

Trois semaines

25.47 % contre 35% en 2010.

Une baisse significative pour les sprints de 3 semaines. C'est assez étonnant, alors que ceux de 2 ou 4 semaines sont plus nombreux.

Quatre semaines ou plus

8.49 %. C'est plus que les 6% de 2010.

Une explication peut être le plus grand nombre de projets de grande taille dans des secteurs industriels. L'Agilité à grande échelle a tendance à faire choisir une durée plus longue, pour limiter les risques.

Ca dépend des sprints

6.6 % alors qu'il n'y en avait que 4% dans le sondage précédent.

L'énoncé de la réponse ne permet pas de dire s'il s'agit de débutants en Scrum qui n'appliquent pas le principe de la boite de temps ou bien d'équipes expérimentées qui sont sorties de ce carcan, soit pour équilibrer la capacité, soit pour déployer dès que c'est possible.

Commentaires

1. Le lundi 28 janvier 2013, 09:02 par pablo

"L'Agilité à grande échelle a tendance à faire choisir une durée plus longue, pour limiter les risques."

drôle de phrase, faudra me convaincre à l'occasion. bye

Je tente une reformulation : quand plusieurs équipes participent au développement d'un seul produit, elles préfèrent généralement, pour arriver à un incrément potentiellement utilisable à la fin du sprint, allonger la durée pour tenir compte du temps pouvant être nécessaire pour se synchroniser entre les équipes.
Pablo, c'est plus clair ?
2. Le mercredi 30 janvier 2013, 22:25 par Alexandre

On diminue donc les risques en augmentant l'effet tunnel ? On augmente surtout le risque de ne pas avoir de produit potentiellement livrable toutes les deux semaines en acceptant dès le départ d'échouer une fois sur deux.

Les pratiques du déploiement continu assureront, à mon avis, une meilleure limitation de ce risque.