C'est une question intéressante, suite à un échange sur une liste parlant de Scrum je reste étonné que personne n'ai relevé cette erreur, mais c'est l'occasion de rappeler les bases.

(une itération, ou sprint est une période de temps fixe pendant laquelle une équipe de développement à estimé pouvoir produire un nombre de points de complexité représentant un volume de tâches à réaliser).

Rappelons d'abord ce qu'amène l'agilité par rapport aux modes projets

Dans un mode projet traditionnel, on garantit :

  • la tenue d'un planning
  • le nombre de fonctionnalité livrée
  • le coût pour le client (enfin on essaye, la tradition des avenants en fin de contrats reste tenace)

=> On ajuste les écarts avec la qualité du code livré (mode L'arrache pour boucler et tenir les engagements qui entraine une baisse de qualité si on à sous-estimer la charge et sur-qualité ou développement de fonctionnalité non demandée si on a sur-estimer la charge).

Dans un mode agile, on sort du mode prédictif pour être dans un mode adaptatif, on garantit :

  • la date de livraison (fin d'itération)
  • le coût pour le client
  • la qualité (définie par la "définition de terminé")
  • l'indépendance du client (à chaque livraison le logiciel est utilisable avec un code suffisamment clair pour être éventuellement repris par d'autres, le client peut donc dire "stop" ou "encore"), on s'adapte avec ce qui à été livré.

=>On ajuste sur le nombre de fonctionnalité livrée (on n'est pas dans un projet, il n'y a pas de check liste à finir, simplement un service à rendre au client qui doit être rentable pour que le client continue).

Pour le cas pratique exposé sur cette liste de diffusion, L'équipe à livré 5 points au lieu de 38 et l'itération à été qualifiée de "ratée"

Dans une logique Scrum, il faut simplement constater que l'équipe une capacité à livrer de 5 points de complexité, elle ne va donc pas s'engager sur plus de 5 points pour la prochaine itération (on peut aussi prendre la moyenne des points livrés pour le prochain engagement, selon le contexte).

Scrum invite aussi à comprendre d'ou vient la différence, à vérifier si le client est satisfait de l'argent que lui à couté cette itération et de voir si il est prêt à continuer à payer l'équipe à ce tarif là.

Dans un mode agile, l'équipe s'engage à faire de son mieux, à livrer une qualité constante et à ne pas mettre le client en situation de dépendance, le client paye pour voir et si l'équipe à envie d'être renouveler elle à intérêt d'être rentable et de communiquer beaucoup avec le client.
Donc on ne peut pas se planter, on peut ne pas avoir été rentable... et si on ne sait pas dire quand l'itération à été rentable, il vaut mieux arrêter tout de suite de dire que l'on fait du Scrum et de parler de "gestion de projet itératif".

Considérer qu'une itération peut être "ratée" en expliquant que l'on a pas tenu le planning c'est que l'on est en mode projet itératif... A la rigueur une itération ratée, c'est une itération pendant laquelle la relation client tellement déplorable (et une relation ça se fait à 2) qu'après celle là, le client ou l'équipe dit Stop, rien à voir avec des critères de performances d'atteinte de résultats hérités de la gestion de projet (ça se trouve l'équipe à largement rentabiliser son salaire avec les 5 points de complexité livré).

Scrum n'est pas simple, c'est subtil, et ça vient d'une autre culture de travail, c'est délicat à appliquer en France car (entre autre) on à pas exactement le même marché du travail ni la même mobilité professionnelle....