J'ai été amené récemment à assister un Product Owner à préparer une réunion de priorisation de backlog (outre la personne en question, à la réunion y assistaient trois autres pour leur première priorisation de ce type). Deux façons se présentaient à nous: prioriser sur 100 points ou démarrer par une priorisation MoSCoW.

Pour rappel MoSCoW est un acronyme et permet de découper les priorités en 4 parties:

Must have: Priorité maximale pour un besoin ou une fonctionnalité absolument indispensable sans quoi le produit est inutile

Should have: La fonctionnalité a une très haute valeur ajoutée et doit absolument être incluse si le temps le permet. Cependant, si ce n'est pas le cas, on peut répondre au besoin d'une autre façon

Could have: Le petit plus Periglioni comme dirait Elie Semoun, le besoin n'est pas absolument nécessaire mais n'est pas négligeable car il peut permettre de faire la différence.

Won't have but Would have: La réponse à ce besoin est pour le moment hautement secondaire et ne doit pas passer avant le reste (la fonctionnalité n’est pas à développer dès la première itération).

Nous avons donc décidé de commencer par MoSCoW quitte à affiner avec la méthode des 100 points. Pourquoi ? Parce qu’il est difficile de prioriser d’autant plus lorsqu’on est nombreux. On limite le nombre de possibilités offertes. Au lieu d’avoir 100 possibilités, on en a 4 ce qui restreint les ardeurs des plus pointilleux d’entre nous.
Le but de la manœuvre est qu’une fois qu’on a fourni nos priorités sur 4, on peut définir des fourchettes sur 100.

La plupart du temps, en MoSCoW les hésitations se feront sur les combinaisons Must/Should ou Should/Could et Could/Would, peu de chance d’avoir une hésitation sur Must/Could (et sur une hésitation Must/Would… on ne sait jamais mais quand même…)

Quelles questions se poser lorsqu’on hésite entre deux priorités ?

Must/Should : Une des premières questions à se poser est « A quel point, le client a mis en avant cette fonctionnalité? », quel est le niveau d’importance pour le client.
Nous savons que la plupart du temps ce dernier mettra une grande partie des fonctionnalités au niveau d’importance le plus haut mais il est assez facile de dégager quel est le point névralgique, ce autour de quoi tourne le projet, si la fonctionnalité est au centre c’est bien sur un Must.
Si ce n’est pas le cas mais qu’un doute persiste, on peut se demander « est-ce que cette fonctionnalité peut être remplacée par une version plus légère dans un premier temps? ». Si la réponse est non c’est un Must, si oui un Could.
Le besoin du client peut être très précis et amener à des choses compliquées à développer. Ces éléments peuvent parfois être simplifiés dans un premier temps (pour un site de restauration, l’utilisation d’un google map interactif pour situer un lieu pourra être remplacé par une image dans un premier temps)

Should/Could : Plus difficile, il faut là savoir si ce besoin est primordial pour le business « que se passerait-il si on ne mettait ça pas en place ? ». S’il a été décidé que la fonctionnalité n’était définitivement pas un Must mais que le fait de ne pas la développer pourrait handicaper le chiffre d’affaire ou l’image du produit c’est que c’est un Should. Si par contre, ce développement permet une amélioration et que son « non-développement » n’est pas impactant, c’est que c’est un Could (ajouter un google map permet mieux situer un lieu en regardant l’espace alentour mais mettre une image avec l’adresse n’empêchera pas aux utilisateurs de trouver le lieu).

Could/Would : Comme l’a très bien posé le Product Owner durant la réunion « si on n’a pas le temps de tout faire, quel serait l’impact si on faisait ce développement par rapport à celui-là (précédemment priorisé en Could) ? ». La réponse a été vite vue, « Would » tous en cœur (en l’occurrence, le « Would » en question était un gadget graphique mais pouvait être estimé utile, d’où l’hésitation).

Il peut être assez simple de débloquer des situations avec les bonnes questions, le fait de n’avoir que 4 possibilités est aussi un atout pour accélérer les décisions.

Après ce découpage, la possibilité offerte est d'apposer aux 4 priorisations une fourchette sur la base 100.

Un exemple simple mais ensuite à vous de voir :

20 items en tout:

• Priorisation MoSCoW
  • 5 items en Must
  • 8 items en Should
  • 4 items en Could
  • 3 items en Would

• Découpage sur 100 points
  • Must => 75 à 100
  • Should => 50 à 75
  • Could => 25 à 50
  • Would => 0 à 25

On limite ainsi le champ des possibles, 5 items à répartir sur 25 points est plus rapide et moins imposant que de tout faire d’un coup sur 100

Petit bonus pour la détente (et mine de rien, bon moyen de ne pas oublier la méthode)
Dschinghis Khan - Moskau

Ça me trottait dans la tête depuis un moment et il fallait que je fasse un retour d’expérience et tant qu’à faire autant que ce soit la mienne… d’expérience.

Je suis actuellement en mission dans un grand groupe où la gestion de projet dite classique est profondément implantée, dans une équipe qui n’a pas été biberonnée au Scrum. Comment alors amener l’outil dans un tel environnement ? Pas simple…

Cet article sera découpé en plusieurs billets que je posterai régulièrement dans le déroulement de la mission.

D’abord décrivons l’équipe en question :

·         1 premier MOA peu intéressé par les méthodes agiles puis un 2^nd MOA très curieux des méthodos et prêt à tenter

·         1 MOE rôdé aux méthodes (normal il est de CLT !)

·         4 développeurs :

o   1 dev formé et déformé au Scrum, moi-même

o   1 autre non formé mais flexible donc bon candidat

o   1 dev non formé plutôt rôdé au cycle en V

o   1 dernier désirant une assignation totale de chaque tâche

Voilà une équipe bien disparate mais n’est-ce pas ce qui rend la chose intéressante ?

1^ère difficulté

Nous avons mis en place directement la totale, scrum board, burndown chart, post-it qui piquent les yeux, nous n’avons pas poussé le vice jusqu’à utiliser le planning poker mais pas loin. Notre première difficulté fût le refus de l’affichage du burndown chart aux passants.
Un trop de plein de transparence avait créé un malaise dans l’équipe de peur que la première réaction des managers voyant une courbe qui ne voulait décidément pas descendre fût cinglante. Selon moi, une bonne communication à l’intérieur de l’équipe et de façon montante permet d’éviter justement une mauvaise interprétation du burndown chart. Nous avons tout de même décidé de ne pas l'afficher.

2^nd difficulté

Difficile de créer un backlog quand le MOA ne semble pas convaincu par l’outil scrum ? Les nombreuses tentatives d’explication et d’implication n’ont pas suffi à lui faire changer d’avis, obligés de faire sans… Nous avons donc tenté de créer des sortes de backlogs virtuels (non pilotés par le client et le PO) qui volaient en éclat à chaque changement dans le planning.

Résume très bien l'agile dans notre environnement

Points positifs et ce qui a rapidement fonctionné

Dans tous ces obstacles, il faut bien voir les points positifs qui ont été amenés.

Tout d’abord et l’un des plus importants, le test unitaire provenant de l’extrême programming lui-même faisant partie des méthodes agiles. L’équipe est aujourd’hui totalement indépendante sur les tests. Chaque développement fait l’objet d’un ou plusieurs tests unitaires. Notre couverture de code a explosée.

De ce fait, nous avons mis rapidement en place l’intégration continue. Nous travaillons avec ClearCase pour le versioning, Hudson pour l’intégration continue. Chaque stream ClearCase possède sa chaîne d’intégration et sa base de données (les tests cependant, codés dans les règles de l’art ne laissent aucune donnée dans la base). Ce fonctionnement convient actuellement à tout le monde et a permis d’éviter bon nombre de bugs lors des phases de test voir de production.

Conclusion

Ce que je retiens de ces deux premières difficultés est qu’il faut faire très attention à ne pas arriver avec une gestion clef en main car les gens avec qui on travaille ne sont pas forcément sensibles à une méthode nouvelle. De même, vérifier que tout le monde est à l’aise avec les aspects de la méthode

Le Scrum est une méthode où toute partie doit adhérer du développeur au client ou tout du moins le MOA sous peine d’essuyer quelques plâtres.

Lorsque le Scrum Board explose et ne tiens pas la route, trouver une autre méthode de gestion des tâches et des sprints

Nous vous proposons une série de billets, issus d'ateliers menés auprès de collègues et d'amis, et dont le but est de proposer des réponses simples à un certain nombre de critiques et lieux communs que vous pouvez régulièrement entendre ou avoir vécu lorsque vous souhaitez parler de Scrum.

Voici le premier de cette série de billets. Il vous propose quelques réponses à apporter à quelqu'un qui vous dit : "Scrum c'est pas sérieux". Les éléments de réponse ci-dessus ne constituent en rien une liste exhaustive et ne sont pas nécessairement purement objectives.

Vous qui pratiquez le Scrum, n'avez vous jamais eu affaire à une personne quelque peu critique voire moqueuse sur la méthode?

• Tout d'abord en réponse à une remarque du type "Scrum c'est pas sérieux" il est important de savoir si la personne en face de vous a déjà eu l'occasion de pratiquer Scrum et/ou si elle s'est déjà renseignée un minimum. Nous partirons du postulat de base que notre interlocuteur connait un minimum la méthode.

• Une de ces premières objections pourrait être : "Je ne comprends pas pourquoi vous faites du Scrum, personne n'en fait" insinuant que le Scrum est une méthode ou une pseudo-méthode applicable sur certains types de projets bien particuliers et qu'elle ne peut être appliquée partout et à tous. Votre réponse peut se résumer en citant quelques références dans le monde informatique: Google, Microsoft, Yahoo, Adobe, Nokia... (n'hésitez pas à en rajouter si vous en avez sous la main). De grands noms de l'informatique ont effectué une transition vers l'agilité et utilisent Scrum.

• Face au Scrum board et à tous ses post-its multicolores, ses cases et le burn down chart, il n'est pas rare d'en voir certain se poser des questions ou encore de vous faire remarquer que "vous avez un peu trop de rose et pas assez de bleu". Pourquoi des post-it? Parce que c'est visuel et clair et que le côté physique du tableau et du papier humanise la méthode.
  
  De même le fait que les membres de l'équipe déplacent les tâches à la vue de tous, offre plus de transparence, un suivi clair et partagé par l'équipe à tout moment et donc une meilleure communication.
  Par expérience, nous nous sommes aperçu que le daily meeting derrière un écran n'offrait pas la même visibilité qu'un grand tableau.
  
  De plus cela rend la méthode ludique. Qui a dit que l'on devait forcément s'ennuyer au travail ?

• "Ce sont les développeurs qui chiffrent? Pas la MOA ou le commercial?" ou bien "Vous laissez les développeurs chiffrer? Mais ils vont vous multiplier par trois ou quatre les coûts!" Ce type d'affirmation sera d'ailleurs bien souvent prononcé par la MOA ou le commercial ou encore le client.
  Le développeur reste tout de même la personne la plus apte à estimer le coût de son propre travail.
  
  De plus, il n'y a pas que les développeurs qui chiffrent, tout le monde peut participer à la réunion de planning permettant ainsi un consensus et de la discussion autour d'une tâche. L'estimation n'en sortira que plus réaliste et transparente pour tout le monde.
  
  Le planning effectué par les développeurs peut créer un cercle vertueux entre les notions de responsabilisation de l'équipe, d'engagement et de prises de responsabilité sur les tâches à effectuer.

Merci à toutes les personnes qui ont permis de constituer cet ensemble de réponses