Pourquoi faire des itérations en méthode Agile? Plus particulièrement en Scrum?
Et bien cette question touche à l’essence même de l’agilité en gestion de projet. Voyons pourquoi.
Se fixer des objectifs
C’est le principe de base. Chaque itération doit être liée à un objectif. Derrière cet objectif l’équipe va s’organiser pour l’atteindre. La planification de l’itération en découle donc forcément.
Sans cela, navigation à vue garantie!
Capitaliser
En réalisant une itération / un sprint, il y a des situations rencontrées, du travail effectué, des galères, des choses qui marchent, des interactions sociales, du stress, des nouveaux besoins… . Bref, toute une activité qui se déroule avec ses points forts et ses points faibles.
S’AMÉLIORER. C’est un point essentiel. Derrière cette période passée il y a des expériences plus ou moins réussies. Le but est de conserver ce qui fonctionne et tenter d’éliminer ce qui coince. D’ailleurs l’un est tout aussi important que l’autre.
Pour arriver à s’améliorer, faire une rétrospective en fin d’itération est important mais pas que. C’est une possibilité qui est offerte durant toute la période de l’itération.
Les “stand up meeting” peuvent être d’ailleurs un excellent moyen de mettre sur la table des propositions ou des actions qui ont permis d’aller plus loin.
FAIRE LES BONS CHOIX PRODUIT. L’itération est le déroulé d’une planification de travaux à mener. Pendant et en fin d’itération il est important de bien se poser les bonnes questions sur le suivi de la ligne produit. A-t-on fait les bons choix? Apportons bien les points de valeur là où il faut? A-t-on mis en place la bonne architecture pour répondre au prochains besoins?
Ces questionnements vont permettre de s’assurer que les travaux menés s’accordent pleinement au client qui ,on le sait, peut avoir des besoins qui évoluent au fil des livraisons.
Le résultats sera possiblement un ajustement de la vision produit notamment sur les prochaines itérations. Il faut d’ailleurs, je le conseille toujours, avoir une vision sur 3 mois minimum.
Livrer régulièrement
Éviter l’effet “Tunnel”! C’est un enjeu majeur. Pour cela les itérations permettent de produire de manière cadencée et régulée. Chaque fin d’itération est le moment rêvé pour livrer de nouvelles fonctionnalités, améliorations ou corrections.
Sans cela, il y a un fort risque de déraper et de décaler sans cesse des livraisons jusqu’à “rusher” dans le stress en dernière minute!
Dynamiser l’équipe
Les itérations permettent de cadencer le projet. Peut importe si tout se passe bien ou s’il y a des problèmes, il est important de garder une bonne dynamique d’équipe.
En effet, en fonction de la durée du projet et des ses aléas, une certaine routine peut s’installer.
Les itérations marquent les moments, et permettent de s’obliger à évaluer ce que l’on produit. Ainsi, par exemple en fin d’itération, il est important de marquer les succès et reconnaitre le travail qui avance auprès de tous.
La fin d’une itération suivi d’un “after work”, un stand up café/croissants, une rétrospective fun et originale sont par exemple des moments tous particulièrement appréciés et qui permettent de souder une équipe.
Communiquer auprès des parties prenantes et des utilisateurs
La fin d’une itération est généralement signe d’une livraison de nouvelles fonctionnalités.
Il est parfois tentant d’enchaîner tête baissée sur le prochain sprint sans communiquer correctement sur la livraison.
C’est une erreur classique mais qui, si elle est répétée, peut nuire gravement au projet.
Ainsi, il faut prendre l’habitude d’informer les parties prenantes (et si possible les utilisateurs) sur les principales avancées.
Cela peut prendre la forme d’un e-mail, d’un post sur un réseau social, d’une vidéo… .
Documenter
Faire des cycles courts permet aussi de se poser la question de la documentation.
Plutôt que de traîner et d’attendre la fin du projet pour le faire, mieux vaut mettre à jour sa documentation aux grès des itérations.
Sans faire un roman il est intéressant de synthétiser les avancées dans la documentation.
D’expérience, les user stories sont une mine d’or mais peuvent être vite compliquées à consulter sur des gros projets. D’où l’intérêt d’en tirer l’essentiel sur un wiki ou une documentation plus classique.
