Transformation Etape par Etape
Choix des Paramètres
Durée des Itérations
Il faut d'abord définir la durée des itérations et le jour de la semaine où chaque itération démarre.
En général, il est préférable d'opter pour la durée la plus courte (une semaine) pour les raisons suivantes :
plus de transparence et réduction de l'effet tunnel,
feedback plus fréquent du client,
possibilité de pivoter et rectifier le tir plus rapidement et fréquemment,
favorisation d'un rythme régulier et durable en évitant les coups de stress en fin d'itération,
calcul plus précis de la vélocité et projection plus précise (e.g. : avec des itérations de 3 semaines, il faut attendre plus de 2 mois avant d'avoir la vélocité moyenne sur les 3 dernières itérations),
si un membre de l'équipe rate un événement, cela devient problématique car le prochain événement aura lieu dans plusieurs semaines,
il est plus facile de coordonner des équipes qui démarrent une nouvelle itération chaque lundi. Autrement, les itérations s'enchevêtrent.
Si vous avez besoin d'itérations plus longues, posez-vous d'abord les questions suivantes :
si vous constatez une volatilité importante de la vélocité ou effet tunnel (i.e. : des itérations ne produisant aucune valeur suivies d'itérations produisant un nombre important de points), est-ce possible de découper les User Stories encore plus finement ?
est-ce possible de réduire le Work-In-Progress Limit ?
si certains événements prennent trop de temps, est-ce que le Definition of Ready est bien respecté ? Est-ce possible d'améliorer le Collective Ownership pour raccourcir les discussions ?
Des itérations plus longues nécessitent plus de préparation et des Sprint Planning plus longs. Si lors du Spring Planning, vous ne préparez qu'une partie de l'itération en attendant le prochain Backlog Refinement, vous êtes peut-être en train de créer une itération au sein de l'itération 😉
Échelle de Points (ou Point Scale)
Il est nécessaire de sélectionner un Point Scale pour évaluer l'effort nécessaire pour chaque User Story.
Nous vous recommandons les échelles :
1, 2, 3 & 8
ou 1, 3, 5 & 15.
où la dernière valeur sert à estimer les User Stories qui nécessiteront d'être découpées ultérieurement. On ne démarre donc pas le développement d'une User Story à 8 ou 15 points.
Nous préférons ces échelles pour les raisons suivantes :
en réduisant le nombre de valeurs possibles, vous réduisez également l'hésitation et la durée des Spring Planning et Backlog Refinement,
ces échelles encouragent le découpage des User Stories,
l'échelle S, M, L & XL est également intéressante mais il faut reconvertir en points pour calculer la vélocité et la projection.
Astuce : dans le cas de planification moyen ou long terme, n'hésitez pas à réduire l'échelle (e.g. : 1, 3 & 8) afin d'accélérer le temps d'estimation en sacrifiant légèrement la précision qui sera probablement erronée dans tous les cas.
Work-In-Progress Limit
Définir un WIP limit relativement bas encourage naturellement le Collective Ownership, le Pair Programming et favorise la communication.
A vous d'expérimenter, mesurer et trouver le WIP limit qui vous convient mais la formule suivante est généralement un bon point de départ :
Definition of Done
L'équipe doit définir son propre Definition of Done puis l'enrichir en fonction de son expérience et ses erreurs.
Definition of Ready
De même que pour le Definition of Done, l'équipe doit définir et maintenir son Definition of Ready.
Préparation de la Première Itération
Premières User Stories
Définissez les premières User Stories conformément au Definition of Ready ; lors d'une session de User Story Mapping par exemple.
Choix des Technologies et Outils (si applicable)
Si vous devez choisir les technologies et outils à utiliser, focalisez-vous sur la simplicité, la maintenabilité et la facilité de changer plus tard.
Pensez à vous faire accompagner dans ce choix.
Recrutement (si applicable)
Recrutez progressivement !
Une rencontre avec l'intégralité de l'équipe pourrait être l'avant dernière étape de recrutement ; la dernière étant une semaine d'essai au sein de l'équipe.
Indicateurs
Pensez à choisir et mesurer vos indicateurs avant de démarrer !
Rencontre Directe avec le Client et les Utilisateurs
Pas d'Intermédiaires
Le Product Owner ne doit pas être un intermédiaire entre l'équipe et le client.
Généralement, il faut éviter les intermédiaires car inconsciemment l'information sera toujours déformée et filtrée.
Il est donc important que l'intégralité de l'équipe et le client puissent échanger au moins lors du Sprint Review.
Faites tout de même attention aux clients envahissants !
Rencontrez vos Utilisateurs !
Organiser des rencontres et échanges directs entre une sélection d'utilisateurs finaux et l'équipe permet de démystifier de nombreux aspects concernant l'utilisation du produit.
La rencontre fournit donc un indicateur qualitatif supplémentaire.
Sprint Review
Organisez des Sprint Review même en l'absence du client et invitez d'autres équipes ou les curieux.
Certaines entreprises affichent les horaires de Sprint Review des différentes équipes dans leurs couloirs.
Transparence et Propagation
Soyez transparents et sincères !
Expliquez votre approche aux autres équipes et partagez votre expérience !
Last updated