Ca Scrum !

Au démarrage d’un nouveau projet, il est toujours bon de se rappeler les dépendances des différents concepts et l’ordre dans lequel il faut les appréhender.
Pour cela, voici le schéma que j’ai en tête :

Que signifie cette roue ?

1. Tout part du besoin exprimé. Avec Scrum, il se formalise dans le Product Backlog.
2. Ces besoins seront « valorisés » par le Product Owner. Cette valorisation est importante car dans Scrum, notre objectif est de produire le plus de valeur métier possible. La première étape est donc naturellement de la connaitre.
3. L’équipe ! Évidemment ! Est-ce que l’équipe a toutes les compétences nécessaires pour produire le logiciel attendu ? Est-elle motivée pour le faire ? Quels seront ses rituels ?
4. Définition du « Done » . Il ne peut se faire que lorsque tous les éléments précédents ont été clarifié.
5. Une fois que l’équipe s’est entendue sur le « Done », elle sera capable d’évaluer l’effort correspondant à chacun des besoins exprimés par le métier. (Poker Planning)
6. Après le Sprint 0, l’équipe connaît sa vélocité de référence. Dans un monde parfait, la vélocité devrait être le seul indicateur nécessaire au pilotage au suivi de l’avancement d’un projet.
7. La vélocité connue, il est possible de dessiner un « release plan« 
8. Si le « release plan » ne convient pas / n’est pas acceptable pour le P.O, il peut alors retravailler son Product Backlog
9. …

Il ne faut jamais oublier que Scrum est un « processus empirique d’amélioration continue » .

• Empirique : C’est en mettant en oeuvre que l’on pourra réellement obtenir de l’information du système.
• Amélioration continue : L’amélioration n’est pas seulement technique (Equipe) : elle se trouve à chacune des étapes de cette roue. Voici quelques exemples vécus lors de précédents projet :

1. L’équipe n’arrive pas à livrer de fonctionnalité lors de la démo car le P.O n’y trouve pas ce qu’il attendait : Est-ce que les fonctionnalités sont clairement exprimées ? N’y a-t-il pas de dépendances entre les fonctionnalités du Product Backlog ?
2. Je suis stressé par une fonctionnalité « critique » mais qui n’est toujours pas livrée : Ai-je bien affecté la valeur adéquate ?
3. La qualité du logiciel ne me convient pas : L’équipe est-elle intéressée à la qualité du produit ?
4. L’incrément de produit n’est jamais complet ! Soit une fonctionnalité manque, soit on ne peut pas l’installer en production car il manque la procédure : Est-ce que la définition du « Done » est réellement appliquée ? Comprend-elle réellement tous les éléments nécessaire jusqu’à l’utilisation du produit ?
5. L’équipe n’arrive jamais à tenir son engagement : Les efforts sont-ils réellement partagés par toute l’équipe ou seulement par un Gourou Charismatique ?
6. L’équipe n’arrive jamais à tenir son engagement : L’équipe mesure-t-elle sa vélocité ? De quelle manière (sous-entendu, ne compte-t-elle bien que les items « Done ») ?

Lorsque vous avez identifié l’élément qui pose problème, il faut bien penser à remonter tout la roue afin de comprendre les causes « racines » (Ceci est surtout une approche Lean).

Un exemple : L’équipe n’arrive pas à tenir son engagement :

1. L’engagement est forcé par un « Gourou » lors du Sprint Planning Meeting
2. Le « done » n’est pas toujours respecté car comme le Gourou est très occupé … Il faut bien livrer
3. L’équipe n’a pas toutes les compétences : seul le Gourou connaît la techno !

La cause racine est en fait une mauvaise constitution de l’équipe. Lors de la rétrospective, l’équipe a décider de consacrer 1 Sprint à de la formation. A L’issue de ce Sprint, l’équipe était alors capable de prendre en charge les items du début à la fin, participer à l’évaluation des efforts, … Et a naturellement améliorer sa vélocité !