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.

Advertisements

Faire une rétrospective positive


Depuis peu, j’ai commencé avec mes équipes à utiliser des techniques de gamestorming et de rétrospectives différentes du schéma classique afin de travailler d’autres aspects de la collaboration et de la réflexion sur le déroulement des sprints.

Celle que je vous présente aujourd’hui est une rétrospective d’appréciation, une rétrospective positive.

Première étape : Check- in (15 minutes)
Il est important, spécialement au début d’une rétrospective de donner à chacun l’occasion de s’exprimer sur l’état d’esprit dans lequel il se trouve au moment d’aborder cette rétrospective. Cela permet de voir comment le sprint a affecté chaque membre de l’équipe. On peut y aller avec un mode de jeton (chacun son tour) puis permettre à qui en ressent le besoin de revenir sur ce qui a été exprimé par ses coéquipiers.
J’accorde en général 3 minutes par personne.

Deuxième étape : mise en place (5 minutes)
Il s’agit ici d’expliquer le déroulement global de la séance de rétrospective, d’en indiquer la durée, la mécanique et l’objectif. Le temps de chacun étant précieux, il est important pour les participants de savoir que celui-ci n’est pas gaspillé, mais au contraire bien organisé et orienté vers un objectif clair.

Troisième étape : appréciation individuelle collective (10 minutes)
Chaque participant va devoir écrire un message d’appréciation à au moins un des autres participants ( finalement ils en écriront pour chaque membre). Une fois que ceci est fait, tour après tour chaque participant lit les appréciations qu’il a écrites aux autres à haute voix. Cette étape force tous les participants à interagir et met en place une logique positive.

Quatrième étape : collecte de données positives (10 minutes)
Idéalement, on dispose de post-it de 3 couleurs. On associe à ces couleurs les thèmes suivants : forces, succès et événements/moments.
Chaque participant va noter sur les post-its de la bonne couleur les éléments correspondants à ces thèmes qui se sont produits durant le sprint.
Donc il notera tout ce qui selon lui aura été des forces pendant le sprint, que ce soit au niveau personnel, équipe, environnement, processus, expert externe, outils, compagnie, collègues, etc. Même chose avec les succès et les moments ou événements marquants positifs.
Il est important de noter un seul élément par post-it.
À l’issue de cette étape, on collecte les post-its et on le colle dans un secteur du tableau blanc.

Cinquième étape : projection dans un futur utopique (15 minutes)
Présenter que l’on est à la fin du sprint suivant, et que ce sprint est le sprint de nos rêves, il n’est composé que de forces, de succès et d’événements positifs.
Quels sont-ils ?
Pour y répondre, on refait le même exercice qu’à l’étape précédente, avec les mêmes thèmes et les mêmes couleurs de post-it.
On récupère les post-its et on les place de l’autre côté du tableau.
Dans d’autres formes de rétrospective on identifie ce qui a moins bien fonctionné que ce que l’on aurait aimé, dans cette forme-ci de rétrospective, cette étape mène le participant à repenser les mêmes éléments mais en les imaginant parfaitement positifs.

Sixième étape : regroupement, mapping et collaboration (20 minutes)
On invite tous les participants à se rejoindre devant le tableau.
On leur propose d’examiner ensemble tous les post-its présents.
Ensuite, ils doivent relier, regrouper les post-its par thème, idée ou logique. ( Pas les thèmes succès forces et événement, mais plutôt des idées telles que technique, collaboration, éthique, environnement, processus… En bref ce que l’on peut déterminer depuis les post-its).
Il est normal de mélanger ce qui vient de la cinquième et ce qui vient de la quatrième étape.
Cette étape permet à chacun de prendre conscience de ce qui pour les autres est un élément positif important, on bâtit ainsi une compréhension collective des succès, des forces et des évènements importants.
En même c’est un exercice qui renforce la communication et la cohésion de l’équipe en la poussant à collaborer.

Septième étape : vote (5 minutes)
Chaque membre de l’équipe possède deux votes qu’il va pouvoir attribuer aux thèmes de ces choix. Il peut très bien décider de donner deux votes au même thème et aucun aux autres.
Sur quels thèmes voter ?
Chaque participant choisi le ou les thèmes sur lesquels il aimerait que l’équipe réfléchisse à comment en faire ou continuer à en faire des succès, des forces et des événements positifs.
On accorde quelques minutes pour faire le choix.

Huitième étape : remue-méninges à jeton (30 minutes)
On reprend les 2 thèmes qui ont remporté le plus de votes à l’étape précédente, et on rediscute tous ensemble de chacun des post-its qu’ils contiennent. On peut utiliser un système de jeton pour s’assurer que chacun aura la chance de prendre la parole sur chaque idée émise dans les post-its.
Le principe du jeton est simple, le participant qui à le jeton a le droit d’émettre une remarque ou idée sur le sujet en discussion puis il passe le jeton au suivant. Évidemment si on n’a rien à ajouter on peut « passer » et laisser le participant suivant s’exprimer. Ainsi de suite jusqu’à ce que l’on n’ait plus rien à ajouter sur le sujet on passe alors au sujet suivant.

Il faut bien entendu synthétiser ce qui sera dit à la huitième étape, identifier des éléments ( pas trop nombreux 2 ou 3) sur lesquels l’équipe veut et peut se concentrer dans son prochain sprint et clore la séance de rétrospective.