Les pieges pour une jeune équipe agile : la perte de focus, l’écart à la définition de fini


Lorsqu’une compagnie décide de prendre le virage de l’agilité, ses équipes de developpement font face à de nombreux pièges.
Bien sur l’ajout de scrum master experimentés aiderait grandement à prévenir l’équipe face à ces pièges, la réalité est que dans la plupart des cas l’entreprise va vouloir effectuer cette transition avec les effectifs déjà en place.
Dans cette optique il est impératif de former des employés à certains des rôles importants d’une équipe scrum.

1: un Product Owner, il faudra déjà identifier la bonne personne, quelqu’un qui connait le metier, les attentes du marché. Une personne qui allie à la fois des compétences techniques et commerciales serait idéale.

2: Des scrum master, il faudra prevoir deux scrum master par équipe afin qu’ils puissent se valider et se surveiller l’un l’autre pour s’assurer que celui qui jouera le role pendant le sprint n’oublie rien et ne devie pas du processus. On leur donnera le rôle en alternance de 2 ou 3 sprints.

Dans notre cas, j’ai suivi les deux formations, je joue donc le role de PO mais aussi celui de facilitateur et de coach agile auprès de l’équipe et des scrum masters.
C’est ce qui me permet de déceler les pièges dont je vais vous parler.

Le premier que je vous présente est la perte de focus.
Il faut se rappeler qu’un des objectifs du processus scrum est de maximiser la valeur de ce qui est créé en éliminant le superflus.
Pour les programmeurs qui ont une longue experience de développement waterfall, l’élimination du superflus n’est pas du tout une habitude.
Et dans le pire cas cela risque de se présenter comme suit :
Votre Product Owner va construire un backlog priorisé allant à l’essentiel.
L’équipe selectionnera ce qu’elle peut réaliser dans le prochain sprint en respectant les priorités du po.
Le sprint commence l’équipe ajoute des tâches reliées aux stories mais certaines de ces taches vont au dela de ce que decrivent les stories, elle en vient a fabriquer un marteau pneumatique pour écraser une mouche.
Elle anticipe sur ce qu’elle pense que le po priorisera pour les prochains sprints.
Et puis l’équipe identifiera des taches « urgentes » pour répondre à des besoins technologiques et réalisera ces tâches au dépend de celles nécessaires aux stories.

Le deuxième est l’écart à la définition de fini :
L’équipe oublie de se referer à la définition de fini pour valider que les stories qu’elle considère terminées le sont bel et bien.
Unvou plusieurs des éléments ne correspondent pas. Par exemple on oublie de valider un des browsers sélectionnés.

Résultat : peu ou pas de stories sont considerées finies.
Est-ce-que ce sprint est un echec ? Absolument pas, il est une source d’enseignements considérable !

Maintenant que l’on a identifié ces pièges, on peut trouver des pistes de solutions.
1- lors de chaque création de tâche reliée à une story, relire la story ET la définition de fini et se poser la question suivante « Comment cette tâche m’aide-t-elle à terminer cette story ?  »
Si la réponse n’est pas évidente, pourquoi réaliser cette tâche ? Plutôt se reposer la question « Comment finir cette story ou comment la finir mieux ou différemment ?

2- lors de l’ajout de tâches « urgentes » non reliées directement à une story, se poser la question suivante « Quel obstacle qui bloque la réalisation de stories de ce sprint cette tâche va-t-elle permettre d’éliminer et comment pourrais je le faire sans cette tâche ou avec une meilleure approche? »
Si la tâche demeure la meilleure option … go for it !
Sinon il faut se poser la question suivante  » Comment cette tâche va me permettre de réaliser les stories plus rapidement et m’assurer de les finir dans ce sprint et comment pourrais je faire autrement ou mieux ? »

Si la tâche ne demeure pas un réel levier dès ce sprint, bien qu’elle puisse être justifiée elle n’est pas urgente et devrait etre réevaluée et repriorisée avec le PO.

3- En tout temps chercher le chemin de moindre résistance permettant de créer la valeur ajoutée attendue par la story en éliminant le superflu.

4- Imprimer la définition de fini et la mettre très visible dans un lieu de passage ou bien exposée sur chaque cubicule afin qu’on s’en impreigne.

5- Se faire de mini démos en cours de sprint entre les membres de l’équipe pour valider l’aspect fini de chaque story terminée.

Advertisements