Le PO et la gestion du projet au quotidien: 6 qualités/facteurs de plus

Leave a comment

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 ..

 

 

La journée du PO : Le Backlog et sa gestion

Leave a comment

Et zoup, un nouveau petit post sur les activités de notre cher PO :  la gestion du backlog et découvrons 6 des qualités du PO.

Pour illustrer les difficultés d’un PO à construite un backlog, Henrik Kniberg à réaliser une illustration parfaite, à méditer:

SplitStory

 

Une des premières étapes pour le PO dans un nouveau projet, est, dans mon idée, d’avoir une ébauche de son backlog et un plan de release.  En général, cette ébauche de backlog est réalisée par le PO avec les décideurs du projet, en amont du démarrage de l’implémentation.

La création du backlog se passe en plusieurs étapes. Au début, on peut utiliser des techniques comme l’impact mapping (présentée par Gojko Adzic), qui permettent entre autre d’obtenir une liste des épics avec la valeur attendue pour chacune d’elles (en définissant les hypothèses sur lesquelles les valeurs attendues sont calculées). Les informations sur les hypothèses et la valeur des épics servira plus tard pour la priorisation du backlog et la création du plan de releases.

Slide1

Dans une deuxième étape, les techniques de story mapping (ex : scrum alliance)  permettront d’aller plus loin dans le découpage des épics en stories et d’obtenir un plan de release.

Slide2

Dans une troisième phase, le travail du PO va consister à transformer le plan de release en liste de stories à implémenter par l’équipe  dans chacune des itérations.

Slide3

Notre PO, à donc maintenant un backlog,  mais attention, dans ce backlog toutes les epics ne sont pas détaillées. En effet, quel peut être l’intérêt de détailler des épics pour la release 2, sachant que nous remettrons peut être en cause le contenu fonctionnel de cette release. Pour la même raison, toutes les stories de la release 1 ne sont pas détaillées. En effet, certaines devront être découpées (suite aux estimations de l’équipe, …), ou évolueront au cours du temps.  Le PO doit faire à mon avis, le travail minimal qui lui permettra de travailler avec l’équipe, tout en ayant les informations nécessaire pour réaliser son plan de release (estimation, risques, …). Parmi les outils qui pourront aider notre PO dans l’écriture de son backlog, on peut noter la définition des personna (la vidéo de Jeff Patton illustre bien cette technique).

Une fois ce backlog en poche, notre PO peut commencer son travail quotidien et être confronté à de nombreux challenges:

  • Avoir un backlog à jour : cela semble le B-A,BA  mais est-ce que tous les PO maitrisent leur liste de livrables, questionne leur plan de release (validation des hypothèses sorties de l’impact mapping, …).
    Il doit préparer avec l’équipe les stories pour l’itération n+1 et n+2. Par préparer j’entends vérifier la compréhension de la story, définir les critères d’acceptations et peut être même l’écriture des scénarios de tests.
    Le PO doit aussi découper logiquement les stories trop grosses après l’estimation de l’équipe (Rappel : une story doit être indépendante des autres, négociable, avoir de la valeur, être estimable, réalisable en un sprint et testable). Parmi les ressources que j’aime bien pour aider a splitter les stories :
    * http://www.agileforall.com/2012/01/new-story-splitting-resource/
    * http://www.agileforall.com/2009/10/patterns-for-splitting-user-stories/
    * http://www.infoq.com/news/2011/04/how-to-split-user-stories
  • Comprendre et incorporer le fonctionnel caché : parmi les aspects que l’on oublie souvent dans le Done, ou dans un backlog nous pouvons citer la performance du logiciel, la sécurité, la traduction, la compatibilités dans les différents environnements ou l’application sera déployée ….
  • Adapter son backlog de manière continue : le travail de jardinage de son backlog est une activité quasi-quotidienne, ou le PO doit tenir compte des remarques de l’équipe, des métriques du projet, des remarques collectées lors des démos, de l’évolution de l’environnement, des retours des clients/utilisateurs, …
  • Gérer les défauts :  2 des objectifs des pratiques agile sont de rendre visible le travail réalisé, et de ne pas montrer de choses non finies (contenant un bug).  Cela implique que le PO doit rendre visible le travail réalisé sur les bugs (en donnant des métriques lors des démos par exemple),  minimiser la durée de vie d’un bug (pour rappel, un bug vue rapidement et corrigé directement par le développeur ne coute rien, proportionnellement à son occurrence en production). Il y a souvent un travail pour faire prendre conscience aux équipes de dev de l’importance ou des impacts de la non-qualité. Cela peut aussi aider l’équipe à prendre conscience de sa zone de responsabilité.
  • Tenir compte des taches techniques : qui n’a pas déjà entendu “sans le framework 2.0 on ne peut rien faire”, “on a du légacy”, mais aussi “cela est de la technique, ce n’est pas mon problème, c’est le vôtre”. Alors je sors le bouclier, et je dis non. Autant j’estime que le rôle d’un équipier est de fournir au PO les informations pertinentes (coûts, bénéfices, alternatives possibles, …), autant j’estime que le PO doit jouer son rôle d’arbitrage entre les solutions possible, et surtout dans la planification de ces évolutions dans le plan de release.
  • Gérer les releases : livrer fréquemment est possible, par contre, livrer incrémentalement de la valeur aux clients est beaucoup plus difficile et demande une discipline au PO pour ordonner les stories, valider et remettre en cause les hypothèses, supprimer régulièrement du logiciel les fonctionnalités sans ou peu de valeurs.

 

l’être : les valeurs d’équipe, la confiance, mon amélioration continue et la relation au monde exterieur

Leave a comment

Dans le monde agile, la collaboration de l’équipe et la confiance entre les équipiers sont des aspects important.

Dans de nombreuses migration à l’agilité, la construction de l’esprit d’équipe est souvent oubliée, et cela peut mener à l’échec de la migration ou du projet.

Parmi les activités que j’aime bien pour la construction d’une équipe, il y a l’arbre des valeurs que j’ai découvert grâce à Jean-Francois. Il permet à une nouvelle équipe d’apprendre à ce connaître.  Un des buts du jeu, et de découvrir les valeurs qui sont importantes pour un équipier, et que l’équipe construise petit à petit ses valeurs communes.

A partir de ces valeurs, l’équipe pourra alors réfléchir sur la cohérence de ces valeurs avec les piliers de l’agilité, et voir comment elles peuvent aider à la réussite. L’exercice sert aussi a identifier les points de vigilances,  quand certaines valeurs peuvent être en contradiction avec l’agilité.

Tout cela pour avoir une équipe autonome et responsable qui sera capable d’agir (et de réagir) efficacement dans la plupart des situations.

Slide2

Parmi les “Bad smell” qui peuvent indiquer que la confiance n’est pas la,  on peut citer :

  • les organisations où les équipiers n’ont pas le droit de manger ensemble (prestataires, stagiaires, … ) ;
  • les équipes avec des objectifs individuels forts ;
  • les équipes ne faisant pas de rétro constructives, en effet,  je pense que la confiance entre les équipiers est une des clés de la réussite des rétro ;
  • l’intégration ou le changement d’équipier sans accompagnement. L’ajout d’une nouvelle personne peut changer (et change souvent) certaines des valeurs communes …

Le deuxième aspect est le fait que développeurs,scrum master et PO fassent une équipe.

Le partage de valeurs et la confiance entre tous les membres de l’équipe est un début, mais cela n’est pas suffisant.

Pour atteindre une relation ou l’équipe est une et indivise dans toutes les situations (cela n’interdit pas la divergence d’opinions, mais elle doit être constructive et dans l’intérêt du projet). Il faut une interaction quasi quotidienne avec le PO. Etre PO est un travail au quotidien et il ne s’agit pas juste de gestion du backlog. Le PO doit être en relation avec l’équipe pour éclaircir les points, préciser les attentes, travailler sur les critères d’acceptation, … Cela implique aussi, que les rôles de chacun sont connus à chaque instant. On peut facilement être amener à oublier la différence entre le rôle et la personne. Par exemple, lorsque le PO est en vacances …  les équipiers peuvent penser qu’ils n’ont plus de PO …. Il est important que dans ce genre de situation, le PO “délègue” son rôle à une ou un ensemble de personne. La gestion des priorités pourra être déléguée à une personne, la validation des stories à une autre, et ainsi de suite….

Slide3

Communication Niveau 1 : Les bases de la communication

Leave a comment

Et voila notre première qualité : La communication !

Slide1

Notre PO échange régulièrement avec les clients, l’équipe et les utilisateurs. Les communications peuvent être locales/distantes,  conviviales/conflictuelles et il est donc important pour un PO de maîtriser cet outil pour être efficace dans son travail quotidien.

Parmi les outils que le PO peut utiliser pour l’aider dans cette tâche nous retrouvons les techniques élémentaires de reformulation, de questionnement, ainsi que toutes les techniques liées à l’accompagnement au changement et/ou au benchmarking.

Attention, cette thématique est difficile à appréhender pour les PO issus du monde la technique ….

Le PO doit aussi faire attention a être cohérent dans le vocabulaire employé avec tous les interlocuteurs. En effet, si le graphe affiché pour un chimiste est une courbe de calibration, le fait d’utiliser le même vocabulaire avec l’équipe de développement fera que le code utilisera le même terme. Ce qui dans le temps, rendra le logiciel plus facilement maintenable et cohérent.

Tip : quelques liens pour débuter

  • http://www.pedagopsy.eu/
  • http://attitudesgagnantes.com/10cles-apprendre-a-ecouter/ … ou comment ça je suis bavard !!!!
    J’ai eu l’occasion de participer à une séance de théâtre d’improvisation improvisé avec Aline … Quelle leçon …. ce prendre en 2 minutes dans les dents qu’on n’écoute pas :)
  • A Practical guide to distributed Scrum (Elizabeth Woodward, Steffan Surdek, Matthex Ganis)

Les 6 grandes catégories

Leave a comment

Slide20    Dans le post précédent, on m’a demandé d’être plus précis sur les 6 catégories que j’ai choisies pour guider mon PO dans sa progression, voila, je vais essayer de mettre des mots et de clarifier ce que nous avions en tête lorsque nous les avons définies.

Les 6 catégories choisies sont :

  1. L’être, l’équipe : dans cette catégorie, je mets ce qui est lié au coté humain du PO. Avec par exemple, toutes les problématiques liées à sa communication avec l’équipe, avec ses clients, …., mais aussi les aspects liés à la confiance qu’il devra instaurer avec ses différents interlocuteurs.  Ce sont des points importants pour chacun des membres de l’équipe, mais à mon avis, ils sont critiques pour le PO et le scrum master.
    Slide21
  2. Le Produit : et oui, notre PO est le champion du produit, il doit en avoir la vision, comprendre les attentes des clients et/ou des acheteurs, être capable de gérer les contraintes légales et/ou marketing, il doit anticiper les besoins des clients, valider les idées, s’assurer de la satisfaction client, … enfin, un travail à plein temps.

    Slide22

  3. Le Backlog : mot un peu fourre tout, qui va de la gestion du plan de release du produit, à la gestion des sprints, et la gestion du backlog au quotidien, ….  Cela inclut aussi la gestion des risques du projet. Notre PO doit faire tout cela, sans oublier d’offrir une vision cohérente des évolutions à l’équipe et à ses clients.

    Slide23

  4. Les Stories : écrire des stories … des livres entiers ont été écrits la dessus, avec les questions récurrentes de la gestion des défauts, des contraintes techniques, du fonctionnel caché, des critères d’acceptation….
    La manière de les écrire dépend bien sûr, un peu de l’équipe qui va les réaliser, mais idéalement pas trop … Comment trouver le juste milieu qui permet à tous les acteurs d’être efficaces ?

    Slide24

  5. Le quotidien : ou comment s’assurer que son produit sortira régulièrement avec de la valeur. Quelles métriques suivre sur son projet, comment maîtriser ses livraisons, comment garder un rythme soutenu et tout cela en s’améliorant régulièrement ?

    Slide25

  6. Qualité : mot qui fait souvent sourire, ou qui fait peur.  Entre la startup qui doit à tous prix sortir la nouvelle fonctionnalité avant la concurrence, et/ou le logiciel médical qui doit sortir sans bugs, comment trouver le juste équilibre ? Comment tirer partie des différents tests réalisés tout au long de la vie d’un logiciel, comment définir sa stratégie de tests ?
    Mais la qualité n’est pas que le nombre de bug, il faut aussi s’assurer d’avoir un processus de développement fiable et prédictible, voire sous contrôle dans certain cas.

    Slide26

Les 6 catégories, ne sont évidemment pas gravées dans le marbre et ne demandent qu’à évoluer au cours du temps :)

Les 36 qualités d’un Product Owner

4 Comments

Cela fait quelques temps que je travaille avec plusieurs collègues et des membres du groupe cara coach, pour arriver a caractériser les qualités que l’on peut attendre d’un Product Owner. Dans le monde de l’agilité on trouve facilement des articles, des conseils, des formations pour les scrum masters. Cela est tout à fait normal, ils sont un peu les gardiens du temple.

Par contre, je trouve que le Product Owner (PO) est souvent délaissé. Son rôle est pourtant tout aussi important que le Scrum master.

Le PO, est un peu le Mc Giver de l’agilité. Il doit savoir presque tout faire, et bien :

  • Il doit être à la fois capable d’avoir une vision produit, et donc une forte compétence métier, voir marketing.
  • Il doit être un leader capable d’emmener les équipes de réalisations avec lui dans le projet.
  • Il doit naviguer entre clients, utilisateurs, acheteurs, sponsors  et satisfaire chacun (ou sacrifier certains) de ses interlocuteurs.
  • Il doit être capable à partir des informations précédentes de faire un plan de release pertinent, tout en ayant des stories utilisables au quotidien par les équipes.
  • Il doit parler l’informaticien(ne)s ….  comment ça, aurais-je des-fois l’impression d’être Chewbacca lorsque je parle avec une chimiste ??? ;-)
  • Il doit faire preuve d’écoute et diplomatie pour expliquer les choix.
  • Il doit être disponible pour répondre au questions de l’équipe, …
  • et je pourrais continuer la liste encore sur quelques points.

Le PO doit donc être un sur-homme (ou femme).

J’ai la chance de fréquenter des PO qui pratiquent ce rôle depuis quelques années, et nous avons voulu essayer d’aider nos petits PO débutants dans leur progression.

Après quelques débats passionnants et enrichissants, nous sommes arrivés à une liste de 36 compétences et/ou pratiques utiles.

Nous avons réussi à les regrouper en 6 catégories :

  1. Etre/Equipe : pour tout ce qui est en relation avec les relations humaines
  2. Produit
  3. Backlog
  4. Story : en effet, c’est un sujet tellement vaste que nous lui avons donné une catégorie rien que pour elles:)
  5. Le quotidien : de l’équipe, du projet, ….
  6. La qualité :  ou comment avoir la qualité juste et adapté dans le contexte de notre projet

Fier de nous, nous avons cependant voulu aller un coup plus loin, et essayer de donner des indices de difficultés (ou de maturité) nécessaires pour acquérir un niveau supérieur. Nous avons été très originaux et utilisé un système de ceinture, connu dans tous les sports d’arts martiaux, ou dans le monde Lean.

Et zoup, 6 catégories, et 6 niveaux, cela nous fait 36 qualités.

FormationPO_Board_Empty

Mais quelles sont elles ????

—————————————> PUB <——————————————-

Un PO dojo à Grenoble : http://www.agilex.fr/2014/01/podojo-atelier-dexperimentation-pour-product-owner/

—————————————> PUB <——————————————-

La suite demain :)

Merci à  Solange, Lucie, Vanessa, Bruno, Jean, Jean-Francois, Luc, Michel pour tous les échanges constructifs

Isabelle & Laurent

[Hudson] Checker le nombre de jobs

Leave a comment

Si vous voulez avoir un job qui joue le rôle de sentinelle :


$url="http://10.190.200.87:8080/hudson/api/xml"
$path="c:\Temp\jobs.xml"
$expectedJobsNb=41
$client = new-object System.Net.WebClient
 #Download the hudson home page in xml, through the web service
$client.DownloadFile( $url, $path )
[xml] $content=get-Content $path
#Get the jobs list
$jobs=$content.SelectNodes("/hudson/job")

if ( $jobs.count -ne $expectedJobsNb ) {
    Write-Error "We do not have the good number of jobs $($jobs.count)"
    exit 1;
} else {
    Write-Output "We have the good number of jobs : $($jobs.count)"
}

Older Entries

Follow

Get every new post delivered to your Inbox.