Définir et évaluer les tâches permettant de réaliser les stories. Est-ce utile ou néfaste ?


Lors de la deuxième partie du sprint planning, l’équipe revoit les stories sélectionnées dans le sprint backlog et détermine les actions à prendre pour réaliser ces stories.

Dans bien des cas, elle essaie d’identifier toutes les tâches, de la facon la plus exhaustive possible, qui seront nécessaires à l’accomplissement de la story.
En même temps elle essaie d’évaluer le temps que prendra chaque tâche. Les tâches étant découpées suffisament petites pour ne jamais depasser 2 jours hommes, on pense être en mesure d’avoir une évaluation précise.

Avons-nous besoin de ces informations ? Nous sont-elles utiles ou néfastes ?
Le besoin :
En fait le besoin exprimé pour cette information provient de notre vieille habitude de waterfall, on ne fait que transformer les sprints en mini-projets waterfall. Partant de cela on prétend avoir une analyse exhaustive et des délais parfaitement évalués.

Agir ainsi c’est un peu oublier ce qui nous amène à Scrum : reconnaitre qu’un développement de logiciel est un projet complexe d’une part, et que l’humain n’est pas habile à évaluer dans l’absolu d’autre part.

Il y a aussi un besoin de rassurance qui nous pousse à vouloir définir et évaluer : est-ce-que les stories choisies sont réalisables dans la durée d’un sprint ?
À cela deux réponses :

  • La première qui répond encore à ce besoin de plannification : Scrum, à travers l’étude statistique de la vélocité de l’équipe nous fournit un indicateur qui nous permet d’identifier le volume (en temps que complexité ) de stories qui seraient réalisables dans un sprint.
  • La deuxième sous forme de question plus philosophique : Vu que le backlog de sprint n’est absolument pas un engagement, quel est l’interêt de savoir si il est vraiment réalisable ?

Il y a aussi le product owner et le manager de l’équipe de développement qui expriment le besoin de voir que les choses avancent.
Ils disent vouloir voir que l’on est dans le temps… Dans le temps de quoi ?
Le temps lui est un élément fixe, mais dans un sprint c’est le périmètre qui est ouvert. L’équipe, elle, fait de son mieux pour réaliser un maximum de stories d’un niveau de qualité supérieure.

Et puis ultimement ce n’est pas le temps qui interesse le product owner ce sont les STORIES!
Donc la vraie métrique qui l’interesse ce n’est pas le burndown en heures mais plutôt le burnup en stories.
Le burnup en tâches est aussi une métrique interessante si on garde en tête que le découpage initial n’est pas exhaustif et qu’il s’ajoutera des tâches tout au long du sprint.

L’utilité :
Ces informations ne pourraient être utiles que dans la mesure ou elles seraient exactes.
Or elles ne peuvent être exactes que lorsque l’équipe est inchangée et collabore depuis longtemps, lorsque la technologie est maitrisée et lorsque la complexité des stories est faible et l’incertitude inexistante. Donc dans la pratique on peut affirmer que cela ne sera jamais utile ou rarement sur des projets en phase-out.

Ces informations seront en fait utiles lorsque l’on commence à adopter Scrum, elles serviront à demontrer qu’elles ne sont pas fiables et donc inutiles. C’est un peu paradoxal j’en conviens mais Je demeure convaincu que c’est une étape nécessaire de l’apprentissage et de l’appropriation de la philosophie agile scrum.

Néfastes :
Ces informations créent une pression indue et donc un stress sur l’équipe et sur le product owner. J’ai déjà lors d’un post précédent abordé le problématique du stress dans les équipes agiles-scrum, et j’avais alors expliqué le lien entre la notion de délai, de temps évalué et le stress ressenti par les membres de l’équipe.
Lorsque les membres de l’équipe débordent du temps évalué, la qualité s’en ressent immèdiatement : on tourne les coins ronds, on bacle les tests d’intègration et on oublie les tests manuels.

C’est d’ailleurs en abordant un problème de qualité par l’approche des « 5 pourquoi » que l’on a réalisé ce qui m’a amené à écrire cet article. En voici, en substance, le contenu.

Pourquoi est-ce-que la qualité n’est pas satisfaisante?
Parceque l’on n’accorde pas l’attention nécéssaire aux tests et à la qualité même.

Pourquoi on n’accorde pas l’attention ?
Parcequ’on déborde déjà du temps évalué.

pourquoi est-ce-que l’on déborde ?
Parceque l’on a sous évalué.

Pourquoi avons-nous sous évalué ?
Parceque c’est complexe et qu’on ne maîtrise pas forcement la technologie.

Pourquoi on continue à évaluer si c’est si complexe et si souvent erroné?
Pour s’assurer de se stresser inutilement ?

La solution : ne pas évaluer !

Quelle décision avons nous prise en rapport à ceci ?
Ne plus évaluer le temps des tâches, le statut « à faire », « en cours » et « fini » sera suffisant.

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.