Nous avons vu dans le post précédent qu’avoir un backlog utile et à jour n’était pas si évident. Malheureusement, un bon backlog, ne suffit pas pour avoir un projet qui se déroule bien.  Dans Scrum, le Scrum Master est le garant du processus et il doit donc s’assurer que le processus ce déroule bien. Le PO (ou les artefacts dont il a la responsabilité : backlog, story) à/ont un rôle clé dans beaucoup des cérémonies : sprint planning, demo, ….

Le PO a donc un rôle clé, et je vais essayer de lister les points de vigilance qu’il doit avoir au quotidien sur ses projets.

  1. From the book : j’ai vu beaucoup d’implémentation de l’agilité, ou dès les premières itérations les équipes ont commencés à customiser scrum pour de “bonnes” raisons, en oubliant souvent l’esprit de scrum ou de l’agilité.  Quand on regarde les cérémonies scrum avec l’œil d’un PO, on pense immédiatement aux Démos et au sprint planning.  Un petit rappel de quelques bases pour nos PO :
    • Au début du projet on définit le DONE avec l’équipe, et on le raffine régulièrement si nécessaire
    • On ne démontre que les stories finies, sans défauts et avec tous les tests qui réussissent.
    • Si possible, l’équipe ne découvre pas la story au sprint planning, on a le droit d’en discuter avant, notamment pour clarifier les critères d’acceptances.
  2. Les rétros : souvent utilisées pour régler des problèmes, elles peuvent aussi servir à l’amélioration de l’équipe.  Voici quelques bonnes pratiques liés aux rétro :
    • L’équipe doit faire régulièrement des rétrospectives
    • L’équipe, lors de ces rétros définit des actions à réaliser, et les réalise.
    • En tant que PO, je peux proposer des sujets de retros.
    • Je collecte les retours des équipiers et j’en tiens compte.

    Les rétros peuvent être un lieu ou de temps en temps le PO peut par exemple faire réfléchir l’équipe sur comment améliorer la qualité du produit.

  3. Les métriques : Dans le quotidien de la gestion de projet, il est important de savoir où on en est. Les métriques classiques, telles que le value burn-up (la valeur que nous avons produite) ou l’effort Burn-down (ce qu’il reste à faire) permettent d’avoir une vision de l’avancement du projet. Par contre, elles ne sont pas forcement suffisantes.  Sans non plus rentrer dans le piège d’avoir 300.000 métriques, il est important d’identifier quels sont les indicateurs qui font du sens, et ne pas hésiter à les remettre en cause, voir les changer régulièrement.
    Il est donc important pour le PO de :

    • Définir au début du projet les métriques qu’il va suivre
    • Revoir régulièrement (release, sprint, …) les métriques utilisées, et de les adapter aux nouvelles contraintes du projet
    • S’assurer que l’équipe ne fait pas une course à la métrique, rendant contre productif toutes les métriques mise en places.

    Parmi les métriques que j’aime bien, il y a par exemple, la dispersion du temps de réalisation  des stories, qui permet d’identifier si régulièrement on a des stories à problèmes, mais aussi de voir si le découpage des stories permet une implémentation dans un temps raisonnable. On peut aussi regarder la répartition entre les différents type de stories, celles ayant de la valeur cliente, les stories soit disant “techniques” et le nombre de bugs corrigés.

  4. Les livraisons : tous le projets ne faisant pas encore du déploiement continu, il existe encore souvent une phase de livraison explicite, avec une phase de qualification du produit. Parmi les anti-pattern que nous pouvons identifier il y a :
    • la phase de validation avant la release est longue (au moins l’équivalent d’un sprint)
    • L’équipe fait un sprint de finalisation.
    • Je fais des démos avec des stories qui ne sont pas complétement finies (cf. DONE)
    • L’équipe n’est pas responsable de la livraison (et peut être du packaging).

    Si on veut avoir un rythme de production soutenable et prédictible, il vaut mieux éviter les points précédant.

  5. Le Rythme : si l’équipe veut être capable de garder un rythme régulier et prédictible au cours des sprints, il est important de :
    • définir des sprint cours (2 ou 3 semaines par exemple)
    • d’avoir des estimations fiables, sans pour autant passer de longues heures à détailler et raffiner les estimations. Il est important de ce poser des questions lorsqu’une story estimée à X journées, prend au moins 25% de  plus. Le graphique sur la dispersion des temps de réalisation peut aider a identifier de telles stories. Parmi les pratiques intéressantes,  j’ai vu des équipes qui en plus des estimations sur une story, évaluaient 2 facteurs de risques : techniques et métier.
    • Les échanges entre le PO et les développeurs sont fréquents. Ces derniers ne découvrent pas les stories le jour du sprint planning, et le PO ne découvre pas l’implémentation de la story le jour de la démo …..
  6. L’amélioration continue personnelle et de l’équipe:  parmi les facteurs de succès  la volonté de s’améliorer est un des piliers clefs. Parmi les indicateurs qui montre que l’équipe est sur la bonne voie:
    • L’équipe a des réunions productives
    • L’équipe a des réunions efficaces
    • L’équipe écrit des documents utiles
    • L’équipe suit les actions définies (par exemple lors des retros)
    • l’équipe s’améliore

 

En rajoutant ces derniers items, je trouve que le terme ‘qualités’ est de plus en plus mal choisi, peut être devrais utiliser plus facteurs, ou …. il va falloir que je me creuse un peu les méninges …. affaire à suivre ..

 

 

Advertisements