Kata d’Amélioration Continue

Lorsqu’une équipe cherche à améliorer son fonctionnement (efficacité de ses outils et processus…), elle rencontre parfois des difficultés pour mesurer le retour sur investissement des efforts qu’elle fournit pour se perfectionner.

Le discours de Simon Sinek à propos du leadership (Inspirationnal Speech about Love, 2016), m’inspire pour illustrer cette difficulté.

453953-200– Do you love your wife ?
– Yes
– Prove it. What’s the metric ? Give me the number that helps me know, because when you met her, you didn’t love her. Now you love her. Tell me the day that love happened. It’s an impossible question. And it’s not that it doesn’t exist. It’s just that it is easier to prove over time. Leadership is the same thing. It’s about transitions.
[…] So if you were to go to the gym, it’s like exercise. If you go to the gym and you work out and you come back and look in the mirror, you will see nothing. And if you go to the gym the next day and you come back and look in the mirror, you will see… nothing. 

L’amélioration n’est pas toujours mesurable dans sa globalité. En revanche, lorsqu’on découpe les mécanismes qui constituent l’organisation d’une équipe ou qu’on extrait un processus dans le but de l’améliorer, il est plus aisé de mesurer des résultats.

Il y a plusieurs semaines, j’ai eu la chance d’observer une formation sur les Kata d’amélioration continue, dispensée chez l’un des clients pour lesquels je travaille. J’ai donc souhaité partager ici quelques éléments clés.

► Un kata d’amélioration continue, qu’est-ce que c’est ?

Dans les arts martiaux, le Kata est un ensemble de mouvements coordonnés et codifiés répétés jusqu’à ce qu’ils deviennent un réflexe ou une seconde nature.

L’amélioration continue selon le Kata consiste à prendre une situation qui a le potentiel d’être améliorée, à l’analyser attentivement afin d’en comprendre les spécificités et les subtilités, puis de définir cette même situation telle qu’on souhaite la voir évoluer.
Le but du Kata est de faciliter la transition entre la situation présente et la situation souhaitée, en prenant en compte cette partie inexplorée qui doit permettre d’atteindre les résultats souhaités.
(Source: Lean Six Sigma France)

Le Kata n’est pas une solution en soi, mais l’implémentation d’une méthode qui permettra à la personne qui l’utilise d’améliorer progressivement un processus ou une situation, jusqu’à atteindre la condition souhaitée. Cet outil permet de prendre le temps de remettre en question le processus en l’observant de manière factuelle.
Les petites expérimentations répétitives permettent d’avancer vers une vision avec assurance et un minimum d’efforts, petits pas par petits pas, pour surmonter les obstacles et les inconnues.

Kata d'amélioration_cheminement

► Comment l’utiliser ?

Le démarrage d’un Kata d’amélioration s’articule autour de 4 étapes clés. La 4ème étape est répétable jusqu’à ce que la prochaine condition cible soit atteinte.

Kata_Guide d'utilisation

Le Kata d’amélioration continue comprend 3 rôles : l’apprenant (Learner) ; le coach et l’équipe

Equipe_Kata_Amélioration

L’apprenant est celui qui fait vivre le Kata en le pratiquant régulièrement. Il définit la direction à prendre, en partant de la position actuelle, en établissant la prochaine condition cible et en faisant vivre les différentes étapes des cycles itératifs : Planifier (Plan), Agir (Do), Vérifier (Check), Ajuster (Adjust).

Le Coach le soutien dans cette démarche en lui posant 5 questions clés à chaque point d’étape du Kata :

  1. Quelle est la situation cible que tu cherches à atteindre ?
  2. Quelle est la situation actuelle ?
    Rétroaction suite à la dernière expérimentation :
    – Quel était ton plan à l’étape précédente ? 
    – Qu’attendais-tu de cette expérimentation ? 
    – Que s’est-il passé en réalité ? 
    – Qu’as-tu appris ?
    .
  3. Selon toi, quels obstacles t’empêchent d’atteindre la condition cible ? 
    Quel obstacle souhaites-tu adresser maintenant ?
    .
  4. Quelle est la prochaine étape ? 
    Quelle est l’expérimentation que tu souhaites faire ?
    Quel résultat attends-tu de cette expérimentation ?
    .
  5. Quand peut-on vérifier le résultat de cette expérimentation et en ressortir un apprentissage ?

L’équipe est constituée par les personnes qui aideront l’apprenant à atteindre la condition cible qu’il a définit. Ils n’interrompent pas ce qu’ils sont en train de faire, mais pourront par exemple apporter des informations sur le fonctionnement du processus et participer à sa modification graduelle pour arriver à la condition cible.

► Les outils 

  • Gabarit de suivi des expérimentations

    Chaque ligne du tableau correspond à une étape/expérimentation, qui contient une itération “Planifier (Plan)Agir (Do)Vérifier (Check)Ajuster (Adjust)“.

Kata d'amélioration_Gabarit de suivi des expérimentations
(cliquez pour télécharger une version à imprimer)

  • La carte des 5 questions

    A chaque étape, le coach pose les 5 questions suivantes, qui constituent le processus d’inspection/adaptation (PDCA) à proprement parler.

Coaching-Kata_5-questionsA noter: On travaille souvent sur un même obstacle pendant plusieurs cycles de PDCA

Par la répétition des étapes “Planifier (Plan)Agir (Do)Vérifier (Check)Ajuster (Adjust)“, le Kata cherche à développer des réflexes d’inspection/adaptation. Au fur et à mesure qu’ils sont pratiqués, ils s’installent comme une routine.
Les “petits” objectifs intermédiaires qui pavent le chemin jusqu’à une condition cible permettent de constater plus facilement la progression et de rester “motivé” face à une situation qui parait difficile à améliorer à première vue.

Pour conclure cet article, voici une illustration des bénéfices de l’Amélioration Continue que je trouve particulièrement pertinente :

Et vous, quels outils utilisez-vous pour améliorer vos processus et pratiques ?

.

Sources :
▪ Lean.org
▪JPD Conseil
▪Illustrations à l’aide de Piktochart

Et si on rendait les réunions plus efficaces ?

Depuis peu, je travaille chez un nouveau client avec mon collègue Julien. Il m’inspire beaucoup car il a (selon moi) une approche  spontanée et bienveillante. Il utilise souvent des histoires (personnelles ou non) ou des images pour faire des parallèles et permettre aux gens de prendre du recul sur certaines situations. Cela semble lui permettre de développer rapidement une proximité avec les personnes auprès desquelles il intervient.

Récemment, il m’a fait part d’une pratique que j’ai trouvée innovante (et pourtant tellement simple), que j’avais envie de partager à mon tour ici : utiliser une approche inspirée du Kanban pour donner un cadre et faciliter une réunion.

Certaines réunions sont longues et n’ont pas d’objectifs clairs, font parfois l’objet de discussions sans fin et se terminent sans qu’on sache vraiment si on a avancé. Par ailleurs, selon le baromètre Wisembly/IFOP, un cadre passerait en moyenne 24 jours par an dans les réunions (source). Il semblerait donc opportun de s’assurer que celles-ci soient efficaces !

Voici donc une idée à essayer ou adapter:

  • Etape 1: Dessiner le flux (“Sujets à aborder” ; “en cours” ; “Traité” et pourquoi pas “Actions”)

Kanban_style_meetings2

  • Etape 2: Lister quelques sujets importants à aborder, en indiquant (éventuellement?) une estimation du temps nécessaire à la discussion. La liste peut évoluer au fil de la réunion.
  • Etape 3: Aborder un sujet à la fois, sur la base du “first in, first out” (ou en les priorisant). Proposer un temps imparti pour le sujet (qui peut correspondre à l’estimation proposée par le porteur du sujet ?), à la fin duquel l’équipe peut se prononcer sur un “stop” ou “encore“, en fonction de la valeur/pertinence/trajectoire de la discussion en cours. On continue ou on passe au sujet suivant, en prenant les actions au fur et à mesure (avec si possible un responsable et un délai ?).
  • Etape 4: A la fin de la séance, demander le ROTI (Return On Time Invested) de chaque participant. Prendre 5 min pour les feedbacks et les axes d’améliorations, à prendre en considération pour une éventuelle prochaine rencontre.

BONUS : Utiliser les 4 principes de l’Open Space Technology

  • Les personnes qui se présentent sont les bonnes ;
  • Ce qui arrive, est la seule chose qui pouvait arriver ;
  • ça commence quand ça commence ;
  • Quand c’est fini, c’est fini.

… Et la loi des deux pieds : “Si vous n’êtes ni en train d’apprendre, ni en train de contribuer, vous avez le devoir de changer le lieu.”

[Astuces] Deux outils “visuels” qui peuvent servir

Depuis bientôt 3 mois, j’ai rejoins Pyxis Technologies à Montréal en tant que Scrum Master/Coach d’équipe. Dans le cadre de mon arrivée, j’ai eu l’opportunité d’accompagner plusieurs Coachs Agiles dans leur quotidien et de suivre plusieurs formations  (j’envisage de raconter ce retour d’expérience plus en détail dans un prochain article)

Je souhaite partager ici 2 outils que j’ai découvert et particulièrement apprécié, par leur côté pratique et facilement réutilisable.

1. Organisation : Vers quelle méthodologie Agile s’orienter et pour quel contexte ? 

Agilité_Equipe_Organisation

Lorsqu’on souhaite optimiser le cadre de travail d’un ou plusieurs produits ou projets complexes, les méthodes Agiles peuvent apparaître comme une opportunité. Mais avec Scrum, Kanban, Scrumban, XP, SAFe, LeSs, Nexus… etc., elles regorgent de modèles et d’outils et il est parfois difficile de s’y retrouver ou d’identifier le framework qui se prêterait le plus au contexte et aux besoins.

Ce graphique est un moyen mnémotechnique qui permet de cerner facilement quelle méthodologie pourrait être appropriée, en fonction de l’organisation “Produit(s)”/”Equipe(s)”.

▪ 1 équipe travaille sur 1 produit : Expérimentez Scrum
▪ 1 équipe travaille sur plusieurs produits : Une approche Kanban pourrait être plus adaptée
▪ Plusieurs équipes travaillent sur 1 même produit : Tournez vous plutôt vers un framework qui permettrait d’adopter une approche Agile à plus grande échelle.
▪ Plusieurs équipes travaillent sur plusieurs produits : Aïe, là ça risque d’être plus compliqué… 😉

.

2. Aide à la priorisation : Le graphique “Valeur vs Risque”

Value_Risk_Chart

Ce deuxième outil m’a paru très utile pour les Product Owners, et à la fois très simple. Il permet de positionner les éléments du carnet de produit (Product Backlog) selon 2 axes : Valeur et Risque.

  • Echelle de Valeur :
    – Quelles sont les fonctionnalités qui pourraient apporter le plus de Satisfaction aux utilisateurs ?
    – Quelles sont celles qui seraient les plus intéressantes d’un point de vue Retour sur Investissement ?
    – […]
  • Echelle de Risque :
    – Quelles sont les fonctionnalités qui impliquent des dépendances avec d’autres équipes/applicatifs ?
    – Quelles sont celles dont la complexité est inconnue ?

En bref, ce graphique permet de visualiser les éléments du backlog selon 2 variables, afin d’avoir une vue globale et relative entre tous les éléments (on pourrait remplacer l’axe “risque” par “effort” si cela fait plus de sens…).

Une fois que tous les éléments du carnet de produit sont positionnés, il est plus aisé de prioriser les éléments. Par exemple :

  1. Commencer par développer les fonctionnalités qui apportent le plus de valeur et qui entraînent le plus de risques (ainsi, l’aspect risque pourrait être écarté rapidement…?).
  2. Ensuite, celles qui apportent encore beaucoup de valeur et moins de risques.
  3. Si le budget et le délai le permettent, terminez par les fonctionnalités qui apportent peu de valeur mais sont sans risques.
  4. Les fonctionnalités qui apportent peu de valeur et entraînent beaucoup de risque n’ont pas lieu d’être développées ( le retour sur investissement serait proche de zéro voire négatif).

 

En conclusion, deux outils simples et visuels, que chacun est libre de s’approprier et d’adapter à son contexte.

Ils n’ont pas pour objectif de dicter une manière de faire, mais plutôt d’apporter un support à la réflexion, sur l’organisation d’une équipe ou la priorisation des fonctionnalités d’un produit.

 

#Meetup – Introduction au Design Thinking

Qu’est-ce que le Design Thinking et comment s’en servir ?
Nous avons expérimenté plusieurs étapes de ce processus lors du dernier Meetup de SchoolOfPO.

quote-512Le Design Thinking est le terme utilisé pour désigner l’ensemble des méthodes et des outils qui aident, face à un problème ou un projet d’innovation, à appliquer la même démarche que celle qu’aurait un designer. C’est une approche de l’innovation et de son management qui se veut une synthèse entre la pensée analytique et la pensée intuitive. Il s’appuie beaucoup sur un processus de co-créativité impliquant des retours de l’utilisateur final.

La méthode de Design Thinking se déroule en 5 étapes clés:

  1. EMPATHISE : Identifier un problème dans sa globalité. Se mettre à la place des personnes qui pourraient y être confrontées. Imaginer leurs caractéristiques. Comprendre leurs expériences et leurs motivations.S’immerger dans leur environnement.
  2. DEFINE : Rassembler les données collectées. Analyser et synthétiser les informations pour définir le cœur du problème rencontré. Définir le(s) problème(s) du point de vue de l’utilisateur. L’exprimer avec ses mots. Rassembler des idées qui pourraient permettre d’apporter une solution, ou qui pourraient permettre aux utilisateur de résoudre eux-mêmes ce problème.
  3. IDEATE : “Think outside the box“. Après avoir rassemblé un grand nombre d’informations dans les deux étapes précédentes, il est plus facile de concrétiser des solutions susceptibles d’apporter une réelle valeur ajoutée. Imaginer des alternatives.
  4. PROTOTYPE : Imaginer des premières versions minimalistes du produit ou de l’application qui pourra répondre au problème. Donner vie au produit dans les grandes lignes. Réaliser le(s) prototype(s) du produit sur une simple feuille blanche, par exemple. Tester ces premières versions auprès de l’équipe, ou une population représentative des utilisateurs auquel il s’adresse.
  5. TEST : Une fois le prototype affiné, une première version du produit peut être développée pour être testée dans des conditions réelles, ou le prototype lui-même peut être abouti pour être testé auprès d’une population plus large.Les 3 dernières étapes du processus pourraient être répétées au fur et à mesure des développements, pour s’assurer que le développement du produit s’oriente vers une solution qui répond réellement aux besoins des utilisateurs. Test & learn.

LucyInTheScrum_DesignThinkingLe processus de Design Thinking pourrait être assimilé à deux entonnoirs successifs.
Collecte d’informations/Brainstorming > Synthèse des éléments/Affinage
> Ré-ouverture sur des questions pour imaginer une solutions > Ré-affiner en développant un prototype
> Tester la solution > Optimiser.
 

Lors du dernier Meetup “School Of Product Owners”, animé par Lucie Teyssou et Samuel Retiere, nous nous sommes concentrés sur les deux premières étapes du processus, en s’attardant sur 2 outils pratiques pour les mettre en oeuvre.

1. “EMPATHY MAP

Cet outil permet de se mettre plus facilement à la place de l’utilisateur par rapport au problème rencontré: Qui est-il ? Que pense ou ressent-il ?  Qu’entends t-il ? Que voit-il ? Que fait ou dit-il ?
Chaque case de la grille peut être complétée dans le cadre d’un Brainstorming. On notera ensuite les points de douleurs et les objectifs de l’utilisateur en question : Quelles sont ses frustrations ? / Que souhaite-t-il ?

Dans le cadre de ce Meetup, nous n’avons pu nous exercer que sur une seule carte, par manque de temps, mais cela nous a permis de confirmer qu’on peut très rapidement se mettre à la place de l’utilisateur si on se pose les bonnes questions.

Plusieurs cartes de ce type permettront d’avoir une vue globale, et de se positionner selon les attentes de différents utilisateurs, avec des profils différents.

Empathy-MapCliquez sur l’image pour l’agrandir

 

2. “CUSTOMER JOURNEY MAP

Cette représentation a pour objectif de schématiser le parcours de l’utilisateur sur plusieurs étapes, en mettant en exergue son niveau de satisfaction à chaque étape. Les différentes étapes peuvent représenter un processus d’achat sur Internet, un voyage… ou autre.

Une fois le parcours synthétisé, on notera les points de douleurs et les interactions de l’utilisateur pour chaque moment clé. Par exemple, dans le cadre d’un achat sur Internet, l’utilisateur peut rencontrer des problèmes au moment du paiement en ligne. On notera également ses besoins : “A ce moment là, quelles sont ses attentes ?”

Ainsi, on peut plus facilement en dégager des axes d’optimisations concrets.

Customer Journey Map TemplateCliquez sur l’image pour l’agrandir

 

Le processus de Design Thinking peut prendre du temps. D’après Lucie et Samuel, on peut compter environ 2 mois entre le moment où on concrétise l’identification d’un problème à résoudre et la finalisation des prototypes.
Evidemment, la durée du processus dépend de l’investissement qu’on souhaite y mettre et du “Time to Market” visé. Dans un secteur très concurrentiel ou dans une startup, on envisagerait un processus accéléré afin de tester très rapidement des hypothèses. Dans une entreprise de grande ampleur, les étapes de validation prendraient sans doute plus de temps.

Quoi qu’il en soit, le processus global et les deux outils présentés restent relativement simples et peu coûteux à mettre en place. A l’image du Lean Startup, le Design Thinking permet de valider des hypothèses au plus tôt et d’éviter de s’attarder dans des conceptions “hors sujet”.

 

SchoolOfProductOwners_DesignThinking

 

Sources :
● Les Cahiers de l’Innovation – Qu’est-ce que le Design Thinking ?
● Interaction Design Foundation – 5 Stages in the Design Thinking Process
Customer Journey Map Template
En savoir plus :
Découvrir SchoolOfPO
● S’inscrire aux prochains #Meetups
● Suivre les Live Tweet : #SchoolofPO / @SchoolOfPO

#Meetup – Intervision / Solution Focus

Le dernier #Meetup de SchoolOfPO avait pour sujet “L’intervision du Product Owner“.

quote-512L’intervision est un dispositif particulier de rencontres entre pairs, des professionnels sociaux, médico-sociaux, éducatifs et judiciaires.
Objectif : Echanger sur leurs expériences, Réfléchir collectivement sur leurs conduites professionnelles.
Déroulement : Mise en commun de la pratique d’un des membres du groupe, voire de ses difficultés à faire face à des situations complexes ou à des résultats insatisfaisants dans l’accomplissement de ses missions.

Pablo et Dragos nous ont aidé à mettre en pratique ce concept, en l’adaptant au rôle de Product Owner et en utilisant plusieurs méthodes.
D’abord, nous avons divisé le groupe en deux. D’un côté, les participants qui joueraient le rôle de Coach. De l’autre, les Product Owners qui prendraient le rôle de “patients”.
A travers 4 sessions de 15 minutes, sous plusieurs formats, les Products Owners ont pu exposer un ou plusieurs problèmes à leurs binômes (les binômes changent à chaque session, c’est aussi l’occasion d’échanger avec de nouvelles personnes :)).

Exemple de problèmes soulevés :
▪ Comment valoriser une démo Mobile quand les fonctionnalités sont les mêmes sur iOS et Android ?
▪ Comment faire lorsque les parties prenantes de mon projet ne valident rien ?

Première session : Perfection Game

  1. Le Product Owner raconte son histoire, son problème ou un retour d’expérience.
  2. Il complète par ce qu’il a mis en place ou ce qu’il compte faire pour répondre à ce problème.
  3. Son binôme (le coach) lui donne une note sur 10.
  4. Il lui explique les bons points de sa solution ou de sa proposition et lui fait part des axes d’améliorations qui, selon lui, aurait pu permettre au Product Owner de gagner quelques points de plus.

Deuxième Session : Appreciative Inquiry (en savoir plus)
Adaptation pour le Meetup :

  1. Definition : Cadrer la zone de l’exploration. Raconter / Partager une expérience positive.
  2. Discovery : Identifier ce qui fonctionne, ce qui semble fonctionner à partir du récit du Product Owner. Se focaliser sur le positif.
  3. Dream : Imaginer des possibilités. “En se basant sur les expériences positives du passé, les gens commencent à rêver de possibilités pour l’avenir. En fondant le processus dans la réalité d’une expérience positive, les gens voient leurs rêves comme plus accessibles.”
  4. Design : Construire de manière concrète la mise en oeuvre de la phase “DREAM”. En énonçant des actions concrètes.
  5. Destiny : Planifier ces actions.

Troisième session : Solution Focus

  1. Le Product Owner énonce un problème à son binôme
  2. Il se projette ensuite dans un futur où le problème n’existe plus, en le décrivant d’une manière la plus concrète possible.
  3. Sur une échelle de 1 à 10, il se positionne ensuite par rapport à sa solution.
  4. Il identifie les étapes déjà franchies pour parvenir à cette solution (ce qui l’éloigne du stade “1”).
  5. Enfin, il se projette dans les étapes restantes pour arriver progressivement à “10”. Il imagine autant de petites étapes qu’il y a de chiffres pour arriver à 10.

Quatrième session : Freestyle

Echange en binôme ou en groupe, successivement sur un ou plusieurs problèmes rencontrés. Un participant expose son problème, les autres lui permettent de l’affiner et l’aide à imaginer des solutions.

Conclusion : Un meetup agréable pour échanger, discuter avec des personnes nouvelles, d’horizons différents.
On constate également qu’il est difficile de rester sur les rails de ces méthodes et qu’on a tendance à se lancer dans de simples discussions, qui ne suivent plus les différentes étapes.
Malgré tout, s’il est difficile de faire émerger des solutions en 15 minutes, l’entraide de ces méthodes permettent surtout de se recentrer sur les bonnes questions.

Intervision PO

Quel PO de M*rde !

#PODM

“Encore une idée farfelue du métier !” – […] – “Non mais c’est pas vrai, les développeurs ont codé ça avec leurs pieds, non ?” – […] – “De toutes manières, si on trouve des anomalies en production, c’est à cause des testeurs !” […]

Stooop. Mercredi on a parlé des bêtises du Product Owner. Elles sont légion. Mais personne n’est parfait. Et si c’était le cas, on n’aurait plus rien à raconter pendant nos Meetups. 😉
L’idée d’Alex : redécouvrir les atouts d’un bon Product Owner en partant de son contraire.
Sous forme de jeu, nous avons raconté des annecdotes de la vie d’une équipe de développement, à l’image du site VieDeMerde.
Au fur et à mesure que nous enoncions les annecdotes, les participants ont dressé une liste de 5 erreurs à ne pas commettre lorsqu’on est Product Owner. A la fin, chaque équipe a partagé ses 5 commandements au reste du groupe. Résultat : on a bien rit, on s’est reconnu et on a décerné un paquet de Schokobons au meilleur #PODM de la soirée.

Esprit fermé, manque de leadership, égoïsme, inefficacité ou négiociation malsaine… voici notre liste de #PODM.

Aujourd’hui, lors d’un Backlog Grooming, le Product Owner s’accroche à son choix fonctionnel malgré les énormes risques et obstacles techniques. Son argument : “Ben la technique, ça ne me concerne pas…”. #PODM.

Aujourd’hui, en Sprint Planning, le PO se plaint : << Le développement de cette fonctionnalité sur iOS engendre 5 points de complexité alors qu’elle en fait 13 sur Android, c’est n’importe quoi ! >> #PODM

Aujourd’hui, étant donné les limites techniques, la faisabilité d’une des stories demandée par le PO était impossible. La réponse implacable à cette contrainte ? “Oui mais sur [un concurrent] ils le font”. #PODM

Aujourd’hui, après un long débat, notre Product Owner a terminé la conversation par la remarque la plus constructive qui soit : “De toute façon, vous devrez le faire comme ça, vous n’êtes tous que des pions”. #PODM

Aujourd’hui, mon PO a lui même macro-estimé le backlog de la prochaine release: “Pour pouvoir montrer [au chef] que ça tient dans le planning”. #PODM

Aujourd’hui, lors de la démo et devant nos hiérarchies, le Product Owner a nié ses PROPRES décisions en accusant “une mauvaise surprise côté dev”. #PODM

Aujourd’hui, nous développons encore une fonctionnalité inutilisée et inutile (selon le PO aussi) demandée par le chef d’un autre département, parce que : “Je n’osais pas refuser sur le moment”. #PODM

Aujourd’hui, nous n’avons pas de vision produit. Le PO nous demande ”Faites des efforts pour garantir la date de release, c’est la seule chose qui compte”. #PODM

Aujourd’hui, les développeurs et les graphistes ont un désaccord sur la meilleure solution de Design sur Android. Le PO est intervenu pour arbitrer ”Démerdez vous, j’en ai marre”. #PODM

Aujourd’hui, ma PO a trouvé une technique verbale pour modifier régulièrement le sprint : Commencer toutes ses phrases par “C’est juste un petit truc…” #PODM

Aujourd’hui, je suis UI Designer. Aujourd’hui, notre PO nous demande des créations graphiques, “c’est les derniers pour ce ticket et après c’est fini”. Sauf que ça n’en finit jamais… #PODM

Quelle est la priorité de ce ticket ? “C’est urgent !”
Et de celui-ci ? “C’est urgent !!”
De [n’importe quel autre] ? “C’est urgent !!!”
Lequel est prioritaire ? “C’est urgent !!!!”
#PODM

Aujourd’hui, il y a bien plus souvent d’urgences qui viennent parasiter le sprint que de contenu prêt pour le Sprint Planning. Notre Product Owner confond “en mode agile” et “à l’arrache”. #PODM

Aujourd’hui, le Product Owner débarque en urgence : “Y’a plus rien qui marche !”
Je lui demande des détails pour investiguer : “Ben y’a tout qui bug !” #PODM

Aujourd’hui, je suis responsable d’une équipe de Product Owners. Aujourd’hui, je demande à mon PO l’objectif du prochain sprint “Aucun objectif en particulier, on va juste occuper les dev”. #PODM

La soirée s’est poursuivie par une session d’Open Space (30 min) suivant les thématiques abordées précédemment (esprit fermé(1), manque de leadership(2), égoïsme(3), inefficacité(4) ou négiociation malsaine(5)). Sur le thème qui les intéressait, les participants ont échangé en groupes sur leur vécu et leurs bonnes pratiques. Ils ont ensuite restitué au groupe les points où la discussion convergeait, leurs points de désaccord et des idées d’approfondissement du sujet.

Décalé et ludique, ce #Meetup a pris une forme différente des deux précédents en étant encore plus participatif. On en retiendra quelques points clés : esprit d’équipe, investissement, rigueur, écoute… quelques bières et beaucop de fun !

PODM_Lucyinthescrum© Romain Calix’s photo 

 

En savoir plus sur SchoolOfPO
Découvrir les prochains #Meetups
E
n savoir plus sur Alexandre Quach (ici ou ici)
En savoir plus sur Thomas Benard (ici)

Savoir lâcher prise

Comment être un Product Owner très impliqué, qui tire son équipe vers le haut, la fait adhérer aux valeurs de son produit, l’encourage et la motive pour atteindre ensemble un objectif commun ?
Et comment être à la fois un Product Owner capable de lâcher prise parfois et d’accepter que l’équipe “se plante” une bonne fois pour toutes, pour mieux progresser ?

F.A.I.L = First Attempt In Learning ?
Vraiment ? Savoir qu’on va potentiellement se planter et y aller quand même ? Et à fond en plus ?

Mon équipe et moi rencontrons des difficultés au quotidien. C’est un euphémisme.
Dépendances applicatives, dette technique, plateformes instables qui ne sont pas à l’image de la production, aucun test automatisé, manque d’autonomie sur la gestion des déploiements… La liste est longue. Et pourtant nous sommes aujourd’hui capables de réaliser un déploiement en production toutes les deux semaines pour apporter de la valeurs aux utilisateurs en continu.
Mais non sans y laisser quelques plumes.
Et si c’est en étant en difficulté qu’on apprend le plus, alors nous serons probablement des petits génies d’ici quelques semaines… (joking). La bonne ambiance dans l’équipe nous permet d’affronter ces difficultés. Malgré tout, je commence à sentir une démotivation progressive et je ne sais pas toujours comment y remédier.

“Arrête de vouloir jouer à Superman” me dit-on.
“Arrête de vouloir être parfaite” me dit Pablo.
“Tout ne dépend pas de toi : tu ne peux pas construire une tour avec un tournevis !”

“On ne demande pas à Usain Bolt d’être à sa vitesse maximale sur 100 km : en Scrum c’est pareil. Il faut forcément des temps morts.”

On m’a dit un jour que la principale différence entre un Chef de Projet “traditionnel” et un Product Owner résidait dans l’implication. Le Chef de Projet livre une expression de besoin, suit les développements de loin, effectue quelques tests et valide le bon fonctionnement. Si cela ne fonctionne pas, ce sera… “la faute des développeurs“. 😉
Le Product Owner s’implique réellement, de la définition du besoin à la supervision en production. Il y met ses tripes. C’est lui qui donne le rythme à son équipe, définit le timing et sera responsable de la qualité du produit. Comment, en ayant participé à l’évolution des conceptions et des développements du matin au soir, pourrait-il ne pas être impliqué à 100% ?

En étant un malin stratège, sans doute. En faisant des choix et des paris. En acceptant que tout ne sera jamais parfait. Parce que si on attend la perfection on ne fera rien. Et au delà de la priorisation du backlog, en faisant du tri dans sa propre to-do-list.

Alors non : on ne va pas complètement lâcher prise. On va faire notre maximum. Tout donner. Et accepter que si on se plante malgré tout, et bien on aura tout tenté.
Et on se dira qu’on fera mieux la prochaine fois…

first-attempt-in-learning

My very first #Meetup

C’est extrêmement bien entourée que j’ai animé mon tout premier Meet-up le mois dernier, aux côtés de Pablo et Dragos dans le cadre de @SchoolOfPO. Intimidée mais très motivée, j’étais curieuse d’éprouver ma capacité à prendre la parole en public. “Les personnes qui vont venir seront sans doute très expérimentées, comment vais-je réussir à capter leur attention ?” – “Et si ce que je dis n’est pas intéressant ?” – “Je vais oublier mon texte, c’est sûr… mais si je l’apprend par cœur, j’aurais l’air de réciter une poésie… 😉 ?”

Passée la timidité des premiers instants, j’ai vraiment adoré l’expérience et le challenge.

Dès le début, j’ai été agréablement surprise de découvrir que j’avais une vision trop étriquée des Meet-ups en général. Un meet-up n’est pas forcément l’intervention de quelqu’un qui parle pendant une heure sur un sujet donné, pendant que les autres l’écoutent. Les deux derniers Meet-ups de SchoolOfPO étaient extrêmement interactifs, y compris pendant l’introduction et la partie “Talk”.
Ensuite, le format intègre deux sessions de 25 minutes sur le format “Open Space“. Les participants se répartissent selon plusieurs thèmes d’échanges, issus de la présentation. A la fin, ils restituent une synthèse de ce qui en ressort et de ce qu’ils ont appris.

En plus du sujet en lui-même, j’ai été particulièrement intéressée par les rencontres et la richesse des échanges qui sont sortis de cette soirée. La “tête dans le guidon” au quotidien, il est parfois difficile de s’en extraire pour réellement prendre du recul sur ses actions ou trouver des pistes d’optimisations.
SchoolOfPO, c’est un concentré de personnes d’horizons très différents, rassemblées autour rôle du Product Owner et ayant une volonté commune de partage et d’amélioration.


Cool Stuff :
 What is a meet-up and why should I care ? – Oleg Podsechin
Bibliothèque du #Meetup SchoolofPo :
Le Pouvoir de dire Non

lucie_lesage

lucie-lesage_2

life-is-about-the-people-you-meet

L’école des Product Owners

Le rôle du Product Owner ne s’apprend pas à l’école, ou si peu. Alors à quoi sert-il ? Quelle posture doit-il adopter ? Quelles sont ses interactions avec l’équipe de développement ? Avec les parties prenantes de l’entreprise ? Quels sont ses outils et ses facteurs clés de succès ? Que fait-il au quotidien ? Quelles sont ses priorités ? A quoi reconnaît-on un “bon” Product Owner ? Peut-il y avoir des “mauvais” Product Owners ? Comment peut-il s’améliorer ?

Il y a quelques semaines, Pablo nous a parlé d’une idée : il voulait créer une “School Of PO”.
Une belle opportunité, au vu de ces questions autour desquelles nous aimerions partager des réponses.
D’abord parce que les entreprises oublient parfois de prioriser la concrétisation de leurs idées par la valeur ajoutée apportée aux utilisateurs. D’où l’importance pour elles de s’entourer de Product Owners capables de les remettre dans le droit chemin.
Ensuite, parce que le besoin d’échange et de partage autour du Product Ownership est réel.
Et enfin, parce qu’on aime bien faire de belles rencontres !

Au fil d’un brainstorming avec les beNexters, le projet d’une série de Meetups était né : 30 minutes de présentation, un Open-Space pour ouvrir la discussion et s’enrichir des avis de tous les participants, et bien sûr une clôture de la soirée avec pizzas/bières.

Le premier Meetup de “School of PO” aura lieu le 16 novembre dans les locaux de beNext.
Pablo et Dragos relèveront le défi du PechaKucha pour nous aider à répondre à la question : “A quoi sert un Product Owner ?”.

Et parce que nous restons dans une démarche d’optimisation continue, n’hésitez pas à nous donner votre avis !

 

✎ Plus d’informations sur InfoQ, SchoolOfPO ou Twitter !
Contactez-nous

schoolofpo

L’importance du Backlog Grooming

Lorsque j’ai intégré un nouveau projet il y a un mois, j’ai découvert que l’équipe que je rejoignais ne connaissait pas et donc n’organisait pas de “Backlog Grooming”.

Le premier Sprint Planning auquel j’ai participé a duré 3 heures. C’est long. C’est barbant. Les participants se sont rapidement désintéréssés. L’atelier a rapidement empiété sur la pause déjeuner. Au secours.
En sortant de la salle (enfin!), je leur ai demandé “mais comment vous faîtes pour supporter ça ?”. L’un d’entre eux m’a répondu “et encore, avant ça nous prenait la journée entière…”. #Help!

Au delà d’être une corvée pour tout le monde, un Sprint Planning où les débats sont sans fin entraîne le risque d’embarquer dans le sprint des User Stories qui ne sont pas prêtes. Ou de passer à côté de certaines subtilités. Un autre exemple : je me suis rendue compte que l’équipe ne rédigeait pas de scénarios de tests pour chaque Story. Une fois la fonctionnalité développée, le testeur demandait donc au développeur “comment tester” avant de suivre ses consignes à la lettre et passer la tâche en “Done”. La probabilité de passer à côté de certains cas fonctionnels et d’engendrer des régressions était donc décuplée.

Je leur ai donc proposé de mettre en place 2 ateliers de Backlog Grooming par sprint, pour partager les sujets du backlog, échanger sur les prochaines fonctionnalités à développer, découper les User Stories, et surtout, en finir avec les discussions interminables au moment de démarrer un nouveau sprint.

Oui, mais si on fait 2 backlog grooming d’une heure et un sprint planning d’environ une heure et demie, au final ça revient au même qu’un sprint planning de 3 heures ?”. Non ! Parce qu’on échelonne les discussions sur plusieurs jours. On prend le temps de laisser décanter nos réflexions. Et on peut aller chercher des informations supplémentaires auprès des interlocuteurs qui ne participent pas à nos cérémonies, pour affiner les sujets. Bref, on gagne en qualité.

La mise en place d’un Backlog grooming récurrent, d’une heure pas plus, c’est la garantie de démarrer un nouveau sprint avec des User Stories qui sont d’avantage formalisées et partagées. L’ensemble des membres de l’équipe sait concrètement ce qu’il faudra faire pour chaque Story. Les estimations de chaque tâche sont affinées. Et le risque de surcharger le sprint parce que tous les impacts n’ont pas été étudiés est diminué.

Quel résultat ?
4 ou 5 Backlog Grooming et 2 sprints de développements plus tard, l’équipe est satisfaite de ce nouveau mode de fonctionnement. Le bénéfice de cet atelier est ressorti plusieurs fois comme un point positif au moment de la rétrospective.
Et bien que le fruit de ces ateliers n’ait pas engendré une amélioration nette de la vélocité de l’équipe, nous constatons clairement d’avantage de sérénité dans le déroulement des sprints.
A long terme, l’équipe pourra également avoir une meilleure visibilité du Backlog du Produit, notamment sur les sujets à venir dans 2 ou 3 mois
Et surtout, l’équipe ne sacrifie plus ses pauses déjeuner !

D’autres articles utiles sur le sujet :
● Pour que les Backlog Grooming ne soient plus une corvée ! ▫TheObserverself
● Backlog Refinement, la clé pour une Agilité réussie ▫QualityStreet