Iteration Review

En fin de semaine, l’équipe prendra une heure pour faire un point sur le déroulé de l’ensemble de la semaine ; ils feront une « iteration review ». Ce moment de partage permettra d’atteindre les objectifs suivant :

• revue de l’ensemble des éléments qui ont été réalisés
• revue de l’ensemble des éléments qui n’ont pas été réalisés alors que l’équipe pensait pouvoir les faire
• discuter ensemble des perturbations rencontrées
• faire un point sur l’état d’avancement du framing agile

Il est important de comprendre que l’iteration review est la fermeture de la cérémonie totalement en lien avec la planning meeting réalisée dès le démarrage de la semaine (soit de l’itération). Le framing master animera cette réunion afin de lui donner un maximum de dynamisme et pour que la réunion atteigne les objectifs de sa raison d’être.

L’iteration review n’est pas une sprint review

Contrairement au scrum (pour ceux qui connaissent ce framework), cette cérémonie ne se fera qu’avec les membres de l’équipe du framing agile ; en effet, cette iteration review n’a pas l’objectif d’amener à des feedbacks sur les rendus. Les feedbacks sur les rendus doivent normalement se réaliser tout au long de la semaine avec l’ensemble des utilisateurs, sponsors et parties prenantes.

Il est donc important de bien lire le contenu de l’iteration revue qui est adaptée au déroulé du framing agile. Faire l’iteration review comme une sprint review classique pourrait amener à omettre des éléments importants pour la suite du framing agile.

Déroulé de l’iteration review

Revue des éléments réalisés

La première étape de cette cérémonie est de faire un point sur tous les éléments du « done » sur le board. L’équipe sous l’impulsion du framing master, parleront de chaque demande en « done », l’une après l’autre en tentant de donner les éléments suivants :

• contenu de la demande
• est-ce que la demande a pris plus de temps que préalablement imaginé ?
• a-t-on rencontré des difficultés ou des perturbations dans sa réalisation ?
• a-t-on découvert de nouveaux éléments à partir de cette demande qui demandera un travail complémentaire par la suite ?

Certaines questions peuvent paraitre simpliste ; cependant le déroulé intensif du framing agile peut amener les équipes à avoir oublié des éléments qui seront clés pour les prochaines itérations. Il est donc important de s’assurer de prendre ce temps pour remettre tout à plat ; cela permettra de mieux redémarrer dès la prochaine itération.

Revue des éléments NON réalisés

Lors de l’iteration review, l’équipe doit impérativement discuter sur les éléments non réalisés. l’équipe traitera en premier, toutes les éléments de la colonne « in progress » avant de parler des éléments de la colonne « todo this week ».

Sur chacun des éléments de la colonne « in progress », l’équipe devra ensemble répondre aux questions suivantes :

• Contenu de l’élément
• N’avons-nous pas terminé par manque de temps ?
• Si non, est-ce que l’élément était plus long que prévu à mettre en oeuvre ?
• Avons-nous été perturbé par des ajouts dans le « todo this week » qui nous ont amené à prendre du retard ?

Bien évidemment, si les réponses sont identiques pour tous les éléments de la colonne « to do this week », il ne sera pas nécessaire de répéter celles-ci pour chaque élément. Le plus important est de s’assurer que tout ce qui a fait évoluer le plan prévu initialement en début d’itération soit clair pour l’ensemble de l’équipe.

Attention, il est important de rappeler que l’équipe a tenté de s’engager sur un scope mais qu’aucune sanction ne doit être émise si le plan initial a évolué ; nous sommes dans un contexte agile et l’équipe ainsi que les acteurs autour de cette équipe doivent être ouverts au changement de plans. Ces changements de plans était probablement essentiels pour un meilleur déroulé de l’itération.

L’équipe ne traitera que les éléments du « todo this week » si cela est réellement nécessaire. En général, tous les éléments ont été déjà cités précédemment excepté si une demande n’a pas été prise en charge à cause d’une dépendance imprévue.

Discuter ensemble des perturbations rencontrées

Maintenant que l’ensemble de la revue des éléments a été réalisée, il est essentiel que l’équipe ensemble prenne le temps de discuter des différentes perturbations rencontrées. L’équipe devra définir une issue possible pour chacune des perturbations :

• 100% terminées, aucune possibilité d’action
• risque de rencontrer à nouveau cette perturbation : ajouter celle-ci au « risk board » présent dans l’Obeya
• action déterminée à mettre en place dès la semaine suivante (responsabiliser un membre de l’équipe, ajouter l’action au kanban)

Ce travail permettra réellement d’affiner le déroulé du framing agile et d’amener l’équipe à diminuer les perturbations futures. Cette cérémonie fait également office de rétrospective pour ceux qui connaissent bien le scrum.

Etat d’avancement du framing agile

L’équipe fera un état d’avancement des travaux réalisés par rapport au framing agile dans son intégralité. L’équipe pourra d’ailleurs ensemble définir si elle pense que le framing agile avance dans le bon sens ; sinon, le framing master devra envisager de faire une demande d’ajouter des itérations complémentaires nécessaires pour être en réelle capacité de lancer la phase de réalisation.

Ce constat est souvent très intéressant. Il n’est pas rare que les avis divergent sur la capacité de finaliser ce cadrage dans les temps. Cela permet ainsi d’ouvrir à de réelles échanges constructifs. Le framing master fera le nécessaire pour que chaque membre puisse exprimer son avis ; il devra d’ailleurs également donner le sien.