Mes histoires sont trop courtes … |

Je me retrouve souvent du côté des agilistes de la vieille école qui croient que les équipes (et leurs chefs de produit) doivent continuellement expérimenter leur chemin vers de bons processus et la collaboration, plutôt que les gens des «meilleures pratiques» qui croient qu’il existe une manière fondamentalement correcte de faire les choses.. Je prends la position que les impératifs catégoriques sont toujours faux.

Voici un exemple à suivre…

«Mon équipe de développement me dit que mes histoires d’utilisateurs ont besoin de plus de détails.»

J’entends cela de la part des chefs de produit presque chaque semaine, souvent lorsqu’ils recherchent un autre modèle ou flux de processus utilisateur parfait. Soupir. Cela semble être une occasion manquée pour la constitution d’équipe, la collaboration et le travail réduction plutôt qu’un autre fardeau pour les chefs de produit surmenés. Surtout quand ces mêmes chefs de produit assurent le suivi “Maintenant, mon équipe de développement me dit que mes histoires d’utilisateurs sont trop normatives, trop axées sur le COMMENT, et ne leur donnent pas la possibilité de résoudre de manière créative à partir d’une bonne déclaration WHAT.” Hein? Que se passe-t-il vraiment?

Une généralisation extrêmement injuste

Je trouve que la plupart des développeurs aiment parler en termes absolus et généraux. (“Scrum est meilleur que Kanban.” “Slack est le cadeau de Dieu.” “Non, Slack est un épouvantable drain sur notre attention.” “Les vendeurs n’écoutent pas.” “Les cadres ne se soucient que des revenus à court terme.” ” Nous ne devrions embaucher que des développeurs avec des diplômes CS / EE provenant d’universités bien connues. »« Non, les meilleurs développeurs scrappy sont tous autodidactes. ») Les développeurs apprécient les joutes intellectuelles du débat technique, prouvant qui est «plus intelligent» ou plus rapide mentalement *. Je ne suis donc pas surpris quand un membre de l’équipe combine l’absolutisme et le biais de récence, convertissant “Cette histoire d’utilisateur particulière est maigre” à un plus universel “Toutes nos histoires ont besoin de plus de détails.”

Mais en tant que chefs de produit, nous devons entendre ce que les gens disent, puis creuser agressivement les problèmes sous-jacents. Nous écoutons avec scepticisme lorsqu’un client payant nous dit comment réparer quelque chose. Nous ne transcrivons pas les demandes textuellement et les remettons à notre équipe de développement. Au lieu de cela, nous déballons et questionnons et validons et recherchons des modèles à travers la base d’utilisateurs…

Donc “Mon équipe de développement me dit que mes histoires d’utilisateurs ont besoin de plus de détails” mérite la même enquête réfléchie. Toutes les histoires? Qu’est-ce qui manque? Cela mène-t-il à un mauvais logiciel ou à une conversation supplémentaire? Les user stories sont-elles le bon moyen de corriger ce qui ne va pas? Comment comprenons-nous ce commentaire si (la semaine dernière) nous avons entendu le contraire? Cela pourrait être un véritable casse-tête à l’échelle de l’équipe ou une grogne générale ou l’hypothèse d’un développeur selon laquelle le seul travail d’un chef de produit est d’écrire des histoires d’utilisateurs parfaites.

Et remarquez que je ne peux pas résoudre ce problème dans ma tête: cela nécessite de parler avec mon équipe, d’extraire de véritables opinions et de disséquer collectivement ces opinions. Appliquer une bonne analyse de produit en interne. Se mettre d’accord sur les prochaines étapes.

Décompressons cela en équipe

Si cela ne s’est pas déjà fait naturellement dans nos rétrospectives **, je pourrais brièvement en parler avec l’équipe à la fin du standup de demain: “J’ai entendu certaines inquiétudes concernant le manque de détails ou d’exhaustivité de nos user stories. Levée de main rapide pour accord? Si nous avons besoin que toute l’équipe passe 45 minutes à discuter des approches et des améliorations de processus, qui y voit un bon investissement en temps? »

C’est peut-être juste une grogne, et personne ne s’en soucie vraiment. La plupart d’une heure sonne beaucoup, même si nous gaspillons cela chaque jour en marchant vers Philz pour le café design. Mais si c’est vraiment irritant, l’équipe doit être prête à prendre le temps.

En supposant que nous nous sommes mis d’accord sur une réunion, redéfinissons également le problème pour qu’il soit plus spécifique, plus traitable, moins universel: “J’ai entendu dire que mes histoires étaient trop longues et trop court. Il est possible que les deux soient vraies pour différents types d’histoires. Examinons 8 ou 10 histoires différentes, obtenez vos votes rapides sur celles qui sont trop longues ou trop courtes, et pourquoi. Nous pourrions remarquer quelques modèles sur QUELS types d’histoires sont dans chaque pile. Ou comment améliorer le cycle de l’histoire. “

Cela donne à l’équipe un cadre pour des discussions plus constructives et une empathie partagée lorsque nous inspectons des exemples réels. Nous combattons le biais de récence en examinant attentivement les données. La dernière fois que j’ai exécuté ce petit exercice, nous avons collectivement identifié quelques types d’histoires différentes, chacune nécessitant son propre traitement:

[1] Très technique, peu de valeur de gestion de produit

Il s’avère qu’une grande partie de mes histoires étaient entièrement évidentes, lourdes à mettre en œuvre, et une seule phrase aurait suffi. («Autoriser les utilisateurs à entrer un numéro de téléphone avec ou sans tirets», «planifier la réindexation de la base de données pour les heures non ouvrées», «tester et prendre en charge iOS 12.3», «zone de texte de forme libre dans le menu d’aide».)

J’énervais involontairement l’équipe avec des pages de commentaires, des retraitements évidents de la valeur commerciale et des suggestions techniques naïves. Mon public (c’est-à-dire l’équipe de développement) ne voulait que quelques choses: tester les limites et les dépendances. Je pourrais donc réduire leur frustration tout en faisant moins de travail – si nous pouvions trier les bonnes histoires dans cette catégorie. Gain de temps, pression artérielle réduite.

[2] Interaction utilisateur intensive, conception de simulations, workflows

Notre produit particulier a eu des interactions complexes avec les utilisateurs, et des changements occasionnels dans l’expérience utilisateur ont souvent eu de mauvais effets secondaires. Mes histoires d’utilisateurs ne comportaient pas suffisamment de détails, en particulier concernant les cas marginaux et les erreurs et le séquencement des utilisateurs. («Nous devons capturer le code postal avant de pouvoir calculer les frais d’expédition, mais ce nouveau flux de travail saute cela pour les nouvelles commandes.»)

Nous avons identifié que mes histoires d’utilisateurs gênaient: le travail de conception nuancé de chaussures dans les modèles d’histoire et la suppression du contexte important.

Nous avons convenu de mener une expérience pendant quelques semaines: attacher des maquettes de conception complètes à des histoires succinctes et planifier une visite virtuelle du tableau blanc pour notre concepteur, les deux développeurs les plus impliqués dans ce flux de travail et moi-même (pour prendre des mesures). Si cela ne se passait pas bien, nous essayerions autre chose, car les résultats comptent plus que les formalités.

[3] Expériences de validation

Toute l’équipe était ravie d’interagir avec de vrais utilisateurs, d’effectuer des expériences légères d’améliorations majeures et de fouiller dans les données d’activité. L’apprentissage collaboratif et pratique a ravivé notre sentiment de mission et d’importance. (Pas de surprise: c’est ce qui apporte joie et sens à ce que nous faisons.) L’équipe débordait d’idées, frustrée par le manque de discussions énergiques et d’engagement émotionnel, se sentant reléguée à COMMENT quand elle avait faim de QUOI et POURQUOI.

Et ils ont eu d’énormes connaissances sur une bonne expérimentation, une fois que tout le monde a été inclus. (“Voici une autre possibilité pour expliquer pourquoi les prospects abandonnent notre entonnoir à l’étape 3b.” “Nous obtenons déjà des données de réponse des campagnes par e-mail. Pouvons-nous l’utiliser au lieu d’ajouter une nouvelle instrumentation de page de destination?” ” il faudra des mois pour rassembler des données statistiquement valides. Essayons plutôt… “) Des validations plus intelligentes, un contexte partagé et plus de passion pour le travail. De plus, cela a aidé que nous appelions ces «sessions de conception d’expériences» au lieu de «réunions» parce que tout le monde déteste les réunions.

[4] Histoires de Boucle d’or

Certaines de mes histoires n’étaient ni trop longues, ni trop courtes, avec des détails appropriés et un contenu utile. JUSTE À DROITE. Les chefs de produit ne sont pas entièrement sans ego, donc je me sentais bien pour la pêche occasionnelle “oui, celui-là était parfait, nous ne changerions rien.” S’il n’est pas cassé, ne le réparez pas.

Votre équipe trouverait (bien sûr) d’autres problèmes, catégories et réactions. Mais notez qu’un format unique, «canonique», obligatoire, pleinement réalisé, de «meilleures pratiques», nous fera échouer dans des directions différentes en fonction du problème en question. Et ajoutera des dizaines d’heures à notre semaine de gestion de produits – créant du contenu inutile que nos équipes peuvent ignorer ou devoir parcourir – au lieu de concentrer notre temps limité sur ce qui génère de vrais résultats de produit.

Je m’appuie donc généralement sur les grands principes agiles qui commencent par «valoriser les individus et les interactions par rapport aux processus et aux outils” avant d’accepter des affirmations procédurales. Les standups sont précieux si nous les gérons bien et savons Pourquoi ils ajoutent de la valeur, surtout si nous voulons expérimenter des alternatives. L’estimation est essentielle pour rester en affaires, mais il existe de nombreuses techniques au-delà de Planning Poker. (En voici un de Ron Lichty que j’aime.) Scrum est bon sauf quand il devient dogmatique ou inflexible ou auto-important.

Je suis profondément sceptique quant aux meilleures pratiques et aux cadres fournis par les consultants / formateurs et à un point de départ unique. Construire un excellent logiciel est beaucoup plus comme écrire un roman à succès (ou une chanson à succès) que creuser un fossé, nous devons donc mobiliser tous les talents de toutes nos équipes pour créer de l’éclat.

Octet sonore

Nous apportons notre œil critique et notre tempérament de produit analytique aux exigences des clients. Ce que les utilisateurs disent vouloir n’est pas toujours ce qu’ils veulent ou ce qui est bon pour eux. Nous devrions apporter la même perspective aux problèmes au niveau de l’équipe: que se passe-t-il vraiment? Comment pouvons-nous impliquer l’équipe en collaboration? Pouvons-nous essayer des expériences peu coûteuses plutôt que de discuter de qui a raison?

* D’après mon échantillonnage limité, je vois moins de cette dynamique dans des équipes plus diversifiées, en particulier là où les femmes et les autres personnes sous-représentées sentent qu’elles appartiennent, sont respectées et participent activement aux conversations. En tant que chefs de produit, nous pouvons soigneusement modérer les discussions afin que chaque observation importante soit entendue. Voir d’autres excellentes réflexions sur l’inclusion chez Better Allies.

** Les rétrospectives peuvent être le rituel agile le plus important, et elles dépendent de la confiance. Chaque semaine (ou deux), toute l’équipe devrait partager ce qui fonctionne – et ce qui ne fonctionne pas – en supposant généreusement que chacun fait de son mieux. “Que pouvons-nous essayer la semaine prochaine?” Les organisations et les processus sont les coupables habituels. Voici la référence classique sur les rétrospectives.

Crédits photo: PostIt by AbsolutVision, livre latin de Mark Rasmuson, workflow de Campaign Creators.