Scrum au-delà du projet, pour des produits et des organisations

C'est le sujet de ma présentation de l'après-midi au Scrum Day.

Avant d’aborder l’au-delà, il faut d’abord définir ce qui pourrait désigner un projet avec Scrum.

La définition classique (celle du PMI) est la suivante : un projet est un effort temporaire dans le but de créer un produit, un service ou un résultat unique. Avec Scrum, l’effort du sprint permet d’obtenir un incrément de produit et, après les efforts de plusieurs sprints, le résultat correspond au produit. L’équivalent le plus proche de la notion de projet serait, avec Scrum, la release, vue comme une suite de sprints.

On peut donc assimiler en Scrum un projet à l’effort d’une équipe qui développe une version d’un produit, pendant la durée d’une release. Quelques chiffres pour mieux illustrer ce que pourrait être un projet moyen : une équipe Scrum a entre 3 et 10 personnes, et une release dure entre 2 et 6 mois. Pendant cette release, l’effort va porter sur la réalisation d’un backlog de 30 à 80 stories.

Le but de cette présentation est de montrer comment Scrum peut s’appliquer quand les dimensions classiques d’un projet (périmètre, taille, délai) vont au-delà de ces chiffres :

  • Quand le nombre de personnes va au-delà de la limite Scrum pour une équipe. Il faut donc plusieurs équipes, définir la façon dont elles vont se partager le travail et se synchroniser.
  • Quand l’effort n’est pas temporaire. Il ne s’arrête pas à la release de quelques mois, mais concerne toute la vie du produit.
  • Quand le périmètre concerné est bien supérieur à quelques stories. Il porte sur plusieurs centaines de stories, et pour garder une bonne visibilité, il convient d'utiliser des notions de plus haut niveau, comme la feature et l'epic.

C'est jeudi, jour de Scrum, à 14h30, dans la salle Rubis, avec la participation de Christophe Vanbelle, DSI de Sarenza, qui a choisi de faire de la transition à Scrum un projet d'entreprise.

Commentaires

1. Le mercredi 30 mars 2011, 16:17 par ja

On demande aux équipes d'être agile, et on parle peu de l'agilité du management, et pourtant le budget, les contrats, le contrôle de gestion, le reporting, la sous-traitance au forfait, le contrôle qualité, le cloisonnement en silo, tout cela entrave un organisme qui se voudrait agile.
Je suis peut être en train de polluer le post, mais c’est son titre qui m’a interpellé. Alors qu’un projet classique c’est : je fais les spec. je calcule un ROI bidon et j’oublie, et j’ai un responsable bouc émissaire si cela se passe mal. Avec un projet agile, le reporting est qualitatif, la mesure de la valeur est permanente, le responsable c’est moi.
Au delà du projet, comment une organisation devient Scrum compatible ?