Auteur: Roman Pichler

Année de parution: 2010

Éditeur: Addison-Wesley

Mes notes manuscrites Acheter ce livre

À Alloprof, je suis ScrumMaster et j’accompagne trois équipes de développement. Une bonne partie du travail de « scrum master » consiste à coacher les gens autour de nous, ce qui inclut les Product Owners qui sont responsables du backlog de produit de l’équipe.

Un gestionnaire en qui j’ai confiance m’a recommandé de lire ce livre et de suivre une formation de Product Owner pour mieux coacher nos PO. La formation ne m’a pas appris grand-chose (PSPO 1 ressemble trop à PSM 1), mais le livre, lui, m’a fait réaliser que mes équipes avaient certains antipatterns qui valaient la peine d’être démêlés. À mon avis, ce qui a le plus besoin d’attention dans mes équipes, c’est tout ce qui entoure la revue de sprint. Souvent, on n’en faisait pas, et quand on en faisait une, c’était des diapos devant plus de 20 personnes. On ne savait pas qui étaient nos parties prenantes, ce qui rendait très difficile de trouver le bon angle pour présenter le travail de l’équipe.

C’est heureusement un livre très court, d’environ 120 pages. Je l’ai lu de mai à novembre, entre d’autres livres qui me semblaient plus urgents. Je le trouve bon et, même s’il a été écrit il y a plus de 16 ans, ce qui est une éternité en tech (c’était avant l’IA… c’était avant la COVID…), les conseils tiennent toujours la route.

Le verdict de Félix Thumb up

Sans rapport avec cette critique, j’aimerais souligner que ça fait un bon moment que je n’ai pas écrit en anglais sur ce blogue. Oui, tu lis ce texte en français, mais à part quelques phrases comme celle-ci parsemées ici et là, ce texte a été traduit de l’anglais vers le français par un IA. Ce n’est pas peut-être pas sexy comme révélation, mais la transparence, c’est une valeur qui me tient beaucoup à cœur.

Je voulais à la fois mettre en valeur le français, ma langue maternelle, et profiter de l’occasion pour le pratiquer, puisque le contrat d’édition que j’ai obtenu pour Apprendre sans anxiété était pour un manuscrit en français. Je n’abandonne pas pour autant l’espoir d’être publié en anglais, et pour ça, je dois m’assurer que mon anglais ne rouille pas.

Quelqu’un en qui j’ai confiance m’a dit que c’était absurde, à l’ère de l’IA, de limiter un blogue à une seule langue. Je dois admettre qu’il a raison. Il y a des sujets pour lesquels je suis plus à l’aise d’écrire dans une langue précise. Et puis, comme je parle couramment le français et l’anglais, n’ai-je pas le privilège de choisir?

Je ne voulais toutefois pas que ça nuise à l’expérience des lecteurs. Certaines personnes qui suivent mon travail ne parlent qu’anglais, et je ne veux pas les perdre. Et l’anglais est, après tout, la langue du monde. Alors, à partir d’aujourd’hui, j’écrirai dans la langue de mon choix, tout en m’assurant de toujours (toujours!) traduire mon travail pour qu’il reste accessible à tous. C’est un peu plus de travail pour moi, mais je peux l’assumer. En échange, j’espère que ça ne te dérange pas si j’utilise parfois l’IA pour traduire mes textes sur ce site. En revanche, pour mes ouvrages publiés, j’ai fait appel à de l’aide professionnelle pour les traductions et je compte continuer ainsi. Ça ne me dérange pas de donner un peu de liberté à l’IA sur ce blogue, mais quand les mots se retrouvent sur papier, c’est une tout autre histoire.

Tout ça pour dire que je digère encore le scandale Thélyson Orélien et que j’essaie de trouver la bonne voie à suivre. J’ai déjà eu mes propres rencontres rapprochées avec l’écriture par IA et je ne veux pas prendre de risques inutiles. Et puis, j’aime écrire!

💡 Réflexions et nouvelles idées

  • (p. 102) La préparation de la réunion de [revue de sprint] devrait être réduite au minimum. La réunion doit rester sobre, et non être un spectacle. Les équipes devraient s’abstenir de faire une présentation formelle et éviter les diapos. Le but de la réunion n’est pas d’impressionner ni de susciter l’enthousiasme, mais d’offrir de la transparence, et d’inspecter et d’adapter le produit.

Nous l’avons fait au travail. Nous avons préparé un ordre du jour dans une page Confluence, sans diapos. Comme c’était une expérience, une seule partie prenante était invitée. Les devs ont présenté leur démo eux-mêmes. Je l’ai trouvé très rafraîchissant, et ça m’a semblé plus transparent que des démos avec diapos. On n’a eu l’occasion de le faire qu’une seule fois pour l’instant, alors j’ai hâte de voir dans 2-3 sprints à quoi ressemblent nos revues de sprint, qui y est invité, etc.

  • (p. 103) Demander aux parties prenantes leur rétroaction sur l’incrément de produit:
    • Aiment-elles ce qu’elles voient?
    • Comment faut-il adapter le produit pour qu’il soit un succès?
    • La vision est-elle toujours valide?
    • Manque-t-il des fonctionnalités, ou y en a-t-il trop?
    • Une fonctionnalité est-elle mal implémentée?
    • Faut-il ajuster l’apparence? Si oui, pourquoi?

Ce sont des questions en or que j’ai hâte d’essayer.

  • (p. 8) Les product owners devraient passer au moins une heure par jour avec leur équipe dans la salle de l’équipe.

    • 💭 À moins d’utiliser un outil comme Gather, c’est beaucoup demander en 2026.

  • (p. 10) Puisque les rôles de product owner et de ScrumMaster sont conçus pour se faire contrepoids, jouer les deux est accablant et insoutenable. Une même personne ne devrait jamais être à la fois ScrumMaster et PO.

    • 💭 Est-ce réaliste en mode start-up? Quand je travaillais chez Contxtful, on voulait utiliser Scrum, mais on était étirés au maximum. Notre CTO était aussi notre PO et ScrumMaster. Je sais que ça ne cadre pas avec la théorie, mais je me demande comment on aurait pu faire autrement.

  • (p. 50) Des activités de raffinement ont aussi lieu à la réunion de revue de sprint, quand l’équipe Scrum et les parties prenantes discutent de la suite; de nouveaux éléments du backlog sont identifiés et d’anciens sont retirés.

    • 💭 Je n’ai jamais fait ça. À essayer.

  • (p. 112) Conseils aux nouveaux PO, de Lyssa Adkins

⭐ Citations étoiles

Chapitre 1: Comprendre le rôle de Product Owner

  • (p. 5) Si tu donnes une idée médiocre à une équipe formidable, elle la réparera, ou la jettera et trouvera quelque chose qui fonctionne.

Chapitre 2: Envisager le produit

  • (p. 32) « Fais moins que tes concurrents pour les battre… Prends ce que tu penses que ton produit devrait être et coupe-le de moitié… Commence avec une app légère et intelligente et laisse-la gagner en traction. Ensuite, tu pourras commencer à ajouter à la base solide que tu as bâtie. » —37signals
  • (p. 32) Les meilleurs designs n’incluent que les fonctionnalités dont les gens ont besoin pour atteindre leurs objectifs.
  • (p. 40) Avec le temps, les éléments de « plaisir » (delighters) finiront par devenir des fonctions de performance, et les fonctions de performance deviendront des éléments de base.
  • (p. 41) Élaborer une feuille de route de produit sur cinq ans avant qu’une seule version soit déployée apporte peu d’avantages; ça peint un rêve plutôt que d’anticiper la réalité. […] Concentre-toi sur les 6 à 12 prochains mois.
  • (p. 43) Les variantes de produit comportent le danger d’implémenter les mêmes fonctionnalités encore et encore, ce qui entraîne des coûts élevés de développement et de maintenance.
  • (p. 45) Aussi excitants que puissent être [les efforts de développement big-bang] (ils sont comme ces longues passes de touché qui rendent les partisans fous. Elles sont bien plus excitantes que le jeu au sol qui avance sur le terrain 10 verges à la fois), [ils] ont un côté sombre: ils consomment beaucoup de temps et d’argent, et présentent un risque élevé d’échec.

Chapitre 3: Travailler avec le backlog de produit

  • (p. 50) Des activités de raffinement ont aussi lieu à la réunion de revue de sprint, quand l’équipe Scrum et les parties prenantes discutent de la suite; de nouveaux éléments du backlog sont identifiés et d’anciens sont retirés.
  • (p. 50) Un backlog bien raffiné est un prérequis à une réunion de planification de sprint réussie.
  • (p. 53) Tu ne devrais pas te sentir obligé de décrire chaque élément du backlog de produit sous forme de récit utilisateur. Par exemple, les exigences d’utilisabilité sont souvent mieux capturées avec des prototypes ou des esquisses. Voici des exemples d’artéfacts utiles:
    • sommaire des différents rôles d’utilisateurs
    • séquences de récits utilisateurs pour modéliser des flux de travail
    • diagrammes pour illustrer les règles d’affaires
    • chiffriers pour capturer des calculs complexes
    • esquisses d’interface utilisateur
    • storyboards
    • diagrammes de navigation de l’interface
    • prototypes d’interface
  • (p. 53) ⭐ Un élément du [backlog de produit] a de la valeur s’il est nécessaire pour donner vie au produit. Si ce n’est pas le cas, l’élément est non pertinent; il est exclu de la version actuelle ou de la version du produit.
  • (p. 57) Parce que le risque et l’incertitude influencent le succès du produit, les éléments incertains et risqués devraient être de haute priorité. Ça accélère la création de nouvelles connaissances, chasse l’incertitude et réduit le risque.
  • (p. 67) Seuls les membres de l’équipe qui créent les incréments de produit devraient être autorisés à estimer les éléments du backlog de produit.
  • (p. 71) Un backlog de produit trop détaillé et trop exhaustif ne favorise pas l’émergence des exigences. […] Il fige très tôt toutes les décisions sur la façon de répondre aux besoins des clients.
  • (p. 73) « La plupart des réunions de planification de sprint auxquelles j’ai assisté étaient amusantes. Celles qui ne l’étaient pas impliquaient un backlog de produit mal raffiné.
  • (p. 73) Si le backlog de produit n’est pas correctement raffiné, le prochain sprint ne devrait pas démarrer. Il devrait être reporté jusqu’à ce que le backlog soit préparé.

Chapitre 4: Planifier les versions

  • (p. 76) Fixer le temps, le budget et les fonctionnalités n’est pas possible; au moins un des trois leviers doit servir de soupape. [Recommandation: fixer le temps et laisser les fonctionnalités flexibles.]
  • (p. 78) Évite les projets à prix fixe et à portée fixe. Si ce n’est pas possible, essaie ceci: scinde un contrat à prix fixe en deux parties et réalise deux projets consécutifs.
  • (p. 79) Le product owner ne devrait pas encourager l’équipe à faire des compromis sur la qualité du logiciel et ne devrait jamais accepter des résultats qui ne respectent pas les critères de « terminé ».
  • (p. 80) La stratégie de Google de livrer tôt et souvent est aussi une stratégie de marketing brillante et inventive: elle dissuade les concurrents potentiels, hausse le coût d’entrée sur le marché et garde les utilisateurs dans la sphère d’influence de Google.
  • (p. 80) Les livraisons fréquentes ont un prix: le logiciel doit être de haute qualité, et le produit doit être facile à obtenir et à installer.
  • (p. 80) « N’abandonne pas, même si tu dois changer la solution technique pour y arriver. Garde les yeux sur les résultats, pas sur les technologies. » —(Gilb, 1988, 336)
  • (p. 96) Sors-le. Ensuite, fais-le bien.

Chapitre 5: Collaborer dans les réunions de sprint

  • (p. 99) La fiabilité vaut plus que la fausse ambition; c’est le prérequis pour faire des prévisions réalistes.
  • (p. 100) ⭐ Si tu t’inquiètes, [par ex.] de l’atteinte de l’objectif du sprint, […] tu peux dire: « J’ai remarqué que le burndown du sprint montre beaucoup de travail restant. Est-ce que ça te préoccupe? »
  • (p. 101) « Les problèmes sont des trésors. Ils offrent une occasion d’apprendre et de s’améliorer. » —Pascal Dennis, 2006.
  • (p. 102) ⭐ La préparation de la réunion de [revue de sprint] devrait être réduite au minimum. La réunion doit rester sobre, et non être un spectacle. Les équipes devraient s’abstenir de faire une présentation formelle et éviter les diapos. Le but de la réunion n’est pas d’impressionner ni de susciter l’enthousiasme, mais d’offrir de la transparence, et d’inspecter et d’adapter le produit.
  • (p. 104) La réflexion est la première étape vers l’amélioration. —Proverbe allemand
  • (p. 105) Pour s’améliorer de façon soutenue, les membres de l’équipe doivent reconnaître que même les meilleures équipes peuvent s’améliorer.

Chapitre 6: Faire la transition vers le rôle de Product Owner

  • (p. 113) Sois patient, mais jamais complaisant.